Configurer les mises à jour de sécurité automatiques avec unattended-upgrades

Sur la plupart des serveurs, un délai sépare la publication d'une mise à jour de sécurité de son installation. Il naît rarement de la négligence, plutôt du fait que quelqu'un s'est promis de l'appliquer « la semaine prochaine ». Les scanners, eux, essaient une faille rendue publique en l'espace de quelques heures. Le paquet unattended-upgrades supprime ce délai.

La version courte figure à l'étape 7 de la checklist pour un nouveau serveur root. Ici, il est question de tout ce qui vient après : mises à jour de sécurité contre toutes les mises à jour, comportement au redémarrage sur un serveur de jeu, notification par mail, paquets exclus, essai à blanc et preuve dans le journal.

Vérifié pour Debian 13 (trixie), Debian 12 (bookworm), Ubuntu 24.04 LTS et Ubuntu 22.04 LTS. Là où ces quatre systèmes diffèrent, c'est indiqué. Les commandes sont écrites pour root ; avec un compte utilisateur normal, faites précéder chacune d'un sudo.

Ce qui tourne réellement ici

Le diagnostic prend du temps ici, parce qu'on ne sait pas lequel des trois composants impliqués ne fait pas son travail :

1. Deux timers systemd : apt-daily.timer pour les listes de paquets et le téléchargement, apt-daily-upgrade.timer pour l'installation.
2. Le script /usr/lib/apt/apt.systemd.daily, qui évalue les options placées sous APT::Periodic::.
3. Le programme unattended-upgrade, qui évalue les options placées sous Unattended-Upgrade:: et fait le travail.

Attention au singulier : le paquet s'appelle unattended-upgrades, le programme unattended-upgrade.

systemctl list-timers 'apt-daily*' --all
systemctl cat apt-daily-upgrade.timer

Les colonnes LAST et PASSED indiquent si une exécution a déjà eu lieu. L'unité contient OnCalendar=*-*-* 6:00 avec RandomizedDelaySec=60m : l'exécution se produit entre six et sept heures, et pour apt-daily.timer la dispersion atteint douze heures. Qui regarde à 06:05 croit à tort que le mécanisme est cassé.

Avant la première modification : le chemin du retour

Les mises à jour automatiques interviennent quand vous n'êtes pas devant l'écran. Trois choses peuvent mal tourner : un redémarrage sort le serveur du service, une opération de paquets s'interrompt et laisse dpkg dans un état incomplet, ou un service ne redémarre plus ensuite.

L'accès qui fonctionne encore dans ces trois cas n'est pas SSH. Les serveurs root KVM et les serveurs dédiés de KernelHost n'ont ni IPMI ni iDRAC, l'accès de secours passe par la console VNC dans l'espace client. Celle-ci dépend de la couche de virtualisation, ou du raccordement lui-même, si bien qu'une panne dans le système invité ne l'atteint pas. Connectez-vous une fois par ce biais au préalable et vérifiez le mot de passe root. Une voie de secours que l'on essaie pour la première fois en pleine urgence n'en est pas une.

Sauvegardez ensuite l'état de départ :

mkdir -p /root/avant-unattended
cp -a /etc/apt/apt.conf.d/50unattended-upgrades /root/avant-unattended/
dpkg --get-selections > /root/avant-unattended/paquets.txt
apt-mark showhold > /root/avant-unattended/holds.txt

L'interrupteur d'urgence existe en deux versions. La version dure passe par les timers :

systemctl disable --now apt-daily-upgrade.timer apt-daily.timer

La voie douce consiste à mettre la valeur APT::Periodic::Unattended-Upgrade "0"; dans /etc/apt/apt.conf.d/20auto-upgrades. Les listes de paquets restent alors à jour, mais rien ne s'installe.

Vérification :

systemctl is-enabled apt-daily-upgrade.timer
apt-config dump APT::Periodic

Pour revenir en arrière : /var/log/apt/history.log donne l'ancien et le nouveau numéro de version. Mais un apt install paquet=version ne réussit que tant que l'ancienne version se trouve encore sur un miroir, et les archives ne conservent le plus souvent que l'état courant. Prévoyez donc une correction vers l'avant et une sauvegarde.

