Pourquoi unattended-upgrades ne fait rien sur Debian

Pourquoi unattended-upgrades ne fait rien sur une nouvelle installation Debian

Sur Debian, unattended-upgrades peut être installé sans jamais effectuer la moindre mise à niveau, car installer le paquet et l’activer sont deux étapes distinctes. Le paquet pose une question debconf avant de se configurer, et l’installateur Debian enregistre la réponse false à cette question. Ubuntu répond à cette même question de l’autre manière. C’est pourquoi le même paquet semble fonctionner sur Ubuntu et paraît défaillant sur Debian.

Rien sur le système ne l’indique. Aucun message d’erreur n’apparaît au démarrage, aucun avertissement ne s’affiche à la connexion et aucun fichier journal n’est disponible, car le code qui écrirait ce journal n’est jamais appelé. L’activation se fait avec une seule commande. La suite de ce guide traite des quatre éléments qui peuvent encore empêcher son fonctionnement : les dépôts depuis lesquels il peut effectuer des mises à niveau, le moment où les timers systemd s’exécutent réellement, la manière de savoir qu’une exécution a échoué et la possibilité pour la machine de redémarrer automatiquement.

Afficher la configuration actuelle avant toute modification

dpkg -l unattended-upgrades | tail -n 1
sudo apt install -y debconf-utils
sudo debconf-show unattended-upgrades
cat /etc/apt/apt.conf.d/20auto-upgrades
apt-config dump APT::Periodic

debconf-show affiche la valeur enregistrée pour unattended-upgrades/enable_auto_updates. La présence de * au début de cette ligne signifie qu’un composant a défini cette valeur au lieu de conserver la valeur par défaut du paquet. Sur une machine installée avec l’installateur Debian, ce composant est l’installateur.

cat peut afficher cat: /etc/apt/apt.conf.d/20auto-upgrades: No such file or directory. Cela suffit à expliquer l’absence d’activité : sans fichier, aucune clé périodique n’est définie et aucune tâche n’est donc planifiée.

apt-config dump est la commande importante. APT lit tous les fichiers de /etc/apt/apt.conf.d/ dans l’ordre des noms de fichiers, puis les fusionne. Une valeur définie dans 99local remplace donc la même valeur définie dans 20auto-upgrades. La lecture d’un seul fichier indique ce que contient ce fichier. apt-config dump indique ce qu’APT va réellement faire.

Deux clés déterminent si quoi que ce soit s’exécute :

• APT::Periodic::Update-Package-Lists actualise les listes de paquets. C’est la tâche que apt update exécute manuellement.
• APT::Periodic::Unattended-Upgrade exécute réellement la mise à niveau.

Leurs valeurs ne sont ni true ni false. Ce sont des intervalles exprimés en jours. "1" signifie « effectuer l’opération si elle n’a pas été effectuée au cours du dernier jour », "7" signifie une fois par semaine et "0" signifie jamais. APT::Periodic::Unattended-Upgrade "0"; est une configuration valide qui n’exécute rien, indéfiniment, sans générer la moindre erreur. Si votre sortie affiche 0 pour cette clé, ou n’affiche aucune clé de ce type, vous avez trouvé la cause.

Activez-le : dpkg-reconfigure ou écrivez vous-même les clés

sudo apt update
sudo apt install -y unattended-upgrades
sudo dpkg-reconfigure --priority=low unattended-upgrades

--priority=low n’est pas facultatif ici. La question est posée avec une priorité basse. Avec la priorité par défaut, dpkg-reconfigure n’affiche rien, ne modifie rien et se termine avec le code 0. Cela ressemble exactement à une commande qui a fonctionné. Répondez oui dans la boîte de dialogue. Le script postinst du paquet écrit ensuite /etc/apt/apt.conf.d/20auto-upgrades à partir de votre réponse.

Sur une machine construite à partir d’un script, aucune boîte de dialogue ne permet de répondre. Définissez donc d’abord la réponse :

echo 'unattended-upgrades unattended-upgrades/enable_auto_updates boolean true' \
  | sudo debconf-set-selections
sudo dpkg-reconfigure -f noninteractive unattended-upgrades
apt-config dump APT::Periodic

Vous pouvez également écrire directement les deux clés :

