Comment vieillir prématurément : FreeBSD, de 8.1 à 8.2
======================================================
Date: 2011-03-06 17:28
Author: jdn06
Category: Distributions
Tags: FreeBSD, Mises à jour
L’ouvrage classique de Michael W. Lucas sur FreeBSD le dit bien :
« Toute mise à jour d’un système d’exploitation peut accélérer la
pousse de vos cheveux blancs. » (FreeBSD 7.0 chez Pearson, p.387) Il
faut cependant le vivre pour le comprendre.
Hier soir, de retour à la maison, je décidai de faire une pause dans
la correction des montagnes de copies que je dois avoir terminé
de corriger demain. Pause geek donc, avec la mise à jour vers
Wordpress 3.1. Sauvegardes et installation en moins de cinq minutes ;
impeccable.
Comme une pause de cinq minutes est un peu trop courte à mon goût, je
prends une décision de bleu, une vraie : passer dans la foulée un
serveur FreeBSD de 8.1 à 8.2. C’est vrai, quoi : pourquoi rester sur
une vieille branche (même si les màj de sécurité sont assurées pour
un bon moment) alors qu’une nouvelle branche toute belle, toute neuve
et stable est apparue ?
Après une brève lecture du guide de la nouvelle release et de
quelques articles sur les màj de FreeBSD, je lance une magnifique
séquence :
Le changement de noyau ne pose pas de problème, mais le programme de
màj me demande de fusionner à la main dans vi tous les fichiers de
/etc : ça fait un paquet ! Les instructions annonçaient effectivement
pudiquement : « During this process, FreeBSD Update may ask the user
to help by merging some configuration files or by confirming that
the automatically performed merging was done correctly. » Le plus
ridicule (je pèse mes mots) dans l’histoire, c’est que pour 99%
des fichiers, les seules différences concernent le commentaire en
en-tête :
# nsswitch.conf(5) - name service switch configuration file
Un temps fou perdu pour des tâches sans aucun impact sur le
fonctionnement de la machine. Je suis assez agacé, je l’avoue.
J’envoie donc paître l’ordinateur à grands coups de :q dans chaque
fichier ouvert par vi, ayant vérifié que les fichiers restaient ainsi
intacts.
Après une bonne vingtaine de minutes de labeur particulièrement
répétitif et absurde, l’ordinateur reprend chaque fichier et me
demande :
Does this look reasonable (y/n)?
J’appuie donc frénétiquement une centaine de fois sur la touche
« y », manière bourrin, puis je m’aperçois, avec l’arrêt brutal de la
séquence de mise à jour, que je viens de faire une grosse bêtise. Au
lieu de garder inchangés mes fichiers de configuration, ils les a
tous modifiés avec une syntaxe illisible puisqu’il a laissé tous les
magnifiques caractères qui soulignent les différences :
<<<<<<< current version
=======
>>>>>>> 8.2-RELEASE
Résultat : tout mon /etc est devenu inutilisable tel quel.
Heureusement, j’en avais fait une sauvegarde auparavant sur mon poste
de travail, avec scp.
Un peu secoué par la catastrophe en cours, je me lance donc dans le
rétablissement du répertoire /etc initial. Pas facile car le ssh ne
fonctionne plus et le montage de clés USB (que je ne maîtrise pas
bien sous FreeBSD) refuse toute partition en ext2 ou xfs (mon poste
de travail est sous Linux) et n’accepte que fat32, ce qui fait perdre
les droits des fichiers /etc : inacceptable. Je m’en sors avec un tar
des fichiers, copié sur la clé en fat32. Mais je commets deux
erreurs :
- Comme ssh est configuré pour ne pas pouvoir se connecter avec root,
j’ai effectué le scp avec un nom d’utilisateur. Les fichiers qui ne
peuvent être lus que par root sont donc absents de ma sauvegarde
(cela je l’ai évidemment réalisé après avoir tout modifié et
redémarré, devant l’absence de certains fichiers importants… trop
tard…)
- L’autre erreur est beaucoup plus stupide et triviale. Stressé comme
je commence à l’être à l’idée qu’il risque de falloir réinstaller le
serveur et m’en passer plusieurs jours, je redémarre sans avoir
rétabli les propriétaires (root:wheel) des fichiers de /etc.
Le redémarrage qui suit est donc bourré d’erreurs et le login ne
fonctionne plus : tous les authentifications d’utilisateurs ont
disparu, y compris celle de root.
Là, évidemment, difficile de ne pas blêmir. Qu’à cela ne tienne, il
me reste le mode single user. Je redémarre dans ce mode, exécute un
mount -a pour disposer de toutes les commandes, puis réinstalle /etc
en prenant soin de rétablir les propriétaires légitimes : root:wheel.
Après redémarrage, cela ne règle pas tout : je n’ai toujours plus
d’utilisateurs. Redémarrage en mode single user mais la commande
passwd root se termine par une erreur.
Il faut récupérer un fichier master.passwd, lancer une commande :
pwd\_mkdb -p /etc/master.passwd
Puis passwd root fonctionne, mais pour les utilisateurs, il faut les
recréer, après avoir déplacé leur home, puis recopier le contenu dans
le nouvel home créé par la création de l’utilisateur.
Le système est sauvé. Restent les services Apache et MySQL. Plus rien
ne marche !
Après bien des questionnements, une recompilation des deux
(l’utilisateur-système mysql avait disparu de /etc/passwd après la
réinitialisation des comptes utilisateurs), je m’aperçois qu’en fait
chacun essaie de démarrer deux fois : une première fois depuis
/etc/rc.d/ et une seconde fois (comme cela doit être) depuis
/usr/local/etc/rc.d/. Le second démarrage échoue puisque le service
est déjà lancé (mais avec de mauvais paramètres puisqu’il ne va pas
les chercher dans /usr/local/etc/ mais dans /etc/)
Je supprime donc les lanceurs dans /etc/rc.d/ et tout rentre dans
l’ordre.
Ma pause geek aura duré cinq heures au lieu d’une demi-heure… J’en
sors plus expérimenté, certes, mais assez peu reposé.
En conclusion :
- Ne jamais utiliser freebsd-update upgrade. Ça sonne comme du
Debian, mais ça n’est pas du Debian. Il existe plusieurs autres
méthodes de màj ; je ne compte cependant pas les tester de sitôt.
- Répéter la màj sur une machine virtuelle avant de s’attaquer au
serveur : ça prend un peu de temps, mais je suis sûr qu’on en gagne
beaucoup plus qu’on en perd.
- Ne pas mettre à jour un serveur sans nécessité.
- Ne pas mettre à jour un FreeBSD sans avoir plusieurs heures devant
soi. Je pense cependant que cette remarque est à peu près vraie
pour tous les systèmes. C’est là qu’on apprécie vraiment les
rolling release : les petits problèmes sont plus fréquents, mais ils
s’étalent dans le temps.
- Un point positif tout de même : le système est costaud, puisqu’on
parvient à le rétablir, même quand il manque un gros morceau
(l’authentification des utilisateurs et plusieurs autres services)
- Je suis un peu moins « bleu » et un peu plus « blanc » (de cheveux)
