Ansible 1.9.1 "devenir" et sudo problème

Je suis en train de lancer un extrêmement simple playbook pour tester un nouveau Ansible de l'installation.

Lors de l'utilisation de la "nouvelle" Ansible de remontée d'options de configuration dans mon ansible.fichier cfg:

[defaults]

host_key_checking=false

log_path=./logs/ansible.log
executable=/bin/bash

#callback_plugins=./lib/callback_plugins

######

[privilege_escalation]
become=True
become_method='sudo'
become_user='tstuser01'
become_ask_pass=False

[ssh_connection]
scp_if_ssh=True

J'obtiens l'erreur suivante:

fatal: [webserver1.local] => Internal Error: this module does not support running commands via 'sudo'

FATAL: all hosts have already failed -- aborting

La playbook est également très simple:

# Checks the hosts provisioned by midrange
---
- name: Test su connecting as current user
  hosts: all
  gather_facts: no
  tasks:
  - name: "sudo to configued user -- tstuser01"
    #action: ping
    command: /usr/bin/whoami

Je ne suis pas sûr si il y a quelque chose de cassé dans Ansible 1.9.1 ou si je fais quelque chose de mal. Sûrement la 'commande' module dans Ansible permet d'exécuter des commandes en tant que sudo.

OriginalL'auteur ilium007 | 2015-04-30

29

Que le problème vient de la configuration, j'ai aussi pris il comme un exemple et a obtenu le même problème. Après avoir joué un certain temps j'ai remarqué que les œuvres suivantes:

1) obsolète sudo:
```
---
- hosts: all
  sudo: yes
  gather_facts: no
  tasks:
  - name: "sudo to root"
    command: /usr/bin/whoami
```
2) nouvelle become
```
---
- hosts: all
  become: yes
  become_method: sudo
  gather_facts: no
  tasks:
  - name: "sudo to root"
    command: /usr/bin/whoami
```
3) à l'aide d'ansible.cfg:
```
[privilege_escalation]
become = yes
become_method = sudo
```
et puis, dans un playbook:
```
---
- hosts: all
  gather_facts: no
  tasks:
  - name: "sudo to root"
    command: /usr/bin/whoami
```
puisque vous "devient" tstuser01 (pas une racine comme moi), merci de vous jouer un peu, probablement le nom d'utilisateur ne doit pas être cité:
```
  become_user = tstuser01
```
au moins c'est la façon dont je définis remote_user dans ansible.cfg et il fonctionne... Mon problème résolu, espère que la vôtre trop

Le problème est certainement la citations sur la become_user et become_method options dans ansible.cfg. Le rpm exemple tort contient des citations; enlever les guillemets amène à travailler.
J'ai utilisé ce "devenir: oui become_user: racine become_method: sudo", Mais encore de montrer que gênant dépréciation d'avertissement...

OriginalL'auteur Maxym
0

Je pense que vous devriez utiliser le sudo directive dans les armées de la section de sorte que des tâches peuvent s'exécuter avec des privilèges sudo, sauf si vous explicitement spécifié sudo:no dans une tâche.

Voici votre playbook que j'ai modifié pour utiliser sudo directive.
```
# Checks the hosts provisioned by midrange
---
- hosts: all
  sudo: yes
  gather_facts: no
  tasks:
    - name: "sudo to configued user -- tstuser01"
      command: /usr/bin/whoami
```
À partir de ce que je lis il se rapporte à l'exécution de Ansible sur une RHEL 6 et une vieille version d'OpenSSH qui ne prend pas en charge ControlPersist. Je suis toujours en train d'enquêter. Je vais essayer cela demain. Il semble il y avait sudo options de configuration obsolète dans Ansible 1.9.0 et sur.
S'avère que nous avons OpenSSL patché avec le ControlPersist fonctionnalité.
La question relative à la "nouvelle" Ansible "devenir" de la syntaxe. Les anciens " sudo: oui fonctionne très bien.
-R SU_USER, --su-user=SU_USER exécuter des opérations avec la ligue en tant que cet utilisateur (par défaut=racine) (obsolète, utilisez le devenir),- s, --sudo exécuter des opérations avec sudo (nopasswd) (obsolète, utilisez le devenir)

OriginalL'auteur James Oguya

Vous devez vous connecter pour publier un commentaire.