Installation et activation

apt update
apt install -y unattended-upgrades

Différence entre les distributions : sur Ubuntu 22.04 et 24.04, le paquet est installé et actif sur les images serveur, vérifiez-le d'abord. Sur Debian, il manque sur les images minimales, et l'installation demande si les mises à jour stables doivent être appliquées automatiquement. Si elle ne tourne pas en mode interactif, lors d'une construction d'image par exemple, la valeur par défaut s'applique et le fichier décisif n'est jamais créé.

Car le paquet seul n'active rien. C'est ce fichier qui le fait :

cat /etc/apt/apt.conf.d/20auto-upgrades

S'il manque, la commande répond cat: /etc/apt/apt.conf.d/20auto-upgrades: No such file or directory. Rattrapez alors la question avec dpkg-reconfigure -plow unattended-upgrades, ou écrivez le fichier vous-même :

cat > /etc/apt/apt.conf.d/20auto-upgrades <<'EOF'
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Download-Upgradeable-Packages "1";
APT::Periodic::Unattended-Upgrade "1";
APT::Periodic::AutocleanInterval "7";
EOF

Ces valeurs ne sont pas des interrupteurs oui/non, mais des intervalles en jours : "1" tous les jours, "7" au plus une fois par semaine, "0" désactivé. AutocleanInterval supprime les fichiers de paquets qui n'existent plus sur le miroir, ce qui se remarque sur les petits disques système (disque plein sous Linux).

Vérification : apt-config dump APT::Periodic affiche les lignes en vigueur. Si rien ne sort, aucun fichier n'a été lu et l'exécution nocturne ne fait rien.

Vos propres réglages au bon endroit

Le fichier livré /etc/apt/apt.conf.d/50unattended-upgrades appartient au paquet. Si vous le modifiez, la prochaine mise à jour du paquet déclenche un conflit sur le fichier de configuration, et unattended-upgrades saute alors ce paquet. L'outil des mises à jour automatiques serait ainsi lui-même exclu.

Vos propres valeurs vont dans un fichier séparé portant un numéro plus élevé. APT lit le répertoire par ordre alphabétique et, pour les valeurs simples, c'est la dernière lue qui l'emporte :

cat > /etc/apt/apt.conf.d/52unattended-upgrades-local <<'EOF'
Unattended-Upgrade::Automatic-Reboot "false";
Unattended-Upgrade::Remove-Unused-Kernel-Packages "true";
Unattended-Upgrade::Remove-New-Unused-Dependencies "true";
Unattended-Upgrade::MinimalSteps "true";
EOF

MinimalSteps est actif d'origine et découpe l'exécution en petites étapes, que l'on peut interrompre proprement au moment de l'arrêt du système. Remove-Unused-Kernel-Packages supprime les anciens noyaux, qui remplissent sinon la partition /boot. Les deux options de nettoyage sont réglées d'origine sur Ubuntu, pas sur Debian.

Le nom du fichier n'est pas un détail. APT ne lit ici que les fichiers sans extension ou en .conf, et uniquement les noms composés de lettres, chiffres, tiret, tiret bas et point. Une copie de sauvegarde 52unattended-upgrades-local.bak est ignorée en silence, ce qui est pratique ; un fichier 52-mes-reglages.txt l'est tout autant, ce qui est agaçant.

Vérification, immédiatement après chaque modification :

apt-config dump > /dev/null && echo "Syntaxe correcte"
apt-config dump | grep "^Unattended-Upgrade::"

Un point-virgule manquant paralyse chaque appel d'apt, y compris celui de la nuit.

Uniquement les mises à jour de sécurité, ou toutes

C'est une liste d'origines autorisées qui décide des paquets éligibles. Les distributions diffèrent dès le nom de la clé : Debian utilise Unattended-Upgrade::Origins-Pattern, Ubuntu Unattended-Upgrade::Allowed-Origins.

