Cedric Abonnel
8.9 KiB
Maintenir un système Debian à jour, c'est un peu comme fermer ses fenêtres avant de partir en vacances : on sait qu'il faut le faire, on sait pourquoi, et pourtant ça finit régulièrement par passer à la trappe. Le problème, c'est qu'une CVE qui traîne plusieurs semaines sur un serveur exposé, ça ne pardonne pas toujours.
Heureusement, Debian fournit tout ce qu'il faut pour automatiser l'application des correctifs de sécurité, à travers un paquet qui s'appelle unattended-upgrades. L'idée est simple : on configure une fois, et la machine se débrouille pour appliquer les patches -security sans qu'on ait à y penser. Ce qui suit, c'est la marche à suivre, avec les pièges que j'ai croisés en route.
Le principe
unattended-upgrades n'est pas un démon qui tourne en permanence. C'est un script qui est lancé une fois par jour par un timer systemd (apt-daily-upgrade.timer), et qui regarde dans sa configuration quelles « origines » de paquets il a le droit de mettre à jour. Par défaut, il est conservateur : il ne touche qu'aux paquets venant du dépôt de sécurité officiel. C'est exactement ce qu'on veut sur un serveur de production.
Deux fichiers entrent en jeu :
/etc/apt/apt.conf.d/20auto-upgradesdécide si et à quelle fréquence unattended-upgrades est exécuté/etc/apt/apt.conf.d/50unattended-upgradesdécide quoi mettre à jour et comment
On va passer par les deux.
Installation
Rien de très exotique :
sudo apt update
sudo apt install -y unattended-upgrades apt-listchanges
apt-listchanges n'est pas strictement nécessaire, mais il est utile : il permet de recevoir un résumé des changements appliqués (notamment les entrées de NEWS.Debian qui annoncent parfois des changements de comportement qu'il vaut mieux ne pas découvrir un lundi matin).
Activer l'exécution automatique
La commande classique pour ça :
sudo dpkg-reconfigure --priority=low unattended-upgrades
L'interface te pose une question simple — « voulez-vous appliquer automatiquement les mises à jour de stabilité ? » — réponds oui. En coulisses, cette commande crée le fichier /etc/apt/apt.conf.d/20auto-upgrades avec ce contenu :
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";
Le "1" signifie « tous les jours ». Tu peux mettre "7" pour hebdomadaire, mais sur un serveur exposé je ne vois pas l'intérêt de retarder.
Pendant qu'on y est, deux options qu'on ajoute souvent à ce fichier :
APT::Periodic::Download-Upgradeable-Packages "1";
APT::Periodic::AutocleanInterval "7";
La première télécharge les paquets en amont, ce qui rend l'installation plus rapide le moment venu. La seconde nettoie le cache /var/cache/apt/archives une fois par semaine, ce qui évite que ce dossier ne grossisse indéfiniment.
Configurer le périmètre des mises à jour
C'est dans /etc/apt/apt.conf.d/50unattended-upgrades que ça se joue. Le fichier est livré commenté et documenté, ce qui aide. La section la plus importante ressemble à ça :
Unattended-Upgrade::Origins-Pattern {
"origin=Debian,codename=${distro_codename}-updates";
"origin=Debian,codename=${distro_codename},label=Debian";
"origin=Debian,codename=${distro_codename},label=Debian-Security";
"origin=Debian,codename=${distro_codename}-security,label=Debian-Security";
};
Sur une Debian récente (Bookworm et au-delà), ces lignes sont décommentées par défaut et couvrent les mises à jour de sécurité. Si tu veux être strictement sécurité-seulement, garde uniquement les deux lignes contenant Debian-Security et commente les autres. La règle est : label=Debian-Security correspond aux correctifs de l'équipe sécurité, le reste correspond aux mises à jour de point release (les 12.6 → 12.7 et compagnie).
Quelques options supplémentaires qui méritent qu'on s'y arrête :
Le redémarrage automatique
Unattended-Upgrade::Automatic-Reboot "false";
Unattended-Upgrade::Automatic-Reboot-Time "02:00";
Question politique autant que technique. Certaines mises à jour — typiquement le noyau ou la glibc — ne prennent effet qu'après reboot. Tant que la machine n'a pas redémarré, le correctif n'est pas réellement appliqué, même si le paquet est installé. Tu as deux options : laisser à "false" et reboot manuellement quand tu veux (en surveillant /var/run/reboot-required), ou passer à "true" avec une heure creuse. Sur un serveur isolé, le reboot auto se défend. Sur une base de données critique, beaucoup moins.
Les notifications
Unattended-Upgrade::Mail "admin@exemple.fr";
Unattended-Upgrade::MailReport "on-change";
Très utile. Tu reçois un mail uniquement quand quelque chose a été installé (ou a échoué), ce qui évite le bruit. Évidemment, il faut un MTA configuré — msmtp ou un postfix en relais SMTP font le boulot.
Le nettoyage
Unattended-Upgrade::Remove-Unused-Kernel-Packages "true";
Unattended-Upgrade::Remove-Unused-Dependencies "true";
Sans ça, les vieux noyaux s'accumulent dans /boot, qui finit par se remplir, ce qui finit par bloquer la prochaine mise à jour du noyau. Classique.
Tester avant de laisser tourner
Avant de partir en weekend, vérifie que la configuration est bien comprise :
sudo unattended-upgrades --dry-run --debug
Le dry-run ne touche à rien, mais il liste les paquets qui seraient installés et — surtout — il indique pourquoi un paquet est ou n'est pas retenu. Si tu vois Checking: <paquet> suivi de Allowed origins are: et que ton dépôt de sécurité apparaît bien dans la liste, c'est bon signe.
Tu peux aussi vérifier que les timers systemd sont actifs :
systemctl list-timers apt-daily.timer apt-daily-upgrade.timer
Ces deux timers sont fournis par le paquet apt lui-même, indépendamment de unattended-upgrades. Le premier rafraîchit la liste des paquets, le second déclenche l'upgrade. S'ils sont marqués inactive, c'est qu'ils sont masqués quelque part — un systemctl unmask règle généralement le problème.
Vérifier après coup
Les logs vivent ici :
sudo less /var/log/unattended-upgrades/unattended-upgrades.log
sudo less /var/log/unattended-upgrades/unattended-upgrades-dpkg.log
Le premier est un résumé lisible, le second contient la sortie brute de dpkg. Quand quelque chose se passe mal, c'est généralement dans le second qu'on trouve l'explication (un fichier de configuration modifié, un service qui refuse de redémarrer, ce genre de choses).
Pour savoir si la machine attend un reboot après une mise à jour de noyau :
ls /var/run/reboot-required 2>/dev/null && cat /var/run/reboot-required.pkgs
Si le fichier existe, c'est qu'au moins un paquet installé recommande un redémarrage. Le second fichier liste lesquels.
Quelques pièges
Les fichiers de configuration modifiés. Si tu as personnalisé un /etc/... dont le paquet propose une nouvelle version, unattended-upgrades va voir un conflit et laisser tomber l'installation par défaut (option --force-confdef). C'est généralement le bon comportement, mais ça veut dire que certaines mises à jour resteront en attente jusqu'à une intervention manuelle. Les logs te le diront.
Les paquets blacklistés. Tu peux exclure des paquets précis de la mise à jour automatique :
Unattended-Upgrade::Package-Blacklist {
"libc6";
"linux-image-.*";
};
À utiliser avec discernement — exclure libc6 ou le noyau, c'est précisément exclure les correctifs qui comptent le plus. Mais sur une machine où un reboot coûte cher, ça permet de garder le contrôle sur les paquets sensibles tout en automatisant le reste.
Les dépôts tiers. Par défaut, seuls les dépôts Debian officiels sont concernés. Si tu utilises un PPA ou un dépôt comme celui de Docker ou de PostgreSQL, il faut explicitement l'ajouter dans Origins-Pattern. Sinon, ces paquets ne sont jamais mis à jour automatiquement — ce qui peut être un piège silencieux.
Pour conclure
L'automatisation des mises à jour de sécurité sur Debian, ce n'est pas une boîte noire : c'est un script qui tourne une fois par jour, qui lit deux fichiers texte, et qui appelle apt avec des règles bien définies. Une fois qu'on a compris ça, le configurer revient à éditer ces deux fichiers selon ses contraintes — niveau de risque, fenêtre de reboot acceptable, notifications souhaitées.
Le minimum vital sur un serveur exposé tient en quatre points : unattended-upgrades installé, le périmètre limité aux dépôts -security, les notifications mail activées, et un coup d'œil régulier à /var/run/reboot-required pour ne pas oublier les redémarrages. Le reste, c'est de l'ajustement selon le contexte.