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

Fonctionnement de 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 les paramètres autorisés par ce fichier. L’installation se fait avec une seule commande. Le reste de ce guide explique les paramètres qui déterminent si le serveur est protégé ou si le programme ne fait rien sans signaler de problème.

Si vous venez de Debian ou d’Ubuntu, dnf-automatic 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 « security » pour le gestionnaire de paquets. Sur Ubuntu, il s’agit d’un pocket distinct de l’archive. Dans la famille RHEL, il s’agit de métadonnées associées aux avis de sécurité publiés. 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 de sécurité, il n’installe rien tout en indiquant que l’opération a réussi.

Ce guide porte sur Rocky Linux 9 et AlmaLinux 9, qui utilisent DNF 4 (DNF est le gestionnaire de paquets de la famille RHEL), en date d’août 2026. Les versions 10 utilisent DNF5 et les noms y sont différents ; elles font donc l’objet d’une section distincte vers la fin du guide. Chaque commande ci-dessous doit être exécutée sur votre propre serveur. Le résultat attendu est indiqué juste à 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.

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 neuve, car l’installation du paquet ne démarre aucun service. C’est la raison la plus fréquente pour laquelle un serveur qui « dispose de dnf-automatic » n’a jamais appliqué la moindre 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 par l’intermédiaire de l’avis RHBA-2023:6645. Rocky 9 et AlmaLinux 9 reconstruisent ce paquet. Une machine à jour dispose donc de ce paramètre, contrairement à une machine qui n’a pas été mise à jour depuis 2023.

Le fichier de configuration est /etc/dnf/automatic.conf. La copie fournie liste toutes les options comprises par cette version, avec leur valeur par défaut, sous forme de commentaires. Lisez-la avant de la modifier, car ce fichier fait foi pour votre version.

Les deux paramètres qui déterminent le comportement

download_updates et apply_updates dans la section [commands] déterminent le comportement. Par défaut, les deux sont no sur EL9 (Enterprise Linux 9, la base commune de Rocky 9 et AlmaLinux 9). Un fichier dnf-automatic que vous activez sans le modifier vous indique donc uniquement les mises à jour disponibles.

• Les deux 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 aucun accès réseau, mais rien n’a été modifié cette nuit.
• Les deux yes avec upgrade_type = default : toutes les mises à jour disponibles sont installées, qu’elles soient de sécurité ou non.
• Les deux 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é sur Internet :

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

network_online_timeout correspond au nombre de secondes pendant lesquelles l’exécution attend un réseau opérationnel avant d’abandonner. Cela compte 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 désormais. Exécutez systemctl cat dnf-automatic.service pour afficher les options exactes transmises par le service fourni.

Vérifiez que le fichier produit bien le comportement attendu, 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 effectué. Vous pouvez également forcer un comportement depuis la ligne de commande. Cette option ne s’applique qu’à cette exécution et remplace le fichier :

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 appelé updateinfo.xml publié dans le référentiel, où chaque avis répertorie les paquets qui le corrigent. AlmaLinux publie ces données 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 effectuée. Si le référentiel ne contient aucun updateinfo.xml, le filtre ne correspond à rien 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 un échec. 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, soit le référentiel ne contient aucune donnée d’avis à lire. Rocky et AlmaLinux les publient tous les deux ; sur ces distributions, une liste vide est donc généralement normale. CentOS Stream ne les 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 processus de mise à niveau normal. Un paquet mentionné dans un avis passe donc à la version la plus récente disponible dans le référentiel et installe également ses dépendances. La mise à niveau limitée à la première version qui corrige l’avis s’effectue avec dnf upgrade-minimal --security, exécuté manuellement. dnf-automatic ne propose aucun réglage pour ce comportement.

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 les updateinfo.xml de Rocky 9 BaseOS n’avaient pas été mis à jour 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 en temps la liste des avis avec les annonces RLSA récentes. Sur un serveur où la couverture est plus importante que la maîtrise des changements, upgrade_type = default selon la planification de votre choix constitue le réglage le plus sûr.

Le timer systemd qui exécute réellement la tâche

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 la tâche ne s’exécutera jamais.

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 miroir à la même seconde. Persistent=true signifie qu’une machine éteinte à 06:00 exécute la tâche manquée peu après son démarrage, au lieu d’ignorer cette exécution.

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 seconde, et la tâche s’exécute 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 concernant les drop-ins s’appliquent à tout ce que vous planifiez, comme indiqué dans écrire des unités de service et des timers systemd.

