Gérer les services

Objectif de cet atelier pratique :

• manipuler les services et gérer le démarrage et l’arrêt d’un système Linux

Au cours des précédents ateliers, nous avons eu l’occasion de parler des « services », ces logiciels qui tournent en tâche de fond pendant que l’utilisateur fait autre chose. C’est un peu comme un serveur (un vrai, en chair et en os) dans un café, discrètement à l’affût dans un coin, attendant que vous daigniez interrompre la lecture de votre journal pour commander un café et deux croissants.

Cet exemple est résolument utopique. Dans un café français qui se respecte, c’est le client qui est à l’affût du serveur.

Certains de ces services sont indispensables pour le fonctionnement cohérent du système et doivent être lancés au démarrage de la machine. D’autres sont facultatifs et dépendent de l’utilisation spécifique que vous faites de votre serveur. Le présent chapitre vous propose une introduction facile et pratique à la gestion des services sous Rocky Linux.

Qu’est-ce qu’un service ?

Pour avoir une idée de ce qu’est un service, nous n’avons qu’à en prendre un au hasard sur notre machine pour le regarder de près :

$ ps ax | grep -v grep | grep sshd
 807 ?        Ss     0:00 /usr/sbin/sshd ...
1022 ?        Ss     0:00 sshd: microlinux [priv]
1038 ?        S      0:00 sshd: microlinux@pts/0

Le service OpenSSH (/usr/sbin/sshd) attend en permanence des connexions depuis des clients. Lorsqu’il reçoit une requête, il se charge d’établir une connexion sécurisée après une authentification.

Un service connaît principalement deux états :

• marche
• arrêt

C’est un peu comme le moteur d’une voiture. Soit il est démarré, soit il ne tourne pas. Après, savoir si vous le laissez tourner au point mort ou si vous embrayez, c’est une autre histoire.

Arrêter et (re)démarrer un service

Dans une voiture, je coupe le contact pour arrêter le moteur. Je peux faire pareil pour un service, après avoir acquis les droits d’administrateur :

$ sudo systemctl stop sshd

Vous serez peut-être vaguement surpris de ne pas avoir été déconnecté. Essayez de lancer une deuxième session à distance :

[kikinovak@alphamule:~] $ ssh microlinux@192.168.2.179
ssh: connect to host 192.168.2.179 port 22: Connection refused

Pour relancer le service, je dois invoquer la commande suivante :

$ sudo systemctl start sshd

Le serveur est à nouveau accessible depuis une machine distante :

[kikinovak@alphamule:~] $ ssh microlinux@192.168.2.179
microlinux@192.168.2.179's password:

Dans certaines situations, il est nécessaire de redémarrer un service, par exemple après avoir apporté des modifications à sa configuration, pour que celles-ci soient prises en compte :

$ sudo systemctl restart sshd

Le « redémarrage » n’est pas véritablement une fonctionnalité à part. Pour le système, il s’agit simplement d’une commande stop suivie d’une commande start.

Interdire les connexions SSH de l’utilisateur root

Dans la configuration par défaut de Rocky Linux 8, le serveur OpenSSH accepte les connexions distantes de l’utilisateur root. Pour renforcer la sécurité de leurs machines, certains administrateurs interdisent à root de se connecter directement.

Pour mettre en place cette politique, il faut éditer le fichier /etc/ssh/sshd_config. Repérez la directive PermitRootLogin et passez-la de yes à no :

PermitRootLogin no

Redémarrez le service SSH pour prendre en compte les modifications :

$ sudo systemctl restart sshd

Recharger la configuration d’un service

Certains services – dont OpenSSH – sont capables de prendre en compte une nouvelle configuration sans pour autant passer par un redémarrage :

$ sudo systemctl reload sshd

La commande reload offre une manière plus gracieuse de recharger la configuration d’un service. Pour vous entraîner, reprenez l’exemple précédent en bloquant et en autorisant successivement l’accès distant pour l’utilisateur root. Cette fois-ci, utilisez reload au lieu de restart.

Activer un service au démarrage de la machine

