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

Pressé ? Les 3 patterns group

# Groupe métier (GID auto, ≥1000)
- ansible.builtin.group:
    name: devops
    state: present
  become: true

# Groupe système avec GID fixé (cohérence multi-hôtes pour NFS/CIFS partagés)
- ansible.builtin.group:
    name: myapp
    gid: 1500          # GID stable — DOIT matcher l'UID du user du même nom
    system: true
    state: present
  become: true

# Suppression (échoue si c'est le groupe primaire d'un user — supprimer le user d'abord)
- ansible.builtin.group:
    name: legacy_team
    state: absent
  become: true

Sécurité non négociable :

• GID fixé sur les groupes système qui apparaissent sur plusieurs hôtes (NFS, fichiers partagés via Ceph/GlusterFS). Sans GID stable, les permissions deviennent incohérentes entre serveurs.
• system: true pour tout groupe applicatif/service — évite la collision avec un GID utilisateur attribué automatiquement.
• Créer le groupe AVANT le user qui en dépend (ordre des tâches dans le playbook).
• Ne jamais supprimer un groupe primaire sans avoir d’abord supprimé/migré les utilisateurs qui l’ont comme primary group — groupdel échoue, mais surtout vous vous retrouvez avec des fichiers orphelins.

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.

Lab d'accompagnement

Cette page est jumelée au lab labs/modules-utilisateurs/group/ dans stephrobert/ansible-training. Détails et commandes en bas de page : Pratiquer dans le lab.

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

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

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

Pratiquer dans le lab

Cette page a un lab d’accompagnement : labs/modules-utilisateurs/group/ dans stephrobert/ansible-training.

Challenge — sur db1.lab :

1. Créer 3 groupes avec GIDs forcés (rhce-shared GID 4000, rhce-admins GID 4001, rhce-readonly GID 4002).
2. Créer un groupe système myapp-system (system: true).

Validation pytest+testinfra :

ansible-playbook solution.yml
pytest -v labs/modules-utilisateurs/group/challenge/tests/

4 tests vérifient les GIDs forcés et le caractère “système” du dernier groupe.

Prochaines étapes

Module user Créer les utilisateurs qui utiliseront ces groupes

Module authorized_key Provisionner les clés SSH des utilisateurs

Module sudoers Règles sudo sur des groupes (préfixe %)

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

×

📖 Voir la documentation →