Module dnf Ansible : enablerepo, security, exclude, autoremove

Sur un parc 100% RHEL/RockyLinux/AlmaLinux, ansible.builtin.dnf est plus puissant que package: car il expose les options spécifiques de DNF. Cette page couvre les options critiques RHCE 2026 : enablerepo:, disablerepo:, security: true, bugfix: true, exclude:, autoremove:, update_cache:, download_only:.

Ces options permettent des opérations qu’on ne peut pas faire avec package: : appliquer uniquement les errata de sécurité, activer un repo temporairement, mettre à jour tout sauf le kernel, ou nettoyer les dépendances orphelines.

# 1. Mise à jour de sécurité uniquement (errata RHEL critiques)
- ansible.builtin.dnf:
    name: "*"
    state: latest
    security: true       # uniquement errata RHSA
    update_cache: true
  become: true

# 2. Activer un repo temporairement (CRB, EPEL, etc.)
- ansible.builtin.dnf:
    name:
      - htop
      - iotop
    state: present
    enablerepo: epel       # actif uniquement pour cette tâche
  become: true

# 3. Upgrade complet sauf kernel (réserver le reboot)
- ansible.builtin.dnf:
    name: "*"
    state: latest
    exclude:
      - kernel*
      - grub2*
    update_cache: true
  become: true

# 4. Nettoyer les orphelines après upgrade
- ansible.builtin.dnf:
    autoremove: true
  become: true

Sécurité non négociable :

security: true est l’usage RHCE par excellence : applique uniquement les patches de sécurité Red Hat (RHSA) sans toucher aux mises à jour de fonctionnalités — exactement ce qu’on veut sur un parc en production.
Ne jamais désactiver la vérification GPG (disable_gpg_check: true) sauf pour debug ponctuel, et jamais en prod.
enablerepo: au niveau de la tâche n’écrit pas la config repo de manière persistante — c’est un override temporaire, idéal pour ne pas activer EPEL globalement.
Pour les upgrades critiques, faire d’abord download_only: true pour récupérer les paquets, puis appliquer dans une fenêtre de maintenance contrôlée.

Ce que vous allez apprendre

Comment activer un repo temporairement avec enablerepo: sans le persister.
Le pattern mise à jour de sécurité uniquement (security: true).
Comment exclure le kernel d’un upgrade massif (exclude: kernel*).
L’option autoremove: true pour le nettoyage post-upgrade.
Quand utiliser download_only: true (préparation d’opérations critiques).

Prérequis

