înregistrare Logare
Puncte:1
avatar Server

Rulați scriptul PHP NextCloud âoccâ ca utilizator de server web, pe conexiune Ansible

drapel co
bignose

Cum scriu un Sarcină ansible pentru a rula un script PHP ca al treilea utilizator; nu utilizatorul root și nu utilizatorul care se conectează, ci utilizatorul âwebserverâ?

Programul de administrare NextCloud occ, conform documentatiei, trebuie rulat ca utilizator de server web:

sudo -u www-data php occ

Pentru a deveni un alt utilizator pentru rularea unei comenzi, Ansible oferă deveni caracteristică. Documentația Ansible cu severitate recomandă să nu încercați să rulați comenzi ca alt utilizator, non-root:

Totul este în regulă dacă fișierul modul este executat fără a fi folosit deveni, cand deveni_utilizator este root, sau când conexiunea la mașina de la distanță se face ca root. În aceste cazuri, Ansible creează fișierul modul cu permisiuni care permit citirea numai de către utilizator și root, sau permite citirea doar de către utilizatorul neprivilegiat la care este comutat.

Cu toate acestea, atunci când atât utilizatorul conexiunii, cât și deveni_utilizator nu sunt privilegiați, fișierul modul este scris ca utilizatorul la care Ansible se conectează (the utilizator_la distanţă), dar fișierul trebuie să fie citit de utilizatorul Ansible este setat să devină.

Folosind deveni_utilizator la acel utilizator

Utilizatorul conexiunii are sudo permisiunea de a rula comenzi ca al treilea utilizator:

$ sudo -u www-data whoami
www-data

Când folosesc deveni_utilizator pe sarcină, pentru a rula comanda ca utilizatorul respectiv:

- nume: „NextCloud: Configurare instanță”
  become_user: „{{ web_process_user }}”
  comanda:
    cmd: >-
        php „{{ apache_nextcloud_dir }}/occ” întreținere:instalare
            --fără-interacțiune
            â¦

ACTUALIZAȚI: um, funcționează. Nu știu ce s-a schimbat, dar încercând să reproduc problema, s-a oprit.

Folosind coajă cu un explicit sudo invocare ca acel utilizator

Când configurez sarcina Ansible cu a coajă comanda:

coajă: >-
    su '{{ web_process_user }}' --shell '/bin/bash' -c ' \
        php „{{ apache_nextcloud_dir }}/occ” â¦

Ansible se plânge:

[AVERTISMENT]: Luați în considerare utilizarea „become”, „become_method” și „become_user” în loc să rulați su

Mi-ar plăcea să fac asta. Al lui Ansible deveni ar fi un mod mult mai grațios decât acesta coajă: su hack.

Dar la utilizare deveni, apar problemele descrise în documentația Ansible: modulul de sarcini trimis prin conexiunea pentru rularea acelei comenzi nu reușește să obțină privilegiul de a-și crea fișierele temporare.

Documentația Ansible recomandă:

  • âutilizați pipeliningâ: Aceasta pierde avantajele sistemului implicit de task-module.
  • âevitați să deveniți un utilizator neprivilegiatâ: nu este o opțiune, deoarece Este necesar un utilizator de server web neprivilegiat pentru rularea acestei comenzi corect.

Cum ar trebui face o sarcină Ansible care rulează php „{{ apache_nextcloud_dir }}/occ” ca al treilea utilizator neprivilegiat {{ web_process_user }}?

ACTUALIZAȚI: cel deveni funcționalitatea pare să funcționeze corect acum.

266
1 + 0
solarchemist avatar
drapel in
solarchemist
Puteți evita întreaga mizerie asigurându-vă că `setfacl` este instalat pe țintă (`apt install acl`). Apoi pur și simplu funcționează. S-ar putea să nu funcționeze pe gazde care folosesc sisteme de fișiere fără suport ACL, dar nu am întâlnit niciodată astfel de sisteme până acum. Consultați această secțiune în documentele Ansible https://docs.ansible.com/ansible/latest/user_guide/become.html#risks-of-becoming-an-unprivileged-user
0
Răspunde
Puncte:0
Michael Hampton avatar Server
drapel cz
Michael Hampton

Există două moduri pe care le cunosc pentru a face față acestei probleme. Primul pe care îl cunoști deja, dar se pare că ai fost speriat de el de documentație. Cu toate acestea, documentația vă spune exact ce trebuie să faceți pentru ca acesta să funcționeze, așa că ar trebui să o parcurgeți cu atenție dacă acest lucru nu reușește prima dată.

Deci trebuie să faci două lucruri:

  1. A stabilit deveni_utilizator utilizatorului neprivilegiat (aici, www-data). Acest lucru va determina ansible să facă sudo pentru acel utilizator în loc de root.

  2. Configurați sudoeri pentru a permite dvs utilizator_la distanţă la sudo la www-data. De exemplu, dacă dvs utilizator_la distanţă este ansible:

    ansible ALL=(www-data) NOPASSWD:ALL

    Rețineți că acest lucru este probabil opțional, deoarece este tipic să aveți deja configurat sudo pentru a permite utilizatorului ansible să facă sudo oricărui utilizator, ceva de genul:

    ansible ALL=(ALL) NOPASSWD:ALL

    sau plasându-l într-un grup care deja poate face asta.

A doua modalitate este de a avea Ansible să se conecteze direct la sistemul de la distanță ca utilizator dorit (aici, www-data) și nu sudo. Faceți acest lucru după cum urmează:

  1. Adăugați cheia publică ssh a Ansible la cea a utilizatorului de la distanță .ssh/authorized_keys.

  2. A stabilit remote_user=www-data și devenit=nu pentru sarcina, bloc, playbook, rol etc., care trebuie să ruleze ca acest utilizator.

0 + 1
drapel co
bignose
âspăimântat de documentaţieâ â dimpotrivă; documentația m-a speriat să încerc să lucrez. Dar acum am actualizat întrebarea cu faptul că nu pot reproduce problema; caracteristica recomandată „deveniți” funcționează corect acum. Mulțumesc pentru îndemnuri.
0
Răspunde
drapel romania
SEF 777
întrebarea această in alte limbi:

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.