Mettre à jour le noyau et la distribution

Pourquoi

Dans la fiche de sig-app-1 dressée à la leçon 1, trois lignes dérangent : uptime dépasse deux cents jours, /var/run/reboot-required date du printemps, et uname -r montre un noyau plus ancien que le plus récent présent dans /boot. unattended-upgrades a fait son travail (Les paquets et les mises à jour), mais personne n'a fait le reste : les correctifs du noyau sont installés, pas en service. Pendant des mois, la machine a tourné avec des failles corrigées sur le disque.

Ce n'est pas de la négligence, c'est l'absence de politique. Les mises à jour quotidiennes s'automatisent ; le redémarrage d'un serveur qui porte du trafic demande une décision : quand, dans quel ordre, avec quelle vérification. Plus loin se profile une question que personne ne pose tant qu'elle n'est pas urgente : le support standard d'Ubuntu 24.04 s'arrête en mai 2029, Debian 13 passe en support à long terme en août 2028. Ces machines devront changer de version ou être remplacées, et mieux vaut ne pas le découvrir la dernière semaine.

Cette leçon transforme « faire les mises à jour » en politique de mise à jour d'un parc : noyaux installés et noyau en cours, processus qui exécutent du code périmé, redémarrages coordonnés sans couper Signalements, portée réelle du correctif à chaud, et changement de version majeure avec un instantané et un plan de retour écrit d'avance. APT lui-même (upgrade, full-upgrade, dépôts) est supposé acquis.

Les concepts

Trois rythmes de mise à jour

Traiter ces trois rythmes de la même façon conduit soit à des interventions manuelles sans fin, soit à des redémarrages jamais faits. Le premier relève de l'automatisation, le deuxième d'une procédure dans une fenêtre de maintenance, le troisième d'un plan avec instantané et retour arrière.

Le noyau, un paquet installé à côté des autres

Mettre à jour un paquet ordinaire remplace ses fichiers. Le noyau fait exception : chaque version est un paquet distinct, et les versions s'installent côte à côte.

• Ubuntu 24.04 : linux-image-6.8.0-146-generic. 146 est le numéro d'ABI, incrémenté à chaque cycle de maintenance ; generic est la saveur (flavour, variante de configuration du noyau). Les images cloud utilisent selon le fournisseur generic, virtual ou une saveur dédiée comme kvm.
• Debian 13 : linux-image-6.12.111+deb13-amd64, ou sa variante allégée pour machines virtuelles ...-cloud-amd64.

On n'installe pas ces paquets à la main, mais un méta-paquet (paquet vide qui dépend de la dernière version d'un autre) : linux-generic ou linux-virtual sur Ubuntu, linux-image-amd64 ou linux-image-cloud-amd64 sur Debian. À chaque nouvelle ABI, le méta-paquet change de dépendance, APT installe le nouveau noyau et garde l'ancien, sélectionnable dans GRUB si le nouveau ne démarre pas (la leçon 5 s'en sert).

Combien de noyaux APT garde

apt autoremove retire les anciens noyaux, selon une règle que l'on lit dans le code d'APT 2.8 (fonction GetProtectedKernelsRegex de apt-pkg/algorithms.cc) :

1. le noyau en cours (uname -r) est toujours protégé ;
2. APT ajoute ensuite les noyaux installés, du plus récent au plus ancien, jusqu'à en protéger APT::NeverAutoRemove::KernelCount, soit 2 par défaut (valeur minimale imposée) ;
3. les autres noyaux installés automatiquement deviennent candidats au retrait.

Sur une machine redémarrée, on garde donc le noyau courant et le précédent. Sur une machine pas redémarrée depuis plusieurs mises à jour, on garde le vieux noyau en cours et le plus récent, jamais démarré ; les intermédiaires, qui ont peut-être fonctionné, partent. Redémarrer régulièrement, c'est aussi garder un noyau de secours éprouvé.

Ce qui reste en mémoire après une mise à jour

Quand dpkg remplace libssl.so.3, il écrit un nouveau fichier et supprime l'ancien nom ; un processus en cours garde l'ancien contenu projeté en mémoire jusqu'à sa fin (/proc/<pid>/maps le marque (deleted), mécanisme vu dans Manipuler fichiers et répertoires). Le correctif est sur le disque, pas dans le processus.

needrestart détecte ces processus après chaque opération APT, remonte au service systemd qui les contient, puis, selon son mode, liste ces services, les propose ou les redémarre. Il compare aussi le noyau en cours avec le plus récent installé. Le noyau, lui, exige un redémarrage de la machine. Sur Ubuntu, le paquet update-notifier-common crée alors /var/run/reboot-required ; sur Debian, le script d'installation des paquets linux-image ne le crée pas : seul le crochet /etc/kernel/postinst.d/unattended-upgrades le fait, à condition que unattended-upgrades soit installé. Pour une détection qui ne dépend d'aucun paquet annexe, on s'en remet à needrestart -k.