printf 'APT::Periodic::Update-Package-Lists "1";\nAPT::Periodic::Unattended-Upgrade "1";\n' \
  | sudo tee /etc/apt/apt.conf.d/20auto-upgrades
apt-config dump APT::Periodic

La modification est immédiate, mais elle crée un piège. La réponse debconf indique toujours l’ancienne valeur. Lors du prochain dpkg-reconfigure ou d’une réinstallation du paquet, le fichier est recréé à partir de debconf et votre modification est annulée sans aucun message. Définissez les deux valeurs, ou configurez debconf et laissez le script postinst gérer le fichier.

C’est la seule différence réelle avec l’autre famille. Dans ce cas, l’installateur active le même paquet pour vous. Ainsi, la configuration Ubuntu des mises à niveau automatiques part d’un système qui applique déjà ses propres correctifs et se concentre sur les réglages. Tout ce qui suit s’applique aux deux.

Quelles mises à jour Debian installe-t-il réellement pour vous ?

Activer le timer ne revient pas à accepter l’installation de tous les paquets. Chaque source de paquets contient des métadonnées de publication : une origine, un label, une suite, un nom de code et un site. unattended-upgrades examine la version candidate de chaque paquet pouvant être mis à jour, lit les métadonnées de la source depuis laquelle ce paquet serait installé, puis ne l’installe que si cette source correspond à une entrée de Unattended-Upgrade::Origins-Pattern. En l’absence de correspondance, aucune mise à jour n’est effectuée. C’est le comportement prévu.

Affichez vos motifs, puis les métadonnées auxquelles ils sont comparés :

