Je n’ai pas oublié mon idée de bloguer sur des migrations Sarge->Etch qui le méritent. Voici donc un deuxième volet avec un petit serveur d’entreprise comprenant les services suivants : OpenLDAP (annuaire, authentification), PostgreSQL, NFS, messagerie (Postfix, Courier-IMAP, Amavisd-new, ClamAV, Bogofilter, DCC, Razor, SpamAssassin, Whitelister, Postgrey, Sympa), Apache/PHP (eGroupWare, webmail Horde, wwsympa, logiciels/sites sur mesure) ainsi qu’un certain nombre de logiciels/scripts sur mesure. J’ai donc profité des jours autour de Noël (période idéale pour les migrations de serveurs d’entreprise) pour m’attaquer à cette tâche.
Tout d’abord, je souligne que cette migration est particulière car j’en profite pour basculer sur du RAID (software) et il s’agit donc de réinstaller un système de base et de gérer les migrations “à la main” (tout en jetant un coup d’oeil sur certains maintainer scripts). Au passage, quelle horreur d’ajouter des disques supplémentaires dans un serveur D3LL format tour quand ça n’a pas vraiment été prévu : une seule paire de glissières, uniquement deux emplacements 3″5, alors que techniquement on pourrait mettre une bonne douzaine de disques… Bref, une fois les soucis matériel gérés (ah oui, la nappe SCSI et la terminaison prévues étaient foireuses), la nuit est bien avancée et je peux couper les services et me lancer dans une réinstallation de base puis re-brancher l’ancien disque et gérer service par service la migration. Voici la liste des points critiques et problèmes rencontrés :
– Au niveau du noyau, aucun problème en vue car je reste avec le même (un noyau personnalisé avec notamment le patch grsecurity). Néanmoins, un petit soucis avec la bibliothèque liblzo notamment utile à lynx (…utile à mutt pour voir les messages HTML et diverses pièces jointes) :
$ lynx lynx: error while loading shared libraries: liblzo.so.1: cannot enable executable stack as shared object requires: Permission denied
La solution est de “mettre un coup de pioche” dans la bibliothèque :
aptitude install prelink && execstack -c /usr/lib/liblzo.so.1.0.0
– OpenLDAP
Il faut bien gérer le passage du service slapd qui n’est plus lancé par root mais par un utilisateur openldap. Lors de la migration, il faut donc bien ajuster tous les droits (schémas LDAP, ré-injection des données avec slapadd, etc.) sinon slapd vous “segfault” dans la tête ; et ajuster le pidfile dans le slapd.conf (le mettre dans un répertoire /var/run/slapd/ où l’utilisateur openldap aura les droits pour créer le pidfile, et non plus simplement /var/run/).
– PostgreSQL
J’ai utilisé le paquet pour avoir une version 7.4 et minimiser les impacts potentiels lors de la migration car Sarge utilisait déjà une version 7.4. Un pg_dumpall dans le chroot de la machine arrêtée et un psql plus tard, aucun soucis à relever. Il a ensuite suffi de migrer les fichiers de configuration pg_*.
– Bind
Rien à sigaler de particulier, à part installer le paquet bind9, lancer mon fameux script chroot-bind.sh, et transférer l’ancienne configuration (named.conf, rndc.conf, etc.).
– Messagerie (Postfix, Courier-IMAP, Amavisd-new, ClamAV, SpamAssassin, Whitelister, Postgrey, Sympa)
Un gros morceau mais tout se passe bien dans l’ensemble pour ces logiciels extrêmement utilisés. Pas de soucis pour Postfix en reprenant l’ancien fichier main.cf. Pour info, j’utilise souvent debian-volatile (donc SpamAssassin, ClamAV et Postgrey en sont issus) et un Whitelister patché pour vérifier aussi les reverse DNS. À noter que pour pas mal de logiciels, je suis reparti de la configuration de Etch et j’ai importé mes modifications plutôt que de repartir de ma configuration pour Sarge (pour amavisd-new, il n’y a pas trop le choix de toute façon).
– Sympa
Là, ce fut un gros morceau de la migration, parce qu’il y a beaucoup de changements de la version 4 à la version 5. J’ai donc importé les configurations des listes et Sympa s’est débrouillé pour avaler tout ça et injecter les admins des listes dans PostgreSQL. Pour les archives, il faut bien penser à re-générer toutes les archives (par wwsympa) pour avoir le nouveau format car l’ancien s’affiche très mal (plein de variables sensées ne pas s’afficher apparaissent). Enfin, pour injecter les utilisateurs dans les tables user_table et subscriber_table (pour les listes qui n’utilisent pas LDAP ;), j’ai du ajouter la colonne robot_subscriber à la main avant d’injecter le tout. Mais après avoir bien ajusté la configuration et redémarré plusieurs dizaines de fois Sympa, tout marche ! Il ne reste plus qu’à activer fcgi, ajouter un petit patch trivial, refaire les couleurs (car l’interface web change complètement et les *_color deviennent des color_n) et tout roule ! Résultat ici.
– Apache/PHP
Afin de minimiser les impacts, j’ai choisi de rester en PHP4 (la migration en PHP5 se fera par la suite, une chose à la fois). Pour la migration des VirtualHosts (une bonne vingtaine), tout se passe plutôt bien à part le changement des directives pour l’authentification via LDAP déjà indiqué précédemment. Passons aux webapps. Pour eGroupWare, c’est vite vu car c’est géré indépendamment de Debian (il n’y a d’ailleurs pas de version d’eGroupWare pour Etch). De la même façon, pour les sites/logiciels développés sur mesure, rien à signaler. Reste le webmail Horde où les dernières versions apportent un ergonomie bien confortable (options intégrées dans la sidebar, dossiers virtuels, etc.) et une amélioration notable des performances IMHO. Je n’ai pas utilisé la version d’Etch mais directement la version de sid qui corrige un bug d’affichage pour Opera et IE7.
Dans l’ensemble, ce fut long, mais au final pas d’accrochage majeur. Les premiers retours des utilisateurs semblent concluants : tout marche aussi bien (voire mieux puisqu’il y a de nouvelles fonctionnalités/optimisations).