Définissez PATH équivalent à "sudo su-" en utilisant l'environnement d'Ansible

■ Qu'est-ce qu'Ansible?

• ** Caractéristiques d'Ansible **

• Un outil qui automatise la construction de serveurs sans agents. --SSH se connecte à la machine exécutant sshd et crée l'environnement.

• Ecrivez le fichier de configuration en YAML. Aucune connaissance en programmation (Ruby, Python, etc.) n'est requise. Il est plus facile que le chef de construire un serveur avec plusieurs à des dizaines d'unités.

• ** Préparer l'environnement ** Voir l'article précédent. Première étape d'Ansible

■ Présentation

À partir d'Ansible 1.9, «devenir» a été ajouté pour s'exécuter avec d'autres privilèges d'utilisateur (par exemple, les privilèges root).

Si vous voulez gérer un serveur dont l'accès direct est interdit en tant que root, vous devez vous connecter en tant qu'utilisateur général, puis utiliser sudo su- pour devenir root. Lors de l'exécution d'une commande avec devenir: ture dans Ansible, et lors de l'exécution d'une commande directement à partir de la ligne de commande après sudo su-, le résultat de l'exécution de la commande peut différer car le PATH de la variable d'environnement est différent. Oui, vous devez être prudent.

Jusqu'à présent, je l'ai utilisé sans prêter beaucoup d'attention à cette zone, donc la commande qui a été confirmée en exécutant directement la commande échouait parfois dans PlayBook, donc j'ai eu un petit problème, donc à propos de devenir et de la variable d'environnement PATH, Je l'ai vérifié à nouveau.

Point de trébuchement

• C'était " devenir: vrai ≠ sudo su -".
• On ne sait pas comment exécuter diverses commandes dans l'état sudo su -.

Le point de vue d'Ansible Honke

J'ai enquêté sur les problèmes sur GitHub, le site officiel d'Ansible.

Site officiel d'Ansible (lien)

Only one method may be enabled per host

Methods cannot be chained. You cannot use sudo /bin/su - to become a user, you need to have privileges to run the command as that user in sudo or be able to su directly to it.

Traduction gratuite:

sudo et su ne peuvent pas être utilisés en même temps, donc si vous voulez sudo su -, veuillez exécuter la commande directement.

Ansible GitHub issues Il semble que la discussion au sein de la famille principale n'ait pas abouti (le statut reste ouvert). 　　GitHub issues#12686

■ Vérification du fonctionnement

Tout d'abord, j'ai étudié à quoi ressemblerait le PATH. Environnement d'enquête: Amazon Linux AMI 2016.03

remote_user: ec2-user

1.　become: false（ec2-user） 　　/usr/local/bin:/bin:/usr/bin:/opt/aws/bin 2.　become: true（root） 　　/sbin:/bin:/usr/sbin:/usr/bin 3.　lookup('pipe', 'echo $PATH') 　　/usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin: 　　/sbin:/opt/aws/bin:/home/ec2-user/.local/bin:/home/ec2-user/bin 4.　lookup('env', 'PATH') 　　/usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin: 　　/sbin:/opt/aws/bin:/home/ec2-user/.local/bin:/home/ec2-user/bin 5.　ec2-user 　　/usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin: 　　/sbin:/opt/aws/bin:/home/ec2-user/.local/bin:/home/ec2-user/bin 6.　sudo su - 　　/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin: 　　/opt/aws/bin:/root/bin 7.　sudo su 　　/sbin:/bin:/usr/sbin:/usr/bin:/opt/aws/bin

C'est magnifiquement disjoint ^^;

■ Définissez le PATH équivalent à "sudo su-"

Une recherche Google vous montrera comment charger .bashrc et .bash_profile avec la commande et le shell, mais cela rend difficile de garantir l'équivalence. Par conséquent, je vais vous présenter comment définir le PATH dans l'environnement.

** État avant le réglage **

Voyons d'abord ce qui se passe si rien n'est fait.

playbook.yml

- hosts: all
  remote_user: ec2-user
  tasks:
    - command: echo $PATH
      register: become_path
      become: true
      changed_when: False

    - name: become
      debug: var=become_path.stdout

    - command: echo $PATH
      register: not_become_path
      changed_when: False

    - name: not become
      debug: var=not_become_path.stdout

Je vais essayer.

$ ansible-playbook env_path.yml

PLAY [all] *********************************************************************

TASK [setup] *******************************************************************
ok: [target03]

TASK [command] *****************************************************************
ok: [target03]

TASK [become] ******************************************************************
ok: [target03] => {
    "become_path.stdout": "/sbin:/bin:/usr/sbin:/usr/bin"
}

TASK [command] *****************************************************************
ok: [target03]

TASK [not become] **************************************************************
ok: [target03] => {
    "not_become_path.stdout": "/usr/local/bin:/bin:/usr/bin:/opt/aws/bin"
}

PLAY RECAP *********************************************************************
target03                   : ok=5    changed=0    unreachable=0    failed=0

