Unattended-upgrades sur Ubuntu : ce que la configuration par défaut installe, et ce qu'elle laisse de côté

« Les mises à jour de sécurité automatiques sont activées » : beaucoup d’audits de serveurs s’arrêtent sur cette phrase. Elle est vraie sur la plupart des machines Ubuntu, et elle décrit moins de choses qu’on ne le croit. Le paquet qui fait le travail, unattended-upgrades, est livré avec un fichier de configuration dont les commentaires disent précisément ce qui est actif, ce qui ne l’est pas, et ce qui n’a jamais fait partie du périmètre.

Ce guide lit ce fichier tel que le projet amont le distribue, option par option, et montre comment vérifier chaque point sur votre propre machine.

La réponse courte

Avec la configuration d’origine, unattended-upgrades :

• installe les paquets de la poche principale de la version et de la poche -security, ainsi que ceux des poches de sécurité ESM quand elles sont disponibles sur le système ;
• n’installe rien depuis -updates, -proposed ni -backports, qui sont en commentaire ;
• ne redémarre pas, car Automatic-Reboot vaut false par défaut ;
• n’écrit à personne, car Unattended-Upgrade::Mail est une chaîne vide par défaut ;
• ne touche pas aux dépôts tiers, car seules les origines listées sont autorisées.

Chacun de ces réglages est un choix délibéré, et chacun se modifie en trois lignes environ.

Deux fichiers, deux rôles

Le comportement est réparti entre deux fichiers de /etc/apt/apt.conf.d/.

20auto-upgrades est l’interrupteur. Tel que le projet amont le fournit, il contient exactement deux lignes :

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";

Le README du projet en donne le sens sans détour : le système vérifie les mises à jour chaque jour et les installe, si c’est possible. Passez l’une des deux valeurs à "0" et l’étape correspondante s’arrête.

50unattended-upgrades est la politique : quels paquets sont éligibles, et ce qui se passe une fois qu’ils sont installés. Tout ce qui suit vient de ce second fichier.

Pour voir les valeurs que votre machine applique réellement, une fois tous les fragments fusionnés, le README renvoie à une commande :

apt-config dump | grep -E 'Periodic|Unattended'

Ce que les « origines autorisées » autorisent vraiment

Le cœur de la politique tient en une liste. Dans la variante Ubuntu du fichier, elle se lit ainsi :

Unattended-Upgrade::Allowed-Origins {
	"${distro_id}:${distro_codename}";
	"${distro_id}:${distro_codename}-security";
	"${distro_id}ESMApps:${distro_codename}-apps-security";
	"${distro_id}ESM:${distro_codename}-infra-security";
//	"${distro_id}:${distro_codename}-updates";
//	"${distro_id}:${distro_codename}-proposed";
//	"${distro_id}:${distro_codename}-backports";
};

(Les deux lignes ESM legacy-security sont omises ici pour la longueur.) Les lignes qui commencent par // sont des commentaires : -updates n’est donc pas une origine autorisée. Un correctif qui n’arrive dans votre version que par la poche -updates attend un apt upgrade manuel.

Le commentaire placé au-dessus de la liste explique pourquoi la poche principale y figure : sur Ubuntu, les mises à jour de sécurité peuvent entraîner de nouvelles dépendances venues de sources hors sécurité (l’exemple cité est chromium), et autoriser la poche principale permet de les récupérer automatiquement.

Le README ajoute une règle plus lourde de conséquences qu’elle n’en a l’air : l’outil n’installe pas les paquets dont les dépendances ne peuvent pas être récupérées depuis les origines autorisées. Une mise à jour de sécurité dont une dépendance vit dans une poche que vous n’avez pas autorisée est retenue, sans erreur à l’écran.

Les dépôts tiers sont hors de la liste

Le dépôt de Docker, un PPA, la source apt d’un éditeur : aucun ne correspond à ${distro_id}:${distro_codename}-security, donc aucun n’est mis à jour automatiquement. Les logiciels installés depuis ces sources restent à la version que vous avez installée à la main la dernière fois.

Le README documente le remède. Chaque dépôt possède une origine et une archive, visibles dans les champs o= et a= de :

apt-cache policy

Ajoutez la paire que vous y lisez à votre propre fichier de surcharge (voir plus bas) plutôt que de la deviner. Le README documente aussi Origins-Pattern, qui compare des motifs de type glob comme "site=www.example.com,component=main".

Le redémarrage que personne n’a planifié

