## Introduction Un laboratoire local avec systemd offre aux développeurs, consultants DevOps et équipes de startups un environnement contrôlé pour apprendre, tester et déboguer la gestion des services sans risquer les systèmes de production. Que vous soyez novice avec systemd ou que vous ayez besoin d'un espace sûr pour reproduire une défaillance délicate, un laboratoire bien structuré rend la courbe d'apprentissage concrète et sécuritaire. Cet article décrit la mise en place d'un laboratoire systemd à partir de zéro, la vérification de votre version et de votre environnement, les modifications sécuritaires, la validation du comportement, le diagnostic des pannes et la récupération en cas de problème. Chaque section inclut des commandes pratiques, des résultats attendus et des exemples concrets que vous pouvez exécuter vous-même. L'objectif est la sécurité opérationnelle : observer avant de modifier, limiter le rayon d'impact, utiliser des variables temporaires au lieu de secrets, vérifier les résultats et documenter les procédures de récupération. ## Inventaire de la version et de l'environnement Avant de modifier quoi que ce soit, sachez exactement avec quoi vous travaillez. Vérifiez la version de systemd, le noyau, la distribution et si vous êtes dans un conteneur ou une machine virtuelle. C'est important car les versions plus récentes de systemd ajoutent des fonctionnalités comme les améliorations de systemd-analyze security ou les capacités de systemd-run --user que les anciennes versions n'ont pas. Commencez par quelques commandes en lecture seule : systemctl --version uname -a cat /etc/os-release systemd-detect-virt Exemple de sortie sur un système Ubuntu 24.04 typique : $ systemctl --version systemd 255 (255.4-1ubuntu8) +PAM +AUDIT +SELINUX +APPARMOR +IMA +SMACK +SECCOMP +GCRYPT -GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN +IPTC +KMOD +LIBCRYPTSETUP +LIBFDISK +PCRE2 +PWQUALITY +P11KIT +QRENCODE +TPM2 +BZIP2 +LZ4 +XZ +ZLIB +ZSTD -BPF_FRAMEWORK -XKBCOMMON +UTMP +SYSVINIT default-hierarchy=unified Cela indique la version (255) et les fonctionnalités activées. Si vous utilisez un conteneur, systemd peut ne pas s'exécuter comme PID 1 et vous aurez peut-être besoin d'une configuration supplémentaire. Capturez toujours l'état actuel avant toute intervention : systemctl list-units --type=service --state=running > services_before.txt Stockez ces fichiers dans un carnet de laboratoire ou un contrôle de version. Ils constituent votre référence de base. Pour un laboratoire fiable, utilisez une machine virtuelle plutôt qu'un conteneur lorsque c'est possible. Une VM offre un vrai système d'initialisation, des journaux et des fonctionnalités du noyau sans affecter votre hôte. Des outils comme VirtualBox, QEMU ou des instances infonuagiques fonctionnent bien. Si vous utilisez un conteneur, assurez-vous qu'il exécute systemd comme PID 1 avec --privileged et -v /sys/fs/cgroup:/sys/fs/cgroup:ro si nécessaire, bien que cela soit moins isolé. Prérequis pour le laboratoire : - Une machine Linux ou une VM avec systemd (idéalement la même version majeure que la production). - Un accès root ou sudo pour créer et démarrer des services. - Un éditeur de texte pour les fichiers d'unité. - Une familiarité de base avec la ligne de commande. Rayon d'impact : uniquement votre machine de laboratoire. Récupération : prenez un instantané de la VM avant tout changement, ou ayez un plan de retour en arrière. ## Chemin de configuration sécuritaire Modifier la configuration de systemd de manière sécuritaire signifie comprendre la priorité des fichiers d'unité, utiliser systemctl edit pour les fichiers de surcharge et tester avant d'activer. Ne modifiez jamais directement /lib/systemd/system/ ; ces fichiers sont gérés par les paquets. Utilisez plutôt /etc/systemd/system/ pour les remplacements ou les unités personnalisées. Parcourons la création d'un service personnalisé simple en toute sécurité. Supposons que vous vouliez exécuter un petit script de serveur web. D'abord, créez un script hello-web.sh : #!/bin/bash while true; do echo -e "HTTP/1.1 200 OK\r\n\r\nHello from systemd lab" | nc -l -p 8080 -q 1 done Rendez-le exécutable et placez-le dans /usr/local/bin/ : sudo chmod +x hello-web.sh sudo cp hello-web.sh /usr/local/bin/ Maintenant, créez un fichier d'unité. Placez-le dans /etc/systemd/system/hello-web.service : [Unit] Description=Hello Web Service (lab) After=network.target [Service] ExecStart=/usr/local/bin/hello-web.sh Restart=on-failure [Install] WantedBy=multi-user.target Avant de démarrer, vérifiez la syntaxe du fichier d'unité : sudo systemd-analyze verify /etc/systemd/system/hello-web.service S'il n'y a pas d'erreurs, cela ne retourne rien. Ensuite, rechargez le démon et démarrez le service : sudo systemctl daemon-reload sudo systemctl start hello-web.service Vérifiez l'état : sudo systemctl status hello-web.service La sortie attendue inclut active (running) et des lignes de journalisation récentes. Si cela échoue, inspectez avec journalctl -u hello-web.service -n 20 . Pour tester le service, exécutez curl http://localhost:8080 . Vous devriez voir le message de salutation. Pour les modifications qui ne sont pas une nouvelle unité, utilisez des fichiers de surcharge : sudo systemctl edit hello-web.service Cela ouvre un fichier de remplacement /etc/systemd/system/hello-web.service.d/override.conf . Ajoutez, par exemple, une variable d'environnement : [Service] Environment=GREETING="Hello from override" Ensuite, redémarrez le service. Cette méthode garde vos modifications séparées et faciles à annuler : supprimez simplement le fichier de surcharge et exécutez daemon-reload . Rayon d'impact : uniquement ce service sur cette machine. Récupération : désactivez et supprimez le fichier d'unité si nécessaire. ## Vérification et diagnostic Une fois votre service en cours d'exécution, vérifiez son comportement réel et approfondissez les diagnostics. Utilisez systemctl status pour un aperçu rapide. Il affiche l'état du service, le PID et les journaux récents. Pour une analyse plus approfondie, utilisez journalctl : journalctl -u hello-web.service --since "10 minutes ago" Cela affiche les journaux de l'unité. Ajoutez -f pour suivre en direct. Vérifiez les dépendances et l'ordre avec systemctl list-dependencies : systemctl list-dependencies hello-web.service La sortie attendue inclut network.target et d'autres unités. Utilisez systemd-analyze pour inspecter les performances de démarrage et les retards : systemd-analyze blame Pour vérifier la posture de sécurité d'un service, utilisez systemd-analyze security : systemd-analyze security hello-web.service Cela donne un score et des suggestions. Dans un laboratoire, vous pouvez expérimenter avec des options de durcissement comme NoNewPrivileges=yes ou ProtectSystem=strict . Si quelque chose ne fonctionne pas, commencez par lire les journaux. journalctl -xe montre les dernières entrées avec des explications. Les problèmes courants incluent : - Chemin ExecStart manquant ou non exécutable - Problèmes de permissions - Erreurs de syntaxe dans le fichier d'unité Diagnostiquez étape par étape. Exécutez la commande manuellement en tant qu'utilisateur du service pour voir l'erreur. Par exemple : sudo -u nobody /usr/local/bin/hello-web.sh Si cela échoue, vous voyez l'erreur exacte. Liste de vérification : - Le service est actif et activé si nécessaire. - Il démarre au démarrage si WantedBy est défini et systemctl enable a été exécuté. - Il répond comme prévu (par exemple, curl renvoie 200). - Les journaux montrent les entrées attendues et aucune erreur inattendue. - Le score d'analyse de sécurité est acceptable pour le cas d'utilisation. ## Modes de défaillance et récupération Même dans un laboratoire, les choses tournent mal. Connaître les modes de défaillance courants et comment récupérer fait gagner du temps. Défaillance : l'unité ne démarre pas avec le code de sortie 203/EXEC Cela signifie généralement que le chemin de l'exécutable est incorrect ou manque de permission d'exécution. Vérifiez avec ls -l /usr/local/bin/hello-web.sh et journalctl -u hello-web.service . Corrigez les permissions ou le chemin, puis daemon-reload et redémarrez. Défaillance : le service démarre mais se termine immédiatement Regardez les journaux. Le script peut avoir une erreur. Exécutez-le manuellement. Assurez-vous que le type de service est correct. Pour les processus de longue durée, utilisez Type=simple (par défaut). Si le processus principal se duplique et se termine, utilisez Type=forking . Ajustez si nécessaire. Défaillance : port déjà utilisé Si un autre processus écoute sur 8080, votre service échoue. Utilisez ss -tulpn | grep 8080 pour trouver le coupable. Changez le port dans votre script ou arrêtez l'autre processus. Défaillance : dépendance non satisfaite Si After=network.target est satisfait mais que votre service échoue toujours parce que le réseau n'est pas prêt, envisagez After=network-online.target et Wants=network-online.target . C'est un problème courant pour les services qui ont besoin d'une connectivité réelle. Modèles de récupération Prenez toujours un instantané de votre système ou gardez une copie des fichiers d'unité d'origine. Pour annuler une surcharge, supprimez le fichier de remplacement : sudo rm /etc/systemd/system/hello-web.service.d/override.conf sudo systemctl daemon-reload sudo systemctl restart hello-web.service Si une unité est complètement cassée, désactivez-la et masquez-la pour empêcher le démarrage : sudo systemctl disable hello-web.service sudo systemctl mask hello-web.service Ensuite, corrigez le fichier d'unité, démasquez et réactivez. Pratiquez un exercice complet de récupération : cassez intentionnellement un service (par exemple, changez le chemin de l'exécutable), puis restaurez-le en utilisant vos étapes documentées. Cela renforce la confiance. ## Pièges courants et comment les éviter Même les utilisateurs expérimentés rencontrent ces pièges. Les connaître à l'avance garde votre laboratoire productif. 1. Modifier directement les fichiers de /lib/systemd/system/ Pourquoi cela arrive : cela semble être l'emplacement canonique, surtout pour les unités empaquetées. Mais les mises à jour de paquets écrasent ces fichiers. Utilisez /etc/systemd/system/ ou des fichiers de surcharge. Pour récupérer, réinstallez le paquet ou recopiez le fichier d'origine. 2. Oublier daemon-reload après des modifications d'unité Pourquoi cela arrive : après avoir modifié un fichier d'unité, systemd utilise encore l'ancienne version en mémoire. Exécutez toujours systemctl daemon-reload avant de redémarrer l'unité. Si vous voyez des avertissements Unit file changed on disk , c'est l'indice. 3. Utiliser Type=forking quand ce n'est pas nécessaire Pourquoi cela arrive : de nombreux scripts d'initialisation hérités se dupliquent. Mais si votre processus reste au premier plan, Type=simple est correct. Utiliser forking sans spécifier PIDFile= peut faire croire à systemd que le service a échoué. Lisez la documentation et testez. 4. Ne pas définir de limites de ressources Pourquoi cela arrive : pendant les tests, vous pouvez oublier que la production a des limites. Mais un processus incontrôlable peut consommer toute la mémoire de votre laboratoire. Utilisez MemoryMax= et CPUQuota= dans l'unité pour contraindre. Exemple : [Service] MemoryMax=256M CPUQuota=20% 5. Coder en dur des secrets dans les fichiers d'unité Pourquoi cela arrive : la commodité. Ne mettez jamais de mots de passe ou de clés API dans Environment= ou ExecStart . Utilisez EnvironmentFile= avec des permissions appropriées, ou mieux, un gestionnaire de secrets. Dans un laboratoire, utilisez des valeurs fictives. 6. Ignorer l'ordre et les dépendances Pourquoi cela arrive : un service peut démarrer correctement seul mais échouer au démarrage parce que les dépendances ne sont pas satisfaites. Utilisez systemd-analyze plot > boot.svg pour visualiser le processus de démarrage et vérifier l'ordre. Ajoutez Requires= et After= si nécessaire. 7. Ne pas vérifier les options de sécurité Pourquoi cela arrive : beaucoup de gens se concentrent sur la fonctionnalité. Mais systemd offre un fort isolement. Exécutez systemd-analyze security et expérimentez avec ProtectSystem=strict , PrivateTmp=yes , NoNewPrivileges=yes . Ils peuvent empêcher un service compromis d'affecter l'hôte. Évitez ces pièges en suivant une liste de vérification : utilisez toujours des fichiers de surcharge, exécutez daemon-reload , testez avec systemd-analyze verify et examinez les journaux avant de déclarer le succès. ## Liste de vérification opérationnelle Utilisez cette liste avant, pendant et après tout changement systemd dans votre laboratoire. Chaque élément a un exemple concret et une commande de vérification.
ÉtapeActionExempleVérification
1Enregistrer l'état actuelsystemctl list-units --type=service --state=running > before.txtVérifier que before.txt existe
2Vérifier la syntaxe de l'unitésystemd-analyze verify /etc/systemd/system/hello-web.serviceAucune sortie ou erreur
3Recharger le démonsystemctl daemon-reloadLa commande réussit
4Démarrer le servicesystemctl start hello-web.servicesystemctl is-active hello-web renvoie active
5Vérifier l'état et les journauxsystemctl status hello-web.service et journalctl -u hello-web.service -n 20Aucune erreur inattendue
6Tester la fonctionnalitécurl http://localhost:8080Renvoie la réponse attendue
7Vérifier la posture de sécuritésystemd-analyze security hello-web.serviceScore acceptable, aucun avertissement critique
8Documenter les étapes de retour en arrièreÉcrire les commandes de suppression ou de restauration dans vos notesCommandes testées
Pour chaque étape, vous devez savoir qui est responsable. Dans un laboratoire individuel, c'est vous. Dans une équipe, attribuez un seul propriétaire, par exemple, « Priya Shah, responsable de l'ingénierie, examine les changements de service chaque semaine. » Revisitez la liste après tout incident ou mise à jour majeure du système. ## Conclusion Un laboratoire local avec systemd est un moyen sûr et puissant d'apprendre et de tester la gestion des services. En suivant les pratiques de cet article, vous pouvez apporter des modifications en toute confiance : connaissez votre version, modifiez la configuration en toute sécurité avec des fichiers de surcharge, vérifiez avec des commandes réelles, diagnostiquez les pannes à partir des journaux et récupérez en utilisant des étapes documentées. La clé est de traiter le laboratoire comme la production en termes de discipline mais pas en termes de risque. Utilisez des variables temporaires pour les secrets, limitez le rayon d'impact et ayez toujours un plan de retour en arrière. Pratiquez les modes de défaillance courants pour être prêt lorsqu'ils surviennent en production. Commencez par une vérification à faible risque : créez une unité simple, démarrez-la et inspectez son état. Ensuite, ajoutez progressivement de la complexité. Au fur et à mesure, prenez des notes et partagez-les avec votre équipe. La capacité de gérer un laboratoire systemd fiable est une compétence fondamentale pour quiconque gère des services Linux.