cans.user-make

Rôle Ansible pour créer plusieurs utilisateurs sur des hôtes cibles

Comment ça fonctionne ?

Chaque utilisateur à créer doit être défini avec un élément comme suit :

usermake_users:
  - name: "johndoe"                # obligatoire
    gecos: "John Doe,,,"           # par défaut : omettre
    groups: "sudo,adm"             # par défaut : omettre
    passwordless_sudo: true        # par défaut : usermake_sudoer_passwordless
    ssh_key_create: false          # par défaut : vrai
    ssh_key_upload_to_ec2: true    # par défaut : usermake_ssh_key_upload_to_ec2
    ssh_key_download: true         # par défaut : usermake_ssh_key_download
    sudoer: true                   # par défaut : usermake_sudoer
    system: false                  # par défaut : faux
    upload_my_key: false           # par défaut : usermake_upload_ssh_key_to_target
    remove: false                  # par défaut : omettre ou usermake_remove
    home_dir: "/home/jdoe"         # par défaut : usermake_home_base_dir/nom

Voici la signification de chaque variable trouvée dans l'élément :

name: le nom de connexion à attribuer au nouvel utilisateur ;
gecos: les données GECOS à attacher au nouvel utilisateur ;
groups: la liste des groupes auxquels l'utilisateur devrait appartenir. Les groupes listés ici sont supposés exister a priori (voir aussi la section suivante)
passwordless_sudo: lorsqu'il est défini sur true, l'utilisateur pourra assumer l'identité d'un autre utilisateur sans entrer de mot de passe ;
remove: lorsque la valeur d'état de l'élément est 'absent', indique s'il faut supprimer les fichiers détenus par l'utilisateur lorsque son compte est supprimé (peut être lent) ;
ssh_key_create: s'il faut générer une paire de clés SSH pour le nouvel utilisateur ;
ssh_key_download: s'il faut télécharger la clé publique SSH générée de l'utilisateur dans un dossier sur la machine locale (voir aussi le usermake_ssh_key_download_dir défini ci-dessous).
ssh_key_upload_to_ec2: s'il faut télécharger la clé publique SSH générée de l'utilisateur dans le système de gestion de clés AWS EC2.
state: s'il faut créer () ou supprimer () l'utilisateur indiqué avec les valeurs 'present' ou 'absent' respectivement (par défaut : 'present');
sudoer: s'il est défini sur vrai, l'utilisateur obtiendra des privilèges sudo (voir aussi la variable usermake_sudoer) ;
system: indique si l'utilisateur devrait être un utilisateur système (avec un numéro UID bas et une connexion désactivée) ;
upload_my_key: s'il faut télécharger votre clé SSH locale sur l'hôte cible.

Tous ces valeurs, si définies, remplaceront les valeurs par défaut définies dans la section des variables de rôle ci-dessous.

Ce que ce rôle ne peut pas faire ?

Il ne peut pas ajouter des utilisateurs à de nouveaux groupes, il écrasera les groupes de l'utilisateur avec la liste donnée de groupes.

Exigences

Ce rôle n'a pas d'exigence spécifique.

Variables de rôle

Tous les noms de variables utilisés dans ce rôle sont préfixés par usermake_.

usermake_home_base_dir: vous permet de remplacer le chemin du répertoire où les maisons des utilisateurs sont créées (par défaut : /home);
usermake_remove: indique s'il faut supprimer le répertoire de la maison des utilisateurs lorsqu'ils sont supprimés (par défaut : faux);
usermake_ssh_key_create: indique s'il faut créer une paire de clés SSH pour les nouveaux utilisateurs par défaut (par défaut : vrai);
usermake_ssh_key_download: indique s'il faut télécharger les clés SSH des utilisateurs créés localement;
usermake_ssh_key_download_dir: le répertoire où stocker les clés publiques SSH téléchargées (par défaut : {{ playbook_dir }}/collected-keys);
usermake_ssh_key_download_dir_mode: le mode du répertoire où stocker les clés publiques SSH téléchargées (par défaut : 0750);
usermake_ssh_key_passphrase: les phrases de passe par défaut pour crypter les clés privées SSH. Il n'est pas recommandé de s'y fier. Vous devriez fournir les phrases de passe par d'autres moyens. (par défaut : omettre [pas de phrase de passe]);
usermake_sudoer: indique si les utilisateurs créés doivent être des sudoers par défaut (par défaut : faux); Note : avant d'accorder des privilèges élevés à un utilisateur avec ceci, considérez que les distributions fournissent un paquet sudo qui définit un groupe sudo ou sudoers qui accorde déjà des privilèges à ses membres. Le mécanisme actuel est plus destiné à préparer des utilisateurs à privilèges élevés sur des images disque pour permettre une configuration et un approvisionnement faciles. Pas pour gérer des privilèges d'utilisateur ou d'application fins;
usermake_sudoer_dir: répertoire sur les machines cibles où placer les fichiers de règles sudoer (par défaut : /etc/sudoers.d);
usermake_system: indique si les utilisateurs créés doivent être des utilisateurs système par défaut (par défaut : faux);
usermake_upload_ssh_key_to_target: indique s'il faut télécharger la clé publique SSH de l'utilisateur local sur l'hôte cible. Utile si vous prévoyez d'effectuer des tâches en tant qu'utilisateur dans les tâches ou rôles suivants de votre playbook (par défaut : vrai);
usermake_upload_ssh_key_file: lorsque usermake_upload_ssh_key_to_target ou la valeur de l'élément de l'utilisateur upload_my_key est true, indique le fichier à partir duquel lire la clé publique à télécharger (par défaut : ~/.ssh/id_rsa.pub);
usermake_user_groups: les groupes à attribuer aux utilisateurs créés par défaut (par défaut : omettre);
usermake_users: la liste des utilisateurs à créer, définie avec des éléments comme décrit ci-dessus (par défaut : []);

Dépendances

Ce rôle n'a pas de dépendances.

Exemple de Playbook

Création de quelques utilisateurs :

- hosts: serveurs
  roles:
     - role: cans.user-make
       usermake_users:
         - name: "alice"
           groups: "sudo,adm"
           system: "non"
           ssh_key_create: "oui"
         - name: "bob"
           gecos: "Bob pas d'éponge,,,"
           system: "oui"
           ssh_key_create: true

Suppression de quelques utilisateurs :

- hosts: serveurs
  roles:
    - role: cans.user-make
      usermake_users:
        - name: "alice"
          state: "absent"
          remove: true  # Supprimer tous les fichiers de l'utilisateur
        - name: "bob"
          state: "absent"

Vous voudrez peut-être également jeter un œil aux tests trouvés dans tests/test.yml pour de nombreux autres exemples d'utilisation (espérons-le exhaustifs) de ce rôle.