Lunixité

Comment vieillir prématurément : FreeBSD, de 8.1 à 8.2

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 :

freebsd-update upgrade -r 8.2-RELEASE
freebsd-update install
reboot
freebsd-update install

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

<<<<<< current version

# \$FreeBSD\$

=======

# \$FreeBSD: src/etc/nsswitch.conf,v 1.1.10.1.6.1 2010/12/21 17:09:25 kensmith Exp \$

>>>>>> 8.2-RELEASE

#

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)

links

social