3 - Paquets, services et journaux¶

C'est la séance du grand écart. Jusqu'ici, Debian et Rocky se ressemblaient beaucoup. À partir de maintenant, les commandes divergent franchement — mais pas les concepts.

C'est tout l'enjeu : apprendre à reconnaître, derrière deux outils qui ne se ressemblent pas, la même idée appliquée deux fois. Quand vous saurez faire ça, vous saurez administrer une distribution que vous n'avez jamais vue.

Ce que vous saurez faire en repartant¶

Installer, chercher et supprimer un logiciel sur les deux familles
Retrouver quel paquet a posé un fichier donné sur le système
Démarrer, arrêter et activer au démarrage un service
Modifier la configuration d'un service sans casser sa mise à jour
Lire les journaux pour comprendre pourquoi quelque chose ne marche pas
Planifier une tâche répétitive

Prérequis¶

Les TP 1 et 2 sont supposés acquis. Vous aurez besoin de sudo en permanence : tout ce qui suit modifie le système.

1. Pourquoi un gestionnaire de paquets¶

Installer un logiciel, ce n'est pas copier un fichier. Il faut le placer aux bons endroits, poser sa configuration, créer son utilisateur système, déclarer son service, et surtout installer les bibliothèques dont il dépend — qui dépendent elles-mêmes d'autres bibliothèques.

Un gestionnaire de paquets fait tout ça, et sait le défaire. Il tient à jour une base de données de ce qui est installé, de quel fichier appartient à quoi, et de ce qui dépend de quoi.

Les logiciels sont stockés sur des dépôts, des serveurs déclarés dans la configuration de la machine. Chaque paquet est signé cryptographiquement : la machine refuse d'installer un paquet dont la signature ne correspond pas à une clé qu'elle connaît. C'est ce qui vous protège d'un miroir compromis.

	Famille Debian	Famille Red Hat
Format	`.deb`	`.rpm`
Outil bas niveau	`dpkg`	`rpm`
Outil haut niveau	`apt`	`dnf`
Dépôts déclarés dans	`/etc/apt/sources.list`, `/etc/apt/sources.list.d/`	`/etc/yum.repos.d/`

L'outil bas niveau manipule un fichier de paquet isolé : il l'installe, mais si une dépendance manque, il échoue et vous laisse vous débrouiller. L'outil haut niveau parle aux dépôts, résout les dépendances et télécharge ce qu'il faut. En pratique vous utilisez le second pour agir, et le premier pour interroger.

Exercice 1 — Les dépôts

Sur srv-deb, affichez les dépôts configurés. Combien y en a-t-il, et que distinguent les mots main, contrib et non-free ?
Sur srv-rhel, faites la même chose. Le format du fichier est complètement différent — décrivez-le en une phrase.
Sur chaque machine, trouvez la commande qui liste les dépôts actifs plutôt que de lire les fichiers à la main.
Sur srv-deb, rafraîchissez la liste des paquets disponibles. Cette étape existe-t-elle sur srv-rhel ? Cherchez pourquoi.

Indice — question 4

Chez Debian, la mise à jour de l'index est une commande explicite et obligatoire avant toute installation. Chez Red Hat, l'outil s'en charge seul selon une durée de validité du cache. Deux philosophies, même besoin.

2. Installer, chercher, supprimer¶

=== "Debian"

```bash
apt update                  # rafraîchir l'index des dépôts
apt search motif            # chercher un paquet
apt show paquet             # description, version, dépendances
apt install paquet          # installer
apt remove paquet           # désinstaller, garder la configuration
apt purge paquet            # désinstaller, supprimer la configuration
apt autoremove              # retirer les dépendances devenues inutiles
apt list --installed        # tout ce qui est installé
apt upgrade                 # mettre à jour les paquets installés
```

=== "Rocky Linux"

```bash
dnf search motif            # chercher un paquet
dnf info paquet             # description, version
dnf install paquet          # installer
dnf remove paquet           # désinstaller
dnf autoremove              # retirer les dépendances devenues inutiles
dnf list --installed        # tout ce qui est installé
dnf upgrade                 # mettre à jour les paquets installés
dnf history                 # historique des transactions
dnf history undo N          # annuler la transaction numéro N
```

Notez la dernière ligne : dnf tient un journal des transactions et sait revenir en arrière. C'est une fonctionnalité qu'apt n'a pas en standard, et elle sauve des situations.

remove ou purge

Chez Debian, remove laisse les fichiers de configuration en place. C'est voulu — cela permet de réinstaller sans perdre vos réglages. Mais si vous désinstallez pour repartir de zéro, il faut purge, sinon l'ancienne configuration reviendra vous hanter.

Exercice 2 — Installer des deux côtés

