Passage de mercure à Lenny avec snapshots LVM

Mercure est le serveur mail du ResEl. Pour éviter de tout casser, pour tirer avantage de la virtualisation, et parce que cela semble être la mode parmi ceux qui parlent d'ext4/zfs/btrfs, j'ai décidé d'utiliser des snapshots LVM. Le premier essai a été fait sur echelon, la machine de surveillance. C'est une machine qui est clairement non critique, dans le sens où si elle tombe les utilisateurs ne s'en plaindront pas (tout au plus, il y aura du retard dans le scan de garbage…).

L'idée est de faire un snapshot de la machine en version lenny. La machine (echelon-etch, ou echelon tout court) continue de tourner sur ce snapshot, pendant qu'une deuxième instance (echelon-lenny) est lancée et mise à jour sur le volume principal. Cela peux sembler contre-intuitif, mais est dû à la mécanique des snapshots LVM : il n'est pas possible de détruire le « volume principal » pour ne garder que le snapshot ; hors à terme, c'est la version passée en lenny qui sera conservée. De plus (mais c'est secondaire, « l'espace disque ça coûte pas cher »), les snapshots ont une taille fixée à l'avance, et le delta entre le volume initial et le snapshot ne doit surtout pas dépasser la taille fixée à la création.

On me souffle à l'oreillette que Linux 2.6.33 supporte la fusion de snapshots. Mais 2.6.33 est bien loin de trolls…

Bref, allons-y. Sur trolls, qui est la dom0 hébergeant les fichiers de configuration des VM :

cd /srv/VM/config
cp echelon.cfg echelon-lenny.cfg
vi echelon-lenny.cfg

Dans echelon-lenny.cfg :

• renommer la VM en echelon-lenny
• ne pas modifier les disques (pour mercure : enlever les partitions mail !)
• passer les @IP de .12 à .16
• idem pour les @mac, de :0c à :10

Dans echelon.cfg :

• renommer la VM en echelon-etch
• changer les disques : e3.6 -> echelon_etch et e3.7 -> echelon_etchswap
• ne pas modifier les @IP ou mac

Ici, checkdisklink.py a dit que la partition e3.6 n'était plus visible, donc il a mis echelon en pause : normal, cette partition n'était pas encore exportée en AoE, et même elle n'avait pas encore été créée (chekdisklink.py est un script tournant sur chaque dom0, vérifiant si les disques de chaque dumU sont accessibles). Pour mercure, penser à éteindre checkdisklink.py avant de modifier mercure.cfg.

Dans /etc/inittab, ajouter les exports AoE de e3.6 et e3.7.

lvcreate --size 512M -n echelon_etch_swap vg1
mkswap echelon_etch_swap

À ce point, echelon est toujours en train de tourner. On va l'arrêter, faire le snapshot, rendre les nouveaux volumes (e3.6 et e3.7) disponibles en AoE, et relancer echelon-etch.

ssh echelon
sudo halt
# de retour sur trolls
lvcreate -s --size 2G -n echelon_etch vg1/echelon
# lancer vblade e3.6 et e3.7 sur echelon_etch{,_swap}
init q  
xmg create echelon perceval 
# oups, le fsck parce que ça n'avait pas été fait depuis longtemps

Temps total avec echelon down : quelques minutes, penser à faire un tune2fs pour éviter le fsck…

Vérifier que echelon-etch tourne bien avec le nouveau disque.

Monter vg1/echelon en local sur trolls, mettre à jour les fichiers suivants :

• /etc/network/interfaces
• hostname
• udev/...persistent-net.rules
• ssh/sshd_config

>>> Non ! ne pas changer hostname : après la machine n'arrive pas à résoudre son propre NDD, et ça bafouille dans tous les sens.

Démonter vg1/echelon.

Refaire le lien /etc/xen/echelon-lenny.cfg vers /srv/VM/cofig.

xmg create echelon-lenny galaad

Éteindre les services pas nécessaires, mettre à jour la Debian normalement (en suivant les notes de mise à jour !).

Sur echelon, postfix/ma{in,ster}.cf ont été automatiquement modifiés (bien sûr, sur mercure, la même chose sera à faire, et les modifications à vérifier).

