Une machine, c'est bien connu, cela ne tombe en rade que dans la nuit ou en week-end. Dés fois, lorsque l'on a un peu de chance, c'est même les deux... Et lorsque le plantage se situe sur une Dédibox, on est un peu dans la mouise, avec Free qui considére que l'administration est une chose qui doit se passer dans des horaires de bureau... Du coup, lorsque la demande porte sur une KVM, nous n'avons plus qu'à attendre tout le week-end avec tous nos sites en carafe...

Fort heureusement il y a l'ami GNU/Linux. Avec celui-là, même si elle n'est pas forcément évidente, il y a toujours une solution de repli. Ici, il s'agit d'exploiter le système de secours de la Dedibox.

Le système de secours des Dedibox

Même si la machine ne répond plus, sauf bien sur si le problème est une carte mère grillée (mais là je crois qu'ils doivent pouvoir faire un effort pour intervenir le week-end), il est toujours possible de démarrer la bête grâce à un protocole réseau (bootp selon toute vraisemblance) et d'y accéder par son IP, via un ssh spécialement lancé pour l'occasion.

Pour accéder à ce mode de votre Dedibox, passez par l'interface d'administration, puis Système de secours et cliquez simplement sur le bouton Passer votre serveur en mode de secours. La machine est ainsi électriquement redémarrée et les identifiant/mot de passe du compte SSH vous sont fournis.

Ce mode consiste en le démarrage d'un noyau linux standard (2.6.24 en l'instance) avec des interfaces réseau correctement montées et une racine placée sur un disque virtuel. Il s'agit finalement de quelque chose d'assez proche du mode "Rescue" de certains CD d'installation (ex. Mandriva) mis à part que les commandes disponibles sont plus nombreuses et n'exploitent pas busibox.

Par défaut, le ssh vous laisse sur une invite "non privilégié", mais vous pouvez passer "root" par un sudo su - en fournissant une seconde fois le mot de passe qui vous a été fourni.

Remontage du serveur

La première chose que l'on cherche à faire avec ce mode, est de monter ses partitions de sorte à aller fouiller dans les logs, ausculter GRUB, mettre à jour des paquets, etc. Pour cela, nous allons utiliser, une fois de plus, la magie du chroot.

# passage en root

gaston$sudo su -

mot de passe: *****

 

# Création de la racine

root#mkdir server

 

# montage des partitions

root#mount /dev/sda2 server

root#mount /dev/sda1 server/boot

 

# montage en mode "bind" des pseudo-dossiers systèmes

root#mount --bind /proc server/proc

root#mount --bind /sys server/sys

root#mount --bind /dev server/dev

 

# Changement de racine

root#chroot server

root@mon_server

Chrootage du serveur

A ce stade vous êtes sur VOTRE serveur, avec la possibilité d'y faire toutes les opérations courantes de réparation, vérification, mise à jour, etc...

Réparation terminée

Lorsque la réparation est faite, ou du moins si vous pensez y être arrivé, vous pouvez redémarrer le serveur en mode "normal". Pour cela il faut d'abord prendre soin de terminer tous les processus que vous auriez lancé au sein du chroot, et d'exécuter les commandes qui vont le défaire :

# on sort du chroot

root@mon_serveurexit

 

# Démontage des binds système

root#umount server/proc

root#umount server/sys

root#umount server/dev

 

# Démontage des partitions

root#umount server/boot

root#umount server

 

# sortie du sudo

root#exit

 

# sortie du ssh

gaston$exit

Maintenant vous pouvez retourner dans l'administration de la Dédibox et cliquer sur le bouton Cliquer ici pour repasser en mode normal. Avec un peu de chance, vous avez bien corrigé et tout refonctionne.

Ça marche po...

Vous en êtes à votre 20^ième passage sur le système de secours, et ça ne marche toujours pas... Vous avez définitivement besoin d'un écran, et donc d'une KVM pour comprendre ce qui coince. Et manque de bol, c'est le week-end, et les messieurs-dames de Free ne répondent plus à ce genre de demande que dans deux jours... En vous promettant de trouver un fournisseur avec un SLA un peu plus sérieux, vous allez tout de même pouvoir appliquer une ou deux béquilles de sorte à garder vos sites en lignes jusque là.

Techniquement le système de secours est juste un Linux, comme le votre. La partie de démarrage du kernel est à peu prés la même, seul les outils de la couche GNU diffèrent. Ainsi une fois en chroot, il n'y a rien ne vous empêche de lancer les services vitaux : postfix, http, firewall, etc. Le seul "problème" est de devoir lancer chaque service à la main en étant sur de ne pas en oublier un...

Comprendre les RunLevels

De manière très simplifiée, le processus de démarrage de GNU/Linux se base sur 5 niveaux.

1. 0 - Arrêt du système
2. 1 - Mode d'administration en utilisateur simple
3. 2 - Mode multi-utilisateur avec réseau mais sans les services réseaux associés (ex. NFS)
4. 3 - Mode multi-utilisateur avec réseau et services associés
5. 4 - Non utilisé.
6. 5 - Mode multi-utilisateur avec réseau et services associés et interface graphique (X11).
7. 6 - Redémarrage.

