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 :

group: (création des groupes nécessaires).
user: (création des users qui les utilisent).
authorized_key: (clés SSH).
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 :

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

Pièges courants

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

À 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.

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 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 modules-utilisateurs-group
dsoxlab check modules-utilisateurs-group

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

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.