Je ne rappellerais pas toutes les précautions nécessaires (tests préalables, sauvegardes, désactivations des services, etc.) ni la classique question  sur  “quand faut-il migrer ?”, vous trouverez tout cela dans mes exemples précédents. Je rappelle simplement l’idée de base : prendre les précieuses Release Notes, mettre à jour le fichier sources.list, puis exécuter les commandes aptitude update && aptitude upgradex, puis mettre-à-jour les services les plus critiques via aptitude install <PACKAGE>, et enfin aptitude dist-upgrade && aptitude dist-upgrade (répéter dist-upgrade est souvent nécessaire).

Passons désormais aux différentes remarques sur ces migrations :

- PostgreSQL : on passe de la version 8.1 à 8.3. Notez qu’il s’agit de paquets différents, il est donc possible de garder la version 8.1 en Etch, et d’installer en parallèle la version 8.3, afin de faciliter encore plus la migration. Pour migrer les données, on réalisera un dump avec pg_dumpall qui sera réinjecté dans la nouvelle base. On pourra ensuite adapter le port dans postgresql.conf pour passer la version 8.3 en production.

- phpPgAdmin : avec PostgreSQL 8.3, on ne peut plus se connecter à la table template1 : c’est le comportement par défaut de phpPgAdmin, qu’on devra donc modifier en mettant postgres à la place (pour la variable $conf['servers'][0]['defaultdb'] dans le fichier config.inc.php)

- Apache : la configuration de l’alias /icons/ est déplacé dans le fichier mods-available/alias.conf, il peut donc faire doublon avec la déclaration dans apache2.conf, ce qui sera signalé via le warning suivant : [warn] The Alias directive in /etc/apache2/apache2.conf at line 240 will probably never match because it overlaps an earlier Alias. Commenter les directives dans le fichier apache2.conf résoudra ce petit soucis.

- OpenLDAP : on passe d’une version 2.3 à 2.4, mais le plus marquant pour la migration est que cela force le processus à tourner avec un utilisateur/groupe dédié. Pour diverses raisons (dist-upgrade interrompu par exemple), on pourra rencontrer des soucis plus ou moins alarmants. Ainsi, j’ai pu rencontrer cette erreur :
bdb(dc=example,dc=com): PANIC: fatal region error detected; run recovery
bdb_db_open: database “dc=example,dc=com” cannot be opened, err -30978. Restore from backup!
backend_startup_one: bi_db_open failed! (-30978)
slap_startup failed
On veillera donc sur l’utilisateur/groupe propriétaire des fichiers dans le répertoire /var/lib/ldap et, au besoin, on ajustera : chown -R openldap:openldap /var/lib/ldap/
Mon conseil : mettre-à-jour le paquet slapd de façon spécifique avant le dist-upgrade

- Postfix : on passe de 2.3 à 2.5. On notera simplement la valeur par défaut de $smtp_line_length_limit characters qui passe à 990, ce qui coupe les lignes trop longues pour se conformer au standard SMTP. Si cela posait problème, on pourrait revenir à l’ancien comportement en positionnant smtp_line_length_limit=0

- SpamAssassin : l’utilisant en stockant la configuration des utilisateurs dans un annuaire LDAP, le daemon spamd s’est mis à râler : cannot use –ldap-config without -u
Le problème sera résolu en ajoutant l’option -u nobody, ce qui fera tourner spamd en tant que nobody (ce qui n’est pas une mauvaise chose, au contraire).

- Amavis : apparemment, lors de la détection d’un virus, le code retourné n’est plus 2.7.1 mais 2.7.0 : 2.7.0 Ok, discarded, id=13735-07 – VIRUS: Eicar-Test-Signature
Rien de bien grave, mais cela a nécessité d’adapter un plugin Nagios pour qu’il attende le bon code de retour.

- Courier-imapd-ssl : après une mise-à-jour gardant mon fichier /etc/courier/imapd-ssl actuel, j’obtenai des erreurs avec certains clients IMAP :
couriertls: accept: error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number
En regardant de plus près, certaines directives changent dans ce fichier de configuration, et il est donc conseillé de repartir du fichier proposé par Lenny, et d’y apporter ses modifications (souvent, cela se limite à préciser le certificat).