Un niveau est associé à une série de services qu'il faut démarrer ou arrêter selon le besoin. Par exemple l'arrêt d'une machine revient à arrêter tous les services du niveau 0. De même, un démarrage complet, consiste à lancer tous les services du niveau 5.

Pour avoir la liste des services associés par exemple au niveau 5, un simple ls -la suffit :

root#ls -al /etc/rc.d/rc5/d

drwxr-xr-x 2 root root 4096 2009-07-18 01:53 ./

drwxr-xr-x 11 root root 4096 2009-07-17 19:03 ../

lrwxrwxrwx 1 root root 16 2009-05-12 16:38 S12syslog -> ../init.d/syslog*

lrwxrwxrwx 1 root root 20 2009-07-18 01:53 S50network-up -> ../init.d/network-up*

lrwxrwxrwx 1 root root 19 2009-07-18 01:53 S50syslog-ng -> ../init.d/syslog-ng*

lrwxrwxrwx 1 root root 17 2008-11-18 07:41 S51network -> ../init.d/network*

lrwxrwxrwx 1 root root 16 2009-05-12 16:38 S52firewall -> ../init.d/firewall*

lrwxrwxrwx 1 root root 14 2009-07-17 23:53 S55sshd -> ../init.d/sshd*

lrwxrwxrwx 1 root root 16 2009-07-18 01:53 S56xinetd -> ../init.d/xinetd*

lrwxrwxrwx 1 root root 20 2009-07-18 01:53 S85postgresql -> ../init.d/postgresql*

lrwxrwxrwx 1 root root 15 2009-07-18 01:53 S90crond -> ../init.d/crond*

lrwxrwxrwx 1 root root 15 2009-07-17 23:52 S92httpd -> ../init.d/httpd*

lrwxrwxrwx 1 root root 11 2009-07-17 19:03 S99local -> ../rc.local*

Liste des services du niveau 5

Comme vous le voyez, chaque niveau correspond à un sous-dossier rc.d du répertoire principal : /etc/rc.d. Il contient donc cinq sous-dossiers, un par niveau.

A l'intérieur de chacun d'eux, vous avez une série de liens symboliques, un par service, pointant vers un script de démarrage localisé en /etc/init.d. Le nom des services, un peu étrange, permet dans une première approche d'ordonnancer leur arrêt ou lancement, en les prenant dans l'ordre alphabétique.

Notre tâche va donc être de réaliser un petit script soft-init.sh dont le but sera simplement de lancer ou d'arrêter tous les services du bon niveau, et dans le bon ordre.

Le scrip soft-init.sh

Ce script en bash n'a rien de sorcier, il s'agit simplement de lui fournir un paramètre stop ou start, de déterminer le niveau 0 ou 5, et donc le dossier correspondant à l'arrêt (/etc/rc.d/rc0.d) ou le démarrage (/etc/rc.d/rc5/d). Cec fait, il suffit de lister les liens symboliques en les triant dans l'ordre alphabétique pour lancer ou arrêter les services correspondants.

#!/bin/sh

# choix du niveau en fonction de l'action demandée
if [ $1 == "start" ] ; then
   rc=rc5.d
else
   rc=rc0.d
fi

# Énumération des services
for service in $(ls /etc/rc.d/$rc/* | sort); do
    case $service in
        # on filtre les services à ne pas utiliser dans notre cas : réseau, kill all ou halt
        *network* | *halt* | *kill*)    ;;

        # application de la commande stop|start au services autorisés
        *)
echo        $service $1
         ;;
 esac
done

Le seule point un peu dangereux de ce script est le filtrage des services qu'il ne faut absolument pas lancer ou arrêter. Ce sont ceux qui touche au réseau, à la destruction des processus et à l'arrêt physique de la machine. Pour plus de sécurité, vous remarquerez la commande echo placée juste avant $service. Vous pouvez ainsi, sans risque, tester le script dans ses deux modes et obtenir la liste des services impactés. Si vous en voyez certain qui ne doivent pas apparaître, rajoutez-les dans la clause d'exclusion. Ceci fait, retirez la commande echo du script, la commande est maintenant prête à être utilisée.

root#./soft-init.sh start

Lancement de syslog [OK]

Lancement de syslog-ng [OK]

Lancement de firewall [OK]

Lancement de sshd [OK]

Lancement de xinetd [OK]

Lancement de postgresql [OK]

Lancement de crond [OK]

Lancement de httpd [OK]

Lancement de rc.local [OK]

root#./soft-init.sh stop

Arrêt de httpd [OK]

Arrêt de crond [OK]

Arrêt de postgresql [OK]

Arrêt de xinetd [OK]

Arrêt de sshd [OK]

Arrêt de syslog-ng [OK]

Arrêt de syslog [OK]

Arrêt de firewall [OK]

utilisation de soft-init.sh

Conclusion

Voilà c'est tout simple, et ça marche (la preuve, je suis dans ce mode pour la rédaction de ce papier). Ce n'est évidement pas l'idéal mais cela permet de maintenir sereinement vos sites et vos services vitaux (courriels, etc.) en ligne, en attendant le bon vouloir de votre fournisseur. Notez que ce script peut aussi être bien pratique pour tester les services si c'était l'un deux qui posait problème pour le démarrage de la machine.