Une traduction de l'article a été préparée spécialement pour les étudiants du cours Administrateur Linux .
Nous traitons de la capacité de systemd à exécuter des conteneurs pour restaurer le système de fichiers racine d'un système endommagé.
Tant que les systèmes GNU / Linux existent, les administrateurs système devront se remettre des dommages causés au système de fichiers racine, des modifications accidentelles de la configuration ou d'autres situations qui empêchent le système de se charger dans un état «normal».En règle générale, les distributions Linux offrent une ou plusieurs options de menu au démarrage (par exemple, dans le menu GRUB) qui peuvent être utilisées pour réparer un système endommagé; ils démarrent souvent le système en mode mono-utilisateur avec l'arrêt de la plupart des services système. 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 lourde de difficultés pouvant entraîner des pertes de temps et des frustrations, alors que le système doit être restauré.
Plus important encore, toutes ces méthodes supposent que le système endommagé possède une sorte de console physique, mais à l'ère du cloud computing, cela ne peut plus être utilisé. Sans console physique, il n'y a que quelques options (si elles sont encore disponibles) pour influencer le processus de démarrage de cette manière. Même les machines physiques peuvent se révéler être de petits appareils intégrés qui n'ont pas de console facile à utiliser, et trouver les bons câbles et adaptateurs de port série et configurer un émulateur de terminal, tout pour utiliser la console sur un port série en cas d'urgence est souvent assez compliqué.
Lorsqu'un autre système est disponible (de la même architecture et d'une configuration généralement similaire), un moyen général de simplifier le processus de récupération consiste à supprimer 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. Sur les systèmes physiques, cela est généralement simple, et la plupart des plates-formes de cloud computing peuvent également le prendre en charge, car elles vous permettent de monter le volume racine de l'instance endommagée dans une autre instance.
Une fois le système de fichiers racine connecté à un autre système, le problème de corruption du système de fichiers est résolu à l'aide de
fsck et d'autres outils. Le dépannage des erreurs de configuration, des packages corrompus ou d'autres problèmes peut être plus difficile car ils nécessitent que vous montiez le système de fichiers et que vous trouviez et modifiez les fichiers de configuration ou bases de données appropriés.
Utilisation de systemd
Avant l'avènement de
systemd, la façon de corriger les configurations dans la pratique était d'éditer les fichiers de configuration à l'aide d'un éditeur de texte. La recherche des fichiers nécessaires et la compréhension de leur contenu est une tâche distincte qui dépasse le cadre de cet article.
Lorsque le système GNU / Linux utilise
systemd , de nombreux changements de configuration sont mieux effectués en utilisant les outils qu'il fournit - par exemple, l'activation ou la désactivation des services nécessite la création ou la suppression de liens symboliques à divers endroits. L'outil
systemctl est utilisé pour effectuer ces modifications, mais son utilisation nécessite que l'instance
systemd fonctionne et écoute les demandes (via D-Bus). Lorsque le système de fichiers racine est monté en tant que système de fichiers supplémentaire sur un autre ordinateur, une instance de travail de systemd ne peut pas être utilisée pour effectuer ces modifications.
Le démarrage manuel du système du système cible est également peu pratique, car il est conçu comme un processus PID 1 pour contrôler tous les autres processus, ce qui peut entrer en conflit avec une instance déjà en cours d'exécution dans le système utilisé pour la correction.
Heureusement,
systemd a la capacité d'exécuter des conteneurs - des systèmes GNU / Linux entièrement encapsulés avec leur propre PID 1 et leur propre environnement, qui utilise diverses fonctionnalités d'espace de noms offertes par le noyau Linux. Contrairement aux outils comme Docker et Rocket,
systemd ne nécessite pas d'image de conteneur pour exécuter le conteneur; il peut l'exécuter avec les privilèges root n'importe où dans le système de fichiers existant. Cela se fait à l'aide de l'
outil systemd-nspawn , qui créera les espaces de noms système nécessaires et démarrera le processus initial dans le conteneur, puis fournira la console. Contrairement à
chroot , qui ne change que la racine visible 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 dans
/ dev ,
/ run et
/ proc , ainsi qu'un espace de noms de processus et IPC séparés. Visitez la
principale ressource systemd-nspawn pour en savoir plus sur ses fonctionnalités.
Un exemple pour montrer comment cela fonctionne
Dans cet exemple, un périphérique de stockage contenant le système de fichiers racine du système endommagé est connecté à 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 résider dans une partition à l'intérieur du périphérique; étant donné que la configuration la plus courante (simple) place le système de fichiers racine dans la première partition du périphérique,
/ dev / vdc1 sera utilisé dans cet exemple.
Assurez-vous de remplacer le nom de périphérique dans les commandes ci-dessous par le nom de périphérique correct de votre système .
Un système de fichiers racine endommagé peut également être plus complexe qu'un système de fichiers distinct sur un périphérique; il peut s'agir d'un volume en LVM ou sur un ensemble de périphériques combinés dans une matrice RAID. Dans ces cas, vous devez effectuer les étapes nécessaires pour créer et activer un périphérique logique contenant le système de fichiers avant qu'il ne soit disponible pour le montage. Encore une fois, ces étapes dépassent le cadre de cet article.
Préparations nécessaires
Tout d'abord, assurez-vous que l'outil systemd-nspawn est installé - la plupart des distributions GNU / Linux ne l'installent pas par défaut. Il est fourni par le package systemd-container sur la plupart des distributions, donc utilisez le gestionnaire de packages de votre distribution pour l'installer. Les instructions de cet exemple ont été testées à l'aide de Debian 9, mais devraient fonctionner de manière similaire sur toute distribution GNU / Linux moderne.
L'utilisation des commandes ci-dessous nécessitera presque certainement des privilèges root, vous devrez donc vous connecter en tant que root, utiliser sudo pour obtenir un shell avec des privilèges root, ou ajouter le préfixe sudo à chaque commande.
Vérifier et monter le système de fichiers
Utilisez d'abord fsck pour vérifier les structures et le contenu du système de fichiers cible:
$ fsck /dev/vdc1
S'il trouve des problèmes avec le système de fichiers, répondez aux questions en conséquence pour les résoudre. Si le système de fichiers est gravement endommagé, il ne peut pas être réparé, auquel cas vous devrez chercher d'autres moyens d'extraire son contenu.
Créez maintenant un répertoire temporaire et montez-y le système de fichiers cible:
$ mkdir /tmp/target-rescue $ mount /dev/vdc1 /tmp/target-rescue
Lorsque le système de fichiers est monté, exécutez le conteneur avec lui comme système de fichiers racine:
$ systemd-nspawn --directory /tmp/target-rescue --boot -- --unit rescue.target
Arguments de ligne de commande pour démarrer le conteneur:
- --directory / tmp / target-rescue fournit le chemin d'accès au système de fichiers racine du conteneur.
- --boot recherche un programme d'initialisation approprié dans le système de fichiers racine du conteneur et le démarre, en lui passant des paramètres depuis la ligne de commande. Dans cet exemple, le système cible utilise également systemd comme PID 1 du processus, donc les autres paramètres sont pour lui. Si le système cible que vous restaurez utilise un autre outil comme PID 1 du processus, vous devez configurer les paramètres en conséquence.
- - Séparer les paramètres de systemd-nspawn de ceux destinés au PID 1 du processus de 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. Pour simplifier les opérations de récupération sur le système cible, démarrez-le en mode «récupération» plutôt qu'en mode multi-utilisateur normal.
Si tout se passe bien, vous devriez voir une sortie qui ressemble à 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 que
systemd démarre en tant que processus d'initialisation dans le conteneur et détermine qu'il s'exécute à l'intérieur du conteneur afin qu'il puisse ajuster son comportement en conséquence. Pour mettre le conteneur en état de fonctionnement, différents fichiers d'unité sont lancés, puis le mot de passe root du système cible est demandé. Vous pouvez entrer le mot de passe root ici si vous souhaitez demander un shell avec des privilèges root, ou vous pouvez appuyer sur
Ctrl + D pour continuer le processus de démarrage, qui affichera l'invite de connexion de console habituelle.
Lorsque vous apportez les modifications nécessaires au système cible, appuyez trois fois de suite sur
Ctrl +] ; cela fermera le conteneur et vous ramènera à la coque d'origine. De là, vous pouvez effectuer le nettoyage 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 tout! Vous pouvez maintenant supprimer les périphériques de stockage du système cible et les renvoyer.
L'idée d'utiliser
systemd-nspawn de cette manière, en particulier
l'option --boot , est venue d'une
question publiée sur StackExchange. Merci à Shibumi et kirbyfan64sos pour les réponses utiles à cette question!Plus de ressources Linux