Si vous avez raté le début :
Usul II : le retour du fils de la vengeance (1ère partie)
Usul II : le retour du fils de la vengeance (2ème partie)
La migration matérielle était à présent terminée et le rodage se passait bien. Si bien que la machine a retrouvé deux jours plus tard son coin du placard (non sans un petit coup d'aspirateur au préalable). J'ai continué néanmoins à corriger ou adapter petit à petit la configuration logicielle suite à la montée en version de Debian.
Suite et fin de la série sur Usul II...
Ajustements et corrections : autofs à la rescousse
Le point qui me chagrinait le plus est qu'à chaque reboot depuis le passage à Wheezy, les montages réseaux (CIFS) définis jusque-là dans /etc/fstab bloquaient la séquence de boot car, apparemment, le réseau n'était pas encore disponible à ce moment-là. La seule manière de poursuivre le chargement était de presser S pour sauter le montage, puis une fois arrivé au shell, remonter les partages concernés avec un
# mount -a
Après une bonne phase de recherche sur le web, j'ai réalisé que ce que je faisais jusque-là fonctionnait plus par erreur qu'autre chose !
En effet, il est plutôt :
1. optimiste de penser que les partages réseaux définis dans /etc/fstab seront toujours accessibles au boot de la machine (si le NAS est éteint par exemple),
2. téméraire de les monter au boot sachant que si une erreur se produit (car, par exemple au hasard, le réseau n'est pas encore actif) c'est la séquence de boot entière qui sera suspendue jusqu'à l'action de l'utilisateur.
Les pistes que j'ai trouvées pour ce genre de cas m'ont dirigé vers autofs.
Autofs est un daemon qui va surveiller certains dossiers préalablement configurés et qui, à la première tentative d'accès, va monter de manière transparente la partition ou le partage réseau associé. Pour l'application à l'origine de ce premier accès, elle verra donc immédiatement le contenu de la cible du montage, même si celui-ci était démonté l'instant d'avant. Cela peut bien sûr occasionner un petit délai lors de l'accès déclenchant le montage, mais sans influer sur le déroulement de l'application.
Il ne s'agissait pas de la seule option possible pour ce cas de figure mais cela me semblait être la plus proche de ce que j'avais jusque-là, sachant que je ne tenais pas à dépendre d'un système basé sur FUSE par exemple.
Pour information, sur les distributions plus récentes utilisant de base systemd comme Archlinux (que j'utilise aussi quotidiennement), il est possible d'utiliser directement /etc/fstab en ajoutant simplement l'option "x-systemd.automount" pour arriver au même résultat. Si Systemd suscite encore aujourd'hui beaucoup de critiques négatives (de la part de passéistes intégristes barbus diront les mauvaises langues), j'avoue que certaines fonctionnalités intégrées sont parfois fort pratiques !
Mais revenons à Debian et son antique sysvinit. Un package éponyme est évidemment disponible pour autofs, on l'installera par la commande
# apt-get install autofs
Ceci installe évidemment le script de démarrage /etc/init.d/autofs qu'il ne faudra pas hésiter à utiliser pour appliquer les changements de configuration ultérieurs.
Le fichier principal est situé au chemin /etc/auto.master dans lequel toutes les lignes sont initialement commentées.
Je rajoute la ligne suivante pour mon cas :
/media/autofs/fedaykin /etc/autofs.d/feydakin.smb --ghost
puis je crée le fichier /etc/autofs.d/fedaykin.smb dans lequel je rajoute une ligne par montage souhaité selon le format suivant :
<nom_partage> <options_montage> :<cible>
Par exemple pour ma mp3thèque je saisirai :
music -fstype=cifs,credentials=/root/.samba/fedaykin.cred,file_mode=0660,dir_mode=0770,uid=0,gid=1006 ://192.168.1.200/music
NOTE : il n'y a pas de retours à la ligne dans cette section, mais ma colonne n'est pas assez large pour l'afficher en entier)
Qu'est-ce que cela signifie en clair ? Je vais détailler.
Dans le premier fichier "maître" tout d'abord :
1. Je souhaite monter tous les partages définis dans le fichier /etc/autofs.d/fedaykin.smb dans le dossier /media/autofs/feydakin (créé préalablement).
2. Fedaykin est le nom de mon NAS, je regroupe ainsi tous les partages le concernant dans un fichier dédié afin de faciliter la maintenance que je nomme "feydakin.smb" par pur choix personnel. Le nom du fichier est le nom de la machine distante, l'extension m'indique le protocole utilisé pour ces montages. J'aurais pu lui donner le nom "coincoin.pouet" cela aurait fonctionné de la même manière, tout simplement car ce n'est pas ici que nous définissons les caractérisques de montage, seulement le dossier parent qui va accueillir les points de montage.
3. L'option "--ghost" en fin de ligne force autofs à créer un dossier correspondant à tous les points de montage même si ceux-ci ne sont pas encore montés. Par exemple au boot de la machine le dossier /media/autofs/fedaykin/music sera automatiqement créé, mais sera vide. C'est assez pratique pour ne pas avoir de chemins invalides tant que les montages ne sont pas en place ce qui évite les erreurs potentielles.
Dans le second fichier à présent :
1. Je défini un montage nommé "music" qui donnera son nom au dossier créé à la racine commune pour les montages de ce fichier : /media/autofs/fedaykin (défini dans le premier fichier)
2. Je spécifie les options de montage, c'est-à-dire essentiellement un copier-coller des options qui étaient jusque là dans /etc/fstab, en préfixant simplement par "-fstype=cifs," qui remplace le "smbfs" de fstab. Je ne détaille pas plus les options suivantes, un petit
$ man mount.cifs
vous en dira plus.
3. Enfin, j'indique où se trouve la cible du montage que je viens de définir. La notation est spécifique au protocole. Pour du SMBFS/CIFS j'aurai donc //192.168.1.200/music pour accéder au partage "music" situé sur la machine à l'adresse "192.168.1.200". Il faut cependant penser à préfixer ce chemin par deux-points ":".
4. Si j'ai d'autres partages, je n'ai qu'à les ajouter sur une nouvelle ligne en utilisant toujours le même format en 3 "colonnes". Et ainsi de suite.
That's all folks!
Je n'oublie pas de commenter les lignes correspondantes dans le fichier /etc/fstab, puis je reboote.
Et cette fois je n'ai plus aucune erreur ! Je tente immédiatement un :
$ ls /media/autofs/fedaykin/music
et après une courte attente (liée au montage automatique par autofs en arrière-plan), le contenu du partage "music" du NAS s'affiche bien avec les bonnes permissions, exactement comme il s'affichait auparavant quand il était monté via fstab.
Dovecot-cot-socket
Petit souci supplémentaire dont je ne me suis pas aperçu immédiatement après la montée en version : Postfix semblait ne plus pouvoir envoyer de mails. En fait le problème n'était pas tant au niveau du MTA que du MDA, en l'occurrence Dovecot, dont la configuration avait largement évolué entre la version fournie avec Squeeze (1.2.x) et celle avec Wheezy (2.1.x). Mes fichiers de configuration ne correspondaient plus et les directives qu'ils contenaient ne s'appliquaient plus.
Il faut savoir que l'évolution entre ces versions ne touche pas seulement au format de certaines directives, mais également à leur répartition dans les fichiers de configuration. Auparavant par défaut rassemblées dans un unique fichier de 3Km de haut au chemin /etc/dovecot/dovecot.conf, elles sont maintenant éclatées, réparties par fonctionnalités dans des fichiers aux noms explicites situés dans le dossier /etc/dovecot/conf.d (comme c'est de plus en plus l'usage sur Debian).
Ce qu'il m'a fallu principalement reporter ce sont les directives de mise à disposition de l'authentification par socket, permettant à Postfix de déléguer l'authentification à Dovecot.
Mon fichier /etc/dovecot/dovecont.conf en version 1.x avait la section suivante aux alentours de la ligne 1140 (rien que ça...) :
...
socket listen {
# Client for postfix SASL
client {
path = /var/spool/postfix/private/dovecot-auth
mode = 0660
user = postfix
group = postfix
}
}
...
J'ai reporté cette section dans le fichier de configuration correspondant dans la version 2.x, c'est à dire /etc/dovecot/conf.d/10-master.conf :
service auth {
[...]
# Postfix smtp-auth
unix_listener /var/spool/postfix/private/dovecot-auth {
mode = 0660
user = postfix
group = postfix
}
[...]
}
La section générale "service auth" était déjà présente. J'ai simplement ajouté/décommenté la sous-section "unix_listener" que j'ai adaptée. Les "[...]" signalent que d'autres sous-sections sont présentes et sont à laisser telles quelles.
Un petit
# /etc/init.d/dovecot restart
# /etc/init.d/postfix restart
suivi d'un :
# ls -l /var/spool/postfix/private/dovecot-auth
srw-rw---- 1 postfix postfix 0 janv. 8 13:59 /var/spool/postfix/private/dovecot-auth
pour vérifier que le socket a bien été créé. Et c'est bon, on peut à nouveau envoyer des zimèles depuis l'extérieur de la machine !
Watchdog
Tout allait pour le mieux (et cette section ne serait pas là si j'avais moins tardé à publier ce post) quand soudain, courant décembre, mon serveur chéri s'est subitement mis à ne plus répondre.
Plus d'accès SSH, plus aucune réponse d'Apache ni de Webmin, rien de rien. J'ai alors branché un moniteur et un clavier sur la tour pour tenter d'en savoir plus sur l'état de la machine, mais le moniteur est resté désespérément en veille malgré mes appuis sur différentes touches.
J'ai dû me résoudre au fait que je faisais face à un crash (du genre plutôt méchant).
J'ai rebooté puis j'ai immédiatement consulté les logs et graphes de charge : chou blanc. Aucun indice ne permettait de comprendre ce qu'il s'était passé. S'il y a bien une chose pire qu'un crash complet de Linux, c'est être incapable d'en déceler l'origine.
J'ai espéré que ce cas resterait exceptionnel et considéré que cela pouvait arriver aux meilleurs (on se rassure comme on peut). Mais je ne tenais pas à ce que, s'il devait se reproduire, je sois obligé d'intervenir manuellement sur la machine, tout simplement car d'après la loi de Murphy, au moment où cela se produira je serai loin, et j'aurai un besoin urgent de la machine et ses services.
La solution ici était de confier la vie de la machine à un watchdog.
(Source : http://www.deviantart.com/art/Life-monitor-175803629)
Je résume rapidement le principe du watchdog (ou "chien de garde" en françois du sud) : un composant matériel (bien) ou logiciel (moins bien) décrémente régulièrement un compteur initialement à N jusqu'à 0. Lorsque 0 est atteint, la machine est rebootée, de manière "soft" ou de manière "hard".
Afin d'éviter le reboot lorsque 0 est atteint, un processus du système est chargé de réinitialiser régulièrement le compteur à N. Tant que ce processus arrive à réinitialiser le compteur, c'est que - a priori - le système n'est pas planté (au moins le noyau donne régulièrement la main à ce processus qui peut faire son travail, ce qui est une bonne évaluation de "pas planté").
Si le système plante (ou est considéré planté(*)) le processus ne réinitialisera plus le compteur. Le watchdog décrémentera lui toujours le compteur et arrivé à 0, il rebootera la machine.
Ça, c'est la version avec un watchdog matériel, mais ni tous les PC ni tous les CPU ne disposent nécessairement d'un watchdog matériel, c'est à dire indépendant des processus exécutés par le CPU. Je ne détaillerai pas ce cas ici mais il existe donc une "émulation" du watchdog sous Linux appelée "softdog" qui, au lieu de rebooter brusquement (mais efficacement) la machine, ordonne au noyau d'effectuer un reboot. Mais vous l'aurez compris : si le noyau lui-même est planté, cela ne sera d'aucun secours...
La première chose à faire dans ce cas de figure est de vérifier si la machine ou le CPU dispose d'un watchdog matériel. Pour cela, on peut utiliser la commande simple suivante :
$ ls -l /dev/watchdog
crw------- 1 root root 10, 130 déc. 21 13:18 /dev/watchdog
Le fichier spécial existe, ce qui signifie très probablement qu'un watchdog est présent et reconnu par le noyau. Pour s'en assurer on peut utiliser la deuxième commande suivante :
$ dmesg | grep -iE "(wdt|watchdog)
[ 5.434643] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.07
[ 5.434926] iTCO_wdt: Found a NM10 TCO device (Version=2, TCOBASE=0x0460)
[ 5.435133] iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0)
Là on en est sûr : un watchdog existe (ici c'est celui inclus dans le chipset NM10 d'Intel, Atom oblige) et est utilisable. On apprend aussi que son "timeout" est de 30 secondes (troisième ligne), c'est au bout de ce temps qu'il reboote la machine si rien n'a réinitialisé le compteur. On apprend aussi que c'est le pilote noyau "iTCO_wdt" qui est chargé de sa gestion (voir la liste complète des pilotes et de leur options ici).
Il ne reste plus qu'à activer et configurer le daemon watchdog de Linux. Pour cela, rien de plus simple :
# nano /etc/watchdog.conf
et décommenter la ligne :
watchdog-device = /dev/watchdog
Puis pour activer le daemon au boot :
# nano /etc/default/watchdog
et décommenter/passer la valeur à 1 :
run_watchdog=1
On peut aussi en profiter pour vérifier que le pilote trouvé un précédemment est bien celui noté sur la ligne :
watchdog_module="iTCO_wdt"
On lance enfin le daemon :
# /etc/init.d/watchdog start
Pour tester : on va simuler un crash en empêchant le daemon de réinitialiser le compteur. Si on arrête "proprement" le dameon, le watchdog ne rebootera pas la machine car actuellement celui-ci est configuré en "nowayout=0" (c.f. résultat de la deuxième commande), c'est-à-dire qu'il reste possible de fermer le fichier /dev/watchdog de manière à ce que le watchodg comprenne qu'il doive arrêter son travail, et donc ne pas rebooter la machine. C'est ce qui se passe si on arrête le daemon en utilisant le script dans /etc/init.d.
Une manière de procéder est comme suivant (source) :
# touch /forcefsck
# sync
# pkill -9 watchdog
# for n in $(seq 1 60); do echo $n; sleep 1; sync; done
J'ajouterai personnellement que j'ai préféré aussi stopper proprement les principaux daemons (notamment Subsonic, MPD, Samba, ...) avant de les jouer.
L'effet est très simple : on force une vérification des disques au prochain reboot (parce que l'arrêt aura été brutal), on force l'écriture sur disque des données en attente, puis on tue le processus du daemon watchdog (donc pas de fermeture propre du fichier). On attend ensuite le reboot automatique pendant 60 secondes en forçant l'écriture des données sur disque toutes les secondes afin d'éviter au maximum les corruptions.
Et au bout de 30 secondes (chez moi) : boum ! Le PC reboote automatiquement, signalant le succès de l'opération. Je peux à présent ressortir de chez moi sans craindre de ne plus accéder à mon serveur à cause d'un crash (qui ne s'est pas encore reproduit par ailleurs).
(*) Mon utilisation ici est la plus simple qui soit, mais il est possible de configurer le daemon pour qu'il considère la machine comme "plantée" selon différents critères : ping d'une machine, charge moyenne, mémoire libre, température, etc. Consulter le fichier /etc/watchdog.conf pour en savoir plus.