Bonjour à tous,
 
Je me suis en train de me faire des noeuds au cerveau concernant un souci de droits sur le .ssh/authorized_keys.
 
J'ai mon script ansible qui fonctionne parfaitement pour la création de mes utilisateurs sur mes serveurs et je souhaite simplement modifier les droits du /home/user , du /home/user/.ssh et enfin du /home/user.ssh/authorized_keys car ils ne sont pas corrects par défaut.
Je n'arrive pas à trouver où est le souci.
 
---
- hosts: all
  become: true
  tasks:
  - name: Creation groupe dev
    group:
      name: dev
      state: present
 
  - name: Creation des utilisateurs
    user:
      name: "{{ item.path }}"
      group: dev
      state: present
      password: "{{ lookup('password', '/dev/null') |password_hash('sha512') }}"
      update_password: on_create
    with_filetree: xx_pub_keys/
 
  - name: copie des clés SSH
    authorized_key:
      user: "{{ item.path }}"
      key: "{{ lookup('file', 'xx_pub_keys/' + item.path ) }}"
      state: present
    with_filetree: xx_pub_keys/
 
  - name: droits repertoires
    command:
      chmod go-w /home/{{ user.path }} && \
      chmod 700 /home/{{ user.path }} && \
      chmod 644 /home/{{ user.path }}/.ssh/authorized_keys
 
  - name: "Suppression des users eventuels"
    user:
      name: "{{ item.path }}"
      state: absent
      remove: true
    with_filetree: xx_pub_remove/
 
  - name: Allow admin users to sudo without a password
    lineinfile:
      dest: "/etc/sudoers"
      state: "present"
      regexp: "^%admin"
      line: "%admin ALL=(ALL) NOPASSWD: ALL"
 
  - name: restart sshd
    service: name=ssh state=restarted
...
 
 
J'ai donc essayé dans la partie "droits repertoires" user.path, item.path, item tout court avec with_items ...  
Je n'ai plus d'idée ...
 
Bref, je suis preneur de toute correction.
 
Merci d'avance

il existe le module "file" pour gérer proprement tes owners/groups/mode des fichiers et répertoires : https://docs.ansible.com/ansible/la [...] odule.html
 
si tu remplaces ton "droits repertoires" par ceci ca passe ?

Merci phraide pour ta réponse.
 
Malheureusement, il en fait rien. Je n'ai pas d'erreur mais aucun changement:
 
TASK [droits home]  
task path: /home/admin/playbook/user_xxx.yml:25
 
TASK [droits .ssh]  
task path: /home/admin/playbook/user_xxx.yml:30
 
TASK [droits auth key]  
task path: /home/admin/playbook/user_xxx.yml:35

Pardon phraid
... Faute de frappe de ma part. Ca fonctionne parfaitement.
 
Merci

Tu peux réduire ces lignes d’astériques, s’il te plaît (boutons ou ) ? Ça flingue la mise en page du forum.

Ah je vois que ça parle d'Ansible. Ça semble très à la mode en ce moment, mais j'ai jamais compris à quoi ça servait ...
Ce qui m'inquiète c'est que je serai peut-être amené à travailler dessus...  

C'est un "configuration manager".
Comme puppet, chef...

Ah ok, ça reste un peu vague pour moi.
Sur une mission où j'ai été, il y avait du Jenkins+ansible. Ça ressemblait à des scripts shell, mais du coup pourquoi ne pas faire en shell directement ?

Libre à toi de le faire en shell si tu l'entends. Mais ce sera sans doute plus long, moins portable, et remplis de bug, et surtout, il n'y a que toi qui saura l'utiliser.
 
Ansible c'est du python, qui est beaucoup plus approprié pour écrire du code que Bash (ce qui n'est pas très difficile), tu t'en sers en écrivant des fichiers de configurations en yaml (processed avec jenja2), pour "définir" l'état du système que tu souhaite.
 
Il existe pleins d'alternatives (et pour avoir bien exploré ansible et même crée des plugin pour, je conseillerais presque toujours à une entreprise de choisir puppet), et tu peux même créer ta propre solution. L'intérêt de l'adoption de cette techno ou d'une autre c'est que si tu connais ansible, tu peux tout de suite être efficace sur un projet (tout le monde parle le même "language" ).

Oullàààà.
Merci pour ta réponse, mais je crois qu'on est pas sur la même longueur d'onde...

Plus long, moins portable et remplis de bug, et que je sois le seul à savoir faire du shell. Alors là ... permet moi d'en douter très sérieusement  

Le shell ça existe depuis de longue date, c'est connu de toute personne qui travaille dans l'informatique, c'est justement hyper portable, et c'est pas prêt de disparaître.
Les bugs, ça ne dépend que de celui qui code.

Ce ne serait pas un troll ton commentaire ?

Si Ansible c'est du python, pourquoi ne pas utiliser Python directement alors ?

Yaml ? Connais à peine. Perso je ne jure que par le CSV
jenja2 ? Connais pas

En tout cas sur ladite mission, je ne comprenais rien à Ansible ...

c'est juste développé en python ... 95% des users ansible ne vont pas en lire ou écrire une ligne, ni meme de shell ... par contre 100% des users vont bouffer du yaml/jinja2

Donne moi n'importe quel code en bash qui fait la meme chose que ansible, et je vais mettre plusieurs heures à comprendre le code et à appliquer des changements. Donne un playbook ansible à n'importe qui connaissant ansible, il va en beaucoup moins de temps, d'ailleurs, donne une config ansible à n'importe qui, il devrait déja comprendre pas mal de ce qu'elle fait.
 
