Configurer dnf-automatic pour les mises à jour de sécurité

Ce que fait dnf-automatic sur Rocky Linux et AlmaLinux

dnf-automatic permet d’installer automatiquement les mises à jour de sécurité sur Rocky Linux et AlmaLinux. Il s’agit d’un petit programme lancé par un timer systemd. Il lit /etc/dnf/automatic.conf et applique ce que ce fichier autorise. L’installation tient en une commande. Le reste de ce guide porte sur les paramètres qui déterminent s’il protège le serveur ou ne fait discrètement rien.

Si vous venez de Debian ou d’Ubuntu, il remplit le même rôle que unattended-upgrades sur un VPS Ubuntu. Une différence est plus importante que les autres : la signification du mot « sécurité » pour le gestionnaire de paquets. Sur Ubuntu, il s’agit d’un dépôt distinct. Dans la famille RHEL, il s’agit de métadonnées associées aux avis publiés, et ces métadonnées peuvent être absentes ou obsolètes. Si vous configurez dnf-automatic pour utiliser un dépôt sans données d’avis, il n’installe rien tout en signalant une réussite.

Ce guide s’appuie sur Rocky Linux 9 et AlmaLinux 9, qui utilisent DNF 4 (DNF est le gestionnaire de paquets de la famille RHEL), en août 2026. Les versions 10 sont passées à DNF5 et les noms y changent. Elles disposent donc de leur propre section vers la fin du guide. Chaque commande ci-dessous est à exécuter sur votre propre serveur. La sortie attendue est indiquée à côté.

Installer dnf-automatic et lire la configuration fournie

L’activation des mises à jour automatiques fait partie de la configuration initiale, dans les dix premières minutes sur un nouveau VPS, juste après la création d’un utilisateur non-root et la configuration d’un pare-feu. Si la configuration du pare-feu n’est pas encore terminée, firewalld est le pare-feu fourni avec Rocky et AlmaLinux, et quelques commandes suffisent pour autoriser SSH, ouvrir le port sur lequel votre site écoute et conserver ces règles après un redémarrage.

sudo dnf install -y dnf-automatic
rpm -q dnf dnf-automatic
systemctl is-enabled dnf-automatic.timer

systemctl is-enabled affiche disabled sur une installation vierge, car l’installation du paquet ne démarre aucun service. C’est la raison la plus fréquente pour laquelle un serveur qui « possède dnf-automatic » n’a jamais appliqué une seule mise à jour.

La version de DNF est importante pour une option. Le paramètre reboot a été ajouté en amont dans DNF 4.15. Red Hat l’a rétroporté dans dnf-4.14.0-6.el9 en novembre 2023, via l’avis RHBA-2023:6645. Rocky 9 et AlmaLinux 9 reconstruisent ce paquet. Un serveur à jour dispose donc de ce paramètre, contrairement à un serveur qui n’a pas été mis à jour depuis 2023.

Le fichier de configuration est /etc/dnf/automatic.conf. La copie fournie liste toutes les options prises en charge par cette version, avec leur valeur par défaut, sous forme de commentaires. Lisez-le avant de le modifier. Ce fichier fait référence pour votre version.

Les deux options qui déterminent le comportement

download_updates et apply_updates dans la section [commands] déterminent le comportement. Elles sont toutes les deux définies sur no par défaut dans EL9 (Enterprise Linux 9, la base commune de Rocky 9 et AlmaLinux 9). Ainsi, un dnf-automatic que vous activez sans le modifier indique seulement les mises à jour disponibles.

• Les deux sur no : dnf-automatic signale les mises à jour disponibles et ne modifie rien sur le serveur.
• download_updates = yes avec apply_updates = no : les paquets sont téléchargés dans le cache DNF. L’installation est ensuite rapide et ne nécessite pas le réseau, mais rien n’a été modifié cette nuit.
• Les deux sur yes avec upgrade_type = default : toutes les mises à jour disponibles sont installées, qu’elles soient de sécurité ou non.
• Les deux sur yes avec upgrade_type = security : seuls les paquets mentionnés dans un avis de sécurité sont installés.

Un point de départ raisonnable pour un VPS exposé à Internet :

[commands]
upgrade_type = security
download_updates = yes
apply_updates = yes
random_sleep = 0
network_online_timeout = 60
reboot = never

