Jak zmienić użytkownika na zadanie lub zestaw zadań?

Powtarzającym się motywem w moich playbookach jest to, że często muszę wykonać polecenie z uprawnieniami sudo ( sudo: yes), ponieważ chciałbym to zrobić dla określonego użytkownika. W idealnym przypadku wolałbym użyć sudo, aby przełączyć się na tego użytkownika i normalnie wykonywać polecenia. Ponieważ wtedy nie będę musiał czyścić moich zwykłych poleceń pocztowych, takich jak chowning katalogów. Oto fragment jednego z moich poradników:

- 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

W idealnym przypadku mógłbym uruchamiać polecenia lub zestawy poleceń jako inny użytkownik, nawet jeśli wymaga to od sudo su dla tego użytkownika.

Z Ansible 1.9 lub nowszym

Ansibl używa become, become_user, i become_methoddyrektywy, aby osiągnąć przekroczenia uprawnień. Możesz zastosować je do całej gry lub poradnika, ustawić je w dołączonym poradniku lub ustawić je do określonego zadania.

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

Możesz użyć, become_withaby określić, w jaki sposób zostanie osiągnięta eskalacja uprawnień, domyślnie jest to sudo.

Dyrektywa obowiązuje dla zakresu bloku, w którym jest używana ( przykłady ).

Aby zapoznać się z dodatkowymi przykładami, zobacz Hosty i użytkownicy oraz Zostań (eskalacja uprawnień), aby uzyskać bardziej szczegółową dokumentację.

Oprócz dyrektyw o zakresie zadań becomei become_userdyrektyw, Ansible 1.9 dodał kilka nowych zmiennych i opcji wiersza poleceń, aby ustawić te wartości na czas trwania gry w przypadku braku wyraźnych dyrektyw:

• Opcje wiersza poleceń dla odpowiedników become/ become_userdyrektyw.
• Zmienne specyficzne dla połączenia, które można ustawić dla hosta lub grupy.

Począwszy od Ansible 2.0.2.0, starsza składnia sudo/ sudo_useropisana poniżej nadal działa, ale w powiadomieniu o wycofaniu jest napisane: „Ta funkcja zostanie usunięta w przyszłej wersji”.

Poprzednia składnia, przestarzała od wersji Ansible 1.9 i przeznaczona do usunięcia:

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

W Ansible 2.x możesz użyć blockdla grupy zadań:

- 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

W Ansible> 1.4 możesz faktycznie określić zdalnego użytkownika na poziomie zadania, który powinien pozwolić ci zalogować się jako ten użytkownik i wykonać to polecenie bez uciekania się do sudo. Jeśli nie możesz zalogować się jako ten użytkownik, rozwiązanie sudo_user również będzie działać.

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

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

Rozwiązaniem jest użycie includeinstrukcji z remote_uservar (opisz je tam: http://docs.ansible.com/playbooks_roles.html ), ale należy to zrobić na poziomie podręcznika zamiast zadania.

Możesz określić, become_methodaby zastąpić domyślną metodę ustawioną w ansible.cfg(jeśli istnieje), a którą można ustawić na jedną z 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 }}'

Powinien wyświetlić

TASK [my-task : my secret identity] ************************************************************
ok: [my_ansible_server] => {
    "msg": "some_user"
}