- Horde : si vous utilisez une base de données pour stocker les paramètres ou autres, la paquet php-db (déjà en Recommends: en Etch) est d’autant plus nécessaire, sous peine d’obtenir l’erreur : PHP Fatal error:  _init() [<a href='function.require'>function.require</a>]: Failed opening required ‘DB.php’ (include_path=’/usr/share/horde3/lib:.:/usr/share/php:/usr/share/pear’) in /usr/share/horde3/lib/Horde/DataTree/sql.php on line 1877

- Sympa : on attaque là le cauchemard de mes migrations. À chaque fois, tellement de soucis majeurs et mineurs, que j’ai l’impression d’être le seul à utiliser ce paquet. Voici en vrac tous les soucis rencontrés : les accents dans les descriptions ont sautés (une sorte de double encodage) et cela a nécessité des corrections manuelles, la table logs_table doit être créée à la main (j’utilise Sympa avec PostgreSQL), et enfin une typo surprenante un “GROUP BY” à la place d’un “ORDER BY” (j’ai ouvert le bug #566252 à ce sujet).

- Asterisk : on passe de la version 1.2 à la version 1.4. Lors de la migration, j’ai constaté un bug étrange, le fichier modules.conf qui charge les modules additionnels a disparu. Du coup, sans lui, Asterisk ne charge pas les modules nécessaires (SIP, etc.). Il a donc fallu le restaurer.

- udev : le meilleur ami des sysadmins (ou pas). Si les migrations douloureuses Sarge->Etch sont loin derrière nous, il reste néanmoins quelques blagues. La dernière en date a été un renommage des interfaces réseau : eth0->eth1 et eth1->eth2. Classique mais étonnant, ce genre d’humour est sensé être dépassé grâce aux “persistent rules” qui nomment les interfaces en fonction de l’adresse MAC. À rester vigilant sur ce point avant le redémarrage donc.

Voilà pour les remarques. Vous noterez que je n’ai pas abordé le noyau Linux. C’est parce que pour la majorité de nos serveurs, ils sont gérés de façons spécifiques (au lieu d’utiliser les noyaux officiels Debian). Ainsi, ils restent dans leur version actuelle (2.6.31 à cette heure) pendant la migration. Bien sûr, cela n’empêche pas d’effectuer un redémarrage de la machine suite à la mise-à-jour : cela permet de s’assurer que tout est bien en place et le sera toujours après un éventuel redémarrage d’urgence.

Rendez-vous pour de prochaines migrations !

Cette présentation a permis de faire un point sur les différentes organisations en place dans des sociétés clientes ou proches d’Evolix. Je remercie d’ailleurs les responsables techniques qui ont répondu à mes questions ces derniers jours. Globalement, il se dégage une forte tendance à l’utilisation d’Eclipse comme IDE, que ça soit pour les projets en Java ou PHP. Au niveau SCM, on retrouve CVS et majoritairement SVN, avec une gestion des branches plus ou moins avancée. En terme de bugracker, c’est assez divers : Trac, Mantis ou Bugzilla. Pour le développement, c’est souvent http://localhost qui est utilisé. Une mise en préproduction est ensuite effectuée, puis une bascule en production, à l’aide de scripts personnalisés s’appuyant sur le SCM. En terme de méthodes, plusieurs sociétés utilisent des méthodes agiles (tests unitaires, sprints, etc.) de façon plus ou moins avancées. En général, l’organisation en place est informelle et reprend les bonnes idées adaptées à son projet. Les benchmarks et tests de performance sont plutôt effectués dans une seconde phase (en préproduction voire en production), sauf dans certains cas où ils sont intégrés aux tests unitaires (ce qui est une très bonne pratique). Enfin, en terme de framework, on distingue deux tendances : l’exploitation d’un framework existant et reconnu, ou l’utilisation d’un framework développé en interne.

Bien évidemment, ce petit inventaire n’a pas la prétention d’être exhaustif ou de définir une organisation idéale. C’est plutôt un passage en revue de bonnes pratiques, permettant de les découvrir … ou de s’assurer qu’on ne passe pas à côté de certains outils.

J’en profite pour rappeler quelques notions basiques pour sécuriser une installation d’un logiciel PHP, surtout quand il est très répandu : si possible, limiter les accès aux parties backoffice via Apache (restriction par adresses IP et/ou authentification HTTP), utiliser des identifiants originaux (pas forcément admin…), des mots de passes complexes, éviter les modules/plugins non fiables, suivre les notifications de mises-à-jour et les appliquer rapidement (cela implique de limiter les modifications intrusives empêchant des futures mises-à-jour, ou du moins les préparer sous forme de patch pour les ré-appliquer très rapidement), etc. Pour le premier point, voici un exemple de sécurisation de Wordpress via Apache :

<LocationMatch "^/wordpress/wp-(admin|login)">
Deny from all
Allow from YOUR_IP
</LocationMatch>

# dpkg-divert --divert /usr/share/doc/sun-java6-jre/US_export_policy.jar.ori \
 --rename /usr/lib/jvm/java-6-sun-1.6.0.12/jre/lib/security/US_export_policy.jar
Adding `local diversion of /usr/lib/jvm/java-6-sun-1.6.0.12/jre/lib/security/US_export_policy.jar
 to /usr/share/doc/sun-java6-jre/US_export_policy.jar.ori'
# dpkg-divert --divert /usr/share/doc/sun-java6-jre/local_policy.jar.ori \
--rename /usr/lib/jvm/java-6-sun-1.6.0.12/jre/lib/security/local_policy.jar
Adding `local diversion of /usr/lib/jvm/java-6-sun-1.6.0.12/jre/lib/security/local_policy.jar
to /usr/share/doc/sun-java6-jre/local_policy.jar.ori'

Attention, bien garder à l’esprit que si une faille de sécurité survient, il faudra mettre à jour manuellement ces fichiers.

MAJOR=`grep megadev /proc/devices|awk '{print $1}'`
mknod /dev/megadev0  c $MAJOR 0

Mais un numéro majeur ne semblait pas utile, car seul un fichier spécial est nécessaire (même avec plusieurs cartes Megaraid) et le numéro mineur n’était jamais utilisé. Cela a donc changé à partir du noyau Linux 2.6.25, et c’est désormais un numéro mineur (et dynamique) et un numéro majeur correspondant à misc qui définit le périphérique /dev/megaraid0. On retrouve ainsi des bugreports chez Debian (#399783) et Gentoo (#233295) à propos de ce changement.

Concrètement, ce matin lors d’une mise-à-jour d’un noyau Linux de 2.6.21 en 2.6.28, le fichier spécial /dev/megaraid0 avec les numéros majeur/mineur 253/0 n’était plus utilisable par les outils de management du RAID. La suppression de ce fichier et l’installation d’udev a permis de retrouver un /dev/megaraid0 fonctionnel.

debug1: Allocating pty
openpty: No such file or directory
session_pty_req: session 0 alloc failed

Si uniquement DEVPTS est monté, et pas PROCFS :

debug1: Allocating pty
openpty: returns device for which ttyname fails.

Voici donc les étapes pour lancer le serveur SSH chrooté avec Debian Lenny :

#  chroot /backup/jails/myserver mount -t proc proc-chroot /proc/
#  chroot /backup/jails/myserver mount -t devpts devpts-chroot /dev/pts/
#  chroot /backup/jails/myserver /usr/sbin/sshd > /dev/null

Pour ce premier post, la question classique : quand faut-il migrer sa machine vers Debian Lenny ? Tout d’abord, Etch reste maintenu environ un an après la sortie de Lenny, soit jusqu’en février 2010. Il n’y a donc aucune raison d’être pressé à migrer si l’on a pas besoin de nouveaux logiciels. Et surtout, je recommande le principe de précaution, à savoir attendre un certain temps ce qui permettra d’avoir une grande quantité d’informations disponibles sur Internet (ressources Debian, moteurs de recherche, blogs). Enfin, il est important de bien planifier sa migration en fonction du métier de la société (haute/basse saison, vacances, etc.).

Évidemment, les précautions suivantes sont nécessaires : faire des essais de migration sur des serveurs de test, avoir des backups tout frais, couper les services durant la migration et bien prévenir à l’avance tous les utilisateurs et personnes concernées.

Entrons dans le vif du sujet. Au menu, un serveur web situé chez un hébergeur low-cost français. Ce serveur fait parti d’un pool de plusieurs serveurs (load-balancing via du round-robin DNS), donc il faut au préalable le désactiver et attendre que le time-to-live le rende totalement inactif. Ensuite, on reprend les Releases Notes, on modifie le sources.list et on se lance.

On s’assure que les partitions /usr et /tmp ont les bonnes options de montage:

# mount -o remount,rw /usr && mount -o remount,exec /tmp

On lance une mise-à-jour minimale :

# aptitude update && aptitude upgrade

Puis une mise-à-jour complète :

# aptitude dist-upgrade

Rien de bien complexe. Il reste à croiser les doigts pendant les opérations ci-dessus, mais si votre système est « propre », cela se passe très bien, comme souvent sur un système Debian. Il est ensuite important de lire les éventuelles instructions de mise-à-jour situées dans le fichier NEWS d’un paquet (en utilisant apt-listchanges, cela peut être affiché automatiquement).

En ce qui concerne la mise-à-jour du kernel, de mauvaises surprises sont possibles après le redémarrage. Il est notamment recommandé d’avoir un accès à la machine (accès physique, accès « rescue », etc.) pour corriger d’éventuels problèmes. Dans mon cas, l’interface réseau a été renommée de eth0 à eth1 suite à la mise-à-jour d’udev : le fichier  /etc/udev/rules.d/z25_persistent-net.rules se transforme en /etc/udev/rules.d/70-persistent-net.rules, jusqu’ici tout est normal, mais un problème surnaturel semble s’être produit, la carte e1000 (MAC=00:0c:29:65:ae:04) est « devenue » une r8168 (MAC=00:1c:c0:51:12:45) ; au final, c’est plutôt un soucis lié au matériel, enquête en cours chez l’hébergeur low-cost…

Un vrai problème s’est par contre posé avec la mise-à-jour du paquet nginx (un petit serveur web très performant). Suite à sa mise-à-jour, il ne démarre plus :

Starting nginx: 2009/04/19 20:45:26 [emerg] 28783#0: could not build the server_names_hash,
you should increase server_names_hash_bucket_size: 32

Il faut donc ajouter dans la section http {} du fichier nginx.conf :

http {
include       /etc/nginx/mime.types;
default_type  application/octet-stream;

# Necessaire depuis l'upgrade Etch->Lenny
# (ajoute le 19.06.2009 by reg)
server_names_hash_bucket_size 33;
...

Voilà pour ce premier exemple de migration. Il s’agissait d’un serveur « simple » sans installation particulière, donc assez peu de problèmes rencontrés. Les prochains exemples seront certainement un peu plus complexes !

Un problème assez classique avec NIS est l’administration de la base d’utilisateurs. Déportée dans une base distincte (/var/yp/DOMAINNAME/), on peut :
- la gérer comme une source de données indépendante, mais cela rend assez complexe l’administration, car on ne peut pas vraiment utiliser les outils classiques (commande adduser, détection du max(UID), etc.)
- gérer les utilisateurs/groupes locaux, et générer la base NIS à partir des données locales. Dans ce cas, la problèmatique est de ne pas exporter les utilisateurs/groupes système !

Dans le second cas, il n’existe pas de distinction des utilisateurs/groupes système dans le Makefile.yp distribué par OpenBSD. Heureusement, Antoine Jacoutot a écrit un petit patch pour gérer des MINUID/MINGID/MAXUID/MAXGID : voici le patch.

:'<,'>s/\%Vfoo/bar/