RHEL System Roles : la bibliothèque de rôles maintenue par Red Hat

Les RHEL System Roles ne sont pas un rôle, mais une bibliothèque de 33 rôles maintenus par Red Hat, qui couvre le pare-feu, SELinux, le stockage, le réseau, SSH, les journaux, l'horloge et une vingtaine d'autres sujets. Chacun expose une intention plutôt qu'une syntaxe de fichier : vous déclarez le résultat voulu, le rôle produit la configuration correspondante et relance ce qu'il faut.

Cette page présente d'abord la bibliothèque et la façon de s'y repérer, puis déroule un exemple complet avec timesync, choisi parce qu'il est le plus court à mettre en œuvre et le plus facile à vérifier.

Ce que vous allez apprendre

• Situer les rôles système parmi les rôles Galaxy, et comprendre ce que leur maintenance apporte.
• Trouver le rôle qui correspond à votre besoin parmi les 33 disponibles.
• Installer la bibliothèque et lire la documentation de référence d'un rôle.
• Consommer un rôle de bout en bout, de la déclaration des variables à la vérification du résultat.

Prérequis

• Savoir consommer un rôle et l'installer depuis Galaxy.
• Une cible RHEL, AlmaLinux ou Rocky pour l'exemple filé.

Ce que ces rôles apportent

Écrire soi-même un rôle qui configure chrony, firewalld ou SELinux est à la portée de tous : un gabarit, un handler, quelques conditions par distribution. La difficulté n'est pas là, elle arrive ensuite.

À votre charge avec un rôle maison	Pris en charge par le rôle système
La syntaxe exacte du fichier, qui évolue avec la version	Un gabarit maintenu avec la distribution
Les différences entre RHEL 8, 9 et 10	Une interface de variables stable d'une version à l'autre
La cohabitation avec la configuration livrée par le système	La régénération complète du fichier
Le rechargement du service concerné	Un handler interne au rôle
Le suivi des dépréciations amont	Le travail de l'équipe qui maintient le rôle

Glissez pour voir

Le gain n'est donc pas le temps d'écriture initial, comparable, mais la maintenance : quand la distribution change quelque chose, le rôle suit et votre playbook ne bouge pas. C'est aussi ce qui explique leur présence à l'examen RHCE, où l'on attend que vous consommiez un rôle éditeur plutôt que de réécrire ce qui existe.

Les 33 rôles, par domaine

Voici la bibliothèque telle qu'elle est livrée, regroupée par sujet. Vous n'en utiliserez qu'une poignée, mais savoir ce qui existe évite d'écrire un rôle qui existe déjà.

Domaine	Rôles
Sécurité et accès	selinux, firewall, crypto_policies, certificate, ssh, sshd, sudo, vpn, fapolicyd, aide, tlog, keylime_server
Chiffrement de disque	nbde_client, nbde_server
Système	timesync, kernel_settings, bootloader, systemd, kdump
Journaux et supervision	logging, journald, metrics
Stockage	storage, snapshot, gfs2
Réseau	network
Services	postfix, postgresql, podman, cockpit
Intégration	ad_integration, rhc, ha_cluster

Glissez pour voir

Quelques-uns méritent d'être connus même si vous ne les utilisez pas tout de suite. storage crée des volumes LVM, des systèmes de fichiers et leurs points de montage à partir d'une simple description. network configure interfaces, agrégats et VLAN sans toucher à NetworkManager. firewall et selinux couvrent les deux sujets où les erreurs manuelles coûtent le plus cher. Et podman déploie des conteneurs gérés par systemd, ce qui surprend souvent dans une bibliothèque estampillée « système ».

Installer la bibliothèque

Deux distributions coexistent, pour le même code.

En communautaire, la collection s'installe depuis Galaxy :

ansible-galaxy collection install fedora.linux_system_roles

Sur un poste de contrôle RHEL abonné, un paquet fournit l'équivalent, supporté par Red Hat au titre de l'abonnement :

dnf install rhel-system-roles ansible-core

