Ansible 2.1.0 mit Become/become_user kann keine Berechtigungen für temporäre Dateien festlegen

Ich habe ein Ansible 2.1.0 auf meinem Server, wo ich die Bereitstellung über mache Landstreicher und am PC auch. Die Rolle “Bereitstellen” haben:

- 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

In diesem Fall mit ansible 2.1.0 erhalte ich eine Fehlermeldung:

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"}

Es ist ansible 2.0.1.0, das ich auf meinem PC verwende, ist alles normal – Ordner /var/www/ hat Ordner main mit Besitzer und Gruppe www-data

Wenn ich nur were_user: www-data verwende und willed_method: sudo mit were_user: www-data verwende, habe ich denselben Fehler

Was ist zu tun, um dies zu beheben?

Unter Debian/Ubuntu können Sie dies beheben, indem Sie zuerst die acl Paket auf dem Remote-Host, wie bei dieser ansiblen Aufgabe:

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

Dasselbe gilt für Redhat/Centos – installieren Sie die acl Paket auf dem Remote-Host:

- name: install setfacl support
  become: yes
  yum: name=acl

Das Problem ist, dass www-data kann nicht auf dieselben Dateien zugreifen, die Ihr standardmäßiger ansibler Nicht-Root-Benutzer erstellt hat, den Sie zum Herstellen einer Verbindung mit dem Computer verwenden. Darauf deutet auch die Fehlermeldung eindeutig hin ansibles Dokumentation die beschreibt, welche Optionen Sie haben, um dieses Problem zu beheben, wenn Sie ein Upgrade von Ansible 2.0 oder niedriger durchführen.

Sie schlagen drei Möglichkeiten vor, um das Problem richtig zu beheben:

• Verwenden Sie Pipelining. Wenn das Pipelining aktiviert ist, speichert Ansible das Modul nicht in einer temporären Datei auf dem Client. Stattdessen leitet es das Modul an die Standardeinstellung des Python-Interpreters weiter. Pipelining funktioniert nicht für Nicht-Python-Module.
• Installieren Sie die Dateisystem-ACL-Unterstützung auf dem verwalteten Host. Wenn das temporäre Verzeichnis auf dem Remote-Host mit aktivierten Dateisystem-ACLs gemountet wird und sich das Setfacl-Tool im Remote-PATH befindet, verwendet Ansible Dateisystem-ACLs, um die Moduldatei mit dem zweiten unprivilegierten zu teilen, anstatt die Datei für alle lesbar machen zu müssen.
• Führen Sie keine Aktion auf dem Remote-Computer aus, indem Sie ein nicht privilegierter Benutzer werden. Temporäre Dateien werden durch UNIX-Dateiberechtigungen geschützt, wenn Sie Root werden oder nicht verwenden. In Ansible 2.1 und höher sind UNIX-Dateiberechtigungen auch dann sicher, wenn Sie die Verbindung zur verwalteten Maschine als Root herstellen und dann ein unprivilegiertes Konto verwenden.

Oder wenn Sie keine dieser Korrekturen durchführen können, können Sie Ansible dazu zwingen, auf eine etwas unsicherere Weise zu laufen (was in Ansible 2 und darunter der Standard zu sein schien), was auch Ihr Problem beheben sollte, aber nicht das zugrunde liegende Problem beheben würde Sicherheitsrisiko:

Wenn Sie keine der oben genannten Änderungen vornehmen können, um das Problem zu lösen, und Sie entscheiden, dass der Computer, auf dem Sie arbeiten, sicher genug ist, damit die Module, die Sie dort ausführen möchten, weltweit lesbar sind, können Sie ihn einschalten allow_world_readable_tmpfiles in dem ansible.cfg Datei. Einstellung allow_world_readable_tmpfiles wandelt dies von einem Fehler in eine Warnung um und lässt die Aufgabe so laufen, wie sie es vor 2.1 getan hat.