network_online_timeout indique pendant combien de secondes l’exécution attend un réseau fonctionnel avant d’abandonner. Cela est important sur un serveur qui vient de démarrer. random_sleep est une ancienne méthode pour répartir la charge entre plusieurs machines ; le timer s’en charge maintenant. Exécutez systemctl cat dnf-automatic.service pour afficher les options exactes transmises par le service fourni.

Vérifiez que le fichier fait bien ce que vous attendez, sans attendre 06:00 :

sudo systemctl start dnf-automatic.service
sudo journalctl -u dnf-automatic.service -n 50 --no-pager

Le journal indique ce que l’exécution a évalué et ce qu’elle a fait. Vous pouvez également imposer un comportement depuis la ligne de commande. Cela remplace le contenu du fichier pour cette exécution uniquement :

sudo dnf-automatic --downloadupdates --no-installupdates

Ce que signifie réellement upgrade_type = security sur Rocky et Alma

DNF ne détermine pas qu’une mise à jour est une mise à jour de sécurité en comparant les numéros de version. Il lit les métadonnées d’errata : un fichier nommé updateinfo.xml publié dans le dépôt, où chaque avis répertorie les paquets qui le corrigent. AlmaLinux publie ces avis sous forme d’avis ALSA, et Rocky sous forme d’avis RLSA. upgrade_type = security construit un filtre à partir de ces métadonnées et met à niveau uniquement les paquets correspondants.

Deux conséquences en découlent, et elles surprennent souvent.

Premièrement, sans métadonnées, aucune mise à jour n’est appliquée. Si le dépôt ne contient aucun updateinfo.xml, le filtre ne trouve aucune correspondance et l’exécution se termine par cette ligne dans le journal :

No security updates needed, but 3 updates available

Le serveur n’est pas corrigé, et rien n’indique une erreur. Vérifiez-le vous-même :

dnf updateinfo list --security
dnf check-update

Si dnf check-update répertorie des paquets alors que dnf updateinfo list --security n’affiche absolument rien, soit aucune mise à jour en attente ne possède d’avis associé, soit le dépôt ne contient aucune donnée d’avis à lire. Rocky et AlmaLinux les publient tous les deux. Sur ces deux distributions, une liste vide est donc généralement normale. CentOS Stream n’en publie pas du tout.

Deuxièmement, le mode security n’applique pas une modification minimale. dnf-automatic ajoute le filtre de sécurité, puis exécute le chemin de mise à niveau normal. Un paquet mentionné dans un avis passe donc à la version la plus récente disponible dans le dépôt et installe également ses dépendances. L’opération plus limitée, qui consiste à passer uniquement à la première version corrigeant l’avis, est dnf upgrade-minimal --security exécutée manuellement. dnf-automatic ne propose aucun réglage pour cela.

Une autre réserve concerne Rocky. Rocky génère ses errata à partir des données de Red Hat au moyen de son propre pipeline, et ce pipeline a pris du retard. En septembre 2025, des utilisateurs ont signalé que le updateinfo.xml BaseOS de Rocky 9 n’avait pas évolué depuis décembre 2024. --security ne contenait donc pas les avis récents, et l’équipe Rocky a confirmé qu’il s’agissait d’un problème connu. Si vous dépendez de upgrade_type = security, comparez de temps à autre la liste des avis avec les annonces RLSA récentes. Sur un serveur où la couverture compte davantage que la maîtrise des changements, upgrade_type = default selon une planification adaptée est le réglage le plus sûr.

Le timer systemd qui l’exécute réellement

sudo systemctl enable --now dnf-automatic.timer
systemctl list-timers dnf-automatic.timer

list-timers doit afficher une ligne avec une heure NEXT située environ un jour plus tard. Un tableau vide signifie que le timer n’est pas activé et que rien ne sera jamais exécuté.

Le timer fourni s’exécute à *-*-* 6:00 avec RandomizedDelaySec=60m et Persistent=true. Le délai aléatoire répartit les serveurs sur une heure, afin qu’ils n’interrogent pas tous le mirror à la même seconde. Persistent=true signifie qu’une machine éteinte à 06:00 exécute le job manqué peu après son démarrage, au lieu de le sauter ce jour-là.

Modifiez la planification avec un drop-in. Ne modifiez pas l’unité fournie, car une mise à niveau du paquet remplace les fichiers sous /usr/lib/systemd/system.

sudo systemctl edit dnf-automatic.timer

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

