Depuis que les systèmes GNU/Linux existent, les administrateurs système ont dû se remettre d'une corruption du système de fichiers racine, de changements de configuration accidentels ou d'autres situations qui empêchaient le système de démarrer dans un état "normal".
Les distributions Linux offrent généralement une ou plusieurs options de menu au démarrage (par exemple, dans le menu GRUB) qui peuvent être utilisées pour sauver un système en panne ; généralement, ils démarrent le système en mode mono-utilisateur avec la plupart des services système désactivés. Dans le pire des cas, l'utilisateur peut modifier la ligne de commande du noyau dans le chargeur de démarrage pour utiliser le shell standard comme processus d'initialisation (PID 1). Cette méthode est la plus complexe et la plus compliquée, ce qui peut entraîner de la frustration et une perte de temps lorsqu'un système doit être récupéré.
Plus de ressources Linux
- Aide-mémoire des commandes Linux
- Aide-mémoire des commandes Linux avancées
- Cours en ligne gratuit :Présentation technique de RHEL
- Aide-mémoire sur le réseau Linux
- Aide-mémoire SELinux
- Aide-mémoire sur les commandes courantes de Linux
- Que sont les conteneurs Linux ?
- Nos derniers articles Linux
Plus important encore, ces méthodes supposent toutes que le système endommagé possède une console physique quelconque, mais ce n'est plus une évidence à l'ère du cloud computing. Sans console physique, il existe peu d'options (voire aucune) pour influencer le processus de démarrage de cette manière. Même les machines physiques peuvent être de petits appareils intégrés qui n'offrent pas une console facile à utiliser, et trouver les câbles et adaptateurs de port série appropriés et configurer un émulateur de terminal série, le tout pour utiliser un port de console série tout en traitant un d'urgence, c'est souvent compliqué.
Lorsqu'un autre système (de la même architecture et de configuration généralement similaire) est disponible, une technique courante pour simplifier le processus de réparation consiste à extraire le ou les périphériques de stockage du système endommagé et à les connecter au système de travail en tant que périphériques secondaires. Avec les systèmes physiques, cela est généralement simple, mais la plupart des plates-formes de cloud computing peuvent également le prendre en charge car elles permettent de monter le volume de stockage racine de l'instance endommagée sur une autre instance.
Une fois que le système de fichiers racine est associé à un autre système, la résolution de la corruption du système de fichiers est simple à l'aide de fsck et autres outils. La résolution des erreurs de configuration, des packages cassés ou d'autres problèmes peut être plus complexe car ils nécessitent de monter le système de fichiers et de localiser et de modifier les fichiers de configuration ou les bases de données appropriés.
Utiliser systemd
Avant systemd , l'édition des fichiers de configuration avec un éditeur de texte était un moyen pratique de corriger une configuration. Localiser les fichiers nécessaires et comprendre leur contenu peut être un défi distinct, qui dépasse le cadre de cet article.
Lorsque le système GNU/Linux utilise systemd cependant, de nombreuses modifications de configuration sont mieux effectuées à l'aide des outils qu'il fournit - l'activation et la désactivation des services, par exemple, nécessitent la création ou la suppression de liens symboliques à divers endroits. Le systemctl L'outil est utilisé pour effectuer ces modifications, mais son utilisation nécessite un systemd instance à exécuter et à écouter (sur D-Bus) les requêtes. Lorsque le système de fichiers racine est monté en tant que système de fichiers supplémentaire sur une autre machine, le systemd en cours d'exécution l'instance ne peut pas être utilisée pour apporter ces modifications.
Lancer manuellement le systemd du système cible n'est pas pratique non plus, car il est conçu pour être le processus PID 1 sur un système et gérer tous les autres processus, ce qui entrerait en conflit avec l'instance déjà en cours d'exécution sur le système utilisé pour les réparations.
Heureusement, systemd a la capacité de lancer des conteneurs, des systèmes GNU/Linux entièrement encapsulés avec leur propre PID 1 et un environnement qui utilisent diverses fonctionnalités d'espace de noms offertes par le noyau Linux. Contrairement à des outils comme Docker et Rocket, systemd ne nécessite pas d'image de conteneur pour lancer un conteneur ; il peut en lancer un enraciné à n'importe quel point du système de fichiers existant. Ceci est fait en utilisant le systemd-nspawn tool, qui créera les espaces de noms système nécessaires et lancera le processus initial dans le conteneur, puis fournira une console dans le conteneur. Contrairement à chroot , qui ne change que la racine apparente du système de fichiers, ce type de conteneur aura un espace de noms de système de fichiers séparé, des systèmes de fichiers appropriés montés sur /dev , /exécuter , et /proc , ainsi qu'un espace de noms de processus et des espaces de noms IPC distincts. Consultez le systemd-nspawn page de manuel pour en savoir plus sur ses fonctionnalités.
Un exemple pour montrer comment cela fonctionne
Dans cet exemple, le périphérique de stockage contenant le système de fichiers racine du système endommagé a été attaché à un système en cours d'exécution, où il apparaît sous la forme /dev/vdc . Le nom du périphérique varie en fonction du nombre de périphériques de stockage existants, du type de périphérique et de la méthode utilisée pour le connecter au système. Le système de fichiers racine peut utiliser l'intégralité du périphérique de stockage ou se trouver dans une partition du périphérique ; puisque la configuration la plus courante (simple) place le système de fichiers racine dans la première partition du périphérique, cet exemple utilisera /dev/vdc1. Assurez-vous de remplacer le nom de l'appareil dans les commandes ci-dessous par le nom d'appareil correct de votre système.
Le système de fichiers racine endommagé peut également être plus complexe qu'un seul système de fichiers sur un périphérique; il peut s'agir d'un volume dans un ensemble de volumes LVM ou d'un ensemble de périphériques combinés dans un périphérique RAID logiciel. Dans ces cas, les étapes nécessaires pour composer et activer le périphérique logique contenant le système de fichiers doivent être effectuées avant qu'il ne soit disponible pour le montage. Encore une fois, ces étapes sortent du cadre de cet article.
Prérequis
Tout d'abord, assurez-vous que le systemd-nspawn est installé — la plupart des distributions GNU/Linux ne l'installent pas par défaut. Il est fourni par le systemd-container package sur la plupart des distributions, utilisez donc le gestionnaire de packages de votre distribution pour installer ce package. Les instructions de cet exemple ont été testées avec Debian 9 mais devraient fonctionner de la même manière sur n'importe quelle distribution GNU/Linux moderne.
L'utilisation des commandes ci-dessous nécessitera presque certainement des autorisations root, vous devrez donc soit vous connecter en tant que root, soit utiliser sudo pour obtenir un shell avec les permissions root, ou préfixez chacune des commandes avec sudo .
Vérifier et monter le système de fichiers
Tout d'abord, utilisez fsck pour vérifier les structures et le contenu du système de fichiers cible :
$ fsck /dev/vdc1S'il détecte des problèmes avec le système de fichiers, répondez aux questions de manière appropriée pour les corriger. Si le système de fichiers est suffisamment endommagé, il se peut qu'il ne soit pas réparable, auquel cas vous devrez trouver d'autres moyens d'extraire son contenu.
Maintenant, créez un répertoire temporaire et montez le système de fichiers cible sur ce répertoire :
$ mkdir /tmp/target-rescue
$ mount /dev/vdc1 /tmp/target-rescue
Avec le système de fichiers monté, lancez un conteneur avec ce système de fichiers comme système de fichiers racine :
$ systemd-nspawn --directory /tmp/target-rescue --boot -- --unit rescue.targetLes arguments de ligne de commande pour lancer le conteneur sont :
- --répertoire /tmp/target-rescue fournit le chemin du système de fichiers racine du conteneur.
- --démarrer recherche un programme d'initialisation approprié dans le système de fichiers racine du conteneur et le lance, en lui transmettant les paramètres de la ligne de commande. Dans cet exemple, le système cible utilise également systemd comme son processus PID 1, les paramètres restants lui sont donc destinés. Si le système cible que vous réparez utilise un autre outil comme processus PID 1, vous devrez ajuster les paramètres en conséquence.
- -- sépare les paramètres pour systemd-nspawn de ceux destinés au processus PID 1 du conteneur.
- --unit rescue.target indique systemd dans le conteneur le nom de la cible qu'il doit essayer d'atteindre pendant le processus de démarrage. Afin de simplifier les opérations de sauvetage dans le système cible, démarrez-le en mode "rescue" plutôt qu'en mode multi-utilisateur normal.
Si tout se passe bien, vous devriez voir un résultat semblable à ceci :
Spawning container target-rescue on /tmp/target-rescue.
Press ^] three times within 1s to kill container.
systemd 232 running in system mode. (+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN)
Detected virtualization systemd-nspawn.
Detected architecture arm.
Welcome to Debian GNU/Linux 9 (Stretch)!
Set hostname to <test>.
Failed to install release agent, ignoring: No such file or directory
[ OK ] Reached target Swap.
[ OK ] Listening on Journal Socket (/dev/log).
[ OK ] Started Dispatch Password Requests to Console Directory Watch.
[ OK ] Reached target Encrypted Volumes.
[ OK ] Created slice System Slice.
Mounting POSIX Message Queue File System...
[ OK ] Listening on Journal Socket.
Starting Set the console keyboard layout...
Starting Restore / save the current clock...
Starting Journal Service...
Starting Remount Root and Kernel File Systems...
[ OK ] Mounted POSIX Message Queue File System.
[ OK ] Started Journal Service.
[ OK ] Started Remount Root and Kernel File Systems.
Starting Flush Journal to Persistent Storage...
[ OK ] Started Restore / save the current clock.
[ OK ] Started Flush Journal to Persistent Storage.
[ OK ] Started Set the console keyboard layout.
[ OK ] Reached target Local File Systems (Pre).
[ OK ] Reached target Local File Systems.
Starting Create Volatile Files and Directories...
[ OK ] Started Create Volatile Files and Directories.
[ OK ] Reached target System Time Synchronized.
Starting Update UTMP about System Boot/Shutdown...
[ OK ] Started Update UTMP about System Boot/Shutdown.
[ OK ] Reached target System Initialization.
[ OK ] Started Rescue Shell.
[ OK ] Reached target Rescue Mode.
Starting Update UTMP about System Runlevel Changes...
[ OK ] Started Update UTMP about System Runlevel Changes.
You are in rescue mode. After logging in, type "journalctl -xb" to view
system logs, "systemctl reboot" to reboot, "systemctl default" or ^D to
boot into default mode.
Give root password for maintenance
(or press Control-D to continue):
Dans cette sortie, vous pouvez voir systemd lancer en tant que processus d'initialisation dans le conteneur et détecter qu'il est exécuté à l'intérieur d'un conteneur afin qu'il puisse ajuster son comportement de manière appropriée. Divers fichiers unitaires sont lancés pour amener le conteneur dans un état utilisable, puis le mot de passe root du système cible est demandé. Vous pouvez entrer le mot de passe root ici si vous voulez une invite de shell avec des autorisations root, ou vous pouvez appuyer sur Ctrl+D pour permettre au processus de démarrage de se poursuivre, ce qui affichera une invite de connexion normale à la console.
Lorsque vous avez effectué les modifications nécessaires sur le système cible, appuyez sur Ctrl+] trois fois en succession rapide; cela mettra fin au conteneur et vous ramènera à votre shell d'origine. À partir de là, vous pouvez nettoyer en démontant le système de fichiers du système cible et en supprimant le répertoire temporaire :
$ umount /tmp/target-rescue
$ rmdir /tmp/target-rescue
C'est ça! Vous pouvez maintenant supprimer le ou les périphériques de stockage du système cible et les remettre sur le système cible.
L'idée d'utiliser systemd-nspawn de cette façon, en particulier le paramètre --boot , provient d'une question publiée sur StackExchange. Merci à Shibumi et kirbyfan64sos d'avoir fourni des réponses utiles à cette question !