Les rôles sont alors disponibles sous le namespace redhat.rhel_system_roles, et leur documentation est déposée dans /usr/share/doc/. Les variables sont identiques d'une distribution à l'autre : seul le préfixe du FQCN change.

Lire la documentation d'un rôle

Chaque rôle embarque sa propre référence, qui vaut mieux que n'importe quel article, y compris celui-ci, car elle correspond exactement à la version que vous avez installée.

COLL=~/.ansible/collections/ansible_collections/fedora/linux_system_roles/roles

# Ce que le rôle accepte, et avec quelles valeurs par défaut
cat "$COLL/timesync/defaults/main.yml"

# La description de chaque variable et des exemples
cat "$COLL/timesync/README.md"

Le fichier defaults/main.yml est la source de vérité pour les noms d'options, qui ne s'inventent pas et changent parfois d'une version majeure à l'autre.

Exemple filé : converger l'horloge avec timesync

Le rôle timesync installe et configure une implémentation NTP ou PTP. Sur une cible RHEL récente, cela veut dire chrony.

Sa variable centrale est timesync_ntp_servers, une liste de dictionnaires. Seule la clé hostname est obligatoire ; les autres portent le nom de la directive chrony correspondante.

timesync_ntp_servers:
  - hostname: 0.fr.pool.ntp.org
    iburst: true          # premières requêtes rapprochées, convergence accélérée
    prefer: true          # source privilégiée si plusieurs conviennent
  - hostname: 1.fr.pool.ntp.org
    iburst: true
  - hostname: 2.fr.pool.ntp.org
    iburst: true
    maxpoll: 10           # intervalle maximal entre deux sondages

Deux réglages d'horloge complètent la description.

Variable	Effet	Valeur par défaut du rôle
timesync_step_threshold	Écart au-delà duquel l'horloge est corrigée d'un coup plutôt que lissée	-1.0, qui produit une correction à 1.0 seconde
timesync_min_sources	Nombre de sources concordantes exigées avant tout ajustement	1

Glissez pour voir

La valeur 0 a un sens particulier pour le seuil : elle supprime la directive de correction brutale, l'horloge n'étant plus ajustée que progressivement.

Assemblé, cela donne un playbook autonome. Le rôle s'appelle en FQCN dans la liste roles:, et toute la configuration tient dans le bloc vars:.

---
- name: Converger la synchronisation horaire
  hosts: dbservers
  become: true
  vars:
    timesync_ntp_servers:
      - hostname: 0.fr.pool.ntp.org
        iburst: true
        prefer: true
      - hostname: 1.fr.pool.ntp.org
        iburst: true
      - hostname: 2.fr.pool.ntp.org
        iburst: true
        maxpoll: 10
    timesync_step_threshold: 0.1    # correction immédiate au-delà de 0,1 s
    timesync_min_sources: 2         # deux sources concordantes exigées
  roles:
    - role: fedora.linux_system_roles.timesync

Aucune tâche de configuration à ajouter, aucun handler à écrire.

Ce que le rôle fait à votre place

Trois comportements expliquent pourquoi ce playbook reste aussi court, et ils valent pour la plupart des rôles de la bibliothèque.

Le rôle régénère /etc/chrony.conf au lieu de le modifier. Les directives livrées par la distribution, comme le pool par défaut, disparaissent donc d'elles-mêmes : vous n'avez rien à nettoyer au préalable.

Il coupe l'injection DHCP en posant PEERNTP=no dans /etc/sysconfig/network, ce qui empêche les serveurs annoncés par le réseau de se greffer sur votre configuration.

Il notifie son propre handler quand le fichier change, et relance chronyd. Ajouter une tâche de redémarrage dans votre playbook produirait un changed à chaque exécution, y compris quand rien n'a bougé.

Vérifier côté démon

Un fichier correct ne prouve rien tant que le service ne l'a pas rechargé. Trois commandes donnent l'état réel.

