Mettre à jour un serveur Linux sans risque avec apt

Sur un serveur tout neuf, une mise à jour est une formalité : il n'y a rien qui puisse casser. Dès que le serveur héberge des services, ce sont les détails qui décident si la mise à jour passe inaperçue ou si, ensuite, un fichier de configuration se retrouve écrasé, un service garde encore l'ancienne bibliothèque en mémoire ou le noyau en cours d'exécution n'est plus celui qui se trouve sur le disque. Cet article les passe en revue dans l'ordre. La version courte pour un système fraîchement livré figure dans la checklist pour un nouveau serveur root.

Toutes les indications se rapportent à Debian 13 (trixie), Debian 12 (bookworm), Ubuntu 24.04 LTS et Ubuntu 22.04 LTS. Les commandes sont écrites pour une exécution en tant que root. En utilisateur normal, faites précéder chaque commande de sudo.

Avant de lancer la première commande : le chemin du retour

Une mise à jour peut coûter cher de trois façons : une question de configuration écrase la configuration SSH, un nouveau noyau refuse de démarrer, ou la connexion se coupe au milieu d'une transaction dpkg. Ces trois cas se maîtrisent, mais seulement si vous prenez vos précautions à l'avance.

Une session qui survit à une coupure de connexion

Si la connexion SSH se coupe pendant le décompactage, le processus en cours reçoit un SIGHUP et dpkg s'arrête au milieu d'une transaction. Le résultat est une base de données de paquets à moitié configurée. Exécutez donc les mises à jour un peu longues dans une session qui continue de tourner sur le serveur, même si votre terminal disparaît :

apt install -y tmux
tmux new -s upgrade

Si la connexion tombe, reconnectez-vous et récupérez la session avec tmux attach -t upgrade. L'opération a continué entre-temps.

L'accès au serveur quand SSH ne répond plus

Sur les serveurs root KVM et les serveurs dédiés de KernelHost, vous atteignez la console VNC depuis l'espace client. Elle ne dépend pas de la pile réseau du système invité et fonctionne aussi lorsque plus aucun service n'écoute. Connectez-vous une fois par ce biais au préalable et assurez-vous de connaître le mot de passe root.

Pour le cas d'un noyau qui ne démarre pas, il vous faut également un menu de démarrage visible. Sur les serveurs, il est souvent masqué :

grep -E '^GRUB_TIMEOUT|^GRUB_TIMEOUT_STYLE' /etc/default/grub

Si vous y trouvez GRUB_TIMEOUT_STYLE=hidden ou GRUB_TIMEOUT=0, mettez GRUB_TIMEOUT_STYLE=menu et GRUB_TIMEOUT=5, puis lancez update-grub. En cas d'urgence, choisissez le noyau précédent dans la console VNC, sous « Advanced options ».

Vérifier l'état du système et le consigner

Trois vérifications préalables, qui trouvent quelque chose plus souvent qu'on ne le croit :

df -h / /boot /var
dpkg --audit
apt-get check

Contrôle de réussite : dpkg --audit n'affiche rien, apt-get check se termine sans ligne d'erreur, et il reste au moins 300 MB d'espace libre dans /boot. Un /boot plein est la cause la plus fréquente d'une mise à jour de noyau interrompue, vous en saurez plus dans disque plein sous Linux. Si dpkg --audit signale quelque chose, réparez cela en premier avec dpkg --configure -a.

Consignez ensuite l'état actuel dans un fichier, pour pouvoir comparer plus tard :

dpkg --get-selections > /root/paquets-avant-upgrade.txt
apt-mark showhold > /root/holds-avant-upgrade.txt
cp -a /etc/apt /root/apt-config-$(date +%F)

update, upgrade, full-upgrade et dist-upgrade

Ces quatre mots sont sans cesse confondus. La différence n'a rien de cosmétique : elle décide si un nouveau noyau est installé et si des paquets ont le droit de disparaître.

Deux conséquences en découlent. Premièrement : dist-upgrade n'a rien à voir avec le passage à une nouvelle version de la distribution. Le nom est historique, la commande reste à l'intérieur de votre version actuelle.

