Gregory Colpart's blog

Après les épisodes [0] et [1], voici la mise-à-jour d’un poste de travail mono-utilisateur KDE/Mozilla/OpenOffice, en place depuis 2 ans environ dans une association. Les remarques concernant la migration sont les suivantes :

– Au niveau de la mise-à-jour complète des paquets (le dist-upgrade), il a été nécessaire de forcer la mise-à-jour de KDE. En effet, aptitude install kde a permis la désinstallation des paquets libhal0 et dbus-1 spécifiques à Sarge.

– Il a été nécessaire de récupérer manuellement la clé GPG pour authentifier les paquets avec aptitude.

– Au niveau de KDE, les icônes sur le bureau ont été désorganisés (tous rassemblés en haut à gauche) et l’application KGPG était lancée par défaut (à désactiver car non utilisée dans ce cas précis).

Bref, surtout des détails. Aucun soucis au niveau de Firefox->Iceweasel et Thunderbird->Icedove (le plus gênant était le changement des… icônes), au niveau d’OpenOffice v1->v2, CUPS, GAIM, etc. La conclusion de cette mise-à-jour a été : « C’est réparti pour 2 ans de stabilité ! » Qui a dit que Debian n’était pas prêt pour le poste de travail en environnement professionnel ?

Plusieurs services (Apache, Tomcat, etc.) dépendent de variables d’environnement, notamment des variables LC_*/LANG*. Il faut donc prendre garde à la façon dont on (re)lance un service. Par exemple, sous Debian, un apache(2)ctl start ne revient pas au même qu’utiliser un “wrapper” comme /etc/init.d/apache(2). Mais il ne suffit pas d’utiliser systématiquement les scripts init.d : toujours sous Debian, /etc/init.d/tomcat5.5 peut dépendre de variables d’environnement. Concrètement, relancer un service depuis un shell avec un environnement particulier peut donc changer son comportement (dates incorrectes, problème de charset, etc.). D’ailleurs, au passage, sous Debian, il est conseillé d’utiliser systématiquement /etc/init.d/apache2 (et non apache2ctl) pour Apache car celui-ci réinitialise l’environnement, et une astuce pour Tomcat est d’exporter les variables voulues (notamment celles concernant la locale) dans le fichier /etc/default/tomcat5.5.

En règle générale, la relance de services sur un serveur en production s’effectue par sudo et/ou SSH. Pour éviter les erreurs d’inattention, il est donc préférable ne pas conserver les variables LC_*/LANG*. Avec sudo, il est ainsi recommandé d’utiliser env_reset pour des raisons de sécurité, mais env_reset conserve ces variables sans qu’il soit possible a priori de les supprimer avec env_delete (voir bug Debian #392321). Au niveau de SSH, on peut agir plus efficacement, comme éviter que ces variables soient envoyées par le client SSH en retirant la directive SendEnv LANG LC_* dans le fichier /etc/ssh/ssh_config. On peut également le faire au niveau du serveur en évitant la directive AcceptEnv LANG LC_* dans le fichier /etc/ssh/sshd_config. Bien sûr, comme toujours toutes ces “astuces” ne doivent pas être appliquées sans précaution ; le principal est de garder en tête que certains services peuvent dépendre des variables d’environnement et d’éviter de les (re)lancer depuis un environnement modifié.

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

Depuis qu’Etch est stable, j’ai effectué quelques migrations Debian Sarge->Etch sur des serveurs en production (un serveur mail en frontal qui m’a appris qu’il était préférable de rebooter sur un noyau sans patch Grsecurity avant de migrer, un serveur mail LDAP/Postfix/Courier/Horde, une dedibox et quelques autres) mais finalement assez peu. Ce week-end, j’avais prévu de mettre à jour mon serveur personnel, ce qui n’est pas forcément trivial car j’ai pas mal de services (web, mail, CVS, SVN, NFS, LDAP…), l’installation date de plus de 4 ans (Woody à l’époque) et plusieurs tests/bidouillages/backports sont en place.

Pourquoi attendre autant ? Théoriquement Sarge reste maintenu jusqu’en avril 2008, donc rien ne presse si l’on a pas besoin des nouveaux logiciels d’Etch. Et surtout, j’applique le principe de précaution d’attendre un certain temps afin d’avoir une grande quantité d’informations disponibles sur Internet (ressources Debian, moteurs de recherche, blogs). Enfin, autant j’ai assez de liberté pour mon serveur personnel, autant je ne suis pas le seul décisionnaire pour des serveurs d’entreprise utiles à plusieurs dizaines ou centaines d’utilisateurs.

Bref, entrons dans le vif du sujet. Mes précautions sont d’effectuer des essais de migration avec un serveur de test, d’avoir des backups tout frais, de couper les services durant la phase de migration et de prévenir les utilisateurs à l’avance des perturbations. Ensuite, j’ai repris les Releases Notes, j’ai adapté mon sources.list puis :

# aptitude update && aptitude upgrade
# aptitude install initrd-tool

Pas de problème particulier à noter jusqu’ici. Ensuite, je dois mettre à jour mon noyau :

# uname -a
Linux serveur 2.4.27-3-k7 #1 Wed Dec 6 00:10:25 UTC 2006 i686 GNU/Linux
# aptitude install linux-image-2.6-k7

Comme prévu, udev a râlé un peu à cause de mon noyau 2.4, mais rien de bien grave. Par contre, cela s’est passé moins bien avec LILO qui a semblé un peu perturbé par tous ces changements :

# lilo
Warning: '/proc/partitions' does not match '/dev' directory structure.
Name change: '/dev/scsi/host0/bus0/target0/lun0/disc' -> '/dev/sda'
Fatal: VolumeID read error: sector 0 of /dev/sda not readable

Je n’avais pas le temps d’investiguer et j’ai décidé de tenter ma chance avec GRUB.

# aptitude install grub && grub-install /dev/hda/ && update-grub

La phase grub-install est très longue mais ça s’est bien passé lors du reboot à la fin de la mise-à-jour.

Ensuite, c’était la mise-à-jour de tout le reste des logiciels :

# aptitude dist-upgrade

Je vous fais grâce des messages/questions debconf et les mises-à-jour des conffiles (à ce sujet, pour info, j’ai pour réflexe de visualiser les différences avant de choisir de garder l’ancienne version ou pas, et je garde des notes pour y revenir en fin de mise-à-jour). Passons maintenant aux divers problèmes rencontrés :

– mod_security

Starting web server (apache2)...
apache2: Syntax error on line 116 of /etc/apache2/apache2.conf:
Syntax error on line 1 of /etc/apache2/mods-enabled/mod-security.load:
Cannot load /usr/lib/apache2/modules/mod_security.so into server:
/usr/lib/apache2/modules/mod_security.so:
cannot open shared object file: No such file or directory failed

Pour des raisons de licence, mod_security n’est plus dans Etch (on peut utiliser les packages upstream si on le souhaite).

– Authentification HTTP avec LDAP

Invalid command 'AuthLDAPEnabled', perhaps misspelled or defined by a module not included in the server configuration

J’ai du adapter mes configurations de la façon suivante :

#AuthLDAPEnabled on
AuthBasicProvider ldap
#AuthLDAPAuthoritative on
AuthzLDAPAuthoritative Off

– Apache-SSL

Syntax error on line 75 of /etc/apache-ssl/httpd.conf:
Invalid command 'TypesConfig', perhaps mis-spelled or defined by a module not included in the server configuration

Il s’agit d’un reste d’une fameuse migration Apache 1->2 ;) Ne l’utilisant plus, je me suis contenté de le supprimer et j’ai ouvert un petit bug pour améliorer le httpd.conf : #441447

