Je demande à mon lectorat de m’excuser pour ce post, qui ne concerne pas directement le développement, mais qui est un retour d’expérience de ma récente installation d’Ubuntu sur mon poste client principal. Je vulgarise volontairement beaucoup de choses, et j’essaye de m’éloigner -une fois n’est pas coutume- de ma vision habituelle de professionnel pour ne parler que des aspects “client”. Je travaille habituellement sous Windows. Je ne cherche pas à dire lequel système est le meilleur, je ne bomberai pas le torse en disant fièrement que je suis sous Ubuntu. Je livre seulement mes premières impressions après la bascule.

D’abord, pourquoi Ubuntu ?

Hébergeant depuis très longtemps l’ensemble de mes sites sous Linux Debian, j’ai appris il y a peu qu’il existait une Ubuntu en version serveur. Me demandant si la migration de ma Debian habituelle à Ubuntu Server pouvait m’apporter quelque chose, j’ai posé la question sur les forums officiels français Ubuntu. Et là, bon accueil, réponse rapide et en bon français, ça commençait bien. Et loin du prosélytisme Apple (si, si.), on m’a clairement dit que si je m’en sortais bien sous Debian, je ne gagnerais pas grand-chose, Ubuntu étant surtout pensée pour être utilisée en poste client (s’en est suivi une bonne vieille polémique, mais le ton est resté cordial et le thread est bourré d’infos intéressantes et d’avis personnels).
Pour quelqu’un qui est sous Windows depuis “toujours”, avec un long passage par RedHat à l’époque de la 7.2, quand les disques durs étaient en os et les souris en silex, et un bref et douloureux essai de quelques mois sous FreeBSD (où j’ai à peu près autant été dépaysé que si j’avais passé un week-end vers Alpha du Centaure), entendre parler d’un Linux “Client-Friendly” en 2009, ça m’a fait craquer et j’ai eu envie d’essayer. Surtout quelques jours après avoir installé Windows Seven par curiosité – et avec dans l’idée de publier mes impressions (ec que je n’ai pas fait puisque le retour d’expérience de Windows Seven sera fait en deux mots : “comme Vista”).

Détection du hardware

Lacie USB: détecté!

Connexion à Internet

Là, pas grand-chose à dire. En Ethernet, je suis déjà connecté. Mon réseau Wifi domestique est aussi détecté et prêt à l’emploi. Pour la petite histoire, sous Debian, j’avais lutté plusieurs jours (ok, j’ai deux mains gauches, mais quand même…) avant de faire reconnaître ma carte Wifi, qui est semble-t-il un peu exotique (une vieille Hercules).

Socialiser sous Ubuntu : la messagerie instantanée

Par défaut est installé Pidgin, un client basé sur libpurple et écrit en Gtk+. Il est compatible avec la plupart des réseaux modernes : MSN, Yahoo!, XMPP (donc Google Talk), ICQ, IRC, plus tout un tas d’autres, dont je n’ai jamais entendu parler, comme Lotus Sametime, Zephyr, MySpaceIm, Gadu-Gadu et QQ.
Il est possible de se connecter sur plusieurs réseaux (et avec plusieurs comptes) simultanément. Pidgin semble pouvoir accepter des plugins et des smileys personnalisés (bah si, moi ça m’a réjoui de voir ça).

Client IRC : Xchat. Pas fan de l’interface (trop hatibué à mIRC dans ma folle jeunesse). Détail sympa: quand on installe Xchat via apt-get, le raccourci se met tout seul dans Applications/Internet/Xchat

En console

Avec un processeur 64bits, l’installation graphique du plugin Flash pour Firefox a échoué (mauvaise architecture). Il a donc fallu passer en console pour essayer de l’installer à la main. Après un petit essai infructueux, mon shell me répond “Essayez avec sudo apt-get install flashplugin-installer“. Et ça a marché.
Dans le même esprit, si je tape “mysql” alors que je n’ai pas de client installé, on me répond que cet exécutable est dans le paquet “mysql-client”. Je sens que les apt-cache search à la recherche de paquets dont j’ai oublié le nom vont se faire assez rares.

Audio / Vidéo

Notification RythmBox (lecteur audio)

LE gros point noir: merci Apple

Evidemment, il fallait que quelque chose cloche. Mais ce n’est pas de la faute d’Ubuntu. Mon gros point noir est causé par Apple, puisque je ne peux pas synchroniser mon iPhone non-jailbreaké avec mon système Ubuntu. Qui plus est, le Jailbreak était considéré comme légal tant qu’il était réalisé à des fins d’interopérabilité (ce qui est le cas ici) mais cela à changé depuis le firmware 3. C’est maintenant interdit. Sans commentaires.