La commande systemctl est un véritable couteau suisse qui gère l’initialisation et les services de la machine. Jetez un coup d’œil sur la page de manuel systemctl(1). Vous serez sans doute surpris par la pléthore d’options existantes. Là comme ailleurs, nous n’allons pas nous décourager face à l’abondance. Nous nous contentons de mettre un pied devant l’autre.

Affichez les services installés et actifs. Notez en passant que vous avez le droit d’effectuer cette opération en tant que simple utilisateur :

$ systemctl list-units --type service

Repérez le service OpenSSH dans la liste. Éventuellement, filtrez les résultats :

$ systemctl list-units --type service | grep sshd
sshd.service loaded active running OpenSSH server daemon

L’option list-unit-files affiche l’ensemble des services installés, indépendamment de leur état :

$ systemctl list-unit-files –-type service

Là aussi, repérez sshd.service dans la liste :

$ systemctl list-unit-files --type=service | grep sshd
sshd-keygen@.service             disabled
sshd.service                     enabled 
sshd@.service                    static

Désactivez le service en utilisant l’option disable. Vous vous doutez probablement que ce genre d’opération requiert certains privilèges :

$ sudo systemctl disable sshd

Notez bien que le service n’est pas arrêté pour autant :

$ ps ax | grep -v grep | grep sshd
 807 ?        Ss     0:00 /usr/sbin/sshd ...
1022 ?        Ss     0:00 sshd: microlinux [priv]
1038 ?        S      0:00 sshd: microlinux@pts/0

L’option status est bien plus pratique pour afficher l’état d’un service :

$ systemctl status sshd

Quelle est donc la portée de la directive disable ? Pour en avoir le cœur net, redémarrez la machine et affichez l’ensemble des services :

$ systemctl list-units –-type service
$ systemctl list-unit-files –-type service

Repérez sshd.service dans l’affichage des résultats des deux commandes, puis vérifiez son état :

$ systemctl status sshd

En effet, la directive disable n’a pas immédiatement arrêté le service OpenSSH. Elle a juste empêché son lancement au prochain démarrage.

Inversement, la directive enable active le lancement du service au prochain démarrage :

$ sudo systemctl enable sshd

Les cibles systemd

Les cibles systemd (ou targets) représentent les différents modes opératoires de notre système. Elles permettent de démarrer une machine avec juste les services requis pour une tâche définie.

$ systemctl list-units --type target

La cible multi-user.target représente ici l’état final de notre système au démarrage :

$ systemctl get-default
multi-user.target

Les autres cibles comme basic.target ou network.target constituent autant d’étapes intermédiaires pour atteindre cet état final.

Dans la pratique quotidienne, nous aurons essentiellement affaire à deux cibles :

• multi-user.target
• graphical.target

Pour les opérations de dépannage, nous utiliserons les deux cibles suivantes :

• rescue.target
• emergency.target

La distinction entre multi-user.target et graphical.target a un sens sur les machines dotées d’un environnement graphique, comme les postes de travail ou les stations de travail. Sur les serveurs sans environnement graphique, on définira multi-user.target comme cible par défaut.

Démarrer en mode de secours

Les cibles rescue.target et emergency.target servent à dépanner un système qui ne démarre pas normalement. En l’occurrence, le démarrage s’effectue avec un nombre de services réduit et permet à l’administrateur root d’ouvrir une console pour chercher la cause de la panne.

• Redémarrez la machine.
• Lorsque l’écran du chargeur de démarrage GRUB s’affiche, appuyez sur la touche E (edit).
• Naviguez dans les paramètres de démarrage avec les touches fléchées.
• Repérez la ligne avec les paramètres du noyau. Elle commence par linux et se termine par des options de démarrage comme rhgb ou nomodeset.
• Ajoutez l’option systemd.unit=rescue.target à la fin de cette ligne. Le clavier est en QWERTY américain par défaut, vous devrez donc tâtonner un peu.
• Démarrez en utilisant la combinaison de touches Ctrl+X.
• Lorsque l’invite de commande vous affiche You are in rescue mode, fournissez le mot de passe root pour ouvrir une console.