Deuxièmement, la différence entre apt upgrade et apt-get upgrade est précisément la raison pour laquelle certains serveurs se retrouvent sans nouveau noyau. Debian intègre le noyau par le métapaquet linux-image-amd64, Ubuntu par linux-image-generic ou linux-image-virtual. À chaque changement d'ABI, ce métapaquet pointe vers un nouveau paquet, dont le numéro de version figure dans le nom. apt-get upgrade n'installe par principe aucun nouveau paquet et laisse donc le noyau de côté, alors que apt upgrade l'installe parce qu'une dépendance l'exige. Si vous utilisez apt-get upgrade dans un script de maintenance, il vous faut y ajouter --with-new-pkgs.

Sur le choix de l'outil : appelé depuis un script, apt affiche la ligne WARNING: apt does not have a stable CLI interface. Use with caution in scripts. Ce n'est pas un message d'erreur, mais un avertissement justifié. Dans les scripts et les rôles Ansible, c'est apt-get qui a sa place ; en interactif, apt est plus confortable.

Le déroulé, avec une vérification après chaque étape

Étape 1 : récupérer les listes de paquets.

apt update

Contrôle de réussite : la sortie ne contient aucune ligne commençant par Err: ou W:. À la fin figure soit All packages are up to date., soit un nombre suivi de packages can be upgraded. Chaque ligne d'erreur à ce stade signifie que vous continueriez à travailler sur une image incomplète.

Étape 2 : regarder ce qui arriverait. Cette étape manque dans la plupart des tutoriels et c'est la plus importante de tout le déroulé.

apt list --upgradable
apt full-upgrade -s

L'option -s simule et ne modifie rien. Les lignes situées sous The following packages will be REMOVED: sont les seules que vous devez vraiment examiner. S'il n'y a rien, full-upgrade ne présente pas plus de risque que upgrade. S'il y figure un paquet dont vous avez besoin, prenez apt upgrade et traitez la cause séparément.

Sur Debian, apt install apt-listchanges vaut la peine en complément. Ce paquet affiche avant l'application les changelogs et, plus important encore, les fichiers NEWS des mainteneurs de paquets. C'est là que figure exactement ce qui demande une intervention manuelle.

Étape 3 : appliquer.

apt upgrade

Restez devant l'écran. L'opération pose des questions, et un -y ne répond qu'à la question propre à apt, pas à celles qui portent sur les fichiers de configuration. Celles-là viennent de dpkg et attendent patiemment que quelqu'un réponde.

Contrôle de réussite :

apt list --upgradable
dpkg --audit
systemctl --failed
journalctl -p 3 -b --no-pager | tail -n 20

Voici ce qui est attendu : apt list --upgradable n'affiche rien d'autre que Listing..., dpkg --audit reste muet, systemctl --failed signale 0 loaded units listed. Ce qui s'est réellement passé reste consigné durablement dans /var/log/apt/history.log, et la sortie dpkg complète dans /var/log/apt/term.log.

Paquets conservés : deux causes bien différentes

Quand apt laisse des paquets de côté, il y a deux raisons fondamentalement différentes, que l'on confond régulièrement.

Premièrement, un vrai blocage. Quelqu'un a explicitement figé le paquet :

apt-mark showhold

Si la commande affiche quelque chose, c'était une décision consciente, le plus souvent pour des bases de données ou des modules du noyau. Vous levez le blocage avec apt-mark unhold NOM_DU_PAQUET et vous le posez avec apt-mark hold NOM_DU_PAQUET. Un blocage au niveau de dpkg se voit avec dpkg --get-selections | grep -w hold.

Deuxièmement, le message The following packages have been kept back:. Ce n'est pas un blocage. Il signifie qu'apt devrait, pour cette mise à jour, installer un paquet supplémentaire ou en supprimer un, et que la commande utilisée n'en a pas le droit. La preuve en une ligne, sans rien modifier :

apt full-upgrade -s | head -n 20

Si le paquet y apparaît, l'explication est trouvée et apt full-upgrade règle la situation. Sur Debian 13, la génération plus récente d'apt met en forme cette sortie autrement, mais le fond ne change pas.

