Ansible: avere sudo ma nessuna radice

Question

Mi piacerebbe usare Ansible per gestire la configurazione di un nostro cluster Hadoop (con Red Hat in esecuzione).

Ho accesso sudo e posso manualmente ssh nei nodi per eseguire comandi. Tuttavia, sto riscontrando problemi quando cerco di eseguire i moduli Ansible per eseguire le stesse attività. Anche se ho l'accesso sudo, non posso diventare root. Quando provo ad eseguire script ansible che richiedono privilegi elevati, ottengo un errore come questo:

Siamo spiacenti, awoolford utente non è autorizzato a eseguire '/ bin/bash -c eco DIVENTARE-SUCCESSO [...]/usr/bin/python /tmp/ansible-tmp-1446662360.01-231435525506280/copy 'as awoolford su [some_hadoop_node].

Guardando attraverso il documentation, ho pensato che la proprietà become_allow_same_user potrebbe risolvere questo problema, e così ho aggiunto il testo seguente ansible.cfg:

[privilege_escalation] 
become_allow_same_user=yes 

Purtroppo, non ha funzionato.

Questo post suggerisce che ho bisogno di autorizzazioni per sudo /bin/sh (o qualche altra shell). Sfortunatamente, questo non è possibile per motivi di sicurezza. Ecco un frammento da /etc/sudoers:

root   ALL=(ALL) ALL 
awoolford  ALL=(ALL) ALL, !SU, !SHELLS, !RESTRICT 

Può ansible lavorare in un ambiente come questo? In tal caso, cosa sto sbagliando?

Answer 1

Bene, semplicemente non è possibile eseguire /bin/sh o /bin/bash come mostra /etc/sudoers. Quello che potresti fare è cambiare la shell predefinita di ansible in qualcos'altro (variabile executable in ansible.conf).

Dal momento che la vostra politica sudo permette tutto di default (non sembra davvero sicuro per me), e suppongo ansible aspetta una shell sh-compatibile, come un hack molto sporca è possibile copiare /bin/bash a qualche altro percorso/nome e imposta la variabile executable di conseguenza (non testata).

Answer 2

Nel file playbook (some.yml), impostare

runthisplaybook.yml

--- 
- hosts: label_which_will_work_on_some_servers 
    sudo: yes 

    roles: 
    - some_role_i_want_to_run 

successiva, nel ruolo // compiti/main.yml per l'azione che si deve eseguito come sudo .. usare qualcosa come become_user (dove common_user è una variabile definita in default di qualche ruolo \ file main.yml come common_user: "this_user_can_sudo":

- name: Run chkconfig on init script 
    command: "sudo -u root /sbin/chkconfig --add tomcat" 

# Set execute permission on run_jmeter_test.sh 
- name: Set execute permission on run_jmeter_test.sh 
    command: "chmod -R 755 {{ jmeter_perf_tests_results }}" 
    become_user: "{{ common_user }}" 

# OR Set execute permission on run_jmeter_test.sh 
- name: Set execute permission on run_jmeter_test.sh 
    command: "sudo -u firstuser sudo -u seconduser chmod -R 755 {{ jmeter_perf_tests_results }}" 
    become_user: "{{ common_user }}" 

# OR Set execute permission on run_jmeter_test.sh 
- name: Set execute permission on run_jmeter_test.sh 
    command: "chmod -R 755 {{ jmeter_perf_tests_results }}" 
    become_user: "{{ common_user }}" 

PS: Durante l'esecuzione ansible-playbook,

ansible-playbook runthisplaybook.yml --sudo-user = this_user_can_sudo host -i.yml -u user_which_will_connect_from_source_machine --private-chiave $ {} DEPLOYER_KEY_FILE --extra-vars "target_svr_type = $ {} server_type deploy_environment = $ {} DEPLOY_ENVIRONMENT ansible_user = $ {} ANSIBLE_USER"

Answer 3

Penso che ora sudo: yes è depricated e sostituirlo con become: yes

--- 
- hosts: servers_on_which_you_want_to_run 
    become: yes 

    roles: 
    - some_role 

la soluzione smiplist è solo creare un ansible.cfg nella directory playbook con il seguente contenuto, se non accetta root utente:

[defaults] 
sudo_user  = UsernameToWhichYouWantToUse 

Spero che questo risolva il tuo problema.