Le correctif à chaud du noyau

Le livepatch (remplacement de fonctions du noyau en mémoire, sans redémarrer) est intégré au noyau depuis la version 4.0. D'après sa documentation, un module charge des versions corrigées de certaines fonctions, et un gestionnaire ftrace détourne les appels vers elles. Chaque tâche bascule quand aucune fonction concernée n'est dans sa pile, ou à son retour en espace utilisateur. Seules les fonctions traçables peuvent être remplacées, et un correctif qui modifie une structure de données demande un travail spécifique. Les éditeurs ne livrent donc des correctifs à chaud que pour une sélection de failles :

• Canonical Livepatch, inclus dans Ubuntu Pro (gratuit pour un usage personnel sur quelques machines), couvre une partie des failles hautes et critiques, pour les noyaux et saveurs listés comme couverts, pendant une fenêtre glissante de 13 mois par révision de noyau, selon l'annonce de Canonical.
• kpatch sur RHEL et ses dérivés livre des paquets kpatch-patch-* pour des failles importantes et critiques, pendant une durée limitée par version de noyau.

Ni l'un ni l'autre ne livre les correctifs ordinaires, les failles mineures, les pilotes ou le micrologiciel. Le correctif à chaud retarde le redémarrage, il ne le supprime pas. Un noyau ainsi corrigé porte la marque K dans ses taints (leçon 3).

Pour mémoire, kexec (systemctl kexec) démarre un nouveau noyau sans repasser par le micrologiciel. Utile sur un serveur physique lent à initialiser, il apporte peu sur une instance cloud, dont le micrologiciel virtuel démarre en quelques secondes.

Noyaux GA et HWE sur Ubuntu LTS

Une LTS sort avec un noyau GA (General Availability), 6.8 pour 24.04, maintenu toute la vie de la version. La lignée HWE (Hardware Enablement) suit au contraire un modèle glissant : à chaque version intermédiaire, elle adopte le noyau de la dernière version semestrielle d'Ubuntu, jusqu'à la LTS suivante. Pour 24.04, elle est passée de 6.8 à 6.11, 6.14, 6.17, puis 7.0, le noyau d'Ubuntu 26.04, où elle s'arrête. D'après l'équipe noyau de Canonical, les installations Server restent sur GA par défaut, HWE s'obtenant par sudo apt install --install-recommends linux-generic-hwe-24.04.

Pour sig-app-1, restez sur GA : le matériel virtuel de Scaleway est pris en charge par 6.8, et l'on évite un changement de version du noyau tous les six mois. HWE se justifie pour du matériel physique récent ou une fonctionnalité précise du noyau.

Le cycle de vie des versions

ESM (Expanded Security Maintenance) prolonge les correctifs de sécurité d'Ubuntu de cinq ans. Debian LTS est un effort distinct, financé par des sponsors, sur un périmètre réduit. Ce sont des filets, pas des stratégies : les logiciels vieillissent, et les dépendances de l'application (la version de Python) finissent par décrocher.

Migrer en place ou reconstruire

• Migrer en place : changer les dépôts et tout mettre à niveau. La machine hérite de son histoire : réglages manuels, paquets orphelins. C'est la voie des notes de publication de Debian et de do-release-upgrade.
• Reconstruire : créer une machine neuve dans la nouvelle version, y déployer configuration et application par l'automatisation, basculer le trafic, détruire l'ancienne. C'est l'infrastructure immuable, le bétail plutôt que les animaux de compagnie (animaux et bétail).

Pour sig-app-1 et sig-app-2, sans état (la base est managée), reconstruire est la voie naturelle. Pour sig-outils, qui conserve journaux reçus et exports, la migration en place reste défendable, avec sauvegarde et instantané.

En pratique

Les sorties ci-dessous sont des sorties typiques, construites d'après la documentation et le code source des outils ; les versions sont des exemples.

Inventorier les noyaux de sig-app-1

$ uname -r
$ dpkg -l 'linux-image-*' | grep '^ii'
$ apt-mark showmanual | grep -E '^linux-'
$ df -h /boot

uname -r donne le noyau en cours. dpkg -l liste les paquets de noyau, dont on garde l'état ii (installé) ; les guillemets protègent l'étoile du shell. apt-mark showmanual doit montrer le méta-paquet, pas les noyaux versionnés, qui doivent rester « automatiques ». df -h /boot surveille la partition qui se remplit la première quand elle est séparée. Sortie typique de la deuxième commande :

ii  linux-image-6.8.0-130-generic  6.8.0-130.130  amd64  Signed kernel image generic
ii  linux-image-6.8.0-141-generic  6.8.0-141.141  amd64  Signed kernel image generic
ii  linux-image-6.8.0-146-generic  6.8.0-146.146  amd64  Signed kernel image generic
ii  linux-image-generic            6.8.0-146.146  amd64  Generic Linux kernel image