La ligne OnCalendar= vide est obligatoire. OnCalendar s’accumule. Sans cette réinitialisation, vous conservez l’entrée de 06:00 et en ajoutez une deuxième. Le job s’exécute alors deux fois par jour. Confirmez le résultat avec systemctl list-timers dnf-automatic.timer et consultez la colonne NEXT. Les mêmes règles de drop-in s’appliquent à tout ce que vous planifiez, comme indiqué dans écrire des unités de service et des timers systemd.

Voici maintenant le piège. Le paquet fournit trois autres timers : dnf-automatic-notifyonly.timer, dnf-automatic-download.timer et dnf-automatic-install.timer. Chacun démarre le même programme avec des options de ligne de commande, et ces options remplacent download_updates et apply_updates dans votre fichier de configuration. Activez-en un en plus de dnf-automatic.timer : le job s’exécutera deux fois avec deux comportements différents, ce qui donnera exactement l’impression que votre fichier de configuration est ignoré. Activez un seul timer et vérifiez :

systemctl list-unit-files 'dnf-automatic*'

Quand quelque chose a-t-il été installé ?

emit_via dans la section [emitters] contrôle la génération des rapports. Avec systemd, l’émetteur stdio écrit dans le journal. C’est l’option la plus fiable, car elle ne nécessite rien d’autre :

sudo journalctl -u dnf-automatic.service --since -7d --no-pager

L’émetteur motd écrit le rapport dans /etc/motd et remplace le contenu de ce fichier. Si vous y conservez une bannière de connexion, n’utilisez pas cet émetteur.

L’émetteur email ouvre une connexion SMTP (simple mail transfer protocol) vers email_host sur email_port, qui prennent par défaut les valeurs localhost et 25. Un VPS fraîchement créé n’a généralement aucun service en écoute à cet endroit. La connexion est donc refusée et aucun e-mail n’est envoyé. Exécutez ss -lnt | grep ':25' avant de vous y fier et configurez un Postfix en mode relais uniquement si la sortie est vide. Lorsque l’envoi fonctionne, l’objet est Updates applied on 'web01'., en utilisant le nom fourni par system_name.

Pour tout autre usage, l’émetteur command transmet le rapport à votre programme sur l’entrée standard :

[emitters]
emit_via = stdio, command
system_name = web01.example.com
send_error_messages = yes

[command]
command_format = /usr/local/bin/notify-ops
stdin_format = {body}

send_error_messages vaut no par défaut. Cela signifie qu’une exécution en échec ne signale absolument rien. Activez cette option. Un système de mise à jour qui n’annonce que ses réussites est pire que l’absence de système, car le silence donne l’impression que tout va bien.

dnf-automatic ne redémarre pas vos services

L’installation d’un paquet remplace des fichiers sur le disque. Un processus déjà en cours d’exécution conserve l’ancien code en mémoire. Une bibliothèque corrigée ne change donc rien pour un daemon démarré le mois dernier. Cet écart entre ce qui est installé et ce qui est effectivement utilisé explique pourquoi les mises à jour automatiques nécessitent une stratégie de redémarrage, et pas seulement une stratégie d’installation.

sudo dnf install -y dnf-plugins-core
dnf needs-restarting -s
dnf needs-restarting -r

-s répertorie les services systemd dont les fichiers ont changé après leur démarrage. -r répond à une question et affiche l’un de deux blocs :

Core libraries or services have been updated since boot-up:
  * kernel
Reboot is required to fully utilize these updates.

No core libraries or services have been updated since boot-up.
Reboot should not be necessary.

-r n’effectue pas une analyse approfondie. Il vérifie une liste fixe de paquets : kernel, kernel-core, kernel-rt, glibc, linux-firmware, systemd, dbus, dbus-broker, dbus-daemon et microcode_ctl. Si l’un d’eux a été installé après le dernier démarrage, vous obtenez la première réponse. Ajoutez vos propres noms de paquets dans un fichier se terminant par .conf sous /etc/dnf/plugins/needs-restarting.d/ lorsqu’un autre composant du serveur doit également être redémarré pour que la mise à jour prenne effet.

Attention pour les scripts : dnf needs-restarting -r renvoie un code différent de zéro aussi bien lorsqu’un redémarrage est nécessaire que lorsque la commande elle-même a échoué. Le code de sortie seul ne permet donc pas de distinguer ces deux cas. Lisez le texte affiché.