C’est le manque dont les conséquences sont les plus lourdes. Le fichier indique :

// Automatically reboot *WITHOUT CONFIRMATION* if
//  the file /var/run/reboot-required is found after the upgrade
//Unattended-Upgrade::Automatic-Reboot "false";

La valeur par défaut est false. Quand une mise à jour exige un redémarrage pour prendre effet, le fichier témoin /var/run/reboot-required est créé et rien d’autre ne se passe. Le paquet du noyau corrigé est installé pendant que l’ancien noyau continue de tourner : le correctif est sur le disque, pas en mémoire. La phrase d’audit « les mises à jour de sécurité sont automatiques » reste vraie pendant tout ce temps.

Vérifiez n’importe quelle machine en une ligne :

test -f /var/run/reboot-required && echo "reboot pending"

Si vous voulez que la machine redémarre seule, le fichier propose deux réglages qui vont ensemble :

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

Sans le second, la valeur par défaut est "now", c’est-à-dire immédiatement après la mise à jour. Notez aussi que Automatic-Reboot-WithUsers vaut true par défaut : des utilisateurs connectés n’empêchent pas le redémarrage, sauf si vous le passez à false.

Sur une machine qui ne peut pas redémarrer sans surveillance (un serveur de base de données primaire, un hôte dont le volume racine chiffré demande une phrase de passe au démarrage), laissez le redémarrage désactivé et traitez l’autre moitié du problème : rendre visible le redémarrage en attente.

Le silence est le réglage par défaut

Unattended-Upgrade::Mail est vide à la livraison, et le fichier est explicite sur la conséquence : si la valeur est vide ou absente, aucun e-mail n’est envoyé. Il énonce aussi le prérequis : une configuration de messagerie fonctionnelle, avec un paquet qui fournit mailx.

MailReport accepte trois valeurs : "always", "only-on-error" et "on-change". Sur un serveur isolé, "on-change" vous laisse une trace de chaque paquet qui a bougé. Sur un parc, "only-on-error" garde la boîte de réception lisible.

Si l’e-mail n’est pas envisageable, il existe un second canal. SyslogEnable vaut false par défaut ; passez-le à true et les événements partent dans syslog, ce que le README juge utile dans les environnements où les messages syslog sont envoyés vers un stockage central.

Où regarder quand rien ne semble se passer

Le README nomme l’endroit : toutes les opérations sont journalisées dans /var/log/unattended-upgrades/, sortie de dpkg comprise. Le fichier principal est /var/log/unattended-upgrades/unattended-upgrades.log.

Pour savoir ce que ferait la prochaine exécution sans rien modifier, utilisez la commande que le projet recommande pour le débogage :

sudo unattended-upgrade --debug --dry-run

La sortie liste les origines autorisées telles que l’outil les a comprises, puis chaque paquet candidat et la raison pour laquelle il a été retenu ou écarté. C’est le moyen le plus rapide de confirmer qu’un dépôt que vous avez ajouté est bien reconnu.

Trois causes d’un paquet resté en arrière sont écrites dans la documentation même du projet :

1. L’origine n’est pas autorisée. Voir la liste ci-dessus.
2. Une dépendance vient d’une origine non autorisée. Le paquet est retenu.
3. Le paquet poserait une question sur un fichier de configuration. Le README précise que l’outil vérifie les invites de fichiers de configuration avant l’installation et retient tout paquet qui en exige une.

Quand il s’exécute

La planification ne se trouve pas dans les fichiers d’unattended-upgrades. Elle vient de deux timers systemd livrés par apt. Dans l’arbre des sources d’apt, consulté le jour de la rédaction de cet article, apt-daily.timer se déclenche à 6,18:00 avec RandomizedDelaySec=12h et se charge des téléchargements, tandis que apt-daily-upgrade.timer se déclenche à 6:00 avec RandomizedDelaySec=60m et se charge de l’installation.

Les deux portent Persistent=true. La documentation de systemd définit ce réglage : le service est déclenché immédiatement s’il aurait dû l’être au moins une fois pendant que le timer était inactif, ce qu’elle présente comme utile pour rattraper les exécutions manquées quand le système était éteint. Un portable resté en veille pendant son créneau se met donc à jour peu après son réveil.

Votre distribution peut livrer d’autres valeurs. Lisez les vôtres :

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

Pourquoi l’extinction attend parfois

