Il y a deux types d’administrateurs système.

Ceux qui lancent leurs mises à jour à la main, quand ils y pensent.

Et ceux qui savent très bien qu’ils ne vont pas toujours y penser.

Sur une machine Debian, une VM de service, un petit serveur web, un conteneur LXC ou même un hôte Proxmox de homelab, automatiser une partie des mises à jour peut vraiment éviter de laisser traîner des correctifs importants pendant des semaines. Mais il faut être clair dès le départ : automatiser les mises à jour, ce n’est pas appuyer sur un gros bouton magique marqué “sécurité”.

C’est plutôt installer un gardien de nuit.

Il travaille pendant qu’on dort, mais il faut quand même lui dire quelles portes il a le droit d’ouvrir.

Dans cet article, on va voir comment fonctionne unattended-upgrades, comment l’utiliser sur Debian et systèmes proches, comment l’adapter à Proxmox, ce qu’il faut faire dans une VM ou un LXC, et surtout ce qu’il vaut mieux éviter.

Ce que fait vraiment unattended-upgrades

unattended-upgrades est un outil utilisé sur Debian, Ubuntu et d’autres systèmes basés sur APT pour installer automatiquement certaines mises à jour.

Le mot important ici, c’est “certaines”.

Par défaut, l’outil ne va pas forcément mettre à jour tout ce que apt full-upgrade, apt-get dist-upgrade ou apt upgrade aurait proposé à la main. Il travaille selon des règles. Ces règles disent quels dépôts sont autorisés, quels paquets sont exclus, s’il faut envoyer un mail, s’il faut redémarrer, supprimer des dépendances inutilisées, écrire dans syslog, etc.

Il ne choisit pas au hasard.

Il regarde les métadonnées APT des paquets, notamment l’origine, le label, la suite, le composant et le nom de code Debian. C’est pour ça que la section Origins-Pattern est si importante.

En gros, cette section répond à la question suivante :

Depuis quels dépôts ai-je le droit d’installer automatiquement des mises à jour ?

Et cette question devient très sérieuse dès qu’on parle de Proxmox, de dépôts tiers, de Ceph, de Netdata, de Webmin, de Docker ou d’autres sources externes.

Compatibilité : Debian, Ubuntu, Proxmox, mais pas tous les Unix

Il faut éviter de présenter unattended-upgrades comme un outil pour “systèmes Unix”.

Ce serait trop large, et techniquement faux.

unattended-upgrades appartient à l’écosystème Debian/APT. Il concerne donc principalement les systèmes utilisant APT et des paquets .deb.

Donc la bonne formulation serait plutôt :

Mises à jour automatiques pour Debian, Ubuntu, Proxmox et systèmes basés sur APT.

C’est moins large, mais c’est juste.

Quand l’utiliser, et quand être prudent

Sur une Debian classique, une VM applicative, un serveur web, un serveur SSH, un DNS interne ou une petite machine de monitoring, unattended-upgrades est souvent une bonne idée.

Sur un hyperviseur Proxmox, il faut être plus mesuré.

Proxmox n’est pas une simple Debian avec deux paquets en plus. C’est un hyperviseur complet avec du stockage, du réseau, un noyau spécifique, des VM, des conteneurs, parfois du Ceph, parfois de la haute disponibilité. Une mise à jour automatique qui redémarre au mauvais moment peut être gênante. Une mise à jour de kernel qui passe sans qu’on s’en rende compte peut aussi laisser un redémarrage nécessaire en attente.

Ce n’est pas forcément dangereux.

Mais ce n’est pas anodin.

Je séparerais les cas comme ça :

Le but n’est pas de faire peur.

Le but est juste d’éviter le classique : “J’ai activé les mises à jour automatiques partout, et maintenant je ne comprends pas pourquoi mon cluster a redémarré cette nuit.”

Installation sur Debian, Ubuntu ou une VM classique

Sur Debian, Ubuntu Server et la plupart des systèmes APT, l’installation est simple.

apt update
apt install unattended-upgrades apt-listchanges

Le paquet apt-listchanges est optionnel, mais utile. Il permet d’être informé des changements importants contenus dans certains paquets.

Sur beaucoup d’installations Debian, notamment sur des templates de VM ou de LXC, unattended-upgrades peut déjà être présent ou activé. Le fichier de configuration principal existe généralement déjà avec une configuration par défaut :

/etc/apt/apt.conf.d/50unattended-upgrades