Redémarrer un service est l’intervention la plus limitée et constitue généralement la bonne solution. Redémarrez le daemon SSH depuis une deuxième session SSH déjà ouverte, afin qu’une configuration incorrecte ne vous bloque pas l’accès. Un nouveau kernel est le cas où seul un reboot est efficace, car le kernel en cours d’exécution ne peut pas être remplacé à chaud. Si vous voulez classer les mises à jour d’un matin donné dans ces deux catégories, quelles mises à jour nécessitent un reboot et lesquelles nécessitent seulement le redémarrage d’un service analyse la sortie paquet par paquet.

Les conteneurs constituent un cas distinct, car dnf-automatic met à jour les paquets de l’hôte et ne modifie jamais l’espace utilisateur intégré à une image. Un serveur exécutant Docker Engine sur Rocky Linux ou AlmaLinux doit donc également télécharger de nouveau ses images et recréer ses conteneurs avant qu’un correctif n’atteigne le code qui sert effectivement le trafic.

Le serveur doit-il redémarrer automatiquement ?

[commands]
reboot = when-needed
reboot_command = shutdown -r +5 'Rebooting after applying package updates'

reboot = never est la valeur par défaut. when-changed redémarre le serveur après chaque mise à jour appliquée. when-needed redémarre le serveur uniquement lorsque le contrôle effectué par needs-restarting -r indique qu’un paquet système essentiel a été remplacé. C’est généralement le comportement souhaité sur un serveur unique, associé à une fenêtre d’exécution choisie par vos soins. La valeur par défaut de reboot_command avertit les utilisateurs connectés cinq minutes à l’avance via shutdown. Vous pouvez augmenter ce délai.

Réglez deux points avant d’activer cette option. Tous les services dont vous dépendez doivent démarrer automatiquement au boot. C’est le problème le plus fréquent avec une stack Docker Compose démarrée manuellement. Vous devez également disposer d’un accès à la console ou au mode rescue fourni par votre hébergeur. Un kernel qui ne démarre pas ne peut pas être réparé via SSH. Si l’une de ces conditions n’est pas remplie, conservez reboot = never et redémarrez manuellement après avoir consulté le journal.

Rocky, AlmaLinux et CentOS Stream : leurs différences

Sur Rocky 9 et AlmaLinux 9, tout ce qui précède est identique, jusque dans le chemin de configuration et les noms d’unités. Les deux distributions publient des errata ; upgrade_type = security dispose donc de données à filtrer. Les errata Rocky obsolètes décrits plus haut sont l’un des rares points où leur comportement quotidien diverge réellement. Si le serveur n’est pas encore installé, prenez ce point en compte avec la promesse de compatibilité et la prise en charge des processeurs plus anciens qui les distinguent.

CentOS Stream fait exception, et la différence est importante. Les dépôts Stream ne contiennent aucun updateinfo.xml. Le filtre de sécurité ne peut donc jamais trouver de correspondance et chaque exécution signale No security updates needed. Sur Stream, utilisez upgrade_type = default et acceptez d’installer toutes les mises à jour. Stream est également en avance sur RHEL. Ce réglage évolue donc davantage sur un serveur Stream qu’avec le même réglage sur Rocky ou AlmaLinux. Cette différence ne vient pas d’un simple choix de packaging. Elle résulte de la décision prise par Red Hat en 2020 de transformer CentOS en version de prévisualisation rolling de RHEL, décision qui est également à l’origine de Rocky Linux et d’AlmaLinux.

Rocky 10 et AlmaLinux 10 sont passés à DNF5, qui renomme certains éléments. La documentation amont de DNF5 indique que le timer est dnf5-automatic.timer, que les valeurs par défaut fournies avec le système se trouvent dans /usr/share/dnf5/dnf5-plugins/automatic.conf tandis que vos surcharges restent dans /etc/dnf/automatic.conf, que download_updates vaut yes par défaut au lieu de no, et qu’un distro-sync est ajouté comme upgrade_type. La requête des advisories est dnf advisory list, tandis que updateinfo reste un alias. Vérifiez ce que votre version a réellement installé avant de reprendre les noms de paquets ou d’unités d’un guide écrit pour la version 9 :

dnf list --available '*automatic*'
systemctl list-unit-files '*automatic*'

De nombreux guides publiés sur ce sujet couvrent encore uniquement Rocky 8. L’ensemble des options s’est enrichi depuis leur rédaction. Consultez donc le fichier commenté sur votre propre serveur au lieu de vous fier à un article ancien.

Modes d’échec et messages affichés