Le cas particulier d'Ubuntu. Ubuntu diffuse les mises à jour par vagues, tous les serveurs ne les reçoivent pas le même jour. Un paquet peut donc être conservé alors qu'aucun blocage n'existe et qu'aucune dépendance ne fait obstacle. Le diagnostic se fait par élimination : apt-mark showhold est vide, apt full-upgrade -s ne montre aucune suppression, et apt-cache policy NOM_DU_PAQUET annonce malgré tout un candidat plus récent. Vous attendez alors quelques jours, ou bien vous récupérez la mise à jour par anticipation :

apt -o APT::Get::Always-Include-Phased-Updates=true upgrade

Sur Debian 13 et Debian 12, la diffusion par vagues n'existe pas, cette cause est donc écartée d'emblée.

Quand apt vous interroge sur un fichier de configuration

Cette question n'apparaît que si deux conditions sont réunies en même temps : le fichier a été modifié localement depuis l'installation, et le paquet apporte une nouvelle version. Elle se présente ainsi :

Configuration file '/etc/ssh/sshd_config'
 ==> 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.
*** sshd_config (Y/I/N/O/D/Z) [default=N] ?

Le réglage par défaut est N, c'est-à-dire conserver votre version. C'est la réponse sûre, mais pas forcément la bonne dans tous les cas.

Pour /etc/ssh/sshd_config, une prudence particulière s'impose : un Y peut ramener PermitRootLogin et PasswordAuthentication aux valeurs livrées par le paquet, et c'est précisément de là que dépend votre accès. Vos propres réglages SSH ont donc leur place dans un fichier distinct sous /etc/ssh/sshd_config.d/, comme décrit dans sécuriser SSH et mettre en place l'authentification par clé. Un fichier qui n'existe pas du tout dans le paquet ne déclenche jamais de question.

Quelle que soit votre réponse, dpkg ne jette rien. Avec N, la nouvelle version atterrit à côté en .dpkg-dist ; avec Y, c'est votre ancienne qui reste en .dpkg-old. Passer ces fichiers en revue constitue le véritable travail de finition :

find /etc -name '*.dpkg-dist' -o -name '*.dpkg-old' -o -name '*.dpkg-new' -o -name '*.ucf-dist'
diff -u /etc/ssh/sshd_config /etc/ssh/sshd_config.dpkg-dist

Pour les exécutions sans surveillance, par exemple dans un script de maintenance, fixez le comportement à l'avance. Cette combinaison conserve votre version et ne pose aucune question :

DEBIAN_FRONTEND=noninteractive apt-get -y \
  -o Dpkg::Options::="--force-confdef" \
  -o Dpkg::Options::="--force-confold" \
  upgrade

--force-confnew serait l'inverse et prend toujours la version du paquet. Sur un serveur avec sa propre configuration, c'est rarement ce que vous voulez.

Les mises à jour du noyau et la question du redémarrage

À l'installation, un nouveau noyau atterrit dans /boot et dans le menu de démarrage. Le noyau en cours d'exécution, lui, reste inchangé en mémoire jusqu'au redémarrage. Un serveur peut donc être à jour et vulnérable en même temps. La démonstration la plus simple passe par une comparaison :

uname -r
ls -1 /boot/vmlinuz-*

Si /boot contient une version plus élevée que celle indiquée par uname -r, un redémarrage s'impose. Sur Ubuntu 24.04 et 22.04, il existe en plus un fichier marqueur qui tient également compte des mises à jour de bibliothèques :

test -f /var/run/reboot-required && cat /var/run/reboot-required.pkgs

Le second fichier nomme les paquets qui ont demandé le redémarrage. Sur Debian 13 et Debian 12, ce marqueur n'est pas créé de façon fiable, et needrestart y est la bonne approche.

needrestart : quels services utilisent encore l'ancienne bibliothèque

Une mise à jour d'OpenSSL ou de glibc remplace le fichier sur le disque. Chaque processus qui l'a déjà chargé continue de travailler avec l'ancienne version. needrestart trouve exactement ces processus. Sur Ubuntu 24.04 et 22.04, il est préinstallé et se manifeste après chaque mise à jour par une question en plein écran ; sur Debian, vous l'installez vous-même :