sed -n '/Allowed-Origins\|Origins-Pattern/,/};/p' /etc/apt/apt.conf.d/50unattended-upgrades

Sont actifs d'origine les motifs visant la source de sécurité et l'archive de base de votre propre version. Les pockets -updates, -proposed et -backports y figurent en commentaire. Sur Ubuntu s'ajoutent deux entrées pour le service de maintenance étendue ; sans abonnement, elles ne livrent rien. Les variables ${distro_id} et ${distro_codename} sont résolues par le programme à l'exécution, par exemple en Debian et trixie.

D'où viennent les éléments d'un motif ? apt-cache policy le montre. Pour chaque source, une ligne commençant par release donne les champs o= (origine), a= (archive), n= (nom de code), l= (label) et c= (composant). La source de sécurité Debian porte le label Debian-Security, et c'est précisément ce que vise le motif livré.

Si vous voulez recevoir automatiquement aussi les correctifs courants de la distribution, ajoutez le motif dans votre propre fichier. Dans la configuration d'apt, les listes sont complétées et non remplacées :

Unattended-Upgrade::Origins-Pattern {
        "origin=Debian,codename=${distro_codename}-updates";
};

Sur Ubuntu, l'équivalent est "${distro_id}:${distro_codename}-updates"; dans un bloc Allowed-Origins. Vous ne pouvez remplacer entièrement une liste qu'en la vidant au préalable avec #clear Unattended-Upgrade::Origins-Pattern;.

La même procédure vaut pour les dépôts tiers. Ceux-ci livrent toutefois souvent de nouvelles versions fonctionnelles plutôt que de simples correctifs de sécurité ; appliqué sans surveillance en pleine nuit, cela relève d'une autre classe de risque. Pour les systèmes de production, la règle est donc de s'en tenir aux sources de sécurité.

L'essai à blanc

apt update
unattended-upgrade --dry-run --debug

Le apt update qui précède n'est pas accessoire : l'essai à blanc ne rafraîchit pas les listes de paquets lui-même, et sans cet appel vous jugez l'état d'hier. Rien n'est installé. Quatre endroits de la sortie comptent :

• Allowed origins are: avec la liste réellement en vigueur. C'est la preuve que votre modification est bien arrivée, pas le coup d'œil dans le fichier.
• Initial blacklist: avec vos exclusions. Si rien n'y figure alors que vous en avez saisi, c'est que votre fichier n'est pas lu.
• Les lignes à partir de Checking:, une par paquet, avec la source et l'autorisation.
• À la fin, soit Packages that will be upgraded: suivi d'une liste, soit No packages found that can be upgraded unattended and no pending auto-removals.

Ce dernier message apparaît aussi lorsque apt list --upgradable énumère bel et bien des paquets. Ce n'est pas une erreur, c'est le filtre au travail : chaque paquet qui figure là et manque à l'essai à blanc provient d'une source non autorisée, se trouve sur votre liste d'exclusion, est retenu par apt-mark hold ou déclenche une question de configuration.

Exclure des paquets de l'automatisme

Certaines choses ne doivent pas être mises à jour la nuit : une base de données dont le redémarrage décroche une application, ou le noyau d'un système qui ne doit pas redémarrer sans préavis. La première des deux méthodes n'agit que sur l'automatisme :

Unattended-Upgrade::Package-Blacklist {
        "mariadb-server$";
        "nginx$";
        "linux-image-";
};

Les entrées sont des expressions régulières, ancrées au début du nom du paquet. "nginx" sans le signe dollar attrape donc aussi nginx-common et nginx-full ; le $ limite l'entrée à ce nom exact. Inversement, "linux-image-" sans $ est la bonne forme quand vous visez tous les paquets du noyau.

La seconde méthode agit sur chaque appel d'apt, donc aussi sur votre apt upgrade manuel :

apt-mark hold mariadb-server
apt-mark showhold

Cela s'annule avec apt-mark unhold. Si un paquet ne doit simplement pas être mis à jour sans surveillance, prenez la liste d'exclusion ; s'il ne doit pas être mis à jour du tout, prenez hold.