Conclusion

Très agréablement surpris par ma première heure sous Ubuntu, j’envisage déjà une migration définitive vu que je n’ai à déplorer aucune perte de fonctionnalité (à part pour l’iPhone, encore un grand merci à Apple). Le système répond bien, même avec de nombreuses applications lancées en simultané (on perd vite l’habitude du VRAI multithread…). Il va falloir que je me penche sérieusement sur la compatibilité entre quelques programmes et leurs penchants opensource (je pense notamment à OpenOffice et Microsoft Office) et si tout se passe bien, c’est fini!

Merci aux utilisateurs des forums Ubuntu-fr.org pour leur accueil sympathique

Le principe de Screen

Screen est un utilitaire en ligne de commande qui permet de créer plusieurs shells virtuels qui tournent en parallèle. En l’utilisant, vous aurez donc accès à plusieurs “sessions”, comme si vous aviez lancé plusieurs clients SSH.

Enorme avantage, screen ne s’arrête pas quand votre connexion au serveur est coupée. En rouvrant votre session Unix normale, vous pourrez faire screen -r (Recover) pour retrouver toutes vos fenêtres exactement dans l’état où vous les avez laissées (les actions en cours ont continué, les scripts ne sont pas interrompus, etc).

Après une rapide installation (le package apt se nomme “screen”), l’utilitaire est directement utilisable. Tapez “screen”, rien ne se passe. Et pourtant tout est ok, on y est. Bienvenue dans le monde de screen. Faites ce que vous avez à faire, éditez par exemple le fichier /etc/hosts de votre machine. Tapez ensuite control+A, puis C (pour Create). Une nouvelle fenêtre virtuelle est créée. Vous vous retrouvez devant une invite de commande, sur un shell vierge. Et c’est là que les réjouissances commencent. Faites un ls, par exemple. Ensuite, un Control+A puis N (Next) vous permet de passer à la fenêtre suivante gérée par Screen.
Toutes les commandes Screen sont composées de la combinaison Control+A puis une lettre (ou un chiffre).

Voici le menu :

• Ctrl-a c Créer une nouvelle fenêtre (Create)
• Ctrl-a k Fermer la fenêtre en cours (Kill)
• Ctrl-a w Liste les fenêtres disponibles (Windows) – La fenêtre courante est repérée par une étoile.
• Ctrl-a 0-9 Aller à la fenêtre N (Les chiffres sont dans la liste des fenêtres obtenue en faisant W)
• Ctrl-a n Aller à la fenêtre suivante (Next)
• Ctrl-a Ctrl-a Switche en mode “2 fenêtres” (ramène à la fenêtre précédemment affichée)
• Ctrl-a [ Copier
• Ctrl-a ] Coller
• Ctrl-a ? Liste des commandes (Aide/Help)
• Ctrl-a Ctrl-\ Quitter “screen”
• Ctrl-a d Détacher le process, en laissant la fenêtre ouverte

Le mode Copie de Screen

Screen peut aussi vous permettre de copier/coller efficacement du texte entre deux fenêtres. Pour cela, ouvrez le mode copie en faisant Ctrl-A [ .
Une fois dans le mode copie, vous pouvez déplacer le curseur à l'aide des touches H,J,K et L. La barre d'espace commence/arrête la sélection du texte. Ctrl-A ] servira alors à coller le texte copié dans le “presse-papiers”.

Pas clair ? Ok, un exemple :

Pas plus compliqué… Le * va capturer le sous-domaine et le passer au VirtualDocumentRoot. Donc pour test.domain.tld, on tombera dans /var/www/domain.tld/test/.

Dans le <VirtualHost>, après un VirtualDocumentRoot, on peut utiliser des directives comme d’habitude. (Je n’ai pas essayé d’y reprendre le %1, pour modifier les options de configuration de l’ensemble des dossiers “virtuels”… quelqu’un sait si ça marche ?)

(Note en réaction au commentaire de Laurentj :
Ce billet s’adresse à des développeurs web hébergés sur des serveurs en ayant un accès SSH, et ayant conscience des problématiques de gestion d’un serveur.
L’administration système, à fortiori sur une machine connectée 24/7, est un métier à part entière, qui requiert évidemment des compétences poussées ; ne pas savoir ce que l’on fait peut être lourd de conséquences.
Les commandes présentées ici sont très simples et ce post est plus destiné à servir de “pense-bête” que de véritable tutoriel.)
Il va falloir copier les scripts et les bases de données. En supposant que vous utilisez MySQL, voici la procédure à suivre.