apt install -y needrestart
needrestart -b

Le mode -b fournit une sortie lisible par une machine. Deux indications y sont décisives : NEEDRESTART-KSTA avec la valeur 1 signifie que le noyau en cours d'exécution est bien celui attendu, toute autre valeur signifie qu'un noyau plus récent est prêt. Chaque ligne NEEDRESTART-SVC nomme un service qui devrait être redémarré.

Vous pilotez le comportement par la variable d'environnement NEEDRESTART_MODE : a redémarre les services automatiquement, l se contente de les lister, i pose la question. De façon permanente, la même chose se règle dans /etc/needrestart/needrestart.conf. Pour les scripts, la variable est le meilleur choix, car elle ne modifie rien dans la configuration :

NEEDRESTART_MODE=a DEBIAN_FRONTEND=noninteractive apt-get -y upgrade

Vous devriez connaître une limite : needrestart examine les processus du système hôte. Il ne renouvelle pas les services dans les conteneurs, où il vous faut de nouvelles images.

La montée de version est une catégorie à part

Passer de Debian 12 à Debian 13 ou d'Ubuntu 22.04 à 24.04 n'est pas une mise à jour au sens précédent. Cette opération remplace les sources de paquets et renouvelle pratiquement chaque paquet. Trois règles valent toujours : une version par passage, aucune version intermédiaire sautée, et au préalable une sauvegarde à partir de laquelle le serveur peut être restauré.

Sur Debian, vous commencez par modifier les sources. Debian 12 utilise pour cela /etc/apt/sources.list, Debian 13 le fichier /etc/apt/sources.list.d/debian.sources au format plus récent. Vient ensuite un déroulé volontairement en deux temps, tel que les notes de publication le prescrivent :

apt update
apt-get upgrade --without-new-pkgs
apt full-upgrade

L'étape du milieu met d'abord à jour les paquets qui se passent de réorganisation. Cela limite le nombre de paquets déplacés en même temps et rend une interruption réparable. N'oubliez pas le composant non-free-firmware : il est autonome depuis Debian 12 et manque dans les anciens fichiers de sources. Si votre apt connaît la commande apt modernize-sources (vérifiable avec apt --version), elle convertit l'ancien fichier de sources au nouveau format.

Sur Ubuntu, il existe un outil dédié, et vous devriez utiliser exclusivement celui-là :

apt install -y ubuntu-release-upgrader-core
do-release-upgrade -c
do-release-upgrade

L'option -c se contente de vérifier et ne change rien. Le fait qu'une montée de version soit proposée dépend de Prompt dans /etc/update-manager/release-upgrades : avec lts, seul le saut vers la prochaine version LTS apparaît, et uniquement après la première publication intermédiaire de celle-ci. Le chemin de 20.04 vers 24.04 passe obligatoirement par 22.04.

Un détail qui surprend beaucoup de monde : lancé par SSH, do-release-upgrade démarre un service SSH supplémentaire sur le port 1022 comme filet de sécurité et signale que vous devrez, le cas échéant, ouvrir ce port dans le pare-feu. Servez-vous-en, mais ne comptez pas dessus. La session tmux et l'accès par la console VNC sont plus fiables.

Le nettoyage après la mise à jour

Après un passage un peu conséquent, trois sortes de restes traînent : les fichiers de paquets téléchargés, les paquets orphelins et les résidus de configuration des paquets supprimés.

apt autoremove --purge
apt autoclean

autoclean ne supprime de /var/cache/apt/archives que les fichiers qui ne sont de toute façon plus proposés. apt clean vide entièrement le cache et libère donc plus de place, mais transforme chaque réinstallation en un nouveau téléchargement.

Vous reconnaissez les résidus de configuration à l'état dpkg rc, c'est-à-dire supprimé, mais configuration encore présente :

dpkg -l | awk '/^rc/ {print $2}'

Ce qui y figure, vous le supprimez définitivement avec apt purge NOM_DU_PAQUET. Avec les anciens noyaux, plus de soin s'impose, car une erreur rend le serveur incapable de démarrer :

uname -r
dpkg -l 'linux-image-*' | awk '/^ii/ {print $2}'