Si une extinction marque un temps d’arrêt pendant qu’une mise à jour est en cours, c’est le comportement prévu. Le commentaire de MinimalSteps explique que la mise à jour est découpée en étapes aussi petites que possible afin de pouvoir être interrompue par SIGTERM, ce qui rend l’extinction possible en cours de mise à jour, avec un court délai. Le fichier note aussi qu’unattended-upgrades porte le InhibitDelayMaxSec de logind à 30 secondes à cette fin.

Couper l’alimentation à ce moment-là est la pire des réponses. Si cela arrive malgré tout, AutoFixInterruptedDpkg, à true par défaut, lance dpkg --force-confold --configure -a à l’exécution suivante pour terminer le travail interrompu.

Modifier sans toucher au fichier livré

Le README est direct sur ce point : la surcharge doit se faire dans un fragment de configuration APT séparé, parce que les mises à jour du fichier livré peuvent entrer en conflit avec vos modifications locales et bloquer la mise à jour d’unattended-upgrades lui-même. Le nouveau fichier doit être trié après 50unattended-upgrades, et le README suggère le nom 52unattended-upgrades-local.

Un point de départ raisonnable pour un serveur isolé, construit uniquement avec des options documentées :

// /etc/apt/apt.conf.d/52unattended-upgrades-local
Unattended-Upgrade::Mail "you@example.com";
Unattended-Upgrade::MailReport "on-change";
Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "02:00";
Unattended-Upgrade::Remove-Unused-Kernel-Packages "true";

Un piège concerne les listes. Le README avertit que pour remplacer une liste comme Origins-Pattern, il faut d’abord vider la liste d’origine avec une directive #clear avant d’insérer la vôtre. Sinon, vos entrées sont autorisées en plus de celles d’origine, et non à leur place.

Pour tenir un paquet à l’écart des mises à jour automatiques, Package-Blacklist accepte des expressions régulières Python. L’exemple du fichier montre l’erreur classique : sans $ final, "libc6" correspond à tous les paquets dont le nom commence par ces caractères. Le README ajoute un effet de bord à connaître : si le paquet A dépend du paquet B placé en liste noire, ni A ni B n’est mis à jour.

Le désactiver, et pourquoi c’est rarement le bon choix

La méthode prise en charge est celle que donne le README :

sudo dpkg-reconfigure -plow unattended-upgrades

Elle règle les deux valeurs périodiques à votre place. Il existe des raisons légitimes de le faire : un système de production soumis à une gestion des changements, où chaque mouvement de paquet est planifié, ou un hôte piloté par un outil de configuration qui applique lui-même les mises à jour.

Sur toute autre machine, désactiver le mécanisme échange un risque faible et borné (une mise à jour qui se comporte mal) contre un risque sans borne (une vulnérabilité connue qui reste ouverte jusqu’à ce que quelqu’un y pense). Les outils plus fins suffisent en général : mettre en liste noire le seul paquet qui vous inquiète, ou limiter les exécutions à certains jours avec Update-Days, qui accepte des valeurs comme {"Mon";"Fri"}.

Un audit en cinq minutes

Lancez ces commandes sur un serveur que vous pensez « à jour tout seul » :

1. apt-config dump | grep -E 'Periodic|Unattended' : les deux valeurs périodiques sont-elles à "1", et quelles origines sont autorisées ?
2. apt-cache policy : quels dépôts existent sur cette machine sans être couverts par la liste autorisée ?
3. test -f /var/run/reboot-required && echo pending : un redémarrage est-il en attente ?
4. tail -n 50 /var/log/unattended-upgrades/unattended-upgrades.log : quand a eu lieu la dernière exécution, et qu’a-t-elle fait ?
5. sudo unattended-upgrade --debug --dry-run : que ferait la prochaine exécution, et que retiendrait-elle ?

Si les réponses sont « oui, aucun, non, cette nuit, rien de retenu », la phrase de l’audit est enfin exacte.

Les noms d’options, les valeurs par défaut et les commentaires rapportés viennent des fichiers 50unattended-upgrades.Ubuntu et 20auto-upgrades et du README du dépôt amont d’unattended-upgrades. Les valeurs des timers viennent de l’arbre des sources d’apt, et la définition de Persistent= du manuel systemd.timer. Tous ont été lus le 7 octobre 2026. Les versions empaquetées diffèrent d’une version d’Ubuntu à l’autre : le fichier présent sur votre machine fait foi.

Les correctifs automatiques ne sont qu’une couche parmi d’autres : la vue d’ensemble est dans le guide de durcissement Linux, et les contrôles au niveau des services sont traités dans le durcissement des services systemd.