jeudi 14 mai 2015

Un conte d'horreur pour sysadmins

Journal d'un sysadmin bénévole - mercredi 13 mai, 20h

Je suis enfin rentré chez moi après une fructueuse journée de travail. Je m'installe dans mon canapé avec ma tablette, lance mon client ssh, attache mon tmux, dans lequel tourne mon client IRC.

Immédiatement, un détail m'interpelle, un enigmatique message dans le log de mes messages privés: "c'est quoi ce bordel ?"

Je lance /map dans mon client. Urgh. Sur la vingtaine de serveurs, réels ou virtuels, de notre petit réseau IRC privé, seule une poignée subsiste. Le site faisait tourner les services est hors circuit. Les admins responsables sont injoignables. Je peste intérieurement. La dernière fois que c'était arrivé, j'avais hurlé pour qu'un backup soit prêt a prendre le relais, ça n'a pas été fait. Tant pis.

En attendant, et ne sachant pas combien de temps durera la panne, je décide de préparer mon site a prendre le relais; je lance la compilation d'Atheme, puis joue un peu avec ma tablette en attendant.

mercredi 13 mai, 21h

Je retourne sur mon client SSH pour vérifier la progression de la compilation. Tiens, il s'est déconnecté. Je le relance. Il refuse de se connecter... plus de réseau ? je visite un site web au hasard, ça fonctionne. Bizarre.

Je vais chercher mon laptop sous windows. J'ouvre un client SSH. Le verdict est sans appel:

Cannot open session: PTY allocation failed.

Allons bon.. voila qui est mauvais. Je vais chercher mon eeePC sous gentoo, et lance la connexion ssh. Le shell se lance, effectivement sans PTY, donc sans prompt, sans couleurs, sans readline, rien. MAIS, il fonctionne. Qu'a-il donc pu se passer ? J'essaie d'attacher mon ancienne session.

open terminal failed: not a terminal

Evidemment. Un horrible pressentiment s'empare de moi...

uptime
21:14:32 up 1 min, 1 user, load average: 0.01, 0.01, 0.01

Mon monde s'écroule. Cette machine avait passé 1000 jours d'uptime. C'est déja un miracle qu'elle aie redémarré proprement. Elle tourne encore un kernel 2.6 openvz, un vieil openrc, un vieil udev...

su: must be run from a terminal

Voila autre chose. Impossible d'inspecter la situation sans un accès root. Je pars a la recherche d'une 3e machine, celle qui contient une clef ssh de secours, qui me permettra d'accéder directement au compte root.

La situation m'est familière; j'ai eu un ennui similaire sur mon eeePC, pendant une mise à jour d'openrc. Pour une raison bizarre, le script de boot responsable de monter le devpts sur /dev/pts se déclenche AVANT le montage d'un devtmpfs sur /dev, avec pour résultat un /dev/pts vide. En attendant, je remonte le /dev/pts à la main. Mon client SSH sur la tablette refonctionne, ouf.

Pour assainir le système, je procède enfin aux mises a jour que je procrastine depuis longtemps: udev (cauchemar), openrc, et le kernel. Dépendances et blocages se succèdent dans tous les sens.

jeudi 14 mai, 00h

Alors que mon nouveau kernel compile, je perds de nouveau la connexion. Petit instant d'angoisse; quelques minutes après, le serveur est de nouveau atteignable, mais la compilation a été interrompue. Je relance le processus, une fois, puis deux, puis trois, même problème. Quelque chose ne tourne pas rond.

uptime
00:02:14 up 1 min, 1 user, load average: 0.01, 0.01, 0.01

Saloperie. Qu'est-ce qui a bien pu se passer ? je fouille les logs. Rien de suspect. Puis, une intuition:

ipmitool sel list
10 | 05/14/2015 |  00:01:12 | Fan #0x54  | Upper Critical going high
10 | 05/13/2015 |  23:58:55 | Fan #0x54  | Upper Critical going high
10 | 05/13/2015 |  23:56:49 | Fan #0x54  | Upper Critical going high

D'accord. Un ventilateur mort, la machine surchauffe pendant les intensives compilations requises par les mises a jour.. Pas mal de choses commencent à s'expliquer.

Mon kernel est finalement compilé, mon udev est a jour. Je monte /boot, lance le make install, reconstruit mon initramfs avec genkernel, vérifie la configuration de grub, tout a l'air correct... Je me prépare a redémarrer. Mais un doute me taraude. Udev a été mis a jour, openrc également, j'ai un mauvais pressentiment. Et si l'interface réseau ne repart pas correctement ?

Cette machine n'a pas de KVM, on travaille sans filet. Si l'interface réseau ne repart pas, je suis bon pour attendre vendredi pour aller la dépanner physiquement. Pendant ce temps, tous les gens qui dépendent de cette machine (les amis d'IRC, et quelques associations) en pâtiront. Je décide de me préparer au pire.

Par chance, cette machine est cohébergée avec un deuxième serveur, lui-même parfaitement opérationnel. Un cable réseau croisé relie les deux systèmes, je décide de l'exploiter, et installe le script suivant dans /etc/rc.local/backdoor.start:

IFACE=`ip link |grep -B1 xx.xx.xx.xx.xx.xx |head -n1 |cut -d: -f2`
ip link set $IFACE up
ip addr add 10.10.10.10/24 dev $IFACE
nohup nc -l -p 1337 --continuous -e /bin/sh -s 10.10.10.10 &

Oui, c'est un risque sur le plan sécurité; mais l'interface est physiquement isolée du monde extérieur, personne n'est actuellement connecté sur l'autre machine, et nous n'utilisons pas ce subnet.

Je lance le reboot et croise les doigts.

jeudi 14 mai, 02h

Quelque chose n'a pas fonctionné. La machine ne répond ni sur son addresse publique, ni sur l'addresse interne habituelle. J'essaie le ping sur 10.10.10.10. ça répond.

J'ai été bien inspiré d'installer cette petite backdoor. Un nc plus tard, et je suis de nouveau aux commandes de la machine, encore une fois sans PTY, mais l'essentiel est la.

J'inspecte l'état de la machine. OpenSSH n'a pas démarré, et les deux bridges sont éteints. Sans cette backdoor improvisée, la machine était perdue. J'essaie de démarrer une des deux interfaces:

error: cannot create bridge

Je revérifie la configuration réseau, elle est correcte. Je met a jour bridge-utils. J'essaie de créer le bridge a la main, rien a faire... la commande échoue silencieusement. Mais enfin, que se passe-il ?

Soudain, l'inspiration me prend:

lsmod

Rien. Nada, zilch, zip, que d'alle. Pas un seul module chargé. Je réalise mon erreur avec horreur.

Je n'ai pas lancé le make modules_install du nouveau kernel.

Par chance, les drivers essentiels (disque et réseau) étaient en dur, tout comme le device-mapper. Un make modules_install plus loin, le module bridge se charge correctement; de tests en tests, tout a l'air de fonctionner. Je relance la machine, elle démarre complètement correctement... le plus gros incident est passé.

Il va maintenant falloir migrer tous les conteneurs d'openvz, qui n'est plus supporté...