Come cambiare un utente per attività o set di attività?


160

Un tema ricorrente presente nei miei libri di risposta è che spesso devo eseguire un comando con i privilegi di sudo ( sudo: yes) perché mi piacerebbe farlo per un determinato utente. Idealmente preferirei usare sudo per passare a quell'utente ed eseguire i comandi normalmente. Perché allora non dovrò fare i miei soliti comandi post come ripulire le directory di chowning. Ecco uno snippet da uno dei miei playbook:

- name: checkout repo
  git: repo=https://github.com/some/repo.git version=master dest={{ dst }}
  sudo: yes
- name: change perms
  file: dest={{ dst }} state=directory mode=0755 owner=some_user
  sudo: yes

Idealmente, potrei eseguire comandi o serie di comandi come un utente diverso anche se richiede sudo per su per quell'utente.

Risposte:


241

Con Ansible 1.9 o successivo

Usi il ansible become, become_user, e become_methoddirettive per ottenere privilegi. Puoi applicarli a un intero play o playbook, impostarli in un playbook incluso o impostarli per un'attività specifica.

- name: checkout repo
  git: repo=https://github.com/some/repo.git version=master dest={{ dst }}
  become: yes
  become_user: some_user

È possibile utilizzare become_withper specificare come ottenere l'escalation dei privilegi, l'impostazione predefinita sudo.

La direttiva è in vigore per l'ambito del blocco in cui viene utilizzata ( esempi ).

Consulta Host e utenti per alcuni esempi aggiuntivi e Diventa (escalazione di privilegi) per una documentazione più dettagliata.

Oltre all'ambito delle attività becomee alle become_userdirettive, Ansible 1.9 ha aggiunto alcune nuove variabili e opzioni della riga di comando per impostare questi valori per la durata di un gioco in assenza di direttive esplicite:

A partire da Ansible 2.0.2.0, la vecchia sudo/ sudo_usersintassi descritta di seguito funziona ancora, ma l'avviso di deprecazione indica "Questa funzione verrà rimossa in una versione futura".


Sintassi precedente, obsoleta a partire da Ansible 1.9 e pianificata per la rimozione:

- name: checkout repo
  git: repo=https://github.com/some/repo.git version=master dest={{ dst }}
  sudo: yes
  sudo_user: some_user

4
Per specificare sudo_user da una variabile, utilizzare le virgolette attorno al modello di variabile, in questo modo - sudo_user: "{{ ansible_ssh_user }}"altrimenti si otterrebbe un errore di sintassi yaml.
— Sumeet Pareek,

Buona pesca. Stavo cercando di abbinare il più possibile la formulazione del problema da parte dell'OP, ma sono d'accordo che l'uso dell'interpolazione variabile sarà la scelta più comune.
— Brett,

5
Da Ansible 1.9, è il becomesistema invece di "sudo *".
— AndiDog,

2
La sintassi 1.9+ per "diventa" è corretta. Potresti anche voler controllare "diventare_metodo", poiché "su" potrebbe talvolta essere migliore del "sudo" predefinito, a seconda della configurazione del tuo sistema.
— ElementalStorm,

New Ansible variables and command line options are added to set these values for the duration of a play. @Brett significa che le attività successive verranno eseguite da questo utente some_usere non dall'utente originale remote_userutilizzato per connettersi all'host, è corretto?
— JohnnyQ,

43

In Ansible 2.x, è possibile utilizzare il blockgruppo per attività:

- block:
    - name: checkout repo
      git:
        repo: https://github.com/some/repo.git
        version: master
        dest: "{{ dst }}"
    - name: change perms
      file:
      dest: "{{ dst }}"
      state: directory
      mode: 0755
      owner: some_user
  become: yes
  become_user: some user

26

In Ansible> 1.4 puoi effettivamente specificare un utente remoto a livello di attività che dovrebbe permetterti di accedere come quell'utente ed eseguire quel comando senza ricorrere a sudo. Se non riesci ad accedere come quell'utente, funzionerà anche la soluzione sudo_user.

---
- hosts: webservers
  remote_user: root
  tasks:
    - name: test connection
      ping:
      remote_user: yourname

Vedi http://docs.ansible.com/playbooks_intro.html#hosts-and-users


Questa è la soluzione migliore per le situazioni in cui non hai i privilegi di sudo
— Darrel Holt,

7

Una soluzione consiste nell'utilizzare la includedichiarazione con remote_uservar (descriverla qui: http://docs.ansible.com/playbooks_roles.html ) ma deve essere eseguita a playbook anziché a livello di attività.


Questa non è una buona soluzione per il caso d'uso sopra. Tuttavia non ero a conoscenza di questa soluzione per molto tempo. Pensavo di poter includere solo ruoli.
— ArjanSchouten,

1

È possibile specificare become_methoddi sovrascrivere il metodo predefinito impostato ansible.cfg(se presente) e che può essere impostato su uno dei sudo, su, pbrun, pfexec, doas, dzdo, ksu.

- name: I am confused
  command: 'whoami'
  become: true
  become_method: su
  become_user: some_user
  register: myidentity

- name: my secret identity
  debug:
    msg: '{{ myidentity.stdout }}'

Dovrebbe visualizzare

TASK [my-task : my secret identity] ************************************************************
ok: [my_ansible_server] => {
    "msg": "some_user"
}
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.