Si uname -r renvoie 6.8.0-130-generic, la machine a manqué deux cycles. apt autoremove garderait 130 (en cours) et 146 (le plus récent), et retirerait 141. Vérifiez-le sans rien toucher :

$ apt-get -s autoremove --purge -o Debug::pkgAutoRemove=1

-s simule ; --purge retirerait aussi les fichiers de configuration ; l'option de débogage affiche les lignes Keeping booted kernel et Keeping previous kernel du code d'APT. Ne gonflez pas KernelCount « par prudence » : vous rempliriez /boot. La vraie prudence est de redémarrer, puis de nettoyer.

Lire needrestart

needrestart s'exécute après chaque opération APT (crochet DPkg::Post-Invoke de /etc/apt/apt.conf.d/99needrestart), et à la demande. D'après sa page de manuel, -r choisit le mode (l liste seulement, i interactif, a automatique), -k limite la vérification au noyau, -l aux bibliothèques, et -b produit une sortie pour les programmes, sans rien redémarrer.

$ sudo needrestart -r l

Après une mise à jour d'OpenSSL, avec le noyau périmé, la sortie ressemble à ceci :

Pending kernel upgrade!

Running kernel version:
  6.8.0-130-generic

Diagnostics:
  The currently running kernel version is not the expected kernel version 6.8.0-146-generic.

Restarting the system to load the new kernel will not be handled automatically, so you should consider rebooting.

Services to be restarted:
 systemctl restart signalements.service
 systemctl restart ssh.service

No containers need to be restarted.

No user sessions are running outdated binaries.

Le diagnostic du noyau distingue une nouvelle version (not the expected kernel version) d'une mise à jour compatible au niveau ABI (has an ABI compatible upgrade pending). Le mode batch dit la même chose pour la supervision :

$ sudo needrestart -b
NEEDRESTART-VER: 3.6
NEEDRESTART-KCUR: 6.8.0-130-generic
NEEDRESTART-KEXP: 6.8.0-146-generic
NEEDRESTART-KSTA: 3
NEEDRESTART-SVC: signalements.service
NEEDRESTART-SVC: ssh.service

NEEDRESTART-KSTA vaut 0 (inconnu), 1 (à jour), 2 (mise à jour ABI compatible en attente) ou 3 (nouvelle version en attente). C'est la valeur à collecter : un 3 qui dure des semaines est une alerte. L'option -o produit le même contenu au format OpenMetrics.

Régler needrestart sur Ubuntu et sur Debian

Ubuntu 24.04 applique un correctif maison (ubuntu-mode.patch) : le crochet APT appelle needrestart avec -m u, et dans ce « mode Ubuntu », faute de mode configuré explicitement, needrestart passe en a et redémarre les services concernés, y compris sous unattended-upgrades. La table $nrconf{override_rc} de la configuration exclut par défaut D-Bus, les getty, les services réseau, docker et les services oneshot d'APT.

Pour Signalements, c'est à la fois bien (le correctif de la bibliothèque TLS est en service dès la nuit) et risqué : un redémarrage coupe les requêtes au-delà du délai de grâce de Gunicorn (30 secondes par défaut), et si les deux machines reçoivent la même mise à jour au même moment, le service tombe des deux côtés. La solution la plus fine garde le mode automatique pour le système et exclut le seul service applicatif, dans un fichier de /etc/needrestart/conf.d/ (le fichier principal appartient au paquet) :

# /etc/needrestart/conf.d/50-lyneko.conf
# signalements.service est redémarré par la procédure coordonnée.
$nrconf{override_rc}{qr(^signalements\.service$)} = 0;

La syntaxe est du Perl : qr(...) est une expression régulière, 0 signifie « non sélectionné ». Le service reste listé, sans être redémarré. Pour revenir à la simple liste pour tout, on écrirait $nrconf{restart} = 'l'; : le correctif d'Ubuntu désactive alors son mode et l'annonce par Disabling Ubuntu mode, explicit restart mode configured.

Debian 13 n'installe pas needrestart par défaut. Dans sa version 3.11, le mode par défaut est interactif, et la page de manuel précise qu'il se replie en « liste seulement » sans terminal, donc sous unattended-upgrades. Sur sig-outils, installez-le (sudo apt install needrestart) au moins pour la détection.

Redémarrer sig-app-1 et sig-app-2 sans couper le service

Les deux instances sont derrière le répartiteur de charge Scaleway sig-lb, dont le backend envoie le trafic vers 172.16.8.11 et 172.16.8.12 sur le port 8000, avec une vérification de santé sur /sante. Règle : une machine à la fois, jamais la seconde avant d'avoir vérifié la première, une mise à jour progressive à l'échelle de deux serveurs.

  sig-lb ──┬── X ── sig-app-1   1. retirée du backend, 2. redémarre, 3. vérifiée
           └─────── sig-app-2   porte seule le trafic
  4. sig-app-1 remise dans le backend, 5. déclarée saine, 6. même chose pour sig-app-2