Ce fichier contient les règles de base, notamment les dépôts Debian et Debian Security autorisés par défaut.

Mais la présence de 50unattended-upgrades ne suffit pas à elle seule à prouver que l’installation automatique est active.

L’activation réelle dépend aussi de la configuration périodique d’APT, notamment du fichier :

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

Pour vérifier :

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

Un fichier minimal actif ressemble souvent à ceci :

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

Dans ce cas, APT met à jour la liste des paquets et lance unattended-upgrades automatiquement selon les timers systemd.

Si le fichier n’existe pas, ou si Unattended-Upgrade vaut "0", l’installation automatique ne se fera pas, même si 50unattended-upgrades est présent.

On peut activer ou réactiver la configuration de base avec :

dpkg-reconfigure -plow unattended-upgrades

Ou créer le fichier à la main.

Le fichier 20auto-upgrades

Le fichier 20auto-upgrades sert à dire à APT ce qu’il doit faire périodiquement.

Chemin :

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

Contenu minimal :

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

On peut aussi utiliser une version un peu plus complète :

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Download-Upgradeable-Packages "1";
APT::Periodic::AutocleanInterval "7";
APT::Periodic::Unattended-Upgrade "1";

Explication rapide :

Update-Package-Lists met à jour la liste des paquets disponibles.

Download-Upgradeable-Packages autorise le téléchargement des paquets pouvant être mis à jour.

AutocleanInterval nettoie périodiquement le cache APT.

Unattended-Upgrade active réellement l’installation automatique selon les règles de unattended-upgrades.

Le "1" signifie généralement “tous les jours”.

Donc ici, on demande au système de vérifier quotidiennement les mises à jour et d’installer automatiquement ce qui est autorisé.

Les timers systemd utilisés par APT

Sur Debian moderne, les actions périodiques d’APT sont déclenchées par systemd avec deux timers principaux :

apt-daily.timer
apt-daily-upgrade.timer

On peut vérifier leur état avec :

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

Les fichiers unitaires par défaut peuvent être consultés ici :

cat /usr/lib/systemd/system/apt-daily.timer
cat /usr/lib/systemd/system/apt-daily-upgrade.timer

Sur une Debian classique, on peut par exemple retrouver une configuration de ce type pour apt-daily.timer :

[Unit]
Description=Daily apt download activities

[Timer]
OnCalendar=*-*-* 6,18:00
RandomizedDelaySec=12h
Persistent=true

[Install]
WantedBy=timers.target

Et pour apt-daily-upgrade.timer :

[Unit]
Description=Daily apt upgrade and clean activities
After=apt-daily.timer

[Timer]
OnCalendar=*-*-* 6:00
RandomizedDelaySec=60m
Persistent=true

[Install]
WantedBy=timers.target

Il faut bien comprendre le rôle du délai aléatoire.

Même si OnCalendar indique 6:00, l’exécution réelle peut être décalée. Par exemple, avec :

RandomizedDelaySec=60m

le lancement peut se faire dans l’heure qui suit.

Avec :

RandomizedDelaySec=12h

le lancement peut être décalé jusqu’à douze heures.

C’est normal. Ce mécanisme évite que toutes les machines contactent les dépôts APT exactement au même moment.

Il ne faut pas modifier directement les fichiers dans :

/usr/lib/systemd/system/

Ils appartiennent aux paquets du système. Pour adapter l’horaire, on utilise une surcharge systemd avec systemctl edit, on verra ça plus loin.

Modifier 50unattended-upgrades : la méthode simple

Le fichier principal de configuration est généralement celui-ci :

/etc/apt/apt.conf.d/50unattended-upgrades

Il est normalement installé avec le paquet unattended-upgrades.

C’est le fichier que l’on modifie le plus souvent au début, parce qu’il contient déjà beaucoup d’exemples commentés et d’explications.

Et pour être clair : oui, on peut travailler directement dans ce fichier.

Ce n’est pas interdit. Ce n’est pas une mauvaise commande. Ce n’est pas une erreur bloquante.

Pour l’ouvrir :

nano /etc/apt/apt.conf.d/50unattended-upgrades

Avant modification, une sauvegarde simple reste une bonne habitude :

cp -a /etc/apt/apt.conf.d/50unattended-upgrades /etc/apt/apt.conf.d/50unattended-upgrades.bak.$(date +%F-%H%M)

C’est la méthode la plus directe.

Elle est très bien pour comprendre le fonctionnement, tester sur une machine personnelle, ou configurer rapidement un serveur isolé.

