Ein wiederkehrendes Thema, das in meinen normalen Spielbüchern vorkommt, ist, dass ich häufig einen Befehl mit Sudo-Berechtigungen ausführen muss (Sudo: yes
) weil ich es für einen bestimmten Benutzer tun möchte. Idealerweise würde ich lieber Sudo verwenden, um zu diesem Benutzer zu wechseln und die Befehle normal auszuführen. Denn dann muss ich nicht meine üblichen Post-Befehle ausführen, wie zum Beispiel das Aufräumen von Verzeichnissen. Hier ist ein Ausschnitt aus einem meiner Spielbücher:
- 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
Idealerweise könnte ich Befehle oder Befehlssätze als ein anderer Benutzer ausführen, selbst wenn Sudo für diesen Benutzer erforderlich ist.
Ansible benutzt den become
, become_user
, und become_method
Anweisungen, um die Eskalation von Berechtigungen zu erreichen. Sie können sie auf ein ganzes Spiel oder ein ganzes Spielbuch anwenden, sie in einem enthaltenen Spielbuch festlegen oder sie für eine bestimmte Aufgabe festlegen.
- name: checkout repo
git: repo=https://github.com/some/repo.git version=master dest={{ dst }}
become: yes
become_user: some_user
Sie können become_with
, um anzugeben, wie die Rechteerweiterung erreicht wird. Der Standardwert ist Sudo
.
Die Direktive gilt für den Umfang des Blocks, in dem sie verwendet wird ( Beispiele ).
Siehe Hosts und Benutzer für einige zusätzliche Beispiele und Werden (Rechteerweiterung) für eine detailliertere Dokumentation.
Zusätzlich zu den Aufgabenbereichen become
und become_user
Direktiven, Ansible 1.9 fügte einige neue Variablen und Befehlszeilenoptionen hinzu, um diese Werte für die Dauer eines Spiels ohne explizite Direktiven festzulegen:
become
/become_user
Anweisungen.Ab Ansible 2.0.2.0 ist das ältere Sudo
/Sudo_user
Die unten beschriebene Syntax funktioniert immer noch, aber in der Hinweisnachricht wird angegeben, dass diese Funktion in einer zukünftigen Version entfernt wird.
- name: checkout repo
git: repo=https://github.com/some/repo.git version=master dest={{ dst }}
Sudo: yes
Sudo_user: some_user
In Ansible 2.x können Sie block
für eine Gruppe von Aufgaben verwenden:
- 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
Unter Ansible> 1.4 können Sie tatsächlich einen Remote-Benutzer auf Task-Ebene angeben, mit dem Sie sich als dieser Benutzer anmelden und diesen Befehl ausführen können, ohne auf Sudo zurückzugreifen. Wenn Sie sich nicht als dieser Benutzer anmelden können, funktioniert auch die Sudo_user-Lösung.
---
- hosts: webservers
remote_user: root
tasks:
- name: test connection
ping:
remote_user: yourname
Siehe http://docs.ansible.com/playbooks_intro.html#hosts-and-users
Eine Lösung besteht darin, die include
-Anweisung mit remote_user
Var zu verwenden (dort beschreiben: http://docs.ansible.com/playbooks_roles.html ), dies muss jedoch geschehen auf Playbook statt auf Task-Ebene erfolgen.
Sie können become_method
Angeben, um die in ansible.cfg
Festgelegte Standardmethode (falls vorhanden) zu überschreiben, und diese kann auf eine von Sudo, su, pbrun, pfexec, doas, dzdo, ksu
Festgelegt werden.
- 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 }}'
Sollte angezeigt werden
TASK [my-task : my secret identity] ************************************************************
ok: [my_ansible_server] => {
"msg": "some_user"
}