Avoir lu Module package — dnf: est le spécialiste RHEL de package:.
Comprendre la notion de repo DNF (/etc/yum.repos.d/*.repo).

enablerepo / disablerepo — activer un repo le temps de l’opération

- name: Installer htop depuis EPEL (sans activer EPEL en permanence)
  ansible.builtin.dnf:
    name: htop
    state: present
    enablerepo: epel

enablerepo: n’active le repo que pour cette tâche — pas de modification persistante. Au prochain dnf list, EPEL sera désactivé. Utile quand on ne veut pas exposer EPEL à des updates automatiques (paquets pas toujours stables).

disablerepo: fait l’inverse — désactive un repo le temps d’une opération. Pattern classique : désactiver un repo flaky quand on veut s’assurer qu’on tire d’un repo précis.

- name: Forcer l installation depuis le repo officiel uniquement
  ansible.builtin.dnf:
    name: nginx
    state: present
    disablerepo: epel,backports

Mises à jour de sécurité — `security: true`

C’est le pattern le plus utile en production : applique uniquement les errata classés “Security Advisory” par le vendor RHEL.

- name: Patcher uniquement les CVE
  ansible.builtin.dnf:
    name: '*'
    state: latest
    security: true

name: '*' = tous les paquets installés. state: latest = mettre à jour. security: true = filtre : seulement les paquets avec un errata de sécurité disponible.

Combiner avec bugfix: true pour aussi appliquer les bugfixes :

- name: Patcher securite ET bugs
  ansible.builtin.dnf:
    name: '*'
    state: latest
    security: true
    bugfix: true

Exclude — préserver des paquets sensibles d’un upgrade massif

- name: Mise a jour complete sauf kernel
  ansible.builtin.dnf:
    name: '*'
    state: latest
    exclude: kernel*

Cas critique RHEL : un upgrade kernel nécessite un reboot. Si vous appliquez les patches de sécurité sans reboot programmé, exclude: kernel* évite de mettre la machine en état “kernel staged but not running” (sécurité dégradée jusqu’au prochain reboot).

exclude: accepte une liste : exclude: ["kernel*", "glibc"]. Wildcards style kernel* matchent kernel, kernel-headers, kernel-modules, etc.

Autoremove — nettoyer les dépendances orphelines

- name: Supprimer un paquet et ses dependances orphelines
  ansible.builtin.dnf:
    name: httpd
    state: absent
    autoremove: true

Quand on désinstalle httpd, ses dépendances exclusives (apr, apr-util, httpd-tools) deviennent orphelines. autoremove: true les supprime automatiquement — comme dnf autoremove après un dnf remove.

Sans autoremove, on accumule des paquets fantômes au fil des cycles install/uninstall.

update_cache — refresh du cache des repos

- name: Refresh cache puis installer
  ansible.builtin.dnf:
    name: nginx
    state: latest
    update_cache: true

Par défaut, DNF utilise un cache de métadonnées (TTL ~6h). update_cache: true force un refresh immédiat — utile quand on vient de modifier un fichier .repo ou de pousser un nouveau paquet dans un repo interne.

download_only — télécharger sans installer

- name: Pre-telecharger pour install offline ulterieure
  ansible.builtin.dnf:
    name:
      - bind
      - dhcp-server
    state: present
    download_only: true
    download_dir: /var/cache/staged-rpms/

Pré-télécharge les RPM dans download_dir sans les installer. Pattern utilisé pour :

Préparer un upgrade air-gapped : télécharger sur un nœud connecté, pousser sur un nœud isolé via copy:.
Réduire la fenêtre de panne : pré-stager 2h avant la maintenance, installer en 30s pendant la fenêtre.

Modules de groupe — `name: '@web-server'`

- name: Installer le groupe Web Server (RHEL group)
  ansible.builtin.dnf:
    name: '@web-server'
    state: present

DNF supporte des groupes pré-définis (@base, @web-server, @minimal-environment). dnf grouplist les liste. Pratique pour provisionner rapidement un rôle métier sans énumérer 30 paquets.

Pièges courants

Symptôme	Cause	Fix
`update_cache: true` lent	Repos lents (CDN, network)	Mettre une fois en début de play, pas par tâche
`security: true` ne trouve rien	Pas d’errata RHEL pour cette release	Vérifier `dnf updateinfo list security`
`exclude: kernel` ne marche pas	Wildcard manquant	`exclude: kernel` (avec ``)
`autoremove: true` supprime un paquet voulu	Dépendance qu’on croyait directe est en réalité orpheline	Vérifier avec `dnf list --installed`, marquer comme `userinstalled` si besoin
`enablerepo:` ignoré silencieusement	Le repo n’existe pas dans `/etc/yum.repos.d/`	Vérifier que le repo est défini (même si désactivé)

À retenir

dnf: est plus puissant que package: sur RHEL — utiliser ses options spécifiques.
enablerepo: active un repo temporairement — pas de modification persistante.
security: true est le pattern de patching de production — applique uniquement les errata CVE.
exclude: kernel* évite de stage un kernel sans reboot programmé.
autoremove: true sur state: absent nettoie les dépendances orphelines.

Pratiquer dans le lab

Cette page a un lab d’accompagnement : labs/modules-paquets/dnf-options/ dans stephrobert/ansible-training.

Challenge — sur db1.lab :

Installer epel-release.
Refresh cache + installer htop et ncdu depuis EPEL avec enablerepo: epel.
Vérifier qu’aucun kernel n’a été touché (utiliser exclude: kernel* sur les opérations à risque).

Validation pytest+testinfra :

ansible-playbook solution.yml
pytest -v labs/modules-paquets/dnf-options/challenge/tests/

5 tests vérifient epel-release, l’installation de htop/ncdu et la configuration du repo EPEL.

Prochaines étapes

Module package Le module agnostique multi-distro — base à comprendre avant les options dnf

Module systemd_service Démarrer et activer un service après installation

Handlers et notification Recharger automatiquement un service après modification (sshd, nginx)

Pivot Modules Ansible Vue d'ensemble : modules builtin, posix, community.general, FQCN obligatoire