web-dev-qa-db-fra.com

Ansible 2.1.0 à l'aide de devenir / devenir_utilisateur ne parvient pas à définir les autorisations sur le fichier temporaire

J'ai un ansible 2.1.0 sur mon serveur, où je fais le déploiement via vagrant et sur PC aussi. Le rôle "déployer" a:

- name: upload code
  become: true
  become_user: www-data
  git: [email protected]:****.git
     dest=/var/www/main
     key_file=/var/www/.ssh/id_rsa
     accept_hostkey=true
     update=yes
     force=yes
 register: fresh_code
 notify: restart php-fpm
 tags: fresh_code

Dans ce cas avec ansible 2.1.0, j'obtiens une erreur:

fatal: [default]: FAILED! => {"failed": true, "msg": "Failed to set permissions on the temporary files Ansible needs to create when becoming an unprivileged user. For information on working around this, see https://docs.ansible.com/ansible/become.html#becoming-an-unprivileged-user"}

Il ansible 2.0.1.0 que j'utilise sur mon PC, est tout normalement - dossier/var/www/avoir dossier principal avec le propriétaire et le groupe www-data

Si j'utilise uniquement

Que faut-il faire pour résoudre ce problème?

gitvagrantansiblesudoansible-2.x
27
DeamonMV

Le problème est que www-data ne peut pas accéder aux mêmes fichiers que votre utilisateur ansible non root créé par défaut que vous utilisez pour vous connecter à la machine. De plus, le message d'erreur indique clairement la documentation de ansible qui décrit les options dont vous disposez pour résoudre ce problème lors de la mise à niveau à partir de ansible 2.0 ou inférieur.

Ils suggèrent trois façons de résoudre correctement le problème:

  • Utilisez le pipelining. Lorsque le pipelining est activé, Ansible n'enregistre pas le module dans un fichier temporaire sur le client. Au lieu de cela, il dirige le module vers l'interpréteur distant python stdin. Le pipelining ne fonctionne pas pour les modules non-python.
  • Installez le support acl du système de fichiers sur l'hôte géré. Si le répertoire temporaire sur l'hôte distant est monté avec le système de fichiers acls activé et que l'outil setfacl se trouve dans le chemin distant, Ansible utilisera le système de fichiers acls pour partager le fichier de module avec le second sans privilège au lieu de devoir rendre le fichier lisible par tout le monde.
  • N'effectuez aucune action sur la machine distante en devenant un utilisateur non privilégié. Les fichiers temporaires sont protégés par des autorisations de fichier UNIX lorsque vous devenez root ou que vous n'utilisez pas dev. Dans Ansible 2.1 et versions ultérieures, les autorisations de fichier UNIX sont également sécurisées si vous établissez la connexion à la machine gérée en tant que root, puis utilisez devenir un compte non privilégié.

Ou si vous ne pouvez pas faire l'un de ces correctifs, vous pouvez forcer ansible à s'exécuter de manière un peu plus non sécurisée (ce qui semblait être la valeur par défaut dans ansible 2 et ci-dessous), ce qui devrait également résoudre votre problème, mais ne résoudrait pas le sous-jacent risque de sécurité:

Si vous ne pouvez apporter aucune des modifications ci-dessus pour résoudre le problème et que vous décidez que la machine sur laquelle vous exécutez est suffisamment sécurisée pour que les modules que vous souhaitez y exécuter soient lisibles par tous, vous pouvez activer allow_world_readable_tmpfiles dans le ansible.cfg fichier. Réglage allow_world_readable_tmpfiles changera cela d'une erreur en un avertissement et permettra à la tâche de s'exécuter comme avant 2.1.

17
SztupY

Sur debian/ubuntu, vous pouvez résoudre ce problème en installant d'abord le package acl sur l'hôte distant, comme avec cette tâche ansible:

- name: install setfacl support
  become: yes
  apt: pkg=acl

Même chose avec redhat/centos - installez le package acl sur l'hôte distant:

- name: install setfacl support
  become: yes
  yum: name=acl
45
Justin Ludwig