Avant, ouvrez la console Scaleway de la machine (seul accès si le réseau ne remonte pas), et vérifiez que l'autre peut porter seule la charge et que le service reviendra :

$ ssh sig-app-2 'systemctl is-active signalements && curl -fsS http://172.16.8.12:8000/sante'
$ systemctl is-enabled signalements

curl -f sort en erreur sur une réponse HTTP d'erreur ; -sS masque la progression mais garde les erreurs.

Retirer sig-app-1 du backend, avec la CLI Scaleway :

$ scw lb backend list lb-id=<id-de-sig-lb> zone=fr-par-1
$ scw lb backend remove-servers <id-du-backend> server-ip.0=172.16.8.11 zone=fr-par-1

Le répartiteur cesse d'envoyer de nouvelles requêtes à cette adresse. Laissez quelques dizaines de secondes aux requêtes en cours : c'est le drain (vidange des connexions avant arrêt).

Redémarrer, en laissant une trace :

$ sudo systemctl reboot --message="Noyau 6.8.0-146, redémarrage coordonné (ticket OPS-412)"

D'après systemctl(1), --message (depuis systemd 225) joint cette explication au message d'arrêt consigné dans le journal : journalctl -b -1 -n 50 dira plus tard pourquoi la machine a redémarré. L'arrêt planifié avec message aux personnes connectées a été vu à la leçon 2.

Vérifier au retour :

$ uname -r
$ systemctl is-system-running
$ systemctl --failed
$ curl -fsS http://172.16.8.11:8000/sante
$ journalctl -b -p err --no-pager
$ sudo needrestart -b | grep KSTA

On attend le nouveau noyau, running (et non degraded, qui signale une unité en échec nommée par systemctl --failed), une réponse de /sante, pas d'erreur nouvelle depuis le démarrage, et NEEDRESTART-KSTA: 1.

Remettre la machine, puis attendre qu'elle soit saine avant de passer à sig-app-2 :

$ scw lb backend add-servers <id-du-backend> server-ip.0=172.16.8.11 zone=fr-par-1
$ scw lb backend list-statistics <id-de-sig-lb> zone=fr-par-1

Cette procédure est un runbook : écrivez-le avec les identifiants réels, jouez-le à la main plusieurs fois, puis automatisez-le (une tâche Ansible avec serial: 1, dans le cours Ansible : les fondamentaux).

Activer Livepatch sur Ubuntu

$ sudo pro attach <jeton>
$ sudo pro enable livepatch
$ canonical-livepatch status --verbose
$ pro status

pro attach rattache la machine à l'abonnement Ubuntu Pro (le jeton est un secret) ; pro enable livepatch installe le client, un snap, et l'active ; canonical-livepatch status --verbose dit si le noyau en cours est couvert et quels correctifs sont appliqués ; pro status résume les services (esm-infra, esm-apps, livepatch) et affiche les avertissements.

Préparer un changement de version majeure : l'instantané

Une mise à niveau de distribution ne se désinstalle pas. Le retour arrière, c'est l'instantané du volume système, pris juste avant :

$ scw instance server get <id-de-l-instance> zone=fr-par-1
$ scw block snapshot create volume-id=<id-du-volume> name=sig-outils-avant-migration zone=fr-par-1
$ scw block snapshot list zone=fr-par-1

La première commande montre les volumes de l'instance ; la deuxième crée l'instantané (le volume doit être in_use ou available, précise la documentation de la CLI) ; la troisième suit son état. Un instantané d'une machine en marche est cohérent comme après une coupure de courant : arrêtez les services qui écrivent avant de le prendre. Et il vit chez le même fournisseur, dans le même compte : il ne remplace pas une sauvegarde (leçon 16).

Le plan de retour s'écrit avant de commencer :

1. Critères d'échec : machine qui ne démarre pas, service qui ne repart pas après une heure de diagnostic, régression constatée par les tests.
2. Procédure : créer un volume depuis l'instantané, le substituer au volume système (ou créer une instance depuis l'instantané), vérifier.
3. Coût : tout ce qui a été écrit depuis l'instantané est perdu. Pour sig-outils, ce sont les journaux reçus pendant la fenêtre, à faire tamponner par les émetteurs (file d'attente sur disque de rsyslog, leçon 12).

Ubuntu : de 24.04 à 26.04 avec do-release-upgrade

do-release-upgrade lit /etc/update-manager/release-upgrades, dont la clé Prompt vaut never, normal (version suivante, LTS ou non) ou lts (LTS suivante seulement). Sur un serveur LTS, gardez lts. Canonical n'ouvre la mise à niveau entre LTS qu'à la première version ponctuelle de la nouvelle (26.04.1).

