3.2. Démarche de migration
Pour chaque ordinateur à migrer, il faut suivre une démarche garantissant une continuité dans les services offerts. Quel que soit le système d'exploitation utilisé, le principe ne change pas.
3.2.1. Recenser et identifier les services
Aussi simple qu'elle paraisse, cette étape est indispensable. Un administrateur sérieux connaît vraisemblablement les rôles principaux de chaque serveur, mais ceux-ci évoluent et quelques utilisateurs expérimentés auront parfois installé des services « sauvages ». Connaître leur existence vous permettra au moins de décider de leur sort au lieu de les supprimer par mégarde.
À ce titre, il est souhaitable d'informer vos utilisateurs de votre projet quelque temps avant la migration effective du serveur. Pour les impliquer dans le projet, il pourra être utile d'installer sur les postes bureautiques les logiciels libres les plus courants qu'ils seront amenés à retrouver lors de la migration des postes de travail sous Debian ; on pense bien entendu à Libre Office et aux logiciels de la suite Mozilla.
3.2.1.1. Réseau et processus
L'outil nmap (paquet Debian du même nom) identifiera rapidement les services Internet hébergés par une machine reliée au réseau sans même nécessiter de s'y connecter (login). Il suffit d'invoquer la commande suivante sur une autre machine connectée au même réseau :
$ nmap mirwiz
Starting Nmap 7.40 ( https://nmap.org ) at 2017-06-06 14:41 CEST
Nmap scan report for mirwiz (192.168.1.104)
Host is up (0.00062s latency).
Not shown: 992 closed ports
PORT STATE SERVICE
22/tcp open ssh
25/tcp open smtp
80/tcp open http
111/tcp open rpcbind
139/tcp open netbios-ssn
445/tcp open microsoft-ds
5666/tcp open nrpe
9999/tcp open abyss
Nmap done: 1 IP address (1 host up) scanned in 0.06 seconds
Si le serveur est une machine Unix offrant un compte shell aux utilisateurs, il est intéressant de déterminer si des processus s'exécutent en tâche de fond, en l'absence de leur propriétaire. La commande
ps auxw affiche tous les processus et leur identifiant utilisateur associé. En croisant ces informations avec la sortie de la commande
who (donnant la liste des utilisateurs connectés), il est possible de retrouver d'éventuels serveurs sauvages ou des programmes fonctionnant en tâche de fond. La consultation des tables de processus planifiés (
crontabs) fournira souvent des renseignements intéressants sur les fonctions remplies par le serveur (l'explication complète des commandes de
cron se trouve dans la section « Planification de tâches » du
Chapitre 9, Services Unix).
Dans tous les cas, il est indispensable de prévoir une sauvegarde du serveur : elle permettra de récupérer des informations a posteriori, quand les utilisateurs feront état de problèmes concrets dus à la migration.
3.2.2. Conserver la configuration
Il convient de conserver la configuration de chaque service identifié afin de pouvoir installer l'équivalent sur le serveur mis à jour. Le strict minimum est de faire une copie de sauvegarde des fichiers de configuration.
Pour des machines Unix, la configuration se trouve habituellement sous /etc/ mais il se peut qu'elle soit placée dans un sous-répertoire de /usr/local/. C'est le cas lorsqu'un logiciel est installé depuis ses sources plutôt qu'avec un paquet. On peut même la rencontrer, dans certains cas, sous /opt/.
Pour les services gérant des données (comme les bases de données), il est fortement recommandé d'exporter celles-ci dans un format standard, plus facile à reprendre par le nouveau logiciel. Un tel format est généralement en mode texte et documenté : il s'agira par exemple d'un dump SQL pour une base de données et d'un fichier LDIF pour un serveur LDAP.
Chaque logiciel serveur est différent et il est impossible de détailler tous les cas existants. Reportez-vous aux documentations du logiciel actuel et du nouveau logiciel pour identifier les portions exportables, puis réimportables, ainsi que celles qui nécessiteront un travail manuel. La lecture de ce livre vous éclairera déjà sur la configuration des principaux logiciels serveurs sous Linux.
3.2.3. Prendre en main un serveur Debian existant
Pour en reprendre efficacement l'administration, on pourra analyser une machine déjà animée par Debian.
Le premier fichier à vérifier est /etc/debian_version, qui contient habituellement le numéro de version du système Debian installé (il fait partie du paquet base-files). S'il indique testing/unstable, c'est que le système a été mis à jour avec des paquets provenant d'une de ces deux distributions en développement.
Le programme apt-show-versions (du paquet Debian éponyme) consulte la liste des paquets installés et identifie les versions disponibles. aptitude permet aussi d'effectuer ces tâches, d'une manière moins systématique.
Un coup d'œil au fichier /etc/apt/sources.list (et au répertoire /etc/apt/sources.list.d/) montrera la provenance probable des paquets Debian déjà installés. Si beaucoup de sources inconnues apparaissent, l'administrateur pourra choisir de réinstaller complètement l'ordinateur pour assurer une compatibilité optimale avec les logiciels fournis par Debian.
Ce fichier sources.list est souvent un bon indicateur : la majorité des administrateurs gardent au moins en commentaires les sources APT employées par le passé. Mais il est toujours possible que des sources employées par le passé aient été supprimées, voire que l'ancien administrateur ait installé manuellement (avec dpkg) des paquets téléchargés sur Internet. Dans ce cas, la machine trompe par son apparence de Debian « standard ». C'est pourquoi il convient d'être attentif à tout indice pouvant trahir la présence de paquets externes (apparition de fichiers .deb dans des répertoires inhabituels, numéros de versions de paquet dotés d'un suffixe particulier représentant l'origine du paquet — comme ubuntu ou lmde, etc.)
De même, il est intéressant d'analyser le contenu du répertoire /usr/local/, prévu pour contenir des programmes compilés et installés manuellement. Répertorier les logiciels installés de cette manière est riche d'enseignements, car cela incite à s'interroger sur la raison justifiant le non-emploi du paquet Debian correspondant — si un tel paquet existe.
Toutes les informations relatives au serveur actuel étant maintenant connues, il est possible de mettre celui-ci hors service et d'y installer Debian.
Pour en choisir la version adéquate, il faut connaître l'architecture de l'ordinateur. S'il s'agit d'un PC, ce sera vraisemblablement amd64 (les anciens PC peuvent nécessiter l'usage de l'architecture i386). Dans les autres cas, on pourra restreindre les possibilités en fonction du système précédemment employé.
Le
Tableau 3.1 ne prétend pas être exhaustif mais pourra vous aider. Dans tous les cas, la documentation d'origine de l'ordinateur vous renseignera de manière plus certaine.
Tableau 3.1. Correspondance entre système d'exploitation et architecture
| Système d'exploitation | Architecture(s) |
|---|
| DEC Unix (OSF/1) | alpha, mipsel |
| HP Unix | ia64, hppa |
| IBM AIX | powerpc |
| Irix | mips |
| OS X | amd64, powerpc, i386 |
| z/OS, MVS | s390x, s390 |
| Solaris, SunOS | sparc, i386, m68k |
| Ultrix | mips |
| VMS | alpha |
| Windows 95/98/ME | i386 |
| Windows NT/2000 | i386, alpha, ia64, mipsel |
| Windows XP / Windows Server 2008 | i386, amd64, ia64 |
| Windows RT | armel, armhf, arm64 |
| Windows Vista / Windows 7-8-10 | i386, amd64 |
3.2.5. Installer et configurer les services sélectionnés
Une fois la distribution Debian installée, il s'agit d'installer et de configurer un à un tous les services que cet ordinateur doit héberger. La nouvelle configuration devra prendre en compte la précédente pour assurer une transition en douceur. Toutes les informations récoltées dans les deux premières étapes sont utiles pour mener à bien cette transition.
Avant de se lancer corps et âme dans cet exercice, il est fortement recommandé de consulter le reste de ce livre, grâce auquel vous aurez une idée plus précise sur la manière de configurer les services prévus.