Mais sur plusieurs serveurs, ou sur une machine que l’on veut maintenir proprement dans le temps, il existe une méthode plus élégante.

Copier 50 vers 52 : la méthode plus propre

APT lit les fichiers de configuration présents dans :

/etc/apt/apt.conf.d/

Ces fichiers sont lus dans l’ordre alphabétique et numérique.

Donc un fichier nommé 52unattended-upgrades-local sera lu après 50unattended-upgrades.

C’est justement l’intérêt.

On peut garder 50unattended-upgrades comme fichier de référence fourni par le paquet, puis placer sa configuration personnalisée dans un fichier local chargé après.

La méthode consiste à copier le fichier de base :

cp -a /etc/apt/apt.conf.d/50unattended-upgrades /etc/apt/apt.conf.d/52unattended-upgrades-local

Puis à modifier la copie :

nano /etc/apt/apt.conf.d/52unattended-upgrades-local

APT utilisera automatiquement ce nouveau fichier parce qu’il se trouve dans /etc/apt/apt.conf.d/.

Il n’y a pas besoin de déclarer ce fichier ailleurs.

Il n’y a pas besoin de l’inclure manuellement.

Il n’y a pas besoin de redémarrer APT.

Le point à bien comprendre, c’est que les deux fichiers seront lus :

50unattended-upgrades
52unattended-upgrades-local

Comme 52unattended-upgrades-local est lu après, il peut compléter ou surcharger certains paramètres.

Pour vérifier ce qu’APT voit réellement, on peut utiliser :

apt-config dump | grep -i unattended

Et surtout tester l’exécution avec :

unattended-upgrade --dry-run --debug

Faut-il supprimer ou vider 50 après copie ?

Non.

En général, on ne supprime pas 50unattended-upgrades.

Ce fichier appartient au paquet unattended-upgrades, il sert de base et de documentation. Le garder permet aussi de retrouver facilement les options disponibles.

La méthode propre consiste plutôt à :

1. garder 50unattended-upgrades comme référence ;
2. mettre les choix personnalisés dans 52unattended-upgrades-local ;
3. vérifier le résultat avec apt-config dump et unattended-upgrade --dry-run --debug.

Il y a cependant un détail important.

Si on copie tout le fichier 50 vers 52, certaines sections comme Origins-Pattern peuvent se retrouver définies deux fois ou être difficiles à lire. Pour éviter les doublons ou un comportement ambigu, on peut nettoyer explicitement la liste avant de la redéfinir.

Dans les fichiers de configuration APT, la directive à utiliser est :

#clear Unattended-Upgrade::Origins-Pattern;

Le #clear peut surprendre, parce qu’il ressemble à un commentaire. Dans la syntaxe APT, c’est bien une directive spéciale.

Exemple dans 52unattended-upgrades-local :

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

Cette directive permet de repartir d’une liste propre avant de définir vos propres dépôts autorisés.

C’est particulièrement utile si vous gardez 50unattended-upgrades intact et que vous voulez que 52unattended-upgrades-local devienne votre vraie configuration active.

Méthode simple ou méthode propre ?

Les deux sont valables.

Pour un tutoriel, on peut présenter les choses comme ça :

Sur une machine personnelle, modifier 50unattended-upgrades directement peut suffire.

Sur un serveur, un hôte Proxmox, ou plusieurs machines à maintenir, je préfère utiliser un fichier local comme 52unattended-upgrades-local.

Ce n’est pas une question de “ça marche ou ça ne marche pas”.

C’est une question de maintenance propre.

Comprendre Origins-Pattern

La section Origins-Pattern est le cœur du sujet.

Elle ressemble souvent à ça dans la configuration Debian par défaut :

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

Chaque ligne est un filtre.

Un paquet sera mis à jour automatiquement seulement si ses métadonnées correspondent à une des lignes autorisées.

Les champs les plus courants sont :

La macro suivante est très pratique :

${distro_codename}

Elle reprend le nom de code de la distribution installée.

Par exemple :

• Debian 12 : bookworm
• Debian 13 : trixie

Donc une même configuration peut être plus facilement réutilisée entre plusieurs machines.

Voir les bonnes valeurs avec apt-cache policy

Avant d’ajouter une ligne dans Origins-Pattern, il faut savoir ce que le système voit réellement.

La commande à utiliser :

apt-cache policy

On peut aussi regarder un paquet précis :