Vérification : apt-config dump | grep -i "Package-Blacklist" et apt-mark showhold. Le revers de la médaille : un paquet exclu, c'est un paquet que vous devez mettre à jour vous-même. Fixez-vous une échéance pour cela, sinon l'exclusion sera dans six mois une faille oubliée.

Le redémarrage automatique

Après la mise à jour, un nouveau noyau est sur le disque, mais il ne tourne qu'après un redémarrage ; les bibliothèques remplacées ne prennent effet qu'au redémarrage du service. Trois options pilotent cela :

Unattended-Upgrade::Automatic-Reboot "false";
Unattended-Upgrade::Automatic-Reboot-WithUsers "true";
Unattended-Upgrade::Automatic-Reboot-Time "02:00";

Automatic-Reboot est désactivé d'origine. Automatic-Reboot-WithUsers est activé d'origine, et cela surprend beaucoup de monde : une session SSH ouverte n'empêche pas le redémarrage, et qui le souhaite met la valeur à "false". Automatic-Reboot-Time devient obligatoire dès que le redémarrage est activé. Sans cette indication, c'est now qui s'applique, et le serveur redémarre donc juste après l'exécution, soit entre six et sept heures du matin.

Il n'est pas déclenché par le paquet du noyau, mais par un fichier témoin :

ls -l /var/run/reboot-required
cat /var/run/reboot-required.pkgs

La différence la plus lourde de conséquences de cet article : Ubuntu crée ce fichier (il provient du paquet update-notifier-common), et le second nomme les paquets responsables. Debian ne le crée pas par défaut. Là-bas, Automatic-Reboot "true" peut rester durablement sans effet, sans que rien ne signale la moindre erreur. Qui s'y fie tourne des mois durant avec un vieux noyau et un sentiment de sécurité. Sur Debian, voici ce qui aide à la place :

apt install -y needrestart
needrestart -b

La sortie donne sous NEEDRESTART-KCUR le noyau en cours d'exécution et sous NEEDRESTART-KEXP celui attendu ; s'ils diffèrent, un redémarrage s'impose. Les lignes NEEDRESTART-SVC listent les services qui tournent encore avec des bibliothèques remplacées.

Pourquoi le réglage est différent sur un serveur de jeu

Sur un serveur web, un redémarrage à 02:00 est l'affaire de quelques secondes, que personne ne remarque. Sur un serveur de jeu, des joueurs sont connectés, le monde se trouve en RAM, et la sauvegarde n'est écrite intégralement qu'à l'arrêt ordonné. Si le processus est tué brutalement, vous perdez les progrès depuis la dernière sauvegarde intermédiaire, et dans le pire des cas le fichier du monde est endommagé.

S'y ajoute un détail de systemd : à l'arrêt, chaque service reçoit son signal d'arrêt, puis un délai limité, à l'issue duquel il est terminé de force. Un serveur de jeu qui sauvegarde d'abord au moment de s'arrêter a souvent besoin de plus de temps que ne le prévoit la valeur par défaut, ainsi que d'une commande d'arrêt qui envoie un stop à la console du serveur au lieu d'un simple signal à un lanceur. Pour un serveur de jeu, la combinaison raisonnable est donc celle-ci :

• Automatic-Reboot "false". Les mises à jour de sécurité continuent, le redémarrage reste votre décision.
• Une fenêtre de maintenance avec peu de joueurs, annoncée plutôt que subie.
• Une unité systemd avec une commande d'arrêt qui sauvegarde et un TimeoutStopSec suffisant, voir créer un service systemd.
• Si vous l'automatisez malgré tout, réglez Automatic-Reboot-Time sur une heure où les joueurs sont peu nombreux.

Cela se vérifie sans redémarrage : arrêtez le service avec systemctl stop, regardez la sauvegarde du jeu, relancez-le. Si tout se passe proprement, il survivra aussi à un redémarrage à 02:00.

Décaler l'heure de l'exécution

systemctl edit apt-daily-upgrade.timer

[Timer]
OnCalendar=
OnCalendar=*-*-* 03:30
RandomizedDelaySec=30m