En temps normal – c’est-à-dire en mode multi-user.target – notre installation minimale lance pas moins de trente-trois services. Voyons comment les choses se présentent maintenant :

# systemctl list-units --type service
...
17 loaded units listed.

Nous constatons que le mode de secours n’affiche plus que dix-sept services actifs, soit près de la moitié du mode normal. Si cela ne vous semble pas si minimal que ça, sachez que nous pouvons faire mieux.

Réitérez l’expérience précédente en éditant les paramètres de démarrage de GRUB, mais en remplaçant rescue.target par emergency.target.

L’invite de commande annonce You are in emergency mode et vous devez fournir le mot de passe root comme vous l’avez fait auparavant pour ouvrir une console. C’est le nombre de services chargés qui fait la différence :

# systemctl list-units --type service
...
2 loaded units listed.

Cette fois-ci, nous sommes bien passés en mode « minimum syndical ». Rien ne tourne sur notre machine en dehors du shell de secours (emergency.service) et des fichiers journaux (systemd-journald.service) du système.

Changer de cible à la volée

Admettons que nous souhaitions basculer du mode de secours rescue.target vers le fonctionnement normal multi-user.target. Nous pouvons le faire directement, sans passer par un redémarrage :

# systemctl isolate multi-user.target

Au bout de quelques secondes, vous retrouvez l’invite de commande du système comme si vous aviez démarré normalement.

Pour vous entraîner un peu, démarrez en mode de secours emergency.target et basculez successivement vers le mode de secours rescue.target et vers le fonctionnement normal multi-user.target.

Afficher l’état du système

Est-ce qu’il y a moyen de savoir si tout s’est bien passé ? Est-ce que tous les services ont été lancés comme prévu ? C’est la directive status qui nous le dira.

$ systemctl status

À quoi ressemblerait un échec au démarrage ? Je vais utiliser une astuce pour vous en faire une simulation.

• Installez le service de synchronisation NTP Chrony (sudo dnf install -y chrony).
• Activez le service au démarrage (sudo systemctl enable chronyd).
• Renommez le fichier de configuration /etc/chrony.conf en /etc/chrony.donf de manière à faire échouer le lancement de ce service.
• Redémarrez la machine.

Une fois que j’ai effectué cette manipulation, j’affiche l’état de mon système :

$ systemctl status

Le statut degraded apparaît en rouge et me suggère qu’il y a eu un problème quelque part… mais où ? C’est l’option --failed qui me le dira :

$ systemctl --failed
  UNIT            LOAD   ACTIVE SUB    DESCRIPTION                                      
● chronyd.service loaded failed failed NTP client/server

Je corrige l’erreur en renommant correctement le fichier de configuration de ce service :

$ sudo mv /etc/chrony.donf /etc/chrony.conf

Je tente de démarrer manuellement le service :

$ sudo systemctl start chronyd

J’affiche à nouveau l’état du système :

$ systemctl status
● linuxbox
    State: running
     Jobs: 0 queued
   Failed: 0 units
...

Apparemment, tout est rentré dans l’ordre.

Définir la cible par défaut

En temps normal – c’est-à-dire si nous ne modifions pas les paramètres de démarrage de GRUB – notre système démarre en mode multi-user.target :

$ systemctl get-default
multi-user.target

Je peux modifier la cible par défaut :

$ sudo systemctl set-default rescue.target

Au prochain redémarrage, le système m’affichera directement l’invite du mode de secours :

You are in rescue mode.

Le mode de secours rescue.target correspond désormais au mode de fonctionnement « normal » de ma machine :

# systemctl get-default
rescue.target

Pour redéfinir la cible multi-user.target comme mode de fonctionnement par défaut, je dois invoquer la commande suivante :

# systemctl set-default multi-user.target

Basculer entre les cibles sur un poste de travail

Dans la pratique quotidienne, on utilisera systemctl set-default et systemctl isolate principalement sur les postes de travail ou les stations de travail pour basculer entre le mode graphique (graphical.target) et le mode texte (multi-user.target).