Rien ne s’exécute. systemctl list-timers dnf-automatic.timer affiche un tableau vide et systemctl is-enabled dnf-automatic.timer affiche disabled. Le paquet a été installé, mais le timer ne l’a jamais été.

Le job s’exécute, mais n’installe rien. Le journal contient No security updates needed, but 3 updates available. Le filtre de sécurité n’a rien trouvé, soit parce qu’aucun élément en attente ne comporte d’advisory, soit parce que le dépôt ne publie aucune donnée d’advisory.

Un paramètre semble ignoré. DNF journalise une option inconnue dans automatic.conf au niveau de debug, puis utilise la valeur par défaut. Une clé mal orthographiée ne change donc rien et ne génère aucun avertissement. Écrivez apply_update = yes et apply_updates reste à no : la machine télécharge indéfiniment, sans jamais installer. Après toute modification, exécutez sudo systemctl start dnf-automatic.service et consultez le journal au lieu de faire confiance au fichier.

Le job s’exécute deux fois par jour. Deux timers sont activés. systemctl list-unit-files 'dnf-automatic*' indique lesquels, et les timers supplémentaires transmettent des flags qui prennent le pas sur votre fichier de configuration.

Aucun e-mail n’arrive. Soit rien n’écoute sur le port 25 pour l’émetteur email, soit send_error_messages vaut encore no et la seule information à signaler était une erreur.

Un service mis à jour indique toujours l’ancienne version. Le fichier sur disque est nouveau, mais le processus en mémoire est ancien. dnf needs-restarting -s indique les services à redémarrer.

FAQ

dnf-automatic installe-t-il uniquement les mises à jour de sécurité sur Rocky Linux ?

Uniquement si vous définissez upgrade_type = security dans /etc/dnf/automatic.conf, et si vos dépôts publient des métadonnées d’errata. Rocky Linux et AlmaLinux les publient tous les deux. Le filtre dispose donc d’avis auxquels faire correspondre les paquets. La valeur par défaut fournie est upgrade_type = default. Elle installe toutes les mises à jour disponibles lorsque apply_updates = yes.

Pourquoi dnf-automatic indique-t-il « No security updates needed, but 3 updates available » ?

DNF détermine ce qui constitue une mise à jour de sécurité en lisant updateinfo.xml dans le dépôt. Chaque avis y répertorie les paquets qui le corrigent. Lorsque ces métadonnées sont absentes ou obsolètes, le filtre de sécurité ne trouve aucune correspondance alors que des mises à jour ordinaires restent disponibles. C’est exactement ce qui produit ce message. Ce comportement est attendu sur CentOS Stream, qui ne publie aucun errata. Sur Rocky Linux ou AlmaLinux, comparez dnf updateinfo list --security à dnf check-update et vérifiez que vos métadonnées sont à jour.

dnf-automatic redémarrera-t-il mon serveur après une mise à jour du noyau ?

Non, sauf si vous le lui demandez. L’option reboot vaut never par défaut. Définissez reboot = when-needed. Une exécution redémarre alors le serveur uniquement lorsque le contrôle effectué par dnf needs-restarting -r détecte qu’un paquet système, tel que kernel ou glibc, a été remplacé depuis le démarrage. reboot = when-changed redémarre le serveur après toute mise à jour appliquée. Les deux options utilisent reboot_command, qui vaut shutdown -r +5 par défaut et affiche un message d’avertissement aux utilisateurs connectés.

Comment modifier l’heure d’exécution de dnf-automatic ?

Exécutez sudo systemctl edit dnf-automatic.timer et ajoutez une section [Timer] avec une ligne OnCalendar= vide, suivie de votre planification, par exemple OnCalendar=*-*-* 03:30. La ligne vide est obligatoire, car OnCalendar accumule les valeurs. Si vous l’omettez, l’exécution fournie à 06:00 est conservée et une seconde exécution est ajoutée. Vérifiez le résultat avec systemctl list-timers dnf-automatic.timer et lisez la colonne NEXT.

Dois-je encore vérifier un serveur qui installe automatiquement ses mises à jour ?

Oui. dnf-automatic installe les paquets, puis s’arrête. Il ne redémarre pas les daemons et ne produit aucun rapport visible, sauf si emit_via désigne un émetteur que vous consultez réellement. Définissez au minimum emit_via sur stdio, activez send_error_messages pour signaler également les échecs, puis exécutez dnf needs-restarting -s après une fenêtre de mise à jour afin de repérer les services qui exécutent encore une ancienne version du code.