systemd - oui, tout en minuscules, même au début d'une phrase - est le remplacement moderne des scripts init et SystemV init. C'est aussi beaucoup plus.
Comme la plupart des administrateurs système, quand je pense au programme init et à SystemV, je pense au démarrage et à l'arrêt de Linux et pas vraiment à autre chose, comme la gestion des services une fois qu'ils sont opérationnels. Comme init, systemd est la mère de tous les processus et il est chargé de mettre l'hôte Linux dans un état dans lequel un travail productif peut être effectué. Certaines des fonctions assumées par systemd, qui est beaucoup plus étendue que l'ancien programme init, consistent à gérer de nombreux aspects d'un hôte Linux en cours d'exécution, notamment le montage de systèmes de fichiers, la gestion du matériel, la gestion des minuteries et le démarrage et la gestion des services système requis. pour avoir un hôte Linux productif.
Cette série d'articles, basée en partie sur des extraits de mon cours de formation Linux en trois volumes, Utilisation et administration de Linux :de zéro à sysadmin , explore les fonctions de systemd à la fois au démarrage et après la fin du démarrage.
Démarrage Linux
Le processus complet qui fait passer un hôte Linux d'un état désactivé à un état en cours d'exécution est complexe, mais il est ouvert et connaissable. Avant d'entrer dans les détails, je vais donner un bref aperçu du moment où le matériel hôte est allumé jusqu'à ce que le système soit prêt pour qu'un utilisateur se connecte. La plupart du temps, "le processus de démarrage" est discuté comme une seule entité, mais ce n'est pas exact. Il y a, en fait, trois parties principales dans le processus complet de démarrage et de démarrage :
- Démarrage matériel : Initialise le matériel du système
- Démarrage Linux : Charge le noyau Linux puis systemd
- Démarrage de Linux : Où systemd prépare l'hôte pour un travail productif
La séquence de démarrage Linux commence après que le noyau a chargé init ou systemd, selon que la distribution utilise respectivement l'ancien ou le nouveau démarrage. Les programmes init et systemd démarrent et gèrent tous les autres processus et sont tous deux connus comme la "mère de tous les processus" sur leurs systèmes respectifs.
Il est important de séparer le démarrage matériel du démarrage Linux du démarrage Linux et de définir explicitement les points de démarcation entre eux. Comprendre ces différences et le rôle que chacun joue pour amener un système Linux à un état où il peut être productif permet de gérer ces processus et de mieux déterminer où un problème se produit pendant ce que la plupart des gens appellent "démarrage".
Le processus de démarrage suit le processus de démarrage en trois étapes et amène l'ordinateur Linux à un état opérationnel dans lequel il est utilisable pour un travail productif. Le processus de démarrage commence lorsque le noyau transfère le contrôle de l'hôte à systemd.
polémique systemd
systemd peut évoquer un large éventail de réactions de la part des administrateurs système et d'autres personnes chargées de maintenir les systèmes Linux opérationnels. Le fait que systemd prenne en charge tant de tâches dans de nombreux systèmes Linux a engendré des réactions négatives et de la discorde parmi certains groupes de développeurs et d'administrateurs système.
SystemV et systemd sont deux méthodes différentes pour exécuter la séquence de démarrage de Linux. Les scripts de démarrage SystemV et le programme init sont les anciennes méthodes, et systemd utilisant des cibles est la nouvelle méthode. Bien que la plupart des distributions Linux modernes utilisent le nouveau systemd pour le démarrage, l'arrêt et la gestion des processus, il y en a encore qui ne le font pas. L'une des raisons est que certains mainteneurs de distribution et certains administrateurs système préfèrent l'ancienne méthode SystemV à la nouvelle systemd.
Je pense que les deux ont des avantages.
Pourquoi je préfère SystemV
Je préfère SystemV car il est plus ouvert. Le démarrage s'effectue à l'aide de scripts Bash. Une fois que le noyau a démarré le programme init, qui est un binaire compilé, init lance le rc.sysinit script, qui effectue de nombreuses tâches d'initialisation du système. Après rc.sysinit se termine, init lance /etc/rc.d/rc script, qui à son tour démarre les différents services définis par les scripts de démarrage SystemV dans /etc/rc.d/rcX.d , où "X" est le numéro du niveau d'exécution en cours de démarrage.
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
À l'exception du programme init lui-même, tous ces programmes sont des scripts ouverts et facilement reconnaissables. Il est possible de lire ces scripts et d'apprendre exactement ce qui se passe pendant tout le processus de démarrage, mais je ne pense pas que beaucoup d'administrateurs système le fassent réellement. Chaque script de démarrage est numéroté de sorte qu'il démarre son service prévu dans une séquence spécifique. Les services sont démarrés en série et un seul service démarre à la fois.
systemd, développé par Lennart Poettering et Kay Sievers de Red Hat, est un système complexe de grands exécutables binaires compilés qui ne sont pas compréhensibles sans accès au code source. Il est open source, donc "l'accès au code source" n'est pas difficile, juste moins pratique. systemd semble représenter une réfutation significative de plusieurs principes de la philosophie Linux. En tant que binaire, systemd n'est pas directement ouvert à l'administrateur système pour afficher ou apporter des modifications faciles. systemd essaie de tout faire, comme la gestion des services en cours d'exécution, tout en fournissant beaucoup plus d'informations d'état que SystemV. Il gère également le matériel, les processus et les groupes de processus, les montages de systèmes de fichiers et bien plus encore. systemd est présent dans presque tous les aspects de l'hôte Linux moderne, ce qui en fait l'outil unique pour la gestion du système. Tout cela est une violation flagrante des principes selon lesquels les programmes doivent être petits et que chaque programme doit faire une chose et bien la faire.
Pourquoi je préfère systemd
Je préfère systemd comme mécanisme de démarrage car il démarre autant de services que possible en parallèle, en fonction de l'étape actuelle du processus de démarrage. Cela accélère le démarrage global et amène le système hôte à un écran de connexion plus rapidement que SystemV.
systemd gère presque tous les aspects d'un système Linux en cours d'exécution. Il peut gérer les services en cours d'exécution tout en fournissant beaucoup plus d'informations d'état que SystemV. Il gère également le matériel, les processus et les groupes de processus, les montages de systèmes de fichiers et bien plus encore. systemd est présent dans presque tous les aspects du système d'exploitation Linux moderne, ce qui en fait l'outil unique pour la gestion du système. (Cela vous semble-t-il familier ?)
Les outils systemd sont des binaires compilés, mais la suite d'outils est ouverte car tous les fichiers de configuration sont des fichiers texte ASCII. La configuration de démarrage peut être modifiée via divers outils d'interface graphique et de ligne de commande, ainsi que l'ajout ou la modification de divers fichiers de configuration pour répondre aux besoins de l'environnement informatique local spécifique.
Le vrai problème
Pensiez-vous que je ne pouvais pas aimer les deux systèmes de démarrage ? Oui, et je peux travailler avec l'un ou l'autre.
À mon avis, le vrai problème et la cause profonde de la plupart des controverses entre SystemV et systemd est qu'il n'y a pas de choix au niveau de l'administrateur système. Le choix d'utiliser SystemV ou systemd a déjà été fait par les développeurs, les mainteneurs et les empaqueteurs des différentes distributions, mais avec raison. Évider et remplacer un système init, de par sa nature extrême et invasive, a de nombreuses conséquences qu'il serait difficile de gérer en dehors du processus de conception de la distribution.
Malgré le fait que ce choix soit fait pour moi, mes hôtes Linux démarrent et fonctionnent, ce qui m'importe généralement le plus. En tant qu'utilisateur final et même en tant qu'administrateur système, ma principale préoccupation est de savoir si je peux faire mon travail, par exemple écrire mes livres et cet article, installer des mises à jour et écrire des scripts pour tout automatiser. Tant que je peux faire mon travail, je ne me soucie pas vraiment de la séquence de démarrage utilisée sur ma distribution.
Je me soucie quand il y a un problème lors du démarrage ou de la gestion des services. Quel que soit le système de démarrage utilisé sur un hôte, j'en sais assez pour suivre la séquence des événements afin de trouver la panne et de la réparer.
Remplacement de SystemV
Il y a eu des tentatives précédentes pour remplacer SystemV par quelque chose d'un peu plus moderne. Pendant environ deux versions, Fedora a utilisé une chose appelée Upstart pour remplacer le SystemV vieillissant, mais il n'a pas remplacé init et n'a fourni aucun changement que j'ai remarqué. Étant donné qu'Upstart n'apportait aucun changement significatif aux problèmes liés à SystemV, les efforts dans ce sens ont été rapidement abandonnés au profit de systemd.
Malgré le fait que la plupart des développeurs Linux conviennent que le remplacement de l'ancien démarrage de SystemV est une bonne idée, de nombreux développeurs et administrateurs système n'aiment pas systemd pour cela. Plutôt que de ressasser tous les soi-disant problèmes que les gens ont - ou ont eu - avec systemd, je vais vous renvoyer à deux bons articles, bien qu'un peu anciens, qui devraient couvrir presque tout. Linus Torvalds, le créateur du noyau Linux, semble désintéressé. Dans un article de ZDNet de 2014, Linus Torvalds et d'autres sur le systemd de Linux , Linus est clair sur ses sentiments.
"Je n'ai pas vraiment d'opinions particulièrement fortes sur systemd lui-même. J'ai eu des problèmes avec certains des principaux développeurs qui, à mon avis, sont beaucoup trop cavaliers sur les bogues et la compatibilité, et je pense que certains détails de conception sont insensés (je n'aiment pas les journaux binaires, par exemple), mais ce sont des détails, pas de gros problèmes."
Au cas où vous ne sauriez pas grand-chose sur Linus, je peux vous dire que s'il n'aime pas quelque chose, il est très franc, explicite et très clair sur cette aversion. Il est devenu socialement plus acceptable dans sa manière d'exprimer son aversion pour les choses.
En 2013, Poettering a écrit un long article de blog dans lequel il démystifie les mythes sur systemd tout en donnant un aperçu de certaines des raisons de sa création. C'est une très bonne lecture, et je la recommande vivement.
tâches systemd
Selon les options utilisées lors du processus de compilation (qui ne sont pas prises en compte dans cette série), systemd peut avoir jusqu'à 69 exécutables binaires qui effectuent les tâches suivantes, entre autres :
- Le programme systemd s'exécute en tant que PID 1 et permet le démarrage du système d'autant de services en parallèle que possible, ce qui, comme effet secondaire, accélère les temps de démarrage globaux. Il gère également la séquence d'arrêt.
- Le programme systemctl fournit une interface utilisateur pour la gestion des services.
- La prise en charge des scripts de démarrage SystemV et LSB est offerte pour la rétrocompatibilité.
- La gestion des services et les rapports fournissent davantage de données sur l'état des services que SystemV.
- Il comprend des outils pour la configuration de base du système, tels que le nom d'hôte, la date, les paramètres régionaux, les listes d'utilisateurs connectés, l'exécution de conteneurs et de machines virtuelles, les comptes système, les répertoires et les paramètres d'exécution, les démons pour gérer la configuration réseau simple, la synchronisation de l'heure du réseau , le transfert de journaux et la résolution de noms.
- Il offre une gestion des sockets.
- Les temporisateurs systemd fournissent des fonctionnalités avancées de type cron pour inclure l'exécution d'un script à des moments relatifs au démarrage du système, au démarrage de systemd, à la dernière fois que le temporisateur a été démarré, etc.
- Il fournit un outil pour analyser les dates et les heures utilisées dans les spécifications de minuterie.
- Le montage et le démontage de systèmes de fichiers avec prise en compte de la hiérarchie permettent une mise en cascade plus sûre des systèmes de fichiers montés.
- Il permet la création et la gestion positives de fichiers temporaires, y compris leur suppression.
- Une interface vers D-Bus permet d'exécuter des scripts lorsque des appareils sont branchés ou retirés. Cela permet à tous les appareils, qu'ils soient enfichables ou non, d'être traités comme plug-and-play, ce qui simplifie considérablement la manipulation des appareils.
- Son outil d'analyse de la séquence de démarrage peut être utilisé pour localiser les services qui prennent le plus de temps.
- Il comprend des journaux pour stocker les messages du journal système et des outils pour gérer les journaux.
Architecture
Ces tâches et bien d'autres sont prises en charge par un certain nombre de démons, de programmes de contrôle et de fichiers de configuration. La figure 1 montre de nombreux composants appartenant à systemd. Il s'agit d'un diagramme simplifié conçu pour fournir une vue d'ensemble de haut niveau, de sorte qu'il n'inclut pas tous les programmes ou fichiers individuels. Il ne donne pas non plus un aperçu du flux de données, qui est si complexe qu'il serait un exercice inutile dans le contexte de cette série d'articles.
Une exposition complète de systemd prendrait un livre à elle seule. Vous n'avez pas besoin de comprendre les détails de la façon dont les composants systemd de la figure 1 s'emboîtent; il suffit de connaître les programmes et les composants qui permettent de gérer divers services Linux et de gérer les fichiers journaux et les journaux. Mais il est clair que systemd n'est pas la monstruosité monolithique que certains de ses détracteurs prétendent être.
systemd comme PID 1
systemd est PID 1. Certaines de ses fonctions, qui sont beaucoup plus étendues que l'ancien programme d'initialisation SystemV3, consistent à gérer de nombreux aspects d'un hôte Linux en cours d'exécution, y compris le montage de systèmes de fichiers et le démarrage et la gestion des services système nécessaires pour avoir un hôte Linux productif. Toutes les tâches de systemd qui ne sont pas liées à la séquence de démarrage sortent du cadre de cet article (mais certaines seront explorées plus tard dans cette série).
Premièrement, systemd monte les systèmes de fichiers définis par /etc/fstab , y compris les fichiers d'échange ou les partitions. À ce stade, il peut accéder aux fichiers de configuration situés dans /etc , y compris la sienne. Il utilise son lien de configuration, /etc/systemd/system/default.target , pour déterminer dans quel état ou cible il doit démarrer l'hôte. La cible par défaut file est un lien symbolique vers le véritable fichier cible. Pour un poste de travail de bureau, il s'agira généralement de graphical.target , qui équivaut au niveau d'exécution 5 dans SystemV. Pour un serveur, la valeur par défaut est plus susceptible d'être multi-user.target , qui est comme le niveau d'exécution 3 dans SystemV. La cible.d'urgence est similaire au mode mono-utilisateur. Les cibles et les services sont des unités systémiques.
Le tableau ci-dessous (Figure 2) compare les cibles systemd avec les anciens niveaux d'exécution de démarrage de SystemV. systemd fournit les alias cibles systemd pour la compatibilité descendante. Les alias cibles permettent aux scripts (et à de nombreux administrateurs système) d'utiliser des commandes SystemV telles que init 3 pour changer de niveau d'exécution. Bien sûr, les commandes SystemV sont transmises à systemd pour interprétation et exécution.
| cibles systemd | Niveau d'exécution SystemV | alias cibles | Description |
| default.target | Cette cible est toujours associée à un lien symbolique vers multi-user.target ou graphical.target . systemd utilise toujours le default.target pour démarrer le système. La cible par défaut ne doit jamais être associé à halt.target , poweroff.target , ou reboot.target . | ||
| cible.graphique | 5 | runlevel5.target | Cible.multi-utilisateur avec une interface graphique |
| 4 | runlevel4.target | Inutilisé. Le niveau d'exécution 4 était identique au niveau d'exécution 3 dans le monde SystemV. Cette cible peut être créée et personnalisée pour démarrer les services locaux sans modifier la valeur par défaut multi-user.target . | |
| multi-user.target | 3 | runlevel3.target | Tous les services sont en cours d'exécution, mais uniquement l'interface de ligne de commande (CLI) |
| 2 | runlevel2.target | Multi-utilisateur, sans NFS, mais tous les autres services non graphiques en cours d'exécution | |
| rescue.target | 1 | runlevel1.target | Un système de base, y compris le montage des systèmes de fichiers avec uniquement les services les plus élémentaires en cours d'exécution et un shell de secours sur la console principale |
| urgence.cible | S | Mode mono-utilisateur :aucun service n'est en cours d'exécution ; les systèmes de fichiers ne sont pas montés. Il s'agit du niveau de fonctionnement le plus élémentaire avec uniquement un shell d'urgence exécuté sur la console principale pour que l'utilisateur puisse interagir avec le système. | |
| halter.cible | Arrête le système sans l'éteindre | ||
| reboot.target | 6 | runlevel6.target | Redémarrer |
| poweroff.target | 0 | runlevel0.target | Arrête le système et coupe l'alimentation |
Chaque cible a un ensemble de dépendances décrites dans son fichier de configuration. systemd démarre les dépendances requises, qui sont les services requis pour exécuter l'hôte Linux à un niveau de fonctionnalité spécifique. Lorsque toutes les dépendances répertoriées dans les fichiers de configuration cible sont chargées et en cours d'exécution, le système s'exécute à ce niveau cible. Dans la figure 2, les cibles avec le plus de fonctionnalités se trouvent en haut du tableau, les fonctionnalités diminuant vers le bas du tableau.
systemd examine également les répertoires d'initialisation hérités de SystemV pour voir s'il existe des fichiers de démarrage. Si tel est le cas, systemd les utilise comme fichiers de configuration pour démarrer les services décrits par les fichiers. Le service réseau obsolète est un bon exemple de celui qui utilise encore les fichiers de démarrage SystemV dans Fedora.
La figure 3 (ci-dessous) est copiée directement à partir de la page de manuel de démarrage. Il montre une carte de la séquence générale des événements lors du démarrage de systemd et les exigences de commande de base pour assurer un démarrage réussi.
cryptsetup-pre.target
|
(various low-level v
API VFS mounts: (various cryptsetup devices...)
mqueue, configfs, | |
debugfs, ...) v |
| cryptsetup.target |
| (various swap | | remote-fs-pre.target
| devices...) | | | |
| | | | | v
| v local-fs-pre.target | | | (network file systems)
| swap.target | | v v |
| | v | remote-cryptsetup.target |
| | (various low-level (various mounts and | | |
| | services: udevd, fsck services...) | | remote-fs.target
| | tmpfiles, random | | | /
| | seed, sysctl, ...) v | | /
| | | local-fs.target | | /
| | | | | | /
\____|______|_______________ ______|___________/ | /
\ / | /
v | /
sysinit.target | /
| | /
______________________/|\_____________________ | /
/ | | | \ | /
| | | | | | /
v v | v | | /
(various (various | (various | |/
timers...) paths...) | sockets...) | |
| | | | | |
v v | v | |
timers.target paths.target | sockets.target | |
| | | | v |
v \_______ | _____/ rescue.service |
\|/ | |
v v |
basic.target rescue.target |
| |
________v____________________ |
/ | \ |
| | | |
v v v |
display- (various system (various system |
manager.service services services) |
| required for | |
| graphical UIs) v v
| | multi-user.target
emergency.service | | |
| \_____________ | _____________/
v \|/
emergency.target v
graphical.target
Le sysinit.target et basic.target les cibles peuvent être considérées comme des points de contrôle dans le processus de démarrage. Bien que l'un des objectifs de conception de systemd soit de démarrer les services système en parallèle, certains services et cibles fonctionnelles doivent être démarrés avant que d'autres services et cibles puissent démarrer. Ces points de contrôle ne peuvent pas être franchis tant que tous les services et cibles requis par ce point de contrôle ne sont pas remplis.
Le sysinit.target est atteint lorsque toutes les unités dont il dépend sont terminées. Toutes ces unités, monter des systèmes de fichiers, configurer des fichiers d'échange, démarrer udev, définir la graine du générateur aléatoire, lancer des services de bas niveau et configurer des services cryptographiques (si un ou plusieurs systèmes de fichiers sont chiffrés), doivent être terminées mais, dans le sysinit.target , ces tâches peuvent être effectuées en parallèle.
Le sysinit.target démarre tous les services et unités de bas niveau nécessaires pour que le système soit légèrement fonctionnel et qui sont nécessaires pour permettre le passage à la base.target .
Après le sysinit.target est atteint, systemd démarre alors toutes les unités nécessaires pour atteindre l'objectif suivant. La cible de base fournit des fonctionnalités supplémentaires en démarrant les unités requises pour toutes les cibles suivantes. Il s'agit notamment de configurer des éléments tels que des chemins vers divers répertoires exécutables, des sockets de communication et des minuteries.
Enfin, les cibles au niveau de l'utilisateur, multi-user.target ou graphical.target , peut être initialisé. La multi-user.target doit être atteint avant que les dépendances cibles graphiques puissent être satisfaites. Les cibles soulignées dans la figure 3 sont les cibles de démarrage habituelles. Lorsque l'un de ces objectifs est atteint, le démarrage est terminé. Si la cible multi-user.target est la valeur par défaut, vous devriez voir une connexion en mode texte sur la console. Si graphical.target est la valeur par défaut, alors vous devriez voir une connexion graphique ; l'écran de connexion GUI spécifique que vous voyez dépend de votre gestionnaire d'affichage par défaut.
La page de manuel de démarrage décrit et fournit également des cartes du démarrage dans le disque RAM initial et le processus d'arrêt de systemd.
systemd fournit également un outil qui répertorie les dépendances d'un démarrage complet ou pour une unité spécifiée. Une unité est une entité de ressource systemd contrôlable qui peut aller d'un service spécifique, tel que httpd ou sshd, à des minuteries, des montages, des sockets, etc. Essayez la commande suivante et faites défiler les résultats.
systemctl list-dependencies graphical.targetNotez que cela développe complètement la liste des unités cibles de niveau supérieur requises pour amener le système en mode d'exécution cible graphique. Utilisez le --tous possibilité de développer également toutes les autres unités.
systemctl list-dependencies --all graphical.targetVous pouvez rechercher des chaînes telles que "target", "slice" et "socket" à l'aide des outils de recherche de moins commande.
Alors maintenant, essayez ce qui suit.
systemctl list-dependencies multi-user.targetet
systemctl list-dependencies rescue.targetet
systemctl list-dependencies local-fs.targetet
systemctl list-dependencies dbus.serviceCet outil m'aide à visualiser les spécificités des dépendances de démarrage pour l'hôte sur lequel je travaille. Allez-y et passez du temps à explorer l'arborescence de démarrage pour un ou plusieurs de vos hôtes Linux. Mais attention car la page man de systemctl contient cette note :
"Notez que cette commande répertorie uniquement les unités actuellement chargées en mémoire par le gestionnaire de services. En particulier, cette commande n'est pas adaptée pour obtenir une liste complète de toutes les dépendances inverses sur une unité spécifique, car elle ne répertorie pas les dépendances déclarées par des unités actuellement non chargées."
Réflexions finales
Avant même d'entrer très profondément dans systemd, il est évident qu'il est à la fois puissant et complexe. Il est également évident que systemd n'est pas un fichier binaire unique, énorme, monolithique et inconnaissable. Il est plutôt composé d'un certain nombre de composants et de sous-commandes plus petits conçus pour effectuer des tâches spécifiques.
Le prochain article de cette série explorera plus en détail le démarrage de systemd, ainsi que les fichiers de configuration de systemd, la modification de la cible par défaut et la création d'une unité de service simple.
Ressources
De nombreuses informations sur systemd sont disponibles sur Internet, mais la plupart sont concises, obtuses ou même trompeuses. En plus des ressources mentionnées dans cet article, les pages Web suivantes offrent des informations plus détaillées et fiables sur le démarrage de systemd.
- Le projet Fedora propose un bon guide pratique de systemd. Il contient à peu près tout ce que vous devez savoir pour configurer, gérer et entretenir un ordinateur Fedora à l'aide de systemd.
- Le projet Fedora a également une bonne feuille de triche qui renvoie les anciennes commandes SystemV à des commandes systemd comparables.
- Pour des informations techniques détaillées sur systemd et les raisons de sa création, consultez la description de systemd par Freedesktop.org.
- Linux.com's "More systemd fun" propose des informations et des conseils plus avancés sur systemd.
Il existe également une série d'articles profondément techniques pour les administrateurs système Linux par Lennart Poettering, le concepteur et développeur principal de systemd. Ces articles ont été écrits entre avril 2010 et septembre 2011, mais ils sont tout aussi pertinents aujourd'hui qu'ils l'étaient alors. Une grande partie de tout ce qui a été écrit sur systemd et son écosystème est basé sur ces articles.
- Repenser le PID 1
- systemd pour les administrateurs, partie I
- systemd pour les administrateurs, partie II
- systemd pour les administrateurs, partie III
- systemd pour les administrateurs, partie IV
- systemd pour les administrateurs, partie V
- systemd pour les administrateurs, partie VI
- systemd pour les administrateurs, partie VII
- systemd pour les administrateurs, partie VIII
- systemd pour les administrateurs, partie IX
- systemd pour les administrateurs, partie X
- systemd pour les administrateurs, partie XI