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”.

(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…