– Bugzilla

Could not execute `/etc/bugzilla/localconfig'! ;
make sure permissions are ok. at /usr/share/perl5/Bugzilla/Config.pm line 161.
Compilation failed in require at /usr/share/bugzilla/lib/checksetup.pl line 505.
BEGIN failed--compilation aborted at /usr/share/bugzilla/lib/checksetup.pl line 505.
ERROR: Unable to find /usr/share/bugzilla/debian/params.new

Je n’arrive plus à repoduire ce problème après avoir désinstallé et réinstallé Bugzilla avec dbconfig. On va donc considérer cela comme une solution.

-Authentification LDAP avec Courier

Le fichier authldaprc a légèrement changé de syntaxe :

#LDAP_SERVER  127.0.0.1
#LDAP_PORT 389
LDAP_URI ldap://127.0.0.1

– Serveur NFS

Afin que le service NFS fonctionne correctement, j’ai du temporairement ajouter des autorisations sur udp/817, udp/896 et tcp/4984 sur le firewall du serveur. Je dois probablement revoir mes diverses options pour forcer les ports de mountd, lockd & co. (RPCMOUNTDOPTS, RPCSTATDOPTS et les options lockd.tcpport, lockd.udpport). Vu que cela “juste marche” pour l’instant, j’ajusterai ces paramètres “plus tard”.

– Onduleur sur le port série

Le logiciel Nut ne fonctionnait plus, mais c’était simplement une question de droits sur le périphérique /dev/ttyS0

– Problèmes mineurs

J’obtiens des messages récurrents du kernel :

parport0: FIFO is stuck
parport0: BUSY timeout (1) in compat_write_block_pio
DMA write timed out

Ils sont du à un ancien CUPS qui traînait dans le coin pour une imprimante sur le port parallèle plus branchée depuis un certain temps…

J’ai du remettre Vim en éditeur par défaut :

#  update-alternatives --config editor

Voilà pour cette migration. Rien d’extraordinaire, mais je trouve intéressant de prendre la peine de noter les petits problèmes rencontrés (ne nécessitant pas forcément un rapport de bug) sur mon blog afin d’informer (voire aider ;) d’autres personnes qui pourraient avoir des soucis similaires. Un bon complément des Releases Notes. Je vais essayer de le refaire pour d’autres migrations, et n’hésitez pas à faire de même !