apt-cache policy proxmox-ve
apt-cache policy pve-manager
apt-cache policy ceph
apt-cache policy nginx

C’est dans cette sortie qu’on retrouve les valeurs comme :

release o=Debian,a=stable,n=bookworm,l=Debian,c=main,b=amd64
release o=Proxmox,n=bookworm,l=Proxmox Debian Repository,c=pve-no-subscription,b=amd64

C’est à partir de ces valeurs qu’on écrit une règle fiable.

Pas à partir d’une intuition.

Et encore moins à partir d’un copier-coller trouvé sur un forum sans vérifier.

Exemple de configuration Debian raisonnable

Pour une VM Debian, un conteneur LXC Debian ou un serveur Debian classique, la configuration par défaut peut déjà suffire pour les dépôts Debian principaux et Debian Security.

On peut le vérifier avec :

cat /etc/apt/apt.conf.d/50unattended-upgrades

Si la section contient déjà les lignes Debian et Debian Security, c’est une bonne base.

Exemple de configuration personnalisée possible, à placer soit directement dans :

/etc/apt/apt.conf.d/50unattended-upgrades

soit, plus proprement, dans :

/etc/apt/apt.conf.d/52unattended-upgrades-local

Contenu conseillé pour la partie personnalisée :

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

Unattended-Upgrade::Package-Blacklist {
};

Unattended-Upgrade::AutoFixInterruptedDpkg "true";
Unattended-Upgrade::MinimalSteps "true";

Unattended-Upgrade::Mail "";
Unattended-Upgrade::MailReport "only-on-error";

Unattended-Upgrade::Remove-Unused-Kernel-Packages "true";
Unattended-Upgrade::Remove-New-Unused-Dependencies "true";
Unattended-Upgrade::Remove-Unused-Dependencies "true";

Unattended-Upgrade::Automatic-Reboot "false";
Unattended-Upgrade::Automatic-Reboot-WithUsers "false";

Unattended-Upgrade::SyslogEnable "true";
Unattended-Upgrade::SyslogFacility "daemon";

Quelques remarques.

#clear Unattended-Upgrade::Origins-Pattern; vide la liste précédente avant de redéfinir la vôtre. C’est utile si vous utilisez un fichier local chargé après 50unattended-upgrades.

Automatic-Reboot "false" est volontaire. Il vaut mieux commencer sans redémarrage automatique, observer pendant quelques jours, puis décider.

Mail "" désactive l’envoi mail. Si vous avez un vrai relais mail configuré, vous pouvez remplacer par votre adresse.

Exemple :

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

Pour recevoir des mails, il faut que la machine sache envoyer du mail. Selon votre infrastructure, ça peut passer par postfix, msmtp, nullmailer, ou un relais SMTP interne.

Adapter à Proxmox : là, on ralentit un peu

Sur Proxmox, le piège classique est simple : configurer unattended-upgrades comme sur Debian, et croire que Proxmox sera entièrement maintenu automatiquement.

Ce n’est pas forcément vrai.

Si vous n’autorisez que les dépôts Debian et Debian Security, les paquets Proxmox ne seront pas inclus. Or un correctif de sécurité ou de stabilité côté PVE ne vient pas forcément de Debian-Security. Il peut venir du dépôt Proxmox.

Donc si vous voulez que les paquets Proxmox soient inclus, il faut ajouter explicitement les dépôts Proxmox dans Origins-Pattern.

Mais avant ça, vérifiez vos dépôts.

apt update
apt-cache policy

Et vérifiez aussi la version :

pveversion

Sur Proxmox VE 8, on est généralement sur Debian 12 bookworm.

Sur Proxmox VE 9, on est sur Debian 13 trixie.

Ne mélangez pas les deux.

Un mélange bookworm et trixie dans les sources APT, c’est le genre de détail qui transforme une maintenance tranquille en soirée désagréable.

Exemple Proxmox avec dépôt no-subscription

Voici un exemple pour un hôte Proxmox utilisant le dépôt pve-no-subscription.

Le dépôt pve-no-subscription est pratique en homelab ou en environnement de test. En production, il faut savoir qu’il n’offre pas le même niveau de validation que le dépôt Enterprise.

Fichier de base possible :

/etc/apt/apt.conf.d/50unattended-upgrades

Fichier local conseillé :

/etc/apt/apt.conf.d/52unattended-upgrades-local

