¿Cómo cambiar un usuario por tarea o conjunto de tareas?

Un tema recurrente que está en mis libros de jugadas ansibles es que a menudo debo ejecutar un comando con privilegios de sudo ( sudo: yes) porque me gustaría hacerlo para un determinado usuario. Idealmente, preferiría usar sudo para cambiar a ese usuario y ejecutar los comandos normalmente. Porque entonces no tendré que limpiar mis comandos de publicación habituales, como los directorios de chowning. Aquí hay un fragmento de uno de mis libros de jugadas:

- 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, podría ejecutar comandos o conjuntos de comandos como un usuario diferente, incluso si requiere sudo para su para ese usuario.

Con Ansible 1.9 o posterior

Usos del ansible become, become_usery become_methoddirectivas para lograr una escalada de privilegios. Puede aplicarlos a un juego completo o libro de jugadas, configurarlos en un libro de jugadas incluido o configurarlos para una tarea en particular.

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

Puede usar become_withpara especificar cómo se logra la escalada de privilegios, siendo la predeterminada sudo.

La directiva está vigente para el alcance del bloque en el que se usa ( ejemplos ).

Consulte Hosts and Users para ver algunos ejemplos adicionales y Become (Privilege Escalation) para obtener documentación más detallada.

Además del alcance de la tarea becomey las become_userdirectivas, Ansible 1.9 agregó algunas nuevas variables y opciones de línea de comando para establecer estos valores para la duración de una jugada en ausencia de directivas explícitas:

• Opciones de línea de comando para las directivas become/ equivalentes become_user.
• Variables específicas de conexión que se pueden establecer por host o grupo.

A partir de Ansible 2.0.2.0, cuanto más viejo sudo/ sudo_usersintaxis describe a continuación sigue funcionando, pero los estados de notificación de desaprobación, "Esta característica se quitará en una versión futura."

Sintaxis anterior, obsoleta a partir de Ansible 1.9 y programada para su eliminación:

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

En Ansible 2.x, puede usar el blockgrupo de tareas:

- 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

En Ansible> 1.4 en realidad puede especificar un usuario remoto en el nivel de tarea que debería permitirle iniciar sesión como ese usuario y ejecutar ese comando sin recurrir a sudo. Si no puede iniciar sesión como ese usuario, la solución sudo_user también funcionará.

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

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

Una solución es usar la includedeclaración con remote_uservar (describir allí: http://docs.ansible.com/playbooks_roles.html ) pero debe hacerse en el libro de jugadas en lugar del nivel de tarea.

Puede especificar become_methodanular el método predeterminado establecido en ansible.cfg(si lo hay), y que se puede establecer en uno de 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 }}'

Debe mostrar

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