Tu n'es pas le seul à faire du shell, mais tu es le seul à écrire ton code, la facon avec laquelle tu l'écris, les conventions que tu utilise, les outils que tu utilise et qui doivent être installés sur ta machine (qui ne l'est peut-etre pas sur la machine des autres). Une "configuration" est "censée" palier à ce problèmes, ou au moins le réduire.
 
Je maintiens ce que j'ai dis. Essaye de prendre une config ansible un peu longue complexe et de la faire en bash, tu vas basiquement devoir développer un config manager en bash. Bon courage, et oui ca aura pleins de bug et sera moins portable.
 
Alors oui, un apt-get install via ssh, c'est aussi simple en bash, mais dès que la complexité des operations que tu vas effectuer va augmenter, tu voudras utiliser un config manager.

En résumé, faut voir ansible ou autres outils similaire comme un outil "haut niveau" alors que tes scripts (que ça soit python ou bash) serait considéré comme du bas niveau.
 
Framework, abstraction, etc...
 
Tu pourrais avoir les mêmes résultats en assembleur, mais à quel prix...

 
Bien résumé    
 

 
Désolé je m'incruste un peu mais j'aimerais bien savoir la réflexion qui te pousse à dire ça, pour moi ce sont 2 outils différents voir complémentaires. Ne serait ce que par son agent, puppet sert à du contrôle de conformité / corriger les écarts / etc... alors qu'ansible à plus une vocation de déploiement et de configuration...
 
Bref je serais intéressé par ton retour la dessus    
 

Merci, j'ai des progrès à faire dans mes explications
 

Tiens je ne pensais même pas à ca. Déja par la quantité de fonctionnalités disponible en utilisant puppet en rapport avec ansible, qui pour certaines ne vont pas être possibles à implémenter sous ansible à moins de rajouter de la complexité (dans la structure et le nombre de variables / tasks), diverger de l'utilisation normale/conseillée (template devenant "séquentiel", se servir de l'include de tasks comme d'un appel de fonction, utiliser les tags comme des paramètres), et sortir des best practices (e.g. se servir du tableau de priorité pour la déclaration des variables), ou à moins d'écrire un plugin/module pour arriver à tes fins.
 
Exemple de feature mandatory que je n'ai pas été capable de reproduire chez ansible (sans mettre en péril la clareté/simplicité du code), la dépendance de rôles. Imaginons que tu aies 2 rôles, "web-server" et "mail-server", si l'un ou l'autre des rôle est utilisé pour cet host, tu souhaite utiliser aussi le rôle "tls". Tu peux faire ca simplement sous puppet.
 
Au dela de tout ça, les best practices ansible, e.g. l'utilisation de rôles pour rendre ton code scalable et plus clair (via par exemple le respect d'une convention de la hierarchie des fichier roles, tasks, hosts_vars) te force au final à recourir à des techniques qui complexifient et nuit à la lisibilité.
 
En finalité, je conseille en général la chose suivante:
Si tu souhaite (comme beaucoup) utiliser juste quelques playbooks autonomes simples, ansible est une très bonne option. Si en revanche tu souhaite une config scalable, pouvant gérer plusieurs types de machines avec différents besoins, en te servant de définitions de rôles, bref si l'échelle de ton projet est un peu plus importante, utilise puppet, en plus c'est le standard industriel et c'est rock-solide.

Merci pour la réponse, au final on est d'accord sur le fond, c'est juste que, pour moi, il s'agit de 2 solutions complémentaires et non qui ont vocation à remplacer l'une ou l'autre:
 
Exemple pris de mon ancien taff:  Pour utiliser puppet, tu as besoin de faire descendre l'agent sur ton nouveau serveur donc :
- Déploiement de la VM par ansible suivant des roles/playbook ou autres
- Installation des "core packet" (puppet agent, rhel satellite etc...) via ansible également
- Puis par la suite, configuration "OS" du serveur par puppet (sudoers, dns etc...) et suvi des écarts de conf si il y en a
 
C'est pour ca que je t'ai demandé ton point de vue car je ne vois pas l'un fonctionner sans l'autre pour de l'automatisation voir de l'IAC

Ah je vois, donc tu te sers d'ansible pour bootstrap l'instance en fait.
Oui c'est un peu le chaînons manquant entre provisionner et config manager.
 
En général même pas besoin d'utiliser ansible pour ça, juste un fichier kickstart généré via un template et tu boot en pxe pour auto-installer l'os. Le fichier kickstart se charge du post-install tout ça avant même le premier boot du système.
Si tu as besoin de modifier pas mal de chose avant le premier boot ca peut parfois être un peu moins évident (e.g. si tu rebuild le initrd ou le kernel sur le système chrooté), mais tu y arrive tout de même assez simplement avec quelques lignes de bash dans le @post-install du kickstart (j'assume que tu es sous rhel/centos vus que tu parle de satellite).
 
Sinon des personnes utilisent cloud-init pour se charger de ce "gap".

Pas forcement pour du bootstrap, on va dire qu'Ansible sert complétement d'outil de déploiement de masse (indépendamment de l'OS) la ou puppet tiens "simplement" le rôle de config manager.
 
Ex : du cloud privé, tu utilises non pas Ansible comme kickstart mais comme outil de déploiement et de pilotage de ta couche de virtu. (création de la VM, push du template, assignation de l'IP et installation de base) Puppet viens vraiment ici en phase de post install et de supervision du run.
 
Je connais pas cloud-init, je vais regarder ca !

Et Chef, Salt?