La ligne vide OnCalendar= est obligatoire, elle efface la valeur livrée. Sans elle, votre horaire vient s'ajouter au premier et l'exécution a lieu deux fois par jour.

systemctl daemon-reload
systemctl restart apt-daily-upgrade.timer
systemctl list-timers 'apt-daily*' --all

Vérification : la colonne NEXT affiche la nouvelle heure.

La notification par e-mail

Un mécanisme dont on n'entend jamais parler n'est pas surveillé, il est oublié. Deux lignes changent cela :

Unattended-Upgrade::Mail "admin@votre-domaine.fr";
Unattended-Upgrade::MailReport "on-change";

MailReport connaît trois valeurs : always après chaque exécution, on-change uniquement quand quelque chose a été installé ou a échoué, only-on-error uniquement en cas d'erreur. Remplacez l'ancienne option MailOnlyOnError si vous la rencontrez.

Encore faut-il disposer d'une voie d'envoi. unattended-upgrades expédie via /usr/bin/mail ou /usr/sbin/sendmail. Si les deux manquent, l'envoi n'a pas lieu et vous n'en savez rien. Sur un serveur neuf, c'est le cas normal :

apt install -y bsd-mailx
echo "Message de test" | mail -s "Test depuis le serveur" admin@votre-domaine.fr

Un service de transport de courrier est installé au passage. Vérifiez ensuite avec ss -lntp | grep ':25' qu'il n'écoute que sur 127.0.0.1. Les messages envoyés directement depuis une IP de serveur atterrissent en outre souvent dans le dossier spam ; si le rapport doit arriver, faites passer l'envoi par un serveur relais dont le domaine expéditeur est correctement configuré.

Conseil pratique : réglez always pendant les deux premières semaines. Un message quotidien annonçant qu'il n'y avait rien à faire est la preuve la plus simple que le mécanisme tourne. Ensuite, revenez à on-change, sinon vous les supprimerez bientôt sans les lire.

Vérifier qu'il s'est vraiment passé quelque chose

ls -l /var/log/unattended-upgrades/
tail -n 40 /var/log/unattended-upgrades/unattended-upgrades.log

On y trouve jusqu'à trois fichiers. unattended-upgrades.log consigne ce que le programme a décidé. unattended-upgrades-dpkg.log contient la sortie brute de l'installation, c'est là que vous regardez quand un paquet a échoué à la configuration. unattended-upgrades-shutdown.log apparaît après une exécution qui s'est terminée pendant l'arrêt du système.

Une exécution sans événement se termine par No packages found that can be upgraded unattended and no pending auto-removals. Une exécution qui a fait quelque chose contient Packages that will be upgraded: et, plus bas, All upgrades installed. Si le fichier est vide ou si le dossier manque, aucune exécution n'a jamais eu lieu.

Indépendamment de cela, le gestionnaire de paquets consigne chaque action avec l'ancien et le nouveau numéro de version :

grep -E "^(Start-Date|Commandline|Upgrade|End-Date):" /var/log/apt/history.log | tail -n 20
zgrep -h "^Upgrade:" /var/log/apt/history.log*.gz | tail -n 10

Le second appel atteint les fichiers ayant subi une rotation ; qui ne regarde que le fichier courant ne trouve rien et en tire la mauvaise conclusion. La troisième source, c'est systemd :

journalctl -u apt-daily-upgrade.service --since "-7 days" --no-pager

Le piège dans lequel presque tout le monde tombe une fois : systemctl status unattended-upgrades.service affiche en permanence active (running). Ce n'est pas une mise à jour en cours. Cette unité termine proprement, au moment de l'arrêt du système, une exécution déjà commencée, et attend le reste du temps. L'installation, elle, se fait dans apt-daily-upgrade.service.

Erreurs fréquentes et solutions

cat: /etc/apt/apt.conf.d/20auto-upgrades: No such file or directory
Le paquet est installé, mais rien n'est activé ; sur Debian, c'est l'état normal après une installation non interactive. Remède : dpkg-reconfigure -plow unattended-upgrades.