Pour copier les scripts, on va compresser le DocumentRoot de chaque site dans une archive tarball (.tar.gz ou .tgz). On prendra le soin d’inclure à l’archive le dump de la base de données utilisée par le site. On n’aura ainsi qu’un seul fichier à envoyer et “installer” sur le serveur B. Ainsi, on est sûrs de ne rien oublier, et la compression diminue évidemment le temps qui sera nécessaire pour le transfert.

Vu qu’on ne travaille JAMAIS sur un site qui est -pour quelques minutes encore- en production (merci de noter ça en rouge dans vos petits cahiers), on commence par créer une copie de ce dossier dans ~/backup. Le ~ signifie “répertoire /home de l’utilisateur courant”. Pour ce faire :

Où -R signifie récursif: copier aussi les sous-répertoires.

Passons ensuite dans le répertoire de backup :

On réalise un dump (sauvegarde) de la base de données (attention, je parle bien ici d’une seule base, et pas du contenu complet du serveur…)

où :

• [utilisateur] est le nom d’un user SQL qui a les privilèges en lecture sur la base
• [nom_de_la_base] est la base qu’on souhaite copier
• [nom_du_fichier] est le nom du fichier dans lequel sera stocké le dump (choisir un fichier qui n’existe pas…)

Il vous sera demandé (grâce à l’option -p) d’entrer le mot de passe associé à ce compte-utilisateur.

Et c’est parti pour la création du tarball :

[nom_de_l_archive] étant le nom du fichier que vous voulez créer.
.. signifie “un répertoire plus haut dans l’arborescence”, donc dans le /home de l’user courant.

On peut vérifier que l’archive est bien formée et comprend bien les fichiers escomptés. Ca ne mange pas de pain et peut éviter de grosses crises d’hystérie quand on s’est raté quelque part. Listons donc le contenu de l’archive (pensez à remonter d’un cran dans l’arbo):

On peut ensuite copier par SCP l’archive sur le nouveau serveur (machine B):

• [nom_du_fichier] étant le nom du dump généré juste au-dessus
• [user] étant un utilisateur existant sur la machine B
• [hostname] étant un nom de domaine qui pointe vers B, ou son adresse IP

Le ~ (tilde) veut toujours dire “dans le répertoire /home” de l’utilisateur (mais sur le nouveau serveur, cette fois). Vous pouvez indiquer n’importe quel path pour lequel l’user spécifié à le droit d’écrire (pensez à bien inclure le premier slash)

On aurait pu faire le dump directement depuis le nouveau serveur, à condition qu’on puisse se connecter au serveur MySQL de l’ancien depuis le réseau (bind-adress *) mais le dump prendrait plus de temps. Donc autant le réaliser directement depuis la machine A et l’envoyer avec le reste du site.

On passe ensuite en SSH sur la machine B. La connexion à la machine A ne servira plus ; on la coupe (une larme d’émotion est permise pour les nostalgiques).
On décompresse notre archive magique :

On se connecte au serveur MySQL et on crée la base de données qui va recevoir le dump :

create database [nom_de_la_base]
On monte la base de données dans le serveur MySQL.

Où [dump] est le nom du dump qu’on a transféré et décompressé.

La base est prête ! (Pensez, si besoin, à recréer les utilisateurs MySQL qui auront les accès nécessaires sur cette base)
On crée alors le DocumentRoot du site, et on s’y rend pour y déplacer les fichiers décompressés :

C’est fait. Vous pouvez vérifier que tout fonctionne en modifiant votre fichier hosts sous Windows : Editez le avec Notepad et ajoutez la ligne “[nouvelle_ip] [www.domain.tld]“. Si vous utilisez Internet Explorer, fermez et rouvrez votre navigateur (pour que les modifications soient prises en compte) et allez voir votre site. Tout marche ? Il ne vous reste plus qu’à changer vos DNS… Migration de site accomplie !

Bien sur, en faisant comme cela, vous “perdrez” les données entre le moment où vous faites le dump et celui où les DNS basculent effectivement. Vous pouvez, une fois les DNS basculés, faire une extraction des données de la base “à la mano” (un différentiel qu’on appelle souvent un Delta…) mais c’est une autre histoire…