# Les directives réellement actives, sans commentaires ni lignes vides
sudo grep -vE '^\s*(#|$)' /etc/chrony.conf

# Les sources que le démon a chargées en mémoire
chronyc -N sources

# La source sur laquelle l'horloge est verrouillée
chronyc tracking

chronyc -N sources doit lister vos serveurs, et chronyc tracking afficher l'un d'eux en référence.

La convergence prend du temps

Juste après le premier run, chronyc tracking peut afficher Reference ID : 00000000 () pendant quelques dizaines de secondes, le temps que le démon interroge ses sources et se verrouille. L'option iburst accélère nettement cette phase, ce qui explique sa présence sur chaque serveur de l'exemple.

Pratiquer dans le lab

Lab pratique

Rôles système RHEL : converger la synchronisation horaire avec timesync

$ dsoxlab run roles-system-roles

Environnement : VM·Durée : ~1 h

Validé : l'état du système est vérifié après reboot, pas la commande tapée.

Première fois ? Qu'est-ce que dsoxlab et comment l'installer

dsoxlab est la ligne de commande qui prépare un environnement jetable (un shell isolé ou une VM), déroule le scénario du lab, puis vérifie l'état réel du système et calcule un score. Rien n'est installé ni cassé sur votre poste de travail.

Installer la CLI dsoxlab, une seule fois :

uv tool install dsoxlab   # ou : pipx install dsoxlab
git clone https://github.com/stephrobert/ansible-training.git
cd ansible-training

Lancer ce lab, puis valider votre travail :

dsoxlab run roles-system-roles
dsoxlab check roles-system-roles

Voir tous les labs : dsoxlab list-labs. Suivre sa progression : dsoxlab progress.

Le challenge demande de converger db1.lab sur trois serveurs NTP avec leurs options, un seuil de correction à 0.1 et un minimum de deux sources, sans jamais écrire /etc/chrony.conf. Un test analyse le YAML de votre solution et exige le rôle en FQCN dans la liste roles:.

Les douze tests ne relisent pas votre configuration : ils inspectent l'état réel de la machine, jusqu'à ce que chronyd a chargé en mémoire, et vérifient que le second passage ne change plus rien.

dsoxlab run roles-system-roles
dsoxlab challenge
# ... vous écrivez challenge/solution.yml ...
dsoxlab check

Deux expériences éclairent la mécanique : passer timesync_dhcp_ntp_servers à true puis rejouer, pour voir l'injection DHCP réapparaître ; retirer timesync_min_sources pour observer la directive minsources s'effacer du fichier généré.

Pièges courants

Symptôme	Cause	Solution
the role 'timesync' was not found	Nom court au lieu du FQCN	Écrire fedora.linux_system_roles.timesync
pool toujours présent après le run	Un template ou un lineinfile écrit dans le même fichier	Retirer toute écriture directe de chrony.conf
Second run toujours en changed	Redémarrage ajouté à la main	Supprimer la tâche, le rôle gère son handler
Aucune directive makestep générée	timesync_step_threshold à 0	Utiliser une valeur strictement positive
Variable ignorée sans message	Nom d'option inventé ou renommé	Relire defaults/main.yml du rôle installé

Glissez pour voir

À retenir

• Les RHEL System Roles forment une bibliothèque de 33 rôles, pas un rôle unique : pare-feu, SELinux, stockage, réseau, SSH, journaux, horloge et bien d'autres.
• Un rôle système expose une intention, la syntaxe du fichier de configuration reste son problème et non le vôtre.
• Le FQCN dépend du packaging, fedora.linux_system_roles en communautaire, redhat.rhel_system_roles sur RHEL abonné, pour un code et des variables identiques.
• Le fichier defaults/main.yml du rôle installé est la référence des noms d'options et de leurs valeurs par défaut.
• Un rôle système régénère la configuration et relance le service : rien à nettoyer, aucun redémarrage à ajouter.
• La preuve se lit côté service, avec chronyc -N sources et chronyc tracking dans le cas de timesync.

×

📖 Voir la documentation →