$ do-release-upgrade -c

-c vérifie sans rien lancer, et répond New release '26.04 LTS' available. ou No new release found. (messages du code de l'outil). Ce code refuse de démarrer s'il reste des mises à jour (Please install all available updates for your release before upgrading.) ou si /var/run/reboot-required.pkgs mentionne un noyau, libc6 ou linux-base (You have not rebooted after updating a package which requires a reboot. Please reboot before upgrading.). D'où la préparation : sudo apt full-upgrade, redémarrage, instantané, retrait du répartiteur, df -h / /boot, et lecture des notes de version. Elles signalent ce qui vous touchera : la version de Python système change, ce qui casse l'environnement virtuel /opt/signalements/venv ; Ubuntu a aussi remplacé sudo et les coreutils par des réimplémentations en Rust depuis 25.10, à valider avec vos scripts.

$ sudo do-release-upgrade

Ce que fait l'outil, d'après son code :

• il se relance dans une session GNU screen nommée ubuntu-release-upgrade-screen-window ; après une coupure, relancer la commande rattache cette session ;
• sous SSH, il avertit (This session appears to be running under ssh. It is not recommended to perform a upgrade over ssh currently because in case of failure it is harder to recover.) et démarre un second démon SSH sur le port 1022, fermé par le groupe de sécurité et le pare-feu (leçon 8) : décidez d'avance si vous l'ouvrez depuis le réseau privé ou si vous travaillez depuis la console ;
• il désactive les dépôts tiers (sauf --allow-third-party), affiche les paquets à installer, mettre à jour et supprimer, demande confirmation, interroge sur les fichiers de configuration modifiés, propose de retirer les paquets obsolètes, puis de redémarrer.

Tout est consigné dans /var/log/dist-upgrade/ : main.log (le déroulé, par où commencer en cas d'échec), apt.log, term.log, et apt-clone_system_state.tar.gz (l'état des paquets avant). Après le redémarrage : cat /etc/os-release, uname -r, systemctl --failed, environnement virtuel recréé, test de santé, retour dans le répartiteur, puis réactivation des dépôts tiers un par un.

Debian : de 12 à 13 selon les notes de publication

Camille a migré sig-outils en Debian 13 sans laisser de notes. La migration vers Debian 14 sera la vôtre, et la méthode sera la même : celle du chapitre 4 des notes de publication de la version cible. On la déroule ici sur l'exemple 12 vers 13, à rejouer sur une machine virtuelle jetable. Debian n'a pas d'outil dédié : on change les dépôts et on pilote APT.

1. Lire les notes, surtout le chapitre 5. Pour trixie : /tmp devient un tmpfs par défaut ; systemd-sysctl ne lit plus /etc/sysctl.conf (utiliser /etc/sysctl.d/, leçon 3) ; OpenSSH abandonne les clés DSA ; certains noms d'interfaces réseau peuvent changer. Seule la mise à niveau depuis Debian 12 est prise en charge : on ne saute pas de version.

2. Vérifier l'état de départ, avec les commandes des notes :

$ sudo apt update && sudo apt full-upgrade
$ sudo dpkg --audit
$ apt-mark showhold
$ apt list '?narrow(?installed, ?not(?origin(Debian)))'
$ apt list '?obsolete'

dpkg --audit signale les paquets mal configurés, apt-mark showhold les paquets retenus, le motif ?narrow(...) les paquets qui ne viennent pas de Debian (chacun est un risque), et ?obsolete (forme courte ~o) ceux qui n'existent plus dans aucun dépôt. Les notes de trixie signalent aussi qu'un défaut d'OpenSSH de bookworm peut rendre la machine inaccessible si une mise à niveau menée par SSH est interrompue, et demandent la version 1:9.2p1-2+deb12u7 au minimum avant de commencer. C'est typiquement ce que seules les notes révèlent.

3. Instantané et sauvegarde. Les notes conseillent de sauvegarder /etc, /var/lib/dpkg, /var/lib/apt/extended_states et la sortie de dpkg --get-selections '*'.

4. Changer les dépôts. Retirez bookworm-backports et proposed-updates, puis :

$ grep -rn bookworm /etc/apt/sources.list /etc/apt/sources.list.d/
$ sudo sed -i 's/bookworm/trixie/g' /etc/apt/sources.list /etc/apt/sources.list.d/*

Le grep d'abord, pour voir aussi les dépôts tiers qui ne publient peut-être pas pour trixie. bookworm-security devient trixie-security. Les notes recommandent ensuite le format deb822 (fichiers .sources en blocs Champ: valeur) ; la conversion se fait après la mise à niveau avec apt modernize-sources, commande d'APT 3.0 inconnue de bookworm.

5. Mettre à niveau en deux temps, dans tmux pour survivre à une coupure :

$ tmux new -s migration
$ sudo apt update
$ sudo apt -o APT::Get::Trivial-Only=true full-upgrade
$ sudo apt upgrade --without-new-pkgs
$ sudo apt full-upgrade

Trivial-Only=true calcule la mise à niveau et l'espace nécessaire sans rien installer. upgrade --without-new-pkgs est la mise à niveau minimale : sans installation ni suppression, elle règle les cas simples et réduit le saut suivant. full-upgrade termine ; lisez la liste des suppressions avant de confirmer.

dpkg s'arrête sur chaque fichier de configuration que vous avez modifié et que le paquet livre dans une nouvelle version :

Configuration file '/etc/rsyslog.conf'
 ==> Modified (by you or by a script) since installation.
 ==> Package distributor has shipped an updated version.
   What would you like to do about it ?  Your options are:
    Y or I  : install the package maintainer's version
    N or O  : keep your currently-installed version
      D     : show the differences between the versions
      Z     : start a shell to examine the situation
 The default action is to keep your current version.

Répondez D d'abord. Souvent, mieux vaut prendre la version du paquet et reporter votre réglage dans un fichier de surcharge (.d/), qui ne posera plus la question. Inventoriez ensuite les restes avec sudo find /etc -name '*.dpkg-*' -o -name '*.ucf-*'.

6. Redémarrer et vérifier : cat /etc/debian_version, uname -r (6.12), systemctl --failed, et les tâches de sig-outils.

7. Nettoyer, selon les notes :

$ sudo apt modernize-sources
$ apt list '~o'
$ sudo apt purge '?obsolete'
$ sudo apt purge '?config-files'
$ sudo apt autoremove

Relisez ~o avant de purger : un outil encore utilisé peut y figurer. ?config-files désigne les paquets retirés dont il ne reste que la configuration (état rc).

Reconstruire plutôt que migrer

Pour les serveurs applicatifs, la voie recommandée est différente : créer sig-app-3 en 26.04 depuis l'image Scaleway avec cloud-init et l'automatisation, déployer Signalements avec un environnement virtuel neuf, l'ajouter au backend, observer, puis retirer et détruire sig-app-2, et recommencer pour sig-app-1. Le retour arrière est trivial : l'ancienne machine tourne encore. Et la procédure de reconstruction, testée ici, servira le jour où une machine sera perdue. Si l'automatisation n'existe pas encore, migrez en place une machine à la fois, et notez la dette.

Sous le capot

Comment APT reconnaît un noyau. Les paquets de noyau fournissent un paquet virtuel spécial, $kernel. APT parcourt ceux qui sont installés, en déduit la version de chacun, les trie selon la comparaison de versions de Debian, et construit une expression régulière des paquets à protéger, noyau et paquets associés (linux-modules-*, linux-headers-*) selon les motifs de APT::VersionedKernelPackages. Les anciennes versions d'APT passaient par un script, /etc/kernel/postinst.d/apt-auto-removal.

L'installation d'un noyau. Le script postinst du paquet Debian est court : depmod, mise à jour des liens /boot/vmlinuz et /boot/vmlinuz.old par linux-update-symlinks, puis exécution des crochets de /etc/kernel/postinst.d/. Les autres paquets s'y branchent : initramfs-tools construit l'initramfs, zz-update-grub régénère grub.cfg (le préfixe le fait passer en dernier), DKMS recompile les modules tiers, et sur Ubuntu update-notifier crée reboot-required. Si un crochet échoue (initramfs trop gros pour /boot, module DKMS qui ne compile pas), le paquet reste à moitié configuré, et dpkg --audit le montre.

needrestart. Il lit /proc/<pid>/maps de chaque processus à la recherche de fichiers projetés supprimés ou remplacés, puis /proc/<pid>/cgroup pour trouver l'unité systemd, ce qui donne directement signalements.service pour un worker Gunicorn. Pour les interpréteurs, il compare la date de démarrage du processus à celle des sources chargées ; pour le noyau, la version en cours à celle des images de /boot. Parce qu'il lance des interpréteurs en root pour cette analyse, il a connu fin 2024 des failles d'élévation de privilèges (CVE-2024-48990 et suivantes), corrigées dans la version 3.6-7ubuntu4.3 d'Ubuntu.

do-release-upgrade. L'outil installé n'est qu'un lanceur : il télécharge le programme de mise à niveau de la version cible, signé, parce que c'est la nouvelle version qui sait comment y arriver (paquets renommés, retirés, contournements, décrits dans sa configuration DistUpgrade.cfg). Il enregistre l'état des paquets avec apt-clone, réécrit les dépôts, puis pilote APT. D'où l'ouverture tardive de la mise à niveau entre LTS : ces règles doivent d'abord être éprouvées.

Les deux temps de Debian. Le résolveur d'APT doit trouver un ensemble cohérent de milliers de paquets dont noms, dépendances et conflits ont changé. Faire d'abord ce qui n'exige ni installation ni suppression réduit le problème, et évite qu'il choisisse de supprimer un paquet important pour satisfaire une dépendance mineure.

Pièges courants

/boot plein. Une mise à jour échoue avec No space left on device pendant update-initramfs, et des paquets restent à moitié configurés. Trop de noyaux, souvent marqués manuels ou jamais nettoyés faute de redémarrage. Diagnostic : df -h /boot, dpkg -l 'linux-image-*', apt-mark showmanual | grep linux-image. Réparation : sudo apt-mark auto sur les noyaux versionnés, retrait des plus anciens sauf celui qui tourne, puis sudo dpkg --configure -a.

Le méta-paquet manquant. apt upgrade ne propose rien, mais le noyau a deux ans. Si dpkg -l linux-generic linux-virtual linux-image-amd64 linux-image-cloud-amd64 ne montre rien d'installé, installez celui qui correspond au suffixe de uname -r.

Signalements redémarré dans la nuit. Sur Ubuntu 24.04, needrestart relance les services après unattended-upgrades, éventuellement sur les deux machines à la fois. journalctl -u signalements --since yesterday montre l'arrêt, /var/log/apt/history.log l'opération qui l'a précédé. Solution : override_rc et redémarrage coordonné.

reboot-required absent sur Debian. Sans unattended-upgrades, rien ne crée ce fichier sur Debian : la supervision qui le teste ne voit jamais rien sur sig-outils. Utilisez NEEDRESTART-KSTA, qui ne dépend pas de ce paquet.

Livepatch qui ne protège pas. Deux messages du client Ubuntu Pro, tirés de ses tests. The current kernel (...) is not covered by livepatch., suivi de Either switch to a covered kernel or \sudo pro disable livepatch` to dismiss this warning.: la saveur ou la version n'est pas couverte (certaines saveurskvm, par exemple). The running kernel has reached the end of its active livepatch window. Please upgrade the kernel with apt and reboot for continued livepatch coverage.` : la machine n'a pas redémarré depuis trop longtemps.

No new release found. alors que la LTS est sortie. La version .1 n'est pas encore là, ou Prompt ne vaut pas lts (avec never, l'outil le dit explicitement). N'utilisez pas -d, qui vise la version de développement.

La session coupée en pleine migration. Relancez sudo do-release-upgrade, qui rattache sa session screen, ou tmux attach -t migration sur Debian ; sinon, la console. Ne lancez jamais un second apt : Could not get lock /var/lib/dpkg/lock-frontend signifie que le premier tourne encore.

L'environnement virtuel cassé. Après migration, Signalements échoue avec status=203/EXEC ou une erreur Python : le venv pointe vers l'interpréteur de l'ancienne version. Recréez-le (python3 -m venv --clear /opt/signalements/venv) et réinstallez les dépendances depuis le fichier verrouillé.

Des réglages perdus en silence. Après trixie, les valeurs de /etc/sysctl.conf ne s'appliquent plus, sans aucun message. Vérifiez à chaud celles qui comptent (sysctl net.core.somaxconn).

Sécurité

• Un correctif installé n'est pas un correctif appliqué. Un scanner qui lit les versions de paquets déclare la machine corrigée alors que le noyau en mémoire est vulnérable. Les failles du noyau sont souvent des élévations de privilèges locales : qui obtient l'identité signalements par une faille de l'application peut devenir root. Mesurez le noyau en cours.
• Fixez un délai maximal de redémarrage, par exemple une semaine pour une faille critique du noyau, un mois sinon, et suivez-le comme un indicateur. Le guide de l'ANSSI sur les systèmes GNU/Linux (BP-028) fait de l'application régulière des correctifs une mesure de base.
• Le correctif à chaud complète, il n'excuse pas. Compter sur lui pour ne jamais redémarrer mène à un noyau hors de sa fenêtre de couverture.
• Une version hors support est vulnérable. Notez la date de fin de support dans la fiche de chaque machine et planifiez la migration un an avant.
• Instantanés et jetons sont des secrets. Un instantané de sig-app-1 contient /etc/signalements/env et le mot de passe de la base : restreignez les droits IAM sur les instantanés et supprimez ceux qui ne servent plus. Traitez le jeton Ubuntu Pro comme une clé d'API.
• Les outils de mise à jour tournent en root, crochets de paquets tiers compris : un dépôt tiers compromis est un accès root différé. Inventoriez-les avant chaque migration.
• Secure Boot et DKMS. Avec Secure Boot (leçon 2), un module recompilé après une mise à jour du noyau doit être signé par une clé enrôlée, sinon il est refusé. Vérifiez-le sur une machine de test.

En production

• Un calendrier plutôt que des interventions : une fenêtre mensuelle pour les noyaux, connue de l'équipe et de la mairie, et une procédure d'urgence pour les failles critiques.
• Un ordre de passage : préproduction, puis sig-app-2, puis sig-app-1, puis sig-outils. Ce qui casse casse d'abord sur la première, quelques jours avant les autres.
• Un inventaire mesuré : distribution, noyau en cours, noyau attendu, dernier démarrage, fin de support. needrestart -b ou -o, uname -r et /etc/os-release suffisent, avec une alerte au-delà du délai fixé.
• Un rayon d'impact borné : les automatismes ne se déclenchent jamais à la même heure sur deux machines du même rôle.
• Les versions majeures se préparent un an avant : machine de test dès la version .1, application validée sur le nouveau Python, puis reconstruction.
• À l'échelle, on remplace : au-delà de quelques machines, on construit une image dorée par version et l'on remplace les instances. Kapsule fait de même pour les nœuds de vos clusters : une montée de version remplace les nœuds un par un.

Exercices

1. Lire l'état d'une machine (niveau 100). Sur sig-outils, uname -r renvoie 6.12.94+deb13-amd64 ; sont installés linux-image-6.12.94+deb13-amd64, linux-image-6.12.111+deb13-amd64 et linux-image-amd64. /var/run/reboot-required n'existe pas. La machine est-elle à jour ? Comment le confirmer ?

2. Ce qu'autoremove retirera (niveau 200). Ubuntu 24.04, uname -r renvoie 6.8.0-141-generic. Sont installés automatiquement les noyaux 130, 141, 144 et 146. Que retire apt autoremove par défaut ? Que conseillez-vous ?

3. Le runbook de sig-app-2 (niveau 200). Écrivez le redémarrage coordonné de sig-app-2 : vérifications préalables, commandes, vérifications après, et critère d'arrêt avant de toucher sig-app-1.

4. needrestart et Signalements (niveau 200). Vous voulez que needrestart continue de redémarrer automatiquement les services système sur les deux serveurs applicatifs, sauf Signalements. Écrivez la configuration et dites comment vérifier son effet.

5. Migrer ou reconstruire (niveau 300). Ubuntu 26.04.1 vient de sortir. Proposez un plan pour que sig-app-1, sig-app-2 et sig-outils restent sur des versions supportées au-delà de 2029 : méthode, plan de retour et risques pour chaque machine, et ordre.

6. Après une migration Debian (niveau 300). Sur une machine de test passée de Debian 12 à 13, apt list '~o' affiche un agent de supervision venu du dépôt d'un éditeur, et sysctl vm.swappiness renvoie 60 au lieu des 10 réglés. Expliquez et dites ce que vous changez dans la procédure avant de migrer sig-outils.

Récapitulatif

• Trois rythmes : correctifs automatisés, noyau qui exige un redémarrage coordonné, version majeure qui est un projet avec plan de retour.
• Les noyaux sont des paquets versionnés installés côte à côte ; le méta-paquet fait arriver les nouveaux.
• apt autoremove protège le noyau en cours et le plus récent : redémarrer, puis nettoyer.
• needrestart repère les processus et le noyau périmés ; il redémarre les services sur Ubuntu 24.04, se contente de lister sous unattended-upgrades sur Debian 13 (où il faut l'installer) ; NEEDRESTART-KSTA alimente la supervision, reboot-required n'est créé sur Debian que par unattended-upgrades.
• Derrière un répartiteur : une machine à la fois, retrait, drain, redémarrage, vérification, remise.
• Livepatch et kpatch corrigent à chaud une partie des failles graves : ils retardent le redémarrage sans le remplacer.
• Serveur Ubuntu LTS : noyau GA ; HWE suit les noyaux des versions intermédiaires.
• Version majeure : instantané et plan de retour d'abord ; do-release-upgrade (Prompt=lts, /var/log/dist-upgrade/) sur Ubuntu ; sur Debian, les notes de la version cible, upgrade --without-new-pkgs puis full-upgrade, puis ~o et nettoyage.
• Machines sans état : reconstruire plutôt que migrer.

Pour aller plus loin

• Les chapitres 4 et 5 des notes de publication de Debian 13, et ceux de Debian 14 le moment venu.
• La documentation de l'équipe noyau de Canonical sur les noyaux HWE, et la liste des noyaux couverts par Livepatch.
• La page Livepatch de la documentation du noyau, pour le modèle de cohérence.
• Le code de do-release-upgrade (dépôt ubuntu-release-upgrader sur Launchpad), court et lisible.
• Le cours Ansible : les fondamentaux, pour automatiser redémarrages coordonnés et reconstructions.
• La leçon suivante, Dépanner un serveur qui ne démarre plus, pour le jour où la machine ne revient pas.