Contenu possible :

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

        "o=Proxmox,n=${distro_codename},l=Proxmox Debian Repository,c=pve-no-subscription";
};

Unattended-Upgrade::Package-Blacklist {
};

Unattended-Upgrade::AutoFixInterruptedDpkg "true";
Unattended-Upgrade::MinimalSteps "true";

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

Unattended-Upgrade::Remove-Unused-Kernel-Packages "false";
Unattended-Upgrade::Remove-New-Unused-Dependencies "false";
Unattended-Upgrade::Remove-Unused-Dependencies "false";

Unattended-Upgrade::Automatic-Reboot "false";
Unattended-Upgrade::Automatic-Reboot-WithUsers "false";

Unattended-Upgrade::SyslogEnable "true";
Unattended-Upgrade::SyslogFacility "daemon";

La ligne importante pour Proxmox est :

"o=Proxmox,n=${distro_codename},l=Proxmox Debian Repository,c=pve-no-subscription";

Mais elle doit être vérifiée sur votre machine avec :

apt-cache policy

Selon la version de Proxmox, le dépôt utilisé, le format des sources APT ou la configuration locale, les valeurs peuvent différer.

Et si Proxmox utilise Ceph ?

Si Proxmox utilise Ceph, il peut aussi y avoir un dépôt Proxmox dédié à Ceph.

Par exemple, pour Ceph Squid, on peut rencontrer une ligne du genre :

"o=Proxmox,n=${distro_codename},l=Proxmox Ceph 19 Squid Debian Repository,c=no-subscription";

Mais il ne faut pas ajouter cette ligne juste “au cas où”.

Elle doit correspondre à un dépôt réellement présent sur la machine.

À vérifier avec :

apt-cache policy

Ou avec un paquet Ceph précis :

apt-cache policy ceph
apt-cache policy ceph-common

Si vous n’utilisez pas Ceph, ne mettez pas de règle Ceph.

C’est plus propre.

Et ça évite d’autoriser des dépôts qui ne concernent pas le serveur.

Pourquoi désactiver l’autoremove global sur Proxmox ?

Dans une configuration Debian classique, on peut avoir :

Unattended-Upgrade::Remove-Unused-Dependencies "true";

Sur Proxmox, je préfère commencer avec :

Unattended-Upgrade::Remove-Unused-Dependencies "false";

Pourquoi ?

Parce qu’un hyperviseur a souvent des dépendances plus sensibles : métapaquets, paquets de stockage, kernel, composants PVE, Ceph, ZFS, outils réseau.

Un autoremove automatique n’est pas forcément mauvais, mais je préfère le faire manuellement sur un hôte Proxmox, après vérification.

Par exemple :

apt autoremove --dry-run

Puis seulement si la sortie est propre :

apt autoremove

Oui, c’est un peu plus manuel.

Mais sur l’hyperviseur qui porte toutes les VM, ce n’est pas forcément une mauvaise chose.

Et les dépôts tiers comme Netdata, Webmin, Docker ou autres ?

Sur un serveur réel, il est assez courant de ne pas avoir uniquement les dépôts Debian ou Proxmox.

On peut avoir un agent de supervision, une interface d’administration, un dépôt applicatif, un outil de sauvegarde, un dépôt Docker, Netdata, Webmin, ou d’autres solutions installées au fil du temps.

Et c’est justement là qu’il faut faire attention.

unattended-upgrades ne met pas automatiquement tout à jour sans distinction. Il applique les règles définies dans Origins-Pattern.

Si un dépôt tiers n’est pas autorisé dans cette section, ses paquets ne seront normalement pas installés automatiquement par unattended-upgrades.

On peut ajouter un dépôt tiers, mais il faut le faire volontairement.

La bonne méthode consiste d’abord à regarder comment APT identifie ce dépôt :

apt-cache policy

Ou, pour un paquet précis :

apt-cache policy netdata
apt-cache policy webmin

La sortie permet de repérer les champs utiles comme :

o=Netdata
l=Netdata
site=repository.netdata.cloud

ou encore :

o=Jamie Cameron
l=Webmin
a=stable
c=contrib
site=download.webmin.com

À partir de là, on peut écrire une règle adaptée.

Exemple :

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

        "o=Netdata,l=Netdata,site=repository.netdata.cloud";
        "o=Jamie Cameron,l=Webmin,a=stable,c=contrib,site=download.webmin.com";
};

Mais ce n’est pas parce que c’est possible qu’il faut tout autoriser.