Le paquet tree affiche une arborescence sous forme de schéma. Il est disponible dans les dépôts de base des deux familles.

Vérifiez qu'il n'est pas déjà installé, sur les deux serveurs.
Cherchez-le dans les dépôts et lisez sa description.
Installez-le sur les deux serveurs.
Utilisez-le sur /etc en limitant la profondeur à deux niveaux — le manuel vous donnera l'option.
Comparez les versions installées de part et d'autre. Sont-elles identiques ? Que vous apprend l'écart, s'il y en a un ?
Sur srv-rhel, affichez l'historique des transactions et repérez celle que vous venez de faire. Annulez-la, puis vérifiez que tree a disparu. Réinstallez-le ensuite.
Sur srv-deb, désinstallez tree puis vérifiez s'il reste des traces dans le système.

3. Interroger la base de paquets¶

Vous tombez sur un fichier inconnu dans /etc et vous voulez savoir d'où il vient. Ou l'inverse : vous voulez savoir ce qu'un paquet a déposé sur le système. C'est le rôle des outils bas niveau.

=== "Debian"

```bash
dpkg -l                   # lister les paquets installés
dpkg -L paquet            # fichiers déposés par un paquet
dpkg -S /chemin/fichier   # quel paquet possède ce fichier
dpkg -s paquet            # état détaillé d'un paquet
```

=== "Rocky Linux"

```bash
rpm -qa                   # lister les paquets installés
rpm -ql paquet            # fichiers déposés par un paquet
rpm -qf /chemin/fichier   # quel paquet possède ce fichier
rpm -qi paquet            # état détaillé d'un paquet
dnf provides /chemin      # quel paquet fournit ce fichier, installé ou non
```

La dernière ligne mérite l'attention : dnf provides interroge les dépôts, pas seulement ce qui est installé. Il répond donc à « quel paquet devrais-je installer pour obtenir cette commande ? », ce que dpkg ne sait pas faire seul.

Exercice 3 — Enquête

Sur les deux serveurs, trouvez quel paquet a déposé /bin/ls.
Listez tous les fichiers déposés par ce paquet. Combien y en a-t-il ? Reconnaissez-vous des commandes du TP 1 ?
Sur srv-rhel, la commande htop n'est pas installée. Trouvez quel paquet la fournirait, sans l'installer.
Sur srv-deb, trouvez quel paquet a déposé /etc/ssh/sshd_config.
Combien de paquets sont installés sur chaque serveur ? Comparez, et reliez l'écart à ce que vous savez de la philosophie de chaque famille.

4. Les services¶

Un service est un programme qui tourne en arrière-plan, démarre avec la machine et n'a pas de fenêtre ni de terminal. Serveur web, serveur SSH, synchronisation de l'heure : tout cela tourne en service.

Sur les deux familles, c'est systemd qui les gère. Mêmes commandes, même syntaxe, mêmes fichiers — c'est la grande zone de convergence de la séance.

systemd manipule des unités, qui ne sont pas toutes des services :

Suffixe	Type d'unité
`.service`	Un programme qui tourne
`.timer`	Un déclencheur périodique
`.socket`	Une écoute réseau qui lance un service à la demande
`.mount`	Un point de montage
`.target`	Un regroupement d'unités, correspondant à un état du système

Commande	Rôle
`systemctl status unité`	État détaillé, avec les dernières lignes de journal
`systemctl start` / `stop`	Démarrer / arrêter maintenant
`systemctl restart`	Arrêter puis redémarrer
`systemctl reload`	Recharger la configuration sans interrompre le service
`systemctl enable` / `disable`	Activer / désactiver au démarrage
`systemctl enable --now`	Activer au démarrage et démarrer tout de suite
`systemctl is-active` / `is-enabled`	Répondre par un seul mot
`systemctl list-units --type=service`	Les services en cours
`systemctl list-unit-files`	Toutes les unités connues et leur état

Démarré et activé sont deux choses différentes

start démarre le service maintenant, mais il ne reviendra pas après un redémarrage. enable le fait démarrer au boot, mais ne le lance pas tout de suite. Confondre les deux est l'erreur la plus fréquente des débutants, et elle ne se voit qu'au redémarrage suivant — souvent des semaines plus tard.

Les unités vivent à deux endroits :

Emplacement	Qui écrit ici	Priorité
`/usr/lib/systemd/system/`	Les paquets	Base
`/etc/systemd/system/`	Vous, l'administrateur	Prioritaire

Une unité placée dans /etc masque celle du paquet. C'est le principe général sous Unix : le paquet propose, l'administrateur dispose, et la mise à jour du paquet n'écrase jamais vos réglages.

Exercice 4 — Piloter un service

On travaille sur chrony, le service de synchronisation de l'heure. Installez-le s'il est absent.