Utilisateur général PATH: / usr / local / bin: / bin: / usr / bin: / opt / aws / bin CHEMIN racine: / sbin: / bin: / usr / sbin: / usr / bin

Il est devenu. Il semble que vous ne soyez pas connecté.

Si vous utilisez la recherche, ce sera comme suit.

playbook.yml

---
- hosts: all
  remote_user: ec2-user
  vars:
    pipe_path: "{{ lookup('pipe', 'echo $PATH') }}"
    env_path: "{{ lookup('env', 'PATH') }}"
  tasks:
    - name: pipe path
      debug: msg={{ pipe_path }}

    - name: env path
      debug: msg={{ env_path }}

Le résultat de l'exécution lors de l'utilisation de la recherche est le suivant.

$ ansible-playbook playbook.yml

PLAY [all] *********************************************************************

TASK [setup] *******************************************************************
ok: [target01]

TASK [pipe path]] **************************************************************
ok: [target01] => {
    "msg": "/usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/sbin:/opt/aws/bin:/home/ec2-user/.local/bin:/home/ec2-user/bin"
}

TASK [env path]] ***************************************************************
ok: [target01] => {
    "msg": "/usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/sbin:/opt/aws/bin:/home/ec2-user/.local/bin:/home/ec2-user/bin"
}

PLAY RECAP *********************************************************************
target01                   : ok=3    changed=0    unreachable=0    failed=0

C'était dans l'état d'être connecté en tant qu'utilisateur ec2.

** Essayez de définir PATH dans l'environnement **

Essayez de définir le PATH dans l'environnement.

À l'avance, faites sudo su - et vérifiez ʻecho $ PATH`.

$ sudo su -
# echo $PATH
/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/opt/aws/bin:/root/bin

Le PlayBook ressemble à ceci:

playbook.yml

- hosts: all
  remote_user: ec2-user
  environment:
    PATH: "/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/opt/aws/bin:/root/bin"
  tasks:
    - command: echo $PATH
      register: become_path
      become: true
      changed_when: False

    - name: become
      debug: var=become_path.stdout

    - command: echo $PATH
      register: not_become_path
      changed_when: False

    - name: not become
      debug: var=not_become_path.stdout

Lançons-le.

$ ansible-playbook playbook.yml

PLAY [all] *********************************************************************

TASK [setup] *******************************************************************
ok: [target01]

TASK [command] *****************************************************************
ok: [target01]

TASK [become] ******************************************************************
ok: [target01] => {
    "become_path.stdout": "/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/opt/aws/bin:/root/bin"
}

TASK [command] *****************************************************************
ok: [target01]

TASK [not become] **************************************************************
ok: [target01] => {
    "not_become_path.stdout": "/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/opt/aws/bin:/root/bin"
}

PLAY RECAP *********************************************************************
target01                   : ok=5    changed=0    unreachable=0    failed=0

Puisque ʻenvironment: est défini pour le PlayBook, c'est le PATH défini à la fois quand devient: true` et quand il ne l'est pas.

En passant, ʻenvironnement: `peut également être écrit dans la tâche. Si vous souhaitez le définir pour chaque tâche, vous devez le spécifier pour chaque tâche. Le PlayBook ressemble à ceci:

playbook.yml

- hosts: all
  remote_user: ec2-user
  tasks:
    - command: echo $PATH
      register: become_path
      become: true
      changed_when: False
      environment:
        PATH: "/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/opt/aws/bin:/root/bin"

    - name: become
      debug: var=become_path.stdout

    - command: echo $PATH
      register: not_become_path
      changed_when: False
      environment:
        PATH: "/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/opt/aws/bin:/root/bin"

    - name: not become
      debug: var=not_become_path.stdout

Le résultat de l'exécution sera le même que celui du paramétrage de ʻenvironment: `pour l'ensemble du PlayBook.

** Périmètre environnement **

La portée de ʻenvironnement: `définie pour PlayBook et Task est la plage définie. Par exemple, si vous le définissez pour un PlayBook, cela n'affectera pas un autre PlayBook. Si vous énumérez vous-même les commandes et les exécutez avec / bin / sh, vous devez également écrire une commande pour restaurer le PATH défini, mais le PlayBook d'Ansible est pratique car il le fera automatiquement. ..

■ Conclusion

Cette fois, j'ai présenté comment définir le PATH en utilisant l'environnement.

La méthode de paramétrage PATH est comme décrit, mais les PlayBooks dépendant de PATH peuvent se retrouver coincés dans des pièges inattendus. Lorsque vous utilisez le shell et les modules de commande dans PlayBook, je pense qu'il est prudent de prendre l'habitude d'écrire avec le chemin complet.

• Peut rester coincé dans un piège (dépendant de PATH)

  - command: cmd
  

• Écriture sûre

  - command: /usr/local/bin/cmd
  

Lorsque vous utilisez un outil de gestion de configuration tel qu'Ansible, il est bon de garder à l'esprit qu'il peut être utilisé en tenant compte de la maintenabilité et de la robustesse, pas seulement pour le fonctionnement.