apt-config dump Unattended-Upgrade::Origins-Pattern
grep -H -E '^(Origin|Label|Suite|Codename|Components):' /var/lib/apt/lists/*Release
apt-cache policy

grep -H conserve le nom du fichier sur chaque ligne. Vous pouvez ainsi voir à quelle source appartient chaque bloc de métadonnées. Les valeurs de ces champs sont les parties droites de vos motifs. Dans un motif, ${distro_codename} est remplacé à l’exécution par le nom de code de la version que vous utilisez. Un même fichier continue ainsi de fonctionner après une mise à niveau vers une nouvelle version.

Lisez vos propres motifs avec ces métadonnées à côté. La réponse à la question « est-ce que je reçois uniquement les correctifs de sécurité, ou aussi les mises à jour de point release ? » se trouve ici, et nulle part ailleurs :

• Un motif qui nomme label=Debian-Security correspond à l’archive de sécurité. C’est là que sont publiés les avis de sécurité Debian.
• Un motif qui nomme la suite -updates correspond à stable-updates. Cette suite contient les mises à jour publiées par Debian entre deux point releases, par exemple les données de fuseaux horaires.
• Un motif qui nomme la suite de la version sans suffixe récupère les changements des point releases dès leur publication. Cela entraîne davantage de changements et de tests à effectuer de votre côté.
• Un dépôt que vous avez ajouté vous-même ne correspond à rien tant que vous n’avez pas écrit de motif pour celui-ci.

Ce dernier point surprend souvent. Un dépôt tiers possède sa propre origine et son propre label. unattended-upgrades voit donc la version candidate, constate que la source ne correspond à aucun motif, puis passe à la suite. Ajouter un motif pour ce dépôt mérite une décision réfléchie : un dépôt fournisseur peut publier une nouvelle version majeure dans la même suite. Vous acceptez alors les mises à niveau majeures automatiques de ce logiciel, potentiellement au milieu de la nuit.

unattended-upgrades ne vous fait jamais passer d’une version Debian à une autre. Il met à jour les paquets au sein de la version que vous utilisez. Le passage d’une version stable à la suivante reste une opération manuelle que vous devez planifier vous-même.

Lorsque vous modifiez la liste, souvenez-vous qu’APT ajoute les entrées. Un second bloc Origins-Pattern dans un autre fichier complète la liste fournie au lieu de la remplacer. Si vous voulez réellement la remplacer, commencez par la vider :

#clear Unattended-Upgrade::Origins-Pattern;
Unattended-Upgrade::Origins-Pattern {
  "origin=Debian,codename=${distro_codename},label=Debian-Security";
  "origin=Debian,codename=${distro_codename}-security,label=Debian-Security";
};

Placez les modifications locales dans un nouveau fichier classé après celui fourni par le paquet, par exemple /etc/apt/apt.conf.d/52unattended-upgrades-local. 50unattended-upgrades est un conffile. Si vous le modifiez, chaque future mise à niveau du paquet s’interrompra pour vous demander quoi faire de votre version. Un fichier séparé n’entre jamais en conflit.

Deux autres clés méritent d’être affichées pendant que vous y êtes. Unattended-Upgrade::Allowed-Origins est l’ancienne forme de la même configuration, écrite sous forme de paires origin:archive, et elle est toujours lue. Une configuration copiée depuis un tutoriel peut donc contenir les deux listes, sans indiquer clairement laquelle a correspondu. Unattended-Upgrade::Package-Blacklist contient des expressions régulières comparées aux noms des paquets. Une expression trop large à cet endroit bloque bien plus de paquets que prévu. La simulation ci-dessous affiche ce qui a effectivement été appliqué.

Pourquoi rien ne s’est-il exécuté au moment prévu ?

Deux timers systemd pilotent ce fonctionnement, et ils ont des rôles différents. apt-daily.timer lance apt-daily.service, qui actualise les listes de paquets et télécharge les paquets. apt-daily-upgrade.timer lance apt-daily-upgrade.service, qui appelle unattended-upgrade. Les deux exécutent /usr/lib/apt/apt.systemd.daily avec des arguments différents. Si le second timer est désactivé ou masqué, les deux clés périodiques peuvent lire 1 sans que rien ne soit jamais installé.

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

list-timers vous fournit NEXT, LEFT, LAST et PASSED pour chaque unité. Un timer sans NEXT ne s’exécutera pas. Si is-enabled affiche masked, quelqu’un l’a désactivé de force, et rien de ce que vous écrivez dans apt.conf.d ne changera cela.

Lisez maintenant la section [Timer] affichée par systemctl cat. OnCalendar indique le premier moment auquel le timer peut se déclencher. RandomizedDelaySec ajoute un délai aléatoire après ce moment, afin qu’un parc de machines Debian ne sollicite pas les mêmes miroirs à la même seconde. C’est pourquoi la colonne NEXT affiche une heure qui ne correspond pas à OnCalendar, et pourquoi l’exécution d’hier a eu lieu à une autre minute. Le comportement est conforme à la configuration. Persistent=true signifie qu’une machine éteinte à l’heure planifiée exécute la tâche peu après le prochain démarrage au lieu de sauter la journée.

Pour déplacer la plage horaire, surchargez l’unité au lieu de la modifier :

sudo systemctl edit apt-daily-upgrade.timer

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

La ligne OnCalendar= vide est nécessaire, car les paramètres d’unité qui acceptent plusieurs valeurs s’accumulent : si vous l’omettez, vous conservez la planification fournie avec le paquet et en ajoutez une deuxième. systemctl edit recharge systemd pour vous. Vérifiez donc le résultat avec systemctl list-timers 'apt-daily*' et consultez le nouveau NEXT.

Vous n’avez jamais besoin d’attendre un timer pour tester tout cela :

sudo systemctl start apt-daily-upgrade.service
journalctl -u apt-daily-upgrade.service --since -1h

Un point déroute les personnes qui cherchent dans /etc/cron.daily : APT fournit toujours /etc/cron.daily/apt-compat pour les systèmes sans systemd. Lisez-le avec cat. Sur un système systemd, il se termine immédiatement. La tâche n’est donc pas exécutée deux fois.

Vérifiez le fonctionnement avec : unattended-upgrade --dry-run --debug

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

Le binaire est au singulier, tandis que le nom du paquet est au pluriel. Si vous saisissez unattended-upgrades ici, vous obtenez command not found, ce que beaucoup de personnes interprètent à tort comme la preuve que le paquet est absent.

Cette commande répond à presque toutes les questions du type « pourquoi ce paquet a-t-il été ignoré ? », car elle affiche son propre raisonnement. Au début, elle affiche les origines calculées à partir de vos motifs :

Allowed origins are: ...

Elle affiche ensuite une ligne par paquet candidat, avec l’enregistrement d’origine de la version qui serait installée :

Checking: curl ([<Origin component:'main' archive:'stable' origin:'Debian' label:'Debian' site:'deb.debian.org' isTrusted:True>])

Elle affiche enfin la liste des paquets concernés ou, sur une machine où aucune action n’est nécessaire :

No packages found that can be upgraded unattended and no pending auto-removals

En combinant les deux premières informations, le diagnostic est direct. Recherchez la ligne Checking: correspondant au paquet que vous pensiez voir mettre à niveau. Comparez champ par champ son enregistrement d’origine avec les origines autorisées affichées au-dessus. Un seul champ différent, le plus souvent label ou archive, suffit à expliquer pourquoi le paquet a été ignoré.

--dry-run simule les paquets en mémoire et n’en installe aucun. Vous pouvez donc l’exécuter aussi souvent que nécessaire. La commande ajoute tout de même des entrées à /var/log/unattended-upgrades/unattended-upgrades.log.

Si les origines correspondent mais qu’un paquet reste bloqué, vérifiez les points suivants :

• apt-mark showhold répertorie les paquets que vous ou un outil avez épinglés. unattended-upgrades ne modifie pas un paquet retenu.
• La mise à niveau devrait supprimer ou ajouter un autre paquet. unattended-upgrades évite cette opération, sauf si les clés concernées l’autorisent. Comparez avec sudo apt-get -s upgrade, qui affiche la même décision sans ces règles de sécurité.
• dpkg est partiellement configuré après une exécution interrompue. Corrigez la situation avec sudo dpkg --configure -a, puis vérifiez à nouveau.
• /var n’a plus assez d’espace libre. Aucun paquet ne peut donc être téléchargé ou décompressé. Vérifiez avec df -h /var.
• /boot contient trop d’anciens noyaux, ce qui empêche la prochaine mise à niveau du noyau. Vérifiez avec df -h /boot et affichez apt-config dump Unattended-Upgrade::Remove-Unused-Kernel-Packages pour savoir si le nettoyage est activé.

Si vous exécutez apt manuellement pendant que le timer fonctionne, vous obtenez Could not get lock /var/lib/dpkg/lock-frontend. Ce message signifie que unattended-upgrades fonctionne correctement. Attendez la fin de son exécution.

Comment savoir quand une exécution échoue ?

Commencez par les journaux, car ils existent que vous configuriez autre chose ou non :

sudo tail -n 40 /var/log/unattended-upgrades/unattended-upgrades.log
sudo tail -n 40 /var/log/unattended-upgrades/unattended-upgrades-dpkg.log
journalctl -u apt-daily-upgrade.service --since -7d

Le premier fichier est le journal des décisions : ce qui a été vérifié, ce qui a été choisi et ce qui a été installé. Le second contient la sortie brute de dpkg. C’est là qu’apparaît l’échec du script postinst d’un paquet. Un journal d’arrêt distinct apparaît si des mises à niveau s’exécutent pendant l’extinction de la machine.

Le courrier est le moyen de notification habituel :

Unattended-Upgrade::Mail "you@example.com";
Unattended-Upgrade::MailReport "on-change";

MailReport accepte always, on-change et only-on-error. only-on-error semble être le choix le plus rigoureux, mais c’est généralement le mauvais choix sur un serveur auquel personne ne se connecte. En effet, une machine qui a complètement cessé de se mettre à niveau n’envoie plus non plus d’erreurs. Le silence indique alors aussi bien un serveur sain qu’un serveur défaillant. on-change vous envoie un message chaque fois qu’un élément est installé. Le message sert donc aussi de preuve que le timer fonctionne toujours.

Le courrier ne quitte la machine que si celle-ci peut envoyer des messages. unattended-upgrades transmet le message au système de messagerie local. Vous avez donc besoin d’un MTA (mail transfer agent), tel que postfix, ou d’un client relais compatible sendmail, tel que msmtp. Vérifiez-le avec command -v sendmail et command -v mail. Si aucun des deux n’est présent, le rapport n’arrive nulle part, la mise à niveau réussit quand même et l’échec reste totalement invisible. N’oubliez pas non plus qu’une nouvelle adresse IP de VPS n’a aucune réputation d’envoi. Les messages envoyés directement vers une boîte aux lettres publique sont donc souvent classés comme spam. Il est plus fiable de relayer les messages via un fournisseur de messagerie que vous utilisez déjà que d’exécuter votre propre serveur pour cela.

Si vous préférez ne pas utiliser la messagerie, surveillez l’horodatage du journal avec votre outil de monitoring :

stat -c '%y %n' /var/log/unattended-upgrades/unattended-upgrades.log

Un horodatage qui n’a pas changé depuis une semaine signifie que le timer s’est arrêté, quelle que soit la configuration. Ce contrôle doit faire partie du reste de vos contrôles courants de maintenance d’un serveur Linux.

Le serveur doit-il redémarrer automatiquement ?

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

Avec Automatic-Reboot défini sur true, unattended-upgrades redémarre sans confirmation, mais uniquement si le fichier /var/run/reboot-required existe à la fin de l’exécution. unattended-upgrades ne crée pas ce marqueur. Un autre paquet doit le créer et, sur Debian, il s’agit généralement de needrestart. Ne partez pas du principe qu’il existe. Vérifiez après votre prochaine mise à niveau du kernel :

ls -l /var/run/reboot-required /var/run/reboot-required.pkgs
uname -r
dpkg -l 'linux-image-*' | grep '^ii'

Si ce fichier n’apparaît jamais sur votre machine, Automatic-Reboot "true" ne se déclenche jamais. Vous pouvez alors passer des mois à croire que la machine redémarre pour appliquer les mises à niveau du kernel, alors qu’elle utilise toujours l’ancien kernel. Exécuter uname -r sur le paquet linux-image installé le plus récent permet de le confirmer.

Automatic-Reboot-Time planifie le redémarrage à cette heure au lieu de l’effectuer immédiatement. Définir Automatic-Reboot-WithUsers sur false empêche le redémarrage tant qu’une personne est connectée. Sur un serveur qui dispose toujours d’une session ouverte, cela signifie qu’il ne redémarre jamais.

La décision porte sur ce qui se passe au redémarrage, et non sur le redémarrage lui-même. Un service lancé manuellement par quelqu’un ne redémarre pas. Un volume chiffré qui demande une phrase secrète au démarrage ne se monte pas. Deux machines qui dépendent l’une de l’autre peuvent redémarrer dans le mauvais ordre. Activez le redémarrage automatique pour un serveur web stateless dont l’interruption pendant une minute à 02:00 est acceptable. Laissez-le désactivé lorsqu’une intervention humaine est nécessaire et configurez plutôt une alerte sur le fichier marqueur afin qu’une personne choisisse le moment. Entre les deux se trouve needrestart, qui redémarre les services utilisant encore une bibliothèque mise à niveau et couvre donc tous les cas sauf le kernel. Son mode par défaut demande une confirmation avant le redémarrage. Consultez donc /etc/needrestart/needrestart.conf avant de vous y fier lors d’une exécution unattended.

Cela fonctionne-t-il de la même manière avec testing et unstable ?

Tout ce qui précède concerne Debian stable, où les correctifs de sécurité arrivent depuis une archive distincte avec leur propre label. C’est cette structure qui permet d’exprimer un réglage « mises à jour de sécurité uniquement ». Les autres suites sont conçues différemment. Une configuration copiée depuis un serveur stable correspond donc moins aux attentes de son auteur. Les mises à niveau automatiques sur une suite évolutive entraînent aussi des changements de version majeure sans intervention. C’est un engagement différent. Si vous évaluez cette option, utiliser Debian stable, testing ou unstable sur un serveur présente ce que chacune garantit. Du côté de Red Hat, la même tâche utilise un autre outil et un autre vocabulaire. dnf-automatic sur Rocky Linux et AlmaLinux l’effectue avec son propre timer et son propre fichier de configuration.

Les mises à niveau automatiques réduisent le délai entre la publication d’un correctif et son installation. Elles ne vous indiquent pas ce qui reste exposé. Associez-les donc à une recherche des CVE connues sur votre serveur. CVE signifie common vulnerabilities and exposures. Il s’agit de l’identifiant public sous lequel un correctif est suivi.

Le contrôle en cinq minutes

1. apt-config dump APT::Periodic affiche les deux clés avec une valeur différente de zéro.
2. systemctl list-timers 'apt-daily*' affiche une heure NEXT pour les deux timers.
3. sudo unattended-upgrade --dry-run --debug affiche les origines autorisées qui incluent l’archive de sécurité correspondant à votre nom de code.
4. sudo systemctl start apt-daily-upgrade.service se termine et l’horodatage de /var/log/unattended-upgrades/unattended-upgrades.log est mis à jour.
5. Une semaine plus tard, ce même journal indique les paquets qu’il a installés.

La réussite des quatre premiers contrôles signifie que la machine est configurée. La réussite du cinquième signifie que tout fonctionne.

FAQ

Pourquoi Debian installe-t-il unattended-upgrades tout en le laissant désactivé ?

Le paquet pose une question debconf, unattended-upgrades/enable_auto_updates, puis écrit /etc/apt/apt.conf.d/20auto-upgrades à partir de la réponse. L’installateur Debian enregistre false pour cette question. Ainsi, lorsque le paquet arrive dans le cadre d’une tâche ou comme dépendance, il est configuré pour ne rien faire. Exécutez sudo debconf-show unattended-upgrades pour afficher la réponse enregistrée, puis sudo dpkg-reconfigure --priority=low unattended-upgrades pour la modifier. La priorité basse est importante, car avec la priorité par défaut, la commande se termine sans jamais afficher la question.

Comment tester unattended-upgrades sans attendre le timer ?

Exécutez sudo unattended-upgrade --dry-run --debug. La commande affiche les origines qu’elle acceptera, une ligne Checking: par paquet pouvant être mis à niveau, avec l’enregistrement d’origine de ce paquet, ainsi que la liste des paquets qu’elle installerait. Elle n’installe rien. Pour tester le chemin réel, exécutez sudo systemctl start apt-daily-upgrade.service, puis consultez journalctl -u apt-daily-upgrade.service --since -1h avec /var/log/unattended-upgrades/unattended-upgrades.log.

unattended-upgrades installe-t-il aussi les mises à jour standard, en plus des correctifs de sécurité ?

Seulement si un pattern le prévoit. Une mise à niveau de paquet est installée lorsque la source dont il provient correspond à une entrée de Unattended-Upgrade::Origins-Pattern. L’archive de sécurité, la suite stable-updates et chaque dépôt que vous avez ajouté vous-même sont des entrées distinctes. Affichez apt-config dump Unattended-Upgrade::Origins-Pattern sur votre machine, puis comparez-le à grep -H -E '^(Origin|Label|Suite|Codename):' /var/lib/apt/lists/*Release. Le paquet ne vous fait jamais passer d’une version Debian à une autre.

Pourquoi la mise à niveau ne s’exécute-t-elle pas à l’heure définie dans le timer ?

apt-daily-upgrade.timer définit RandomizedDelaySec en plus de OnCalendar. systemd choisit donc un moment aléatoire dans cette fenêtre au lieu de s’exécuter à l’heure prévue dans le calendrier. Cela répartit la charge entre toutes les machines Debian qui utilisent les mêmes miroirs. systemctl list-timers 'apt-daily*' affiche le moment effectivement choisi. Pour déplacer la fenêtre, exécutez sudo systemctl edit apt-daily-upgrade.timer et indiquez-lui une ligne OnCalendar= vide, suivie de votre propre valeur.

Dois-je activer le redémarrage automatique pour les mises à jour de sécurité ?

Seulement lorsqu’un redémarrage imprévu ne présente aucun risque. Unattended-Upgrade::Automatic-Reboot "true" redémarre sans confirmation chaque fois que /var/run/reboot-required existe après une exécution. Ce fichier est créé par un autre paquet, généralement needrestart, et non par unattended-upgrades lui-même. Vérifiez que le fichier apparaît bien sur votre machine après une mise à niveau du kernel avant de faire confiance à ce réglage. Sur une machine qui demande une passphrase au démarrage, ou qui exécute des services lancés manuellement par quelqu’un, laissez cette option à false et déclenchez une alerte sur le fichier marqueur afin qu’une personne choisisse le moment du redémarrage.