No packages found that can be upgraded unattended and no pending auto-removals, alors que apt list --upgradable affiche des paquets
Ce n'est pas une erreur, c'est le filtre. Vérifiez dans l'ordre : les origines autorisées dans l'essai à blanc, la liste d'exclusion, apt-mark showhold, les questions de configuration.

E: Syntax error /etc/apt/apt.conf.d/52unattended-upgrades-local:2: Extra junk at end of file
Un point-virgule manquant en fin de ligne, ou une accolade jamais refermée. Tant que l'erreur est présente, chaque appel d'apt échoue, pas seulement l'automatisme.

E: Could not get lock /var/lib/dpkg/lock-frontend. It is held by process 1234 (unattended-upgr) avec E: Unable to acquire the dpkg frontend lock (/var/lib/dpkg/lock-frontend), is another process using it?
L'exécution automatique est occupée, et le nom de processus tronqué à quinze caractères le trahit. Attendez quelques minutes. Tuer le processus produit l'erreur suivante de cette liste. En détail : l'erreur apt « Could not get lock ».

E: dpkg was interrupted, you must manually run 'dpkg --configure -a' to correct the problem.
Exécutez exactement cette commande. Unattended-Upgrade::AutoFixInterruptedDpkg, activé d'origine, laisse l'exécution suivante réparer cela d'elle-même, mais seulement si elle va jusque-là.

Package nginx-common has conffile prompt and needs to be upgraded manually dans le journal
Vous avez modifié un fichier de configuration qui appartient au paquet, et la nouvelle version en apporte une variante différente. Le programme saute alors ce paquet durablement. Faites la mise à jour à la main. Les cas en attente se montrent ainsi :

find /etc -type f \( -name "*.dpkg-dist" -o -name "*.dpkg-new" -o -name "*.ucf-dist" \)

Cache has broken packages, exiting dans le journal
Une opération antérieure a laissé un état incomplet. apt --fix-broken install, puis dpkg --configure -a. D'ici là, l'automatisme ne fait rien chaque nuit.

Vos réglages restent sans effet, et aucun message d'erreur n'apparaît.
C'est la signature d'un nom de fichier ignoré. Vérifiez avec apt-config dump | grep -i unattended que les valeurs ont bien été lues.

Automatic-Reboot "true" ne produit rien sur Debian.
Le fichier témoin /var/run/reboot-required y est absent.

Les quatre systèmes comparés

Ce que l'automatisme ne fait pas

• Aucun passage à une nouvelle version majeure ni aucun dépôt tiers, tant qu'aucun motif n'est prévu pour cela.
• Rien en dehors du gestionnaire de paquets. Les programmes décompressés à la main, les extensions d'un système de gestion de contenu, les plugins d'un serveur de jeu et les conteneurs continuent de tourner avec leur version du moment.
• Aucun remplacement de la sauvegarde et de la surveillance. Une mise à jour peut mettre un service à l'arrêt, et si personne ne regarde, il reste arrêté jusqu'au matin.
• Aucune protection contre les attaques réseau. Des paquets à jour ferment les failles connues, mais contre les attaques volumétriques seul un filtrage en amont dans le réseau agit, chez KernelHost dans le centre de données maincubes à Francfort-sur-le-Main.

Le contrôle final

1. apt-config dump APT::Periodic affiche Update-Package-Lists "1" et Unattended-Upgrade "1".
2. apt-config dump | grep "^Unattended-Upgrade::" montre vos propres valeurs.
3. systemctl list-timers 'apt-daily*' --all montre les deux timers avec une colonne NEXT plausible.
4. unattended-upgrade --dry-run --debug se déroule sans erreur et nomme les origines attendues.
5. tail -n 40 /var/log/unattended-upgrades/unattended-upgrades.log contient une entrée datée après la première exécution.
6. ls -l /var/run/reboot-required sur Ubuntu, needrestart -b sur Debian.

Le point cinq est celui qui compte vraiment, et il demande un jour de patience : tout ce qui précède n'est que préparation, seule l'entrée de cette nuit constitue la preuve.