Un dépôt tiers peut mettre à jour un service important, changer un comportement, redémarrer un daemon, ou introduire une dépendance qu’on n’avait pas prévue. Pour un agent de monitoring, c’est souvent acceptable. Pour une interface d’administration ou un composant sensible, il vaut mieux réfléchir un peu plus.

Le plus raisonnable est d’ajouter les dépôts progressivement.

On commence avec Debian et Debian Security.

Puis on teste :

unattended-upgrade --dry-run --debug

On lit les logs :

tail -n 200 /var/log/unattended-upgrades/unattended-upgrades.log
tail -n 200 /var/log/unattended-upgrades/unattended-upgrades-dpkg.log

Et seulement ensuite, on décide si certains dépôts tiers doivent aussi être inclus.

L’idée n’est pas de bloquer toutes les mises à jour externes.

L’idée est de ne pas donner les clés de la maintenance automatique à n’importe quel dépôt sans l’avoir vérifié.

Tester avant de laisser tourner tranquillement

Le test le plus important :

unattended-upgrade --dry-run --debug

Cette commande simule l’exécution sans appliquer les mises à jour.

Elle permet de voir quels paquets seraient pris en compte, quels dépôts correspondent, et quels paquets seraient ignorés.

Ensuite, vérifiez les logs :

tail -n 200 /var/log/unattended-upgrades/unattended-upgrades.log
tail -n 200 /var/log/unattended-upgrades/unattended-upgrades-dpkg.log

On peut aussi regarder l’historique APT :

grep -R "Start-Date" /var/log/apt/history.log*

Et les timers systemd :

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

Si rien ne se lance jamais, commencez par vérifier :

cat /etc/apt/apt.conf.d/20auto-upgrades
systemctl is-enabled apt-daily.timer
systemctl is-enabled apt-daily-upgrade.timer

Pour vérifier la configuration fusionnée par APT :

apt-config dump | grep -i unattended

C’est particulièrement utile si vous avez à la fois 50unattended-upgrades et 52unattended-upgrades-local.

Changer l’heure d’exécution

Les mises à jour automatiques sont déclenchées par des timers systemd.

Sur un serveur, on peut vouloir éviter les heures de production.

Il ne faut pas modifier directement :

/usr/lib/systemd/system/apt-daily.timer
/usr/lib/systemd/system/apt-daily-upgrade.timer

Ces fichiers appartiennent aux paquets du système.

Pour modifier proprement l’horaire du timer d’installation :

systemctl edit apt-daily-upgrade.timer

Mettre :

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

Puis recharger systemd :

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

Le OnCalendar= vide l’ancienne valeur.

Ensuite, OnCalendar=*-*-* 03:30 définit la nouvelle heure.

RandomizedDelaySec=30m ajoute une petite marge aléatoire. C’est utile si vous avez beaucoup de serveurs, pour éviter qu’ils tapent tous les dépôts exactement à la même minute.

Faut-il activer le reboot automatique ?

Sur une VM Debian simple, ça peut se défendre.

Sur un hôte Proxmox, je déconseille au début.

Un redémarrage automatique peut être pratique, mais il faut une fenêtre de maintenance, une supervision, et surtout savoir ce qui tourne sur la machine.

Pour activer le reboot automatique à 4h du matin :

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

Sur Proxmox, je préfère cette approche :

Unattended-Upgrade::Automatic-Reboot "false";

Puis surveiller la présence de ce fichier :

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

Et éventuellement :

cat /var/run/reboot-required.pkgs

Comme ça, on sait qu’un redémarrage est nécessaire, mais on garde la main sur le moment.

C’est moins automatique, oui.

Mais c’est aussi moins brutal.

Cas particulier des conteneurs LXC

Dans un conteneur LXC Debian, unattended-upgrades peut fonctionner si le conteneur utilise systemd et APT normalement.

D’ailleurs, sur certains templates Debian LXC, le paquet et les fichiers suivants peuvent déjà être présents :

/etc/apt/apt.conf.d/20auto-upgrades
/etc/apt/apt.conf.d/50unattended-upgrades

C’est donc à vérifier avant d’installer ou de reconfigurer.

Mais il faut garder en tête une chose : un conteneur ne gère pas son propre kernel.

Le kernel appartient à l’hôte Proxmox.

Donc mettre à jour un LXC Debian mettra à jour ses paquets internes, ses bibliothèques, ses services, son nginx, son openssh-server, son PHP, etc.

