Maintenir un serveur Linux en bon état

Cette page ouvre le module Maintenir du parcours Linux. Un serveur mis en service ne reste pas en bon état tout seul : ses paquets vieillissent, des correctifs de sécurité sortent chaque semaine, un service oublié ne repart pas au redémarrage, et le disque finit par se remplir. Le module couvre ces quatre fronts en 14 leçons, cette page comprise, pour environ 3 h 30. Vous repartez d'ici avec le modèle commun aux cinq familles de gestionnaires de paquets, une routine de contrôle à passer chaque semaine, et la leçon à ouvrir pour chaque geste précis.

Ce que vous allez apprendre

Situer les treize leçons qui suivent et l'ordre dans lequel les suivre.
Relier chaque geste de maintenance à la commande qui prouve qu'il est fait.
Distinguer ce qui s'automatise (la sécurité) de ce qui se planifie (le fonctionnel).
Tenir une routine hebdomadaire en cinq contrôles sur Debian, Ubuntu et RHEL.
Savoir ce que ce module ne couvre pas, et où le trouver.

Les leçons du module, dans l'ordre

Le module suit la vie d'un serveur en exploitation. D'abord les paquets, parce que tout le reste en dépend : le modèle commun, puis un guide par gestionnaire. Viennent ensuite la réparation et les correctifs, puis les services au démarrage, et enfin la surveillance de la charge et du disque. Les guides de gestionnaires se lisent à la carte : suivez celui de votre distribution, survolez les autres.

Les paquets d'abord. La leçon gestion des paquets pose le modèle commun à tous les gestionnaires : dépôt, métadonnées, dépendances. Viennent ensuite les guides par famille, à lire selon votre distribution : APT pour Debian et Ubuntu, avec l'épinglage de version et les dépôts deb822, DNF pour RHEL et Fedora, avec son historique annulable, puis Flatpak pour les applications isolées, APK pour Alpine et les images conteneur minimales, Pacman pour Arch et son flux continu, et Zypper pour SUSE. La leçon fpm inverse le point de vue : construire un .deb, un .rpm et un .apk depuis les mêmes fichiers.

Réparer et corriger. Corriger les dépendances cassées traite l'installation interrompue, le verrou et le conflit de versions. Appliquer les mises à jour de sécurité apprend à ne patcher que la sécurité, et démasque les commandes répandues qui ne patchent rien.

Démarrage et ressources. Activer un service au démarrage distingue enable, is-enabled et ce que seul un vrai redémarrage prouve. Vérifier la charge système lit le load average, vmstat et PSI pour dire si le goulot est le processeur, la mémoire ou le disque, et contrôler l'espace disque et les inodes couvre le disque plein, les inodes épuisés et les fichiers supprimés encore ouverts.

Quatre fronts, une commande de preuve pour chacun

Maintenir un serveur tient en quatre gestes qui reviennent toutes les semaines : garder les paquets à jour, appliquer les correctifs, s'assurer que les services repartent au démarrage, surveiller les ressources. Pour chacun, le réflexe du module est le même : une action, suivie de la commande qui prouve qu'elle a produit l'effet voulu, jamais l'absence de message d'erreur.

Front	Action	Preuve sur Debian / Ubuntu	Preuve sur RHEL / AlmaLinux
Paquets	Mettre à jour	`apt list --upgradable` vide	`dnf check-update` rend le code 0
Sécurité	Appliquer les correctifs	`unattended-upgrades --dry-run -v` ne liste plus de paquet	`dnf updateinfo list security` vide
Services	Activer au démarrage	`systemctl is-enabled nginx` rend `enabled`	idem
Ressources	Surveiller	`df -h`, `df -i`, `uptime`	idem

La colonne de droite n'est pas symétrique par hasard. Sur la famille RHEL, DNF lit des avis de sécurité publiés par l'éditeur et sait cibler un correctif ; sur Debian et Ubuntu, seul unattended-upgrades lit l'origine des paquets. Ce détail décide de la façon dont vous automatiserez la sécurité, et la leçon 10 le démontre : deux recettes très répandues ne patchent rien tout en rendant un code de retour nul.

Ce qui s'automatise, ce qui se planifie

La règle que le module défend tient en une phrase : la sécurité s'automatise, le fonctionnel se planifie, le redémarrage se décide. Les confondre est la première source d'incident lié aux mises à jour. Un automate de sécurité mal restreint pousse des montées de version fonctionnelles sans que personne les ait testées, et un redémarrage automatique coupe un service en pleine journée.

L'automate existe sur les deux familles, unattended-upgrades côté Debian et dnf-automatic côté RHEL, et les deux partagent le même défaut : leur configuration livrée ne se limite pas à la sécurité. C'est le premier réglage à vérifier sur un serveur que vous reprenez, avant même de lire ses journaux.

Une routine hebdomadaire en cinq contrôles

Ces cinq contrôles, déclinés pour chaque famille, ne modifient rien et se passent en deux minutes. Ils couvrent les quatre fronts et donnent, chaque semaine, une photo de l'état du serveur. Une sortie inattendue renvoie vers la leçon correspondante du module.

df -h && df -i                      # espace et inodes (leçon 13)
uptime && nproc                     # charge rapportée aux cœurs (leçon 12)
systemctl --failed                  # unités en échec, sortie vide attendue (leçon 11)
apt list --upgradable 2>/dev/null   # Debian / Ubuntu : mises à jour en attente
sudo dnf check-update               # RHEL / AlmaLinux : code 100 si mises à jour
[ -f /run/reboot-required ] && cat /run/reboot-required.pkgs   # Debian / Ubuntu
sudo dnf needs-restarting -r        # RHEL / AlmaLinux : redémarrage requis ?

Les deux dernières lignes répondent à la question que la routine oublie le plus souvent : un correctif du noyau ou de la glibc n'est actif qu'après un redémarrage. Sur RHEL, dnf needs-restarting -r rend le code 1 quand il en faut un ; le fichier /run/reboot-required n'existe que sur Debian et Ubuntu.

Ce que ce module ne couvre pas

Le module s'arrête au système en place. Le stockage, qui a son propre module juste après celui-ci, commence là où le disque plein ne se règle plus par du ménage : il faut agrandir un volume ou en ajouter un. La configuration réseau relève du module Réseau, qui précède.

Le module Stockage couvre partitions, systèmes de fichiers, LVM, RAID et chiffrement ; quand l'espace manque durablement, sa leçon LVM montre comment étendre un volume logique à chaud. Le module Réseau traite interfaces, adresses, routes et l'outil de configuration de chaque distribution. Enfin, si un service activé ne repart pas après le redémarrage, la procédure un service ne démarre pas du module Dépanner prend le relais.

À retenir

Le module Maintenir couvre quatre fronts : paquets, correctifs de sécurité, services au démarrage, ressources. 14 leçons, environ 3 h 30.
Chaque geste se termine par une commande de preuve, jamais par l'absence d'erreur : is-enabled, dnf updateinfo list security, df -i.
La sécurité s'automatise, le fonctionnel se planifie, le redémarrage se décide. Les automates livrés (unattended-upgrades, dnf-automatic) ne se limitent pas à la sécurité par défaut.
Une routine hebdomadaire en cinq contrôles en lecture seule donne l'état du serveur en deux minutes.
Un correctif du noyau n'est actif qu'après redémarrage : dnf needs-restarting -r sur RHEL, /run/reboot-required sur Debian.