Vous vous souvenez peut-être de mes déboires lors de la dernière mise
à jour de FreeBSD. J’ai réussi à faire encore plus fort cette
fois-ci… Pourtant, tout avait bien commencé. J’avais tenu mes bonnes
résolutions d’alors et avais répété la manœuvre sur une machine
virtuelle. Cette machine ne servait pas d’ailleurs qu’à répéter :
grâce au système des jails – dont je ne dirais jamais assez de bien –
il s’agissait de transférer tous les services en ligne sur la machine
virtuelle pendant que je mettais à jour le serveur en dur. Comme ça,
même en cas de pépin, pas d’interruption de service et donc pas de
coup de stress. Eh bien, j’ai rudement bien fait de procéder ainsi.
Comme je suis joueur, je décide de réutiliser freebsd-update et lance
la procédure sur ma machine virtuelle :
- Copier le /etc et vérifier la copie (ne pas faire deux fois la même
bêtise…)
- Remettre un noyau générique dans /boot/GENERIC
- Lancer un petit nextboot -k GENERIC et redémarrer
- freebsd-update -r 8.3-RELEASE upgrade
- La machine répond par _Preparing to download files… done.- Fetching
27286 patches_ - Prévoir donc un bon moment
- Puis se lance le merge des fichiers de config : _21 files changed,
119 insertions(+), 117 deletions(-)_ L’instrument est toujours
aussi mal fait, surtout en comparaison de mergemaster que j’ai
appris à utiliser entre temps. Pourquoi n’est-il pas intégré à
freebsd-update ? Cela me dépasse… et donne très envie de ne plus
mettre à jour que par les sources ; mais je m’obstine.
- freebsd-update install
- nextboot -k GENERIC à nouveau puis reboot
- freebsd-update install
- Ensuite, je mets à jour les ports puis je recompile tous les
logiciels tiers avec portmaster -afd
- nextboot -k GENERIC à nouveau puis reboot
- Je recompile ensuite mon noyau perso allégé et qui intègre ALTQ et
redémarre
- J’arrête les jails et lance un ezjail-admin update -s 8.3-RELEASE
-u
- Ensuite il ne reste plus qu’à effectuer un mergemaster de chaque
jail :
mount_nullfs /usr/src /usr/jails/jail1/mnt #Depuis l’extérieur de
la jail
echo "IGNORE_FILES='/boot/device.hints /etc/motd /etc/hosts'" >\
/etc/mergemaster.rc #Depuis l’intérieur de la jail
mergemaster -iFU -m /mnt
- et une recompilation des logiciels tiers avec portmaster -afd après
un ezjail-admin update -P
L’ensemble est assez long, mais se déroule parfaitement. Je prends
note du détail de la procédure, transfère le routage vers le serveur
virtuel et me lance dans la mise à jour du véritable serveur. Comme
j’ai pu mesurer la longueur du téléchargement et de l’application
des patches, je le laisse tourner la nuit suivante pour s’y
employer. Au matin, je retrouve la machine méchamment plantée. Au
redémarrage le fsck de la partition qui contient /var bloque. Il faut
dire que la partition est pleine à 109%. J’ai oublié de vider
/var/db/freebsd-update/files et les patches téléchargés ont rempli
la partition à bloc. Lorsque j’essaie de libérer de l’espace,
l’opération plante, comme si l’écriture des métadonnées n’était plus
possible tant le disque était plein. Je redémarre en single user,
puis même avec la clé USB d’installation pour un fixit. Rien n’y
fait : je descends à 105%, mais le disque finit toujours par planter
et le fsck qui suit réécrit dans lost+found les fichiers effacés.
Je suis assez agacé, et cette fois, le problème paraît paradoxalement
plus compliqué à régler que la dernière fois : je pourrais formater
la partition et la réinstaller depuis une sauvegarde, mais je finis
par me dire que c’est peut-être le bon moment pour réinstaller le
système et régler les problèmes d’alignement que j’avais sur les
systèmes de fichiers présents sur des supports SSD et faire passer ma
partition /var de 6 Go à 12 Go.
La mise à jour se transforme donc en installation de 8.3. Comme
je veux utiliser des partitions gpt, je renonce à utiliser le
traditionnel sysinstall et me lance dans une installation à la main,
qui rappelle beaucoup OpenBSD, en suivant un tutoriel.
L’installation se déroule très bien et je peux utiliser mergemaster,
pour mettre à jour mes anciens fichiers de configuration. Mais le
disque dur USB sur lequel se trouvent mes jails n’est plus reconnu au
démarrage, pour une raison qui je crois m’échappera définitivement :
si je le débranche et le rebranche, alors tout rentre dans l’ordre :
pas très pratique pour un serveur, même si les redémarrages sont
rares !
Je vais donc pousser plus loin l’expérimentation et remplacer ce
disque dur par deux autres installés en miroir : en effet, j’avais
connu un vilain crash en janvier et ce disque dur alimenté par USB
reste le point faible de mon serveur. Quant à faire, puisque mes
services sont toujours sur machine virtuelle, passons donc ces
disques dédiés aux jails en ZFS et testons la fiabilité : ce serait
quand même sympathique d’utiliser ça sur mon vieux eeePC 900 32 bits
avec 1Go de ram. En prenant quelques précautions, l’ensemble semble
tout à fait opérationnel. En lançant plusieurs grosses copies en même
temps, le serveur semble tenir la charge. Après 2 semaines en
utilisation réelle, je n’ai pas constaté de problème. Et le gain
d’administration dépasse encore mes attentes. Mais laissons cela pour
un prochain article.
Mes conclusions restent à peu près inchangées depuis la dernière mise
à jour :
- Éviter freebsd-update upgrade
- Répéter l’opération en virtuel
- Disposer de pas mal de temps devant soi