Affichez son état complet. Est-il actif ? Activé au démarrage ? Depuis quand tourne-t-il ?
Arrêtez-le, vérifiez qu'il est arrêté, redémarrez-le.
Répondez en un seul mot, avec la commande adaptée, aux questions « est-il actif ? » et « démarrera-t-il au boot ? ».
Désactivez-le au démarrage sans l'arrêter. Vérifiez que les deux états sont bien différents.
Remettez-le dans son état initial.
Combien de services tournent actuellement sur srv-deb ? Et sur srv-rhel ? Comparez.
Trouvez le fichier d'unité de chrony et affichez-le. Dans quel répertoire se trouve-t-il, et pourquoi celui-là ?

Le service qu'il ne faut pas arrêter

Ne testez jamais stop sur ssh ou sshd : vous êtes connecté à travers lui. Vous perdriez l'accès à la machine et devriez passer par la console de l'hyperviseur pour la récupérer. La règle vaut bien au-delà de ce TP.

5. Modifier un service proprement¶

Vous voulez changer un paramètre de chrony. Le réflexe naturel est d'éditer son fichier d'unité dans /usr/lib/systemd/system/. C'est une mauvaise idée : la prochaine mise à jour du paquet l'écrasera sans prévenir.

La bonne méthode est le fichier d'extension : un fragment déposé dans /etc/systemd/system/nom.service.d/, qui ne remplace pas l'unité mais la complète.

systemctl edit chronyd          # créer ou modifier l'extension
systemctl edit --full chronyd   # copier l'unité entière dans /etc (à éviter)
systemctl cat chronyd           # voir l'unité effective, extensions comprises
systemctl daemon-reload         # recharger après une modification manuelle

systemctl edit ouvre un éditeur, crée l'arborescence nécessaire et recharge systemd tout seul. Si vous modifiez un fichier à la main, en revanche, systemd ne le voit pas tant que vous n'avez pas fait daemon-reload.

Exercice 5 — Une extension

Affichez l'unité effective de chrony avec la commande adaptée. Repérez la ligne Description.
Créez une extension qui remplace cette description par un texte de votre choix.
Affichez à nouveau l'unité effective. Que voyez-vous en haut du résultat, et que vous dit-il sur la façon dont systemd assemble les deux ?
Trouvez, dans /etc/systemd/system/, le fichier que systemctl edit a créé pour vous.
Vérifiez que le fichier d'origine dans /usr/lib n'a pas été modifié.
Supprimez votre extension à la main, rechargez systemd, et vérifiez le retour à l'état initial.

6. Les journaux¶

Quand un service refuse de démarrer, il ne vous le dit pas à l'écran : il l'écrit dans le journal. Savoir le lire est la compétence de dépannage la plus rentable de toute l'administration système.

systemd centralise tout dans journalctl, identique sur les deux familles.

Commande	Rôle
`journalctl`	Tout le journal, du plus ancien au plus récent
`journalctl -u chronyd`	Uniquement les messages d'un service
`journalctl -f`	Suivre en direct ce qui s'ajoute
`journalctl -n 50`	Les cinquante dernières lignes
`journalctl -b`	Depuis le démarrage courant
`journalctl -b -1`	Depuis le démarrage précédent
`journalctl --since "10 min ago"`	Fenêtre de temps
`journalctl --since today --until "12:00"`	Bornes précises
`journalctl -p err`	Uniquement les erreurs et plus grave
`journalctl -xe`	Fin du journal, avec explications

Les priorités vont de emerg (0) à debug (7). En dépannage, -p err élimine d'emblée 95 % du bruit.

Le triplet du dépannage

Dans l'ordre, systématiquement : systemctl status service pour l'état, journalctl -u service -n 50 pour les messages, journalctl -u service -f dans un second terminal pendant que vous relancez. Ces trois commandes résolvent la majorité des pannes de service.

La persistance¶

Par défaut, selon la distribution, le journal peut n'exister qu'en mémoire et disparaître au redémarrage — ce qui est gênant quand la panne est justement au démarrage. La configuration se trouve dans /etc/systemd/journald.conf, et le journal persistant s'écrit dans /var/log/journal/.

Exercice 6 — Lire les journaux

Affichez les vingt dernières lignes du journal de chrony.
Redémarrez le service tout en suivant son journal en direct dans un second terminal. Que voyez-vous apparaître ?
Affichez toutes les erreurs survenues depuis le démarrage de la machine. Combien y en a-t-il ?
Affichez le journal du démarrage précédent. Si la commande ne renvoie rien, cherchez pourquoi — la réponse est juste au-dessus.
Vérifiez sur chaque serveur si le journal est persistant. Diffèrent-ils ?
Trouvez, dans le journal, la trace des commandes sudo que vous avez tapées au TP 2.

Indice — question 6

