Mises à jour automatiques

Module 4: Logiciels et mises à jour · Temps de lecture : 10 minutes

Objectif pédagogique : À la fin de cette leçon, vous savez activer et vérifier les mises à jour de sécurité automatiques, vous savez ce qui se fait automatiquement et ce qui ne se fait pas, et vous savez quand un redémarrage est nécessaire.

Notions clés : unattended-upgrades, 20auto-upgrades, 50unattended-upgrades, Origins-Pattern et Allowed-Origins, timers apt-daily, needrestart, /var/run/reboot-required, Automatic-Reboot, mise à jour du noyau, dnf-automatic

Pourquoi automatiser ?

Les failles de sécurité sont découvertes, corrigées, puis activement exploitées, souvent en quelques jours. Un serveur que vous mettez à jour une fois par mois reste donc exposé en moyenne pendant des semaines à des failles connues. Le NCSC néerlandais compte l'installation rapide des mises à jour parmi les principes de base de la résilience numérique : « Mettre à jour et corriger les logiciels à temps aide à éliminer rapidement les vulnérabilités. »

Pourtant, « tout automatiser » n'est pas non plus une bonne idée. La nouvelle version d'un programme peut se comporter autrement que l'ancienne, et un serveur qui redémarre tout seul en pleine journée peut gêner vos visiteurs. Le juste milieu habituel sur Debian et Ubuntu est le suivant :

• les mises à jour de sécurité automatiquement, chaque jour ;
• les autres mises à jour et les mises à niveau de version manuellement, au moment que vous choisissez, avec un snapshot au préalable ;
• les redémarrages planifiés, à un moment calme, et contrôlés.

Le programme qui s'en charge s'appelle unattended-upgrades.

Activer unattended-upgrades

Sur Ubuntu Server, unattended-upgrades est installé par défaut et les mises à jour de sécurité automatiques sont actives dès l'installation. Sur Debian, il est aussi présent sur de nombreuses installations et images, mais pas toujours. Vérifiez et activez :

anna@web1:~$ sudo apt install unattended-upgrades
anna@web1:~$ sudo dpkg-reconfigure -plow unattended-upgrades

La deuxième commande pose la question « Automatically download and install stable updates? » (télécharger et installer automatiquement les mises à jour stables ?). Choisissez Yes. Cela écrit le fichier /etc/apt/apt.conf.d/20auto-upgrades :

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

La valeur 1 signifie : chaque jour. Avec 0, vous le désactivez. Le travail lui-même est lancé par deux timers systemd (leçon 6.3), que vous consultez ainsi :

anna@web1:~$ systemctl list-timers 'apt*'
NEXT                        LEFT     LAST                        PASSED  UNIT                    ACTIVATES
Tue 2026-11-10 06:24:11 CET 9h left  Mon 2026-11-09 06:41:03 CET 14h ago apt-daily-upgrade.timer apt-daily-upgrade.service
Tue 2026-11-10 08:02:47 CET 11h left Mon 2026-11-09 19:12:30 CET 1h ago  apt-daily.timer         apt-daily.service

apt-daily récupère les listes (comme apt update), apt-daily-upgrade installe les mises à jour. Les horaires sont répartis de manière aléatoire, afin que tous les serveurs du monde ne sollicitent pas les dépôts de paquets en même temps.

Qu'est-ce qui est installé automatiquement ?

C'est défini dans /etc/apt/apt.conf.d/50unattended-upgrades. Sur Debian, le bloc s'appelle Unattended-Upgrade::Origins-Pattern, sur Ubuntu Unattended-Upgrade::Allowed-Origins. Par défaut, le dépôt de sécurité et le dépôt stable de votre version y sont activés, et le dépôt -updates est désactivé. Sur Ubuntu, cela ressemble à ceci :

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 lignes précédées de // sont désactivées. Pour un premier serveur, laissez cela tel quel. Ne modifiez pas ce fichier directement, car une prochaine version du paquet pourrait vouloir le remplacer. Debian recommande de placer vos propres modifications dans un fichier à part, par exemple /etc/apt/apt.conf.d/52unattended-upgrades-local ; les fichiers lus plus tard l'emportent sur les précédents.