Lorsque je dois changer la carte graphique d’un poste client, je commence par basculer vers le mode texte :

$ sudo systemctl set-default multi-user.target
$ sudo systemctl isolate multi-user.target

Une fois que j’ai apporté les modifications nécessaires à mon système, je teste d’abord si l’affichage graphique fonctionne correctement :

$ sudo systemctl isolate graphical.target

Si tout se passe comme prévu, je redéfinis le mode graphique par défaut :

$ sudo systemctl set-default graphical.target

Dans ce contexte, le mode multi-user.target est considéré comme une sorte de mode de maintenance qui me permet de manipuler mon poste de travail sans affichage graphique.

Éteindre et redémarrer la machine

Tout comme pour le démarrage, le système doit suivre une certaine procédure pour arrêter tous les services. L’extinction du système nécessite de tuer les processus dans un ordre cohérent et de faire le ménage dans les systèmes de fichiers avant l’arrêt des disques. C’est la commande halt qui s’en charge :

$ sudo halt -p

L’option -p (poweroff) se charge d’éteindre la machine lors de l’arrêt du système. Consultez la page de manuel halt(8) pour en savoir plus.

La commande reboot a le même effet que halt, au détail près que la machine redémarre au lieu de s’éteindre :

$ sudo reboot

Alternativement, nous pouvons invoquer systemctl avec les options respectives poweroff et reboot pour arrêter et redémarrer le système :

$ sudo systemctl poweroff

Lorsque je suis directement connecté à ma console, je peux également utiliser la combinaison de touches Ctrl+Alt+Suppr pour redémarrer.

Les utilisateurs de systèmes Microsoft Windows seront probablement bien familiarisés avec la combinaison de touches Ctrl+Alt+Suppr, qui sert à afficher un mot de leur sponsor en cas de plantage d’une application. Sachez que, sous Linux, il s’agit là du raccourci clavier normal pour redémarrer une machine en mode console.

Un peu de contexte historique

Les lecteurs de mon ouvrage Débuter avec Linux paru en 2017 et basé sur Slackware Linux 14.2 ont eu l’occasion de découvrir le système d’initialisation BSD. Ce système « brut de décoffrage » reste fidèle à la philosophie Unix aussi bien qu’au principe KISS (Keep It Simple Stupid) et se base sur une série de scripts shell pour gérer les services et les niveaux d’exécution.

Red Hat Enterprise Linux, CentOS et Debian ont longtemps utilisé la procédure System V, avec des niveaux d’exécution organisés différemment. D’autres systèmes d’initialisation ont vu le jour petit à petit, comme Upstart, développé par Canonical et adopté pendant quelque temps par Ubuntu et Fedora, ou encore OpenRC, utilisé par Gentoo depuis ses débuts. Actuellement, l’écrasante majorité des distributions a décidé d’adopter systemd, une alternative à System V spécifiquement conçue pour le noyau Linux.

L’adoption de systemd a suscité une série de controverses sans précédent dans le monde du libre. En résumé, les objections ne portent pas tant sur ses mérites en tant que système d’initialisation, mais sur le fait qu’il s’est imposé de force au détriment des solutions alternatives en s’étendant de façon tentaculaire dans des domaines qui n’ont plus rien à voir avec l’initialisation à proprement parler, sans oublier qu’il casse volontairement la compatibilité POSIX avec les systèmes non-Linux comme la famille des BSD.

Quoi qu’il en soit, systemd a bel et bien gagné la bataille et s’est progressivement imposé un peu partout. En dépit de son côté « usine à gaz », il constitue une solution robuste qui offre quelques fonctionnalités fort pratiques pour les administrateurs système, sans oublier le mérite d’abolir les différences inutiles entre les distributions Linux.

 

Lire la suite : Accéder aux périphériques amovibles

---

La rédaction de cette documentation demande du temps et des quantités significatives de café espresso. Vous appréciez ce blog ? Offrez un café au rédacteur en cliquant sur la tasse.