Configuration d'un laboratoire local avec systemd : exemples pratiques

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.

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.