Le journal accepte un filtre par identifiant de programme, de la même façon qu'il accepte un filtre par unité. Sinon, un simple tube vers grep fait l'affaire.

7. Planifier une tâche¶

Deux mécanismes coexistent. L'ancien, cron, est universel et se retrouve partout. Le moderne, les timers systemd, est plus verbeux mais s'intègre aux journaux et gère les rattrapages.

cron¶

┌── minute (0-59)
│ ┌── heure (0-23)
│ │ ┌── jour du mois (1-31)
│ │ │ ┌── mois (1-12)
│ │ │ │ ┌── jour de la semaine (0-7, 0 et 7 = dimanche)
│ │ │ │ │
* * * * *  commande

crontab -e      # éditer ses propres tâches
crontab -l      # les lister
sudo crontab -e # éditer celles de root

30 2 * * * signifie « tous les jours à 2 h 30 ». */15 * * * * signifie « toutes les quinze minutes ».

Les timers systemd¶

Un timer est un couple de deux unités : un .service qui décrit quoi faire, un .timer qui décrit quand.

# /etc/systemd/system/menage.service
[Service]
Type=oneshot
ExecStart=/usr/local/bin/menage.sh

# /etc/systemd/system/menage.timer
[Timer]
OnCalendar=daily
Persistent=true

[Install]
WantedBy=timers.target

Persistent=true rattrape l'exécution manquée si la machine était éteinte à l'heure prévue — ce que cron ne sait pas faire.

Commande	Rôle
`systemctl list-timers`	Les timers actifs et leur prochaine échéance
`systemd-analyze calendar "daily"`	Tester une expression de temps

Exercice 7 — Planifier

Écrivez un script dans /usr/local/bin/ qui ajoute la date courante à la fin d'un fichier de journal. Rendez-le exécutable.
Avec cron, planifiez-le toutes les deux minutes. Attendez, puis vérifiez le fichier.
Supprimez la tâche cron.
Refaites la même chose avec un timer systemd. Vérifiez qu'il apparaît dans la liste des timers avec sa prochaine échéance.
Consultez le journal du service associé. Voyez-vous chaque exécution ?
En une phrase : qu'est-ce que le timer vous apporte que cron ne vous donnait pas ?

Indice — question 4

Deux fichiers à créer, un daemon-reload pour que systemd les voie, et c'est le .timer qu'il faut activer — pas le .service.

8. Synthèse¶

Action	Debian	Rocky Linux
Rafraîchir l'index	`apt update`	automatique
Chercher	`apt search`	`dnf search`
Installer	`apt install`	`dnf install`
Supprimer	`apt remove` / `purge`	`dnf remove`
Lister l'installé	`dpkg -l`	`rpm -qa`
Fichiers d'un paquet	`dpkg -L`	`rpm -ql`
Propriétaire d'un fichier	`dpkg -S`	`rpm -qf` / `dnf provides`
Annuler une transaction	—	`dnf history undo`
Gérer un service	`systemctl`	`systemctl`
Lire les journaux	`journalctl`	`journalctl`

Exercice 8 — Tableau de correspondance

Complétez votre tableau avec les lignes de cette séance :

Élément	Debian	Rocky Linux
Commande d'installation
Emplacement des dépôts
Nom du service SSH
Nombre de paquets installés
Nombre de services actifs
Journal persistant par défaut

Avant de partir¶

[ ] Je sais installer et désinstaller un logiciel sur les deux familles
[ ] Je sais retrouver quel paquet a déposé un fichier
[ ] Je fais la différence entre démarrer un service et l'activer au démarrage
[ ] Je sais modifier un service sans que la mise à jour écrase mon travail
[ ] Je sais lire le journal d'un service et filtrer sur les erreurs
[ ] Je sais planifier une tâche répétitive de deux façons

Pour aller plus loin¶

Le service qui refuse de démarrer

Introduisez volontairement une faute dans la configuration de chrony, puis tentez de le redémarrer. Utilisez le triplet de dépannage pour identifier la ligne fautive sans regarder le fichier. C'est exactement ce que vous ferez en production.

Les dépendances

Choisissez un paquet volumineux et affichez la liste de ses dépendances sans l'installer. Combien de paquets seraient tirés ? Cherchez ensuite l'inverse : quels paquets dépendent d'une bibliothèque donnée ?

Les cibles systemd

Affichez la cible par défaut de vos deux serveurs. Listez les unités rattachées à multi-user.target. Que se passerait-il si vous changiez la cible par défaut pour rescue.target ? Réfléchissez avant d'essayer — et n'essayez que si vous savez comment revenir en arrière.

Les sockets

Certains services ne tournent pas en permanence : systemd écoute le port à leur place et les lance à la première connexion. Listez les unités de type socket et trouvez à quels services elles correspondent.