Rebasculement vers la version mise à jour : sudo halt sur echelon-lenny , monter la partition sur trolls, annuler les modifications faites à /etc/network/interfaces & friends, svn revert echelon.cfg pour retrouver notre echelon du début.

xmg shutdown echelon-etch
xmg create echelon galaad

Ce coup-ci, Nagios n'a pas eu le temps de voir qu'echelon s'est éteinte.

Pour me repérer entre echelon-etch et echelon-lenny, j'avais modifié /etc/hostname de echelon-lenny. Il y a un certain nombre de systèmes qui n'aiment pas ne pas pouvoir résoudre le hostname de la machine, au vu du nombre de mails (que j'ai droppé) contenant « can't resolve echelon-lenny ».

echelon-lenny ne pouvait pas se connecter à maia (compte MySQL / pgSQL). Donc, je n'ai pas testé voir si somak continait à marcher, ayant la flemme de refaire un compte avec la nouvelle IP d'echelon-lenny. On aura le même souci avec la base MySQL de sympa (qui devra probablement être convertie…) -> les modifications faites sur la base MySQL de sympa le temps de la MàJ seront perdues.

D'une manière générale, vérifier que mercure-lenny fonctionnera bien ne sera pas forcément trivial.

mercure_etch -> e3.8
mercure.cfg : e1.13
phy:/dev/etherd/e0.0,hda10,r',
@IP : .106, et @mac : :70

Désactivation du fsck régulier pour éviter qu'il ne tourne au reboot de mercure.

On a gardé /var/lib/postfix dans / : bonne idée ?

Fichiers modifiés après avoir monté mercure en local :

network/interfaces, udev/rules/...persistent-net, ssh/sshd_config, fstab

mercure-lenny relancée sur galaad.

Après le premier allumage, éteindre amavisd, postgrey, spamd, whitelister, clamd n'a pas réussi à démarrer sans /var/log, authdaemond, imapd, pop3d, inn2, postfix, sympa, apache, munin.

Il a fallu fusionner à la main divers fichiers de configuration : /etc/default/saslauthd, /etc/courier/pop3d-ssl, /etc/courier/imapd, /etc/courier/imapd-ssl, vérifier /etc/amavis/conf.d/15-content_filter_mode, /etc/amavis/conf.d/50-user.

WWSympa : modification de la position de la CSS.

sympa : il a fallu refaire le lien /var/lib/sympa -> /srv/mail/lib-sympa

Recoder les descriptions de listes en UTF-8 (puisqu'au moment de l'upgrade, sympa --upgrade ne pouvait pas voir les vrais définitions de listes).

Sympa n'avait pas accès à ses bases de données, les mots de passe ont dû être restaurés depuis un backup (changement subtile dans le format de la base de données ? je n'ai rien vu pour ma part…)

La partition des mail et de sympa (le gestionnaire des listes de diffusion) est séparée de la partition racine. Je m’étais dit que chouette, les mails vont continuer à vivre leur vie, et lors du basculement sur la version de mercure mise à jour, on va récupérer la queue des mails, et les modifications faites par les lusers sur les fichiers de conf de sympa, tout ça. Le problème, c’est qu’il s’est passé avec les fichiers de conf ce que je craignais avec les base SQL de sympa : l’un des scripts post-upgrade de sympa a fait des modifications (une sombre histoire d’encodage des fichiers) sur les configurations des listes de diffusion. Lors du basculement sur la version de mercure mise à jour, sympa n’avait plus les fichiers dans le format qu’il attendait, et a refusé de redémarrer. Dans le même genre, les seuils des spams ont dû changer, et après le passage à mercure-lenny, plein de spams ont été acceptés ; on a eu aussi des problèmes avec les mots de passe sur sympa.

En résumé, on a eu deux soucis : les modifications sur les fichiers de configuration des listes de diffusion par les scripts post-upgrade de Debian ont été perdues. L’alternative était de perdre les modifications faites sur ces fichiers par les lusers le temps de l’upgrade (et non, je ne me voyais pas faire le merge à la main). L’autre souci, c’est que certains effets de la mise à jour ne peuvent se manifester que lors du passage en production.

La mécanique des snapshots en elle-même a bien fonctionné ; j’ai pu tester, en étant serein, un certain nombre de services de mercure avant le basculement. Xen en permettant de lancer rapidement une copie d’une machine sur un snapshot a également été utile (pour une fois au ResEl ?).