Mais ça ne mettra pas à jour le kernel réellement exécuté.

Pour ça, il faut mettre à jour l’hôte Proxmox.

Dans un LXC, je conseille :

Unattended-Upgrade::Automatic-Reboot "false";

Puis, si certains services doivent être redémarrés après mise à jour, les gérer proprement avec supervision ou maintenance.

Un conteneur qui redémarre tout seul à 3h du matin, ce n’est pas dramatique dans tous les cas.

Mais quand c’est le conteneur DNS, reverse proxy ou base de données, on préfère le savoir.

Cas particulier des VM

Une VM, c’est plus simple.

Elle se comporte comme une machine classique.

Si elle a son propre kernel, ses propres services et son propre init system, unattended-upgrades peut être utilisé normalement.

La vraie question devient alors :

• est-ce que la VM peut redémarrer automatiquement ?
• est-ce qu’elle héberge un service critique ?
• est-ce qu’elle est sauvegardée ?
• est-ce qu’on reçoit une alerte si quelque chose échoue ?

Pour une petite VM applicative, j’activerais facilement les mises à jour automatiques avec notification.

Pour une VM base de données, je serais plus prudent sur le redémarrage.

Et sur les autres systèmes ?

Sur Ubuntu, le principe est très proche de Debian. On retrouve aussi unattended-upgrades, les fichiers dans /etc/apt/apt.conf.d/, les logs dans /var/log/unattended-upgrades/, et les timers systemd.

Sur les distributions de la famille Red Hat, Fedora, Rocky Linux, AlmaLinux ou RHEL, l’équivalent courant est plutôt dnf-automatic.

Exemple rapide :

dnf install dnf-automatic
systemctl enable --now dnf-automatic.timer

La configuration se fait généralement ici :

/etc/dnf/automatic.conf

Sur openSUSE et SUSE, on trouve plutôt des mécanismes autour de zypper, et sur certains systèmes, transactional-update, notamment quand les mises à jour sont appliquées via snapshots et activées après reboot.

Le concept reste le même.

Automatiser, oui.

Mais avec des règles, des logs, des notifications et une stratégie de retour arrière.

Questions fréquentes

Est-ce que unattended-upgrades s’active automatiquement après installation ?

Ça dépend de l’image système et de la configuration APT déjà présente.

Sur certaines Debian, VM ou templates LXC, unattended-upgrades est déjà installé ou déjà activé. On peut alors trouver directement :

/etc/apt/apt.conf.d/20auto-upgrades
/etc/apt/apt.conf.d/50unattended-upgrades

Si 20auto-upgrades contient :

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

alors les mises à jour automatiques sont activées côté APT.

Si ce fichier n’existe pas, ou si la valeur est "0", il faut l’activer.

Est-ce que 50unattended-upgrades est déjà configuré par défaut ?

Oui, le fichier 50unattended-upgrades est généralement installé avec une configuration par défaut.

Sur Debian, il autorise souvent les dépôts Debian et Debian Security, avec beaucoup d’options supplémentaires commentées.

Mais attention : ce fichier définit ce qui peut être mis à jour automatiquement.

Le fichier 20auto-upgrades, lui, définit si APT lance vraiment cette automatisation périodiquement.

Les deux sont donc complémentaires.

Est-ce que unattended-upgrades remplace apt dist-upgrade sur Proxmox ?

Non, je ne le présenterais pas comme ça.

Sur Proxmox, la méthode habituelle en CLI reste de passer par une mise à jour complète avec :

apt-get update
apt-get dist-upgrade

ou via l’interface web.

unattended-upgrades peut automatiser une partie des mises à jour, y compris Proxmox si les dépôts sont bien autorisés, mais il ne remplace pas une vraie maintenance planifiée, surtout pour les changements importants.

Est-ce que ça met à jour Debian 12 vers Debian 13 automatiquement ?

Non, pas tout seul.

Si vos dépôts restent en bookworm, vous restez sur bookworm.

Si vous changez manuellement vos dépôts vers trixie, là c’est une autre histoire. Mais une montée majeure Debian ou Proxmox doit être faite volontairement, en suivant une procédure dédiée.

Ce n’est pas le rôle d’unattended-upgrades de décider ça pour vous.

Et heureusement.

Puis-je mettre origin=* pour tout mettre à jour ?

Techniquement, oui.

Pratiquement, je ne le conseille pas sur un serveur sérieux.

Une règle comme celle-ci :