Les paquets provenant de dépôts supplémentaires (Docker, Caddy, PostgreSQL de l'éditeur) ne sont pas mis à jour automatiquement par défaut. C'est un choix délibéré : vous les suivez vous-même (leçon 9.4), ou vous ajoutez manuellement le dépôt à la liste si vous faites confiance à l'éditeur et en connaissez les conséquences.

Quelques réglages que l'on souhaite souvent :

// /etc/apt/apt.conf.d/52unattended-upgrades-local
Unattended-Upgrade::Mail "root";
Unattended-Upgrade::MailReport "only-on-error";
Unattended-Upgrade::Remove-Unused-Kernel-Packages "true";
Unattended-Upgrade::Automatic-Reboot "false";

Mail ne fonctionne que si le serveur peut envoyer des e-mails (un petit relais, leçon 8.3). Si ce n'est pas le cas, ignorez ce réglage et utilisez la surveillance de la leçon 8.3.

Vérifier que cela fonctionne

Un automatisme qui s'arrête en silence est plus dangereux que l'absence d'automatisme, car vous vous croyez protégé. Vérifiez donc trois choses.

1. Un essai à blanc. Il montre ce qui se passerait, sans rien modifier :

anna@web1:~$ sudo unattended-upgrade --dry-run --debug
...
Allowed origins are: origin=Debian,codename=trixie,label=Debian, origin=Debian,codename=trixie-security,label=Debian-Security, ...
Packages that will be upgraded: libssl3t64 openssh-server

2. Le journal. Chaque exécution écrit dans /var/log/unattended-upgrades/unattended-upgrades.log :

anna@web1:~$ sudo tail -n 5 /var/log/unattended-upgrades/unattended-upgrades.log
2026-11-09 06:41:15,201 INFO Packages that will be upgraded: openssh-server
2026-11-09 06:41:15,202 INFO Writing dpkg log to /var/log/unattended-upgrades/unattended-upgrades-dpkg.log
2026-11-09 06:41:29,874 INFO All upgrades installed

3. Ce qui reste en attente. apt list --upgradable (leçon 4.1) ne doit plus afficher de paquets provenant de -security après une nuit. S'ils y restent plusieurs jours de suite, quelque chose coince : un disque plein, un verrou laissé par un apt manuel bloqué, ou un paquet qui pose une question.

Redémarrer : les services et le noyau

Un programme mis à jour sur le disque n'est pas encore un programme mis à jour en mémoire. Si OpenSSH tourne depuis trois semaines, c'est l'ancien code qui tourne jusqu'au redémarrage du service.

• Les services : le programme needrestart vérifie après une mise à jour quels services utilisent encore d'anciennes bibliothèques. Sur Ubuntu 24.04 et versions ultérieures, unattended-upgrades redémarre par défaut ces services automatiquement via needrestart. Sur Debian, needrestart est un paquet séparé (apt install needrestart) qui vous demande de manière interactive quels services doivent redémarrer.
• Le noyau : un nouveau noyau ne prend effet qu'après un redémarrage complet du serveur. Debian et Ubuntu créent alors le fichier /var/run/reboot-required :

anna@web1:~$ cat /var/run/reboot-required
*** System restart required ***
anna@web1:~$ cat /var/run/reboot-required.pkgs
linux-image-6.12.57+deb13-amd64

Vous avez deux options. Soit vous redémarrez vous-même, par exemple chaque semaine à un moment fixe après avoir vérifié si le fichier est présent. Soit vous laissez unattended-upgrades s'en charger :

Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "04:30";

La valeur par défaut est false. Ne l'activez que si vous êtes certain que tout redémarre de lui-même après un redémarrage : les services avec enable (leçon 6.1), les conteneurs avec une politique restart: (leçon 9.3), et une surveillance qui vous alerte si ce n'est pas le cas (leçon 8.3). Testez d'abord une fois manuellement : sudo reboot, puis vérifiez que tout revient.

Ubuntu propose aussi, via Ubuntu Pro, Livepatch, qui applique certains correctifs du noyau sans redémarrage. C'est un complément, pas un remplacement : même avec Livepatch, vous redémarrez de temps en temps.

Ce que vous n'automatisez pas

• Les mises à niveau de version (de Debian 12 vers 13, d'Ubuntu 24.04 vers 26.04) : toujours manuellement, avec un plan (leçon 4.3).
• Les versions majeures de vos propres applications (une nouvelle version majeure d'une base de données, d'un CMS) : toujours manuellement, après une sauvegarde et la lecture des notes de version.
• Les conteneurs : unattended-upgrades ne les met pas à jour. Une image de 2024 reste l'image de 2024 jusqu'à ce que vous exécutiez docker compose pull (leçon 9.4).

Sur AlmaLinux et Rocky Linux

Là, l'outil s'appelle dnf-automatic. Installez-le avec dnf install dnf-automatic. Dans /etc/dnf/automatic.conf, vous définissez upgrade_type = security et apply_updates = yes, puis vous activez le timer avec systemctl enable --now dnf-automatic.timer. Sur les systèmes de type RHEL, un redémarrage après une mise à jour du noyau est tout aussi nécessaire que sur Debian ; dnf needs-restarting -r vous indique si c'est le cas.

En pratique

Chez WebOké, un VPS fonctionne de la même manière qu'ailleurs : ce qui est mis à jour à l'intérieur du serveur, c'est vous qui le gérez. L'hébergeur met à jour le matériel et la plateforme de virtualisation, pas votre système d'exploitation. Avant une grosse mise à jour manuelle, créez un snapshot dans le panneau de votre hébergeur ; pour les mises à jour de sécurité automatiques quotidiennes, ce n'est pas nécessaire.

Résumé

• Activez les mises à jour de sécurité automatiques avec unattended-upgrades (Ubuntu : actif par défaut ; Debian : à vérifier avec dpkg-reconfigure -plow unattended-upgrades).
• Par défaut, seuls le dépôt de sécurité et le dépôt stable de la version sont mis à jour automatiquement ; les dépôts supplémentaires ne le sont pas.
• Vérifiez avec un essai à blanc, le journal dans /var/log/unattended-upgrades/ et apt list --upgradable.
• Les services doivent redémarrer après une mise à jour (needrestart), le noyau exige un redémarrage du serveur (/var/run/reboot-required).
• Les mises à niveau de version, les versions majeures d'applications et les conteneurs se mettent à jour manuellement.

Quiz

Exercice

Exercice O4.2 : Activer et vérifier les mises à jour automatiques. Sur votre propre serveur, activez unattended-upgrades (ou vérifiez qu'il est actif), faites un essai à blanc et consultez le journal et les timers. Remplissez la checklist et répondez : quels dépôts sont mis à jour automatiquement chez vous, quand a eu lieu la dernière exécution, un redémarrage est-il en attente, et comment allez-vous redémarrer (vous-même à un moment fixe ou automatiquement, et pourquoi) ?

Pour aller plus loin

• Sécuriser votre VPS : les cinq premières minutes
• Wiki Debian, mises à jour automatiques (UnattendedUpgrades) : https://wiki.debian.org/PeriodicUpdates
• NCSC néerlandais (source en néerlandais), principe de base 3 : protéger les systèmes, applications et appareils : https://www.ncsc.nl/basisprincipes/basisprincipe-3-bescherm-systemen-applicaties-en-apparaten
• Documentation Ubuntu Server, Automatic updates : https://ubuntu.com/server/docs/how-to/software/automatic-updates/