Module group Ansible : gérer les groupes Linux

ansible.builtin.group: gère les groupes Linux, création, suppression, forçage du GID. Module compagnon de user: : on crée d'abord les groupes, puis on rattache les utilisateurs.

Trois options principales : name:, state:, gid: (et system: true pour les groupes système avec GID < 1000).

Ce que vous allez apprendre

• Créer un groupe simple ou avec GID forcé (cohérence multi-hôtes).
• Distinguer un groupe utilisateur (GID ≥ 1000) d'un groupe système (system: true).
• Comprendre pourquoi la suppression d'un groupe primaire échoue.
• Ordonner correctement : group: AVANT user: qui le référence.

Prérequis

• Comprendre le concept de groupe primaire vs groupes secondaires sous Linux.

Création basique

- name: Creer le groupe dev-team
  ansible.builtin.group:
    name: dev-team
    state: present

groupadd dev-team est exécuté. Le GID est auto-attribué (premier libre ≥ 1000). Idempotent : 2e run → ok.

GID forcé pour la cohérence multi-hôtes

- name: Groupe avec GID 4000 force
  ansible.builtin.group:
    name: rhce-shared
    gid: 4000
    state: present

Pourquoi forcer le GID ?

• NFS : un fichier gid=4000 côté serveur n'est lisible côté client que si le client a aussi gid=4000.
• Containers : les volumes partagés entre hôte et conteneur exigent les mêmes IDs.
• Audit : comparer les GIDs entre hôtes pour détecter une divergence.

Si le GID est déjà pris par un autre groupe, la tâche failed, pas de collision silencieuse.

Groupes système (system: true)

- name: Groupe applicatif systeme (GID < 1000)
  ansible.builtin.group:
    name: myapp-system
    system: true
    state: present

system: true demande un GID auto-attribué dans la plage système (< 1000 par convention RHEL). Sans cette option, le GID auto-attribué est ≥ 1000 (groupe utilisateur).

Cas d'usage : groupe applicatif réservé au démon (nginx, postgres, myapp). On ne veut pas qu'il soit confondu avec un groupe utilisateur normal, la différence d'UID/GID est un signal visuel pour les administrateurs.

Ordonnancement : group: AVANT user:

Pattern correct :

- name: Step 1 - creer le groupe
  ansible.builtin.group:
    name: rhce-team
    gid: 5000

- name: Step 2 - creer alice avec rhce-team comme primaire
  ansible.builtin.user:
    name: alice
    group: rhce-team   # Le groupe DOIT exister avant

Si vous inversez l'ordre : user: crée alice avec un groupe rhce-team auto-généré (GID 1001 ou autre). Puis group: gid: 5000 essaie de créer le groupe avec un GID différent → conflit ou incohérence.

Convention RHCE : dans un même play, ordonner :

1. group: (création des groupes nécessaires).
2. user: (création des users qui les utilisent).
3. authorized_key: (clés SSH).
4. sudoers: (droits sudo).

Suppression : la protection du groupe primaire

- name: Supprimer dev-team
  ansible.builtin.group:
    name: dev-team
    state: absent

Si un utilisateur a dev-team comme groupe primaire, la tâche failed :

groupdel: cannot remove the primary group of user 'carl'

C'est une protection système, Linux refuse de laisser un utilisateur sans groupe primaire valide.

Solution : réassigner d'abord :

- name: Reassigner carl a un autre groupe primaire
  ansible.builtin.user:
    name: carl
    group: nogroup

- name: Maintenant supprimer dev-team
  ansible.builtin.group:
    name: dev-team
    state: absent

Le piège : modifier le GID d'un groupe existant

- name: Tenter de changer le GID
  ansible.builtin.group:
    name: ops-team
    gid: 3500   # Avant : 3000

La tâche réussit (groupmod -g 3500 ops-team). Mais tous les fichiers appartenant à gid=3000 sont maintenant orphelins :

# Avant changement
$ ls -la /home/alice/data
-rw-r--r-- 1 alice ops-team 0 ... data

# Apres changement
$ ls -la /home/alice/data
-rw-r--r-- 1 alice 3000     0 ... data   # Plus de nom !

Règle : ne jamais modifier un GID en production. Si nécessaire :

1. Supprimer le groupe.
2. Recréer avec le nouveau GID.
3. chgrp -R sur tous les fichiers concernés.

Pièges courants

Trois de ces quatre pannes tournent autour du GID, et pour la même raison : le système accorde ses droits sur un numéro, alors que l'administrateur raisonne sur un nom. Un identifiant laissé au hasard diverge d'une machine à l'autre, un identifiant modifié laisse des fichiers orphelins, un groupe applicatif sans system: true atterrit dans la plage des humains. La quatrième, le refus de supprimer un groupe primaire, n'est pas un défaut mais une protection du système.

Symptôme	Cause	Fix
Conflit GID entre hôtes	Pas de gid: forcé	Forcer gid: sur les groupes partagés (NFS, containers)
groupdel failed (primaire)	User a ce groupe comme primaire	Réassigner d'abord avec user: group:
Fichiers orphelins après modif	Modification du gid: sur groupe existant	Ne jamais modifier, supprimer + recréer + chgrp
Groupe applicatif avec GID > 1000	Oubli de system: true	Ajouter system: true à la création

Glissez pour voir

Contrôle de connaissances

Vérifiez que l'essentiel de ce guide est acquis. Les questions portent uniquement sur ce qui vient d'être expliqué ici.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

6 questions

6 min.

70% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

À retenir

• gid: forcé pour la cohérence multi-hôtes (NFS, containers, audit).
• system: true pour les groupes applicatifs / système (GID < 1000).
• Ordonner : group: AVANT user: qui le référence.
• Suppression d'un groupe primaire d'un user → failed. Réassigner d'abord.
• Ne pas modifier le GID d'un groupe existant, fichiers orphelins.

Mettre en pratique

Un GID mal choisi ne se manifeste qu'au moment où un partage réseau refuse l'accès, bien après le run qui l'a créé. Le lab vous fait poser plusieurs groupes avec un GID forcé sur une machine réelle, ajouter un groupe système distinct des groupes utilisateurs, et respecter l'ordre qui place le groupe avant les comptes qui le référencent. La vérification interroge la cible pour confirmer chaque GID attribué et la plage dans laquelle tombe le groupe système.

Lab pratique

Module group : gérer les groupes Linux

$ dsoxlab run modules-utilisateurs-group

Environnement : VM·Durée : ~30 min

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 et brancher le catalogue, une seule fois :

uv tool install dsoxlab   # ou : pipx install dsoxlab
dsoxlab catalog add https://github.com/stephrobert/ansible-training

Lancer ce lab, puis valider votre travail :

dsoxlab run modules-utilisateurs-group
dsoxlab check modules-utilisateurs-group

Voir tous les labs : dsoxlab list-labs. Suivre sa progression : dsoxlab progress. Le guide complet de dsoxlab détaille l'installation, le calcul du score et les pièges.

Pour aller plus loin

• Module sudoers : écrire une règle sur un groupe plutôt que compte par compte, avec le préfixe %.
• Module getent : vérifier la présence d'un groupe et son GID directement depuis la base du système.
• Module mount : le cas concret qui justifie un GID forcé : un partage NFS où les identifiants numériques doivent concorder.

×

📖 Voir la documentation →