Voici 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 : la tâche s’exécute alors deux fois avec deux comportements différents, ce qui ressemble exactement à un fichier de configuration 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, ce qui constitue l’option la plus fiable, car elle ne nécessite aucun autre logiciel installé :

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 neuf n’a 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 relay-only si la sortie est vide. Lorsque l’envoi fonctionne, l’objet du message est Updates applied on 'web01'., en utilisant le nom provenant de 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 par défaut no, ce qui signifie qu’une exécution échouée ne signale absolument rien. Activez cette option. Un système de patching qui annonce uniquement ses réussites est pire que l’absence de système, car le silence donne l’impression que tout fonctionne.

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 n’a donc aucun effet sur un daemon lancé le mois dernier. Cet écart entre la version installée et la version effectivement utilisée explique pourquoi l’application automatique des correctifs nécessite 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 été modifiés après leur démarrage. -r répond à une seule 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 boot, 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 soit effective.

Attention dans les scripts : dnf needs-restarting -r renvoie un code différent de zéro à la fois lorsqu’un reboot est requis et lorsque la commande elle-même a échoué. Le code de retour 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 mauvaise configuration 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.

Le serveur doit-il redémarrer automatiquement ?

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

reboot = never est le comportement par défaut. when-changed redémarre le serveur après chaque mise à jour appliquée. when-needed redémarre uniquement lorsque la vérification effectuée par needs-restarting -r indique qu’un paquet système essentiel a été remplacé. C’est généralement le choix adapté à un serveur unique, associé à une fenêtre d’exécution définie par vos soins. Par défaut, 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 fonction. Tous les services dont vous dépendez doivent démarrer automatiquement au boot. C’est généralement le point oublié 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’un de ces éléments manque, conservez reboot = never et redémarrez vous-même après avoir consulté le journal.

Rocky, AlmaLinux et CentOS Stream : quelles 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 des unités. Les deux distributions publient des errata. upgrade_type = security dispose donc de données sur lesquelles effectuer le filtrage.

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 évolue également avant RHEL. Ce paramètre entraîne donc davantage de changements sur un serveur Stream qu’avec le même paramètre sur Rocky ou 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 paquet se trouvent dans /usr/share/dnf5/dnf5-plugins/automatic.conf, tandis que vos surcharges restent dans /etc/dnf/automatic.conf, que la valeur par défaut de download_updates est désormais yes au lieu de no, et qu’elle ajoute distro-sync en tant que upgrade_type. La requête d’advisory est dnf advisory list, updateinfo restant 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 étoffé 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 jamais le timer.

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 possède 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 déclenche 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 vous fier au fichier.

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

Aucun e-mail n’arrive. Soit aucun processus 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 corrigé signale toujours l’ancienne version. Le fichier sur le disque est à jour, mais le processus en mémoire utilise encore l’ancienne version. 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 ?

Seulement si vous définissez upgrade_type = security dans /etc/dnf/automatic.conf, et uniquement 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. Cette situation produit exactement cette ligne. Elle est attendue sur CentOS Stream, qui ne publie aucun errata. Sur Rocky 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 utilise par défaut la valeur never. Définissez reboot = when-needed. Une exécution redémarrera alors le serveur uniquement si le contrôle effectué par dnf needs-restarting -r détecte qu’un paquet essentiel, 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, dont la valeur par défaut est shutdown -r +5, avec un message d’avertissement destiné 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 cumule les valeurs. Si vous l’omettez, l’exécution fournie à 06:00 est conservée et une deuxième exécution est ajoutée. Vérifiez avec systemctl list-timers dnf-automatic.timer et consultez la colonne NEXT.

Dois-je encore contrôler un serveur qui installe automatiquement ses correctifs ?

Oui. dnf-automatic installe les paquets, puis s’arrête là. Il ne redémarre pas les daemons et ne signale rien que vous puissiez voir, 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 afin que les échecs soient également signalés, puis exécutez dnf needs-restarting -s après une fenêtre de maintenance pour trouver les services qui utilisent encore l’ancien code.