#clear Unattended-Upgrade::Origins-Pattern;
Unattended-Upgrade::Origins-Pattern {
        "origin=*";
};

autorise beaucoup trop largement les dépôts configurés.

Si vous avez uniquement des dépôts officiels, bien maîtrisés, avec du pinning APT propre, ça peut se défendre dans certains environnements.

Mais sur une machine avec Proxmox, Netdata, Webmin, Docker, un dépôt applicatif ou autre, c’est risqué.

Mieux vaut déclarer précisément les sources acceptées.

Pourquoi mes paquets Proxmox ne se mettent pas à jour ?

Probablement parce que vous n’avez autorisé que Debian dans Origins-Pattern.

Il faut vérifier avec :

apt-cache policy

Puis ajouter une ligne correspondant au dépôt Proxmox.

Exemple pour pve-no-subscription :

"o=Proxmox,n=${distro_codename},l=Proxmox Debian Repository,c=pve-no-subscription";

À adapter selon votre dépôt réel.

Comment savoir si un redémarrage est nécessaire ?

Sur Debian et systèmes proches :

test -f /var/run/reboot-required && echo "Redémarrage nécessaire"

Pour voir quels paquets le demandent :

cat /var/run/reboot-required.pkgs

Sur Proxmox, après mise à jour du kernel ou de composants importants, un redémarrage est souvent nécessaire pour réellement utiliser la nouvelle version.

Comment savoir si mon fichier 52 est bien pris en compte ?

APT lit automatiquement les fichiers présents dans :

/etc/apt/apt.conf.d/

Donc si votre fichier s’appelle :

/etc/apt/apt.conf.d/52unattended-upgrades-local

il sera lu après :

/etc/apt/apt.conf.d/50unattended-upgrades

Pour vérifier ce que la configuration donne réellement :

apt-config dump | grep -i unattended

Puis testez avec :

unattended-upgrade --dry-run --debug

C’est ce test qui fait foi.

Est-ce obligatoire de copier 50 vers 52 ?

Non.

Ce n’est pas obligatoire.

Modifier directement 50unattended-upgrades fonctionne.

La copie vers 52unattended-upgrades-local est surtout une méthode plus propre pour séparer le fichier fourni par le paquet et votre configuration locale.

En pratique :

• pour comprendre rapidement : modifier 50 ;
• pour une configuration durable : utiliser 52 ;
• pour un serveur critique : tester avec --dry-run --debug et surveiller les logs.

Est-ce que je dois modifier les timers dans /usr/lib/systemd/system ?

Non.

On peut les lire pour comprendre le comportement par défaut, mais il ne faut pas les modifier directement.

Pour changer l’horaire, il faut utiliser :

systemctl edit apt-daily-upgrade.timer

puis recharger systemd :

systemctl daemon-reload
systemctl restart apt-daily-upgrade.timer

Ma recommandation finale

Pour une Debian classique, j’activerais unattended-upgrades assez volontiers, au moins pour les dépôts Debian et Debian Security.

Pour une VM, pareil, avec une réflexion sur le reboot.

Pour un LXC, oui, mais sans oublier que le kernel dépend de l’hôte.

Pour Proxmox, je ferais plus progressif :

1. vérifier si 20auto-upgrades et 50unattended-upgrades sont déjà présents ;
2. vérifier que les mises à jour automatiques sont bien activées dans 20auto-upgrades ;
3. garder la base Debian et Debian Security ;
4. tester les lignes Proxmox avec unattended-upgrade --dry-run --debug ;
5. activer les notifications mail ou syslog ;
6. ne pas activer le reboot automatique au départ ;
7. faire les mises à jour lourdes et les redémarrages pendant une fenêtre prévue ;
8. garder les montées majeures Proxmox entièrement manuelles.

Pour le fichier de configuration, je vois les choses comme ça :

• 50unattended-upgrades pour la méthode simple et directe ;
• 52unattended-upgrades-local pour une configuration plus propre et maintenable.

Automatiser les mises à jour, c’est très bien.

Mais sur une infrastructure, surtout quand elle porte d’autres machines, il faut automatiser avec une laisse courte au début.

On observe.

On ajuste.

Puis seulement après, on donne un peu plus d’autonomie au système.

Méta-description SEO naturelle

Guide pratique pour configurer unattended-upgrades sur Debian, Ubuntu, Proxmox, VM et conteneurs LXC, avec exemples de fichiers, dépôts APT, timers systemd, tests, logs et précautions avant automatisation.