Ne supprimez jamais le noyau que nomme la première ligne, et gardez en plus un ancien noyau qui fonctionne, pour que le menu de démarrage dispose d'un filet de sécurité. La plupart du temps, apt autoremove --purge s'en charge de toute façon correctement.

Erreurs fréquentes et solutions

E: Could not get lock /var/lib/dpkg/lock-frontend. It is held by process 1234 (unattended-upgr) : une deuxième opération de paquets tourne déjà, le plus souvent la mise à jour de sécurité automatique. Ne l'interrompez pas, laissez-la aller à son terme. La marche à suivre complète, réparation comprise, figure dans corriger l'erreur apt « Could not get lock ».

E: dpkg was interrupted, you must manually run 'dpkg --configure -a' to correct the problem. : une exécution précédente a été interrompue, typiquement par une coupure de connexion. Lancez exactement cette commande, puis reprenez la mise à jour.

E: Unmet dependencies. Try 'apt --fix-broken install' with no packages (or specify a solution). : un paquet est installé, ses dépendances manquent. apt --fix-broken install les récupère. Si l'erreur revient, la cause est presque toujours une source tierce qui propose des paquets pour une autre version de la distribution.

E: Release file for http://deb.debian.org/debian/dists/trixie/InRelease is not valid yet (invalid for another 5h 3min 2s). : l'horloge du serveur retarde. Vérifiez avec timedatectl status que System clock synchronized: yes est bien signalé, corrigez l'heure et relancez apt update. Le dépôt n'y est pour rien.

W: GPG error: ... The following signatures couldn't be verified because the public key is not available: NO_PUBKEY ..., suivi de E: The repository '...' is not signed. : la clé de signature d'une source tierce manque ou a été remplacée. Aujourd'hui, cette clé a sa place dans /etc/apt/keyrings/ et se référence dans la déclaration de source par signed-by ou par le champ Signed-By:. apt-key est déprécié et ne devrait plus être utilisé.

E: Repository '... InRelease' changed its 'Suite' value from 'stable' to 'oldstable' : cela arrive normalement quand une nouvelle version de Debian sort et que vos sources pointent vers stable au lieu du nom de code. Confirmez une fois avec apt update --allow-releaseinfo-change, puis faites pointer les sources vers le nom de code. Sinon, un serveur qui suit stable finit un jour par changer de version de distribution sans que vous l'ayez voulu.

E: The repository 'http://... Release' does not have a Release file. : la source ne propose rien pour votre version, le plus souvent parce qu'une source tierce ne prend pas encore en charge le nom de code, ou parce que la distribution a atteint sa fin de vie. Désactivez la ligne concernée et vérifiez la source.

No space left on device en plein décompactage : /boot ou /var sont pleins. Remettez de l'ordre avec dpkg --configure -a, libérez de la place, recommencez. Avant chaque mise à jour du noyau, un coup d'œil sur df -h /boot vaut la peine.

debconf: unable to initialize frontend: Dialog : simple remarque, pas un dysfonctionnement. Elle apparaît en l'absence d'un terminal complet, par exemple dans un script. Avec DEBIAN_FRONTEND=noninteractive, elle disparaît.

Les quatre systèmes comparés

Le contrôle final

Qu'une commande soit revenue sans erreur ne signifie pas que le système est en ordre. Ces six vérifications, elles, sont parlantes :

1. apt list --upgradable n'affiche rien d'autre que Listing....
2. apt-mark showhold ne contient que ce que vous avez sciemment bloqué.
3. dpkg --audit reste muet.
4. needrestart -b signale NEEDRESTART-KSTA: 1 et aucun service en attente.
5. systemctl --failed ne liste rien.
6. find /etc -name '*.dpkg-dist' ne trouve plus rien, parce que vous avez traité chaque écart.

Si le point quatre réclame un redémarrage, planifiez-le et effectuez-le. Un serveur qui attend pendant des mois un redémarrage en suspens accumule précisément les failles contre lesquelles vous aviez mis à jour. Vérifiez ensuite une dernière fois uname -r et systemctl --failed. Le redémarrage est le moment où l'on voit si tout remonte correctement.