Permisiuni recomandate pentru fișiere
Salutare, am petrecut mult timp încercând să rezolv această problemă. Aș dori să știu cum ar trebui să arate permisiunile fișierelor în WordPress pentru a putea folosi funcția de actualizare automată. Momentan, instalarea mea WordPress continuă să-mi ceară informațiile FTP și nu vreau să folosesc această metodă de actualizare/instalare, ci doar PHP direct.
Context:
- serverul web și daemonii PHP fcgi rulează sub
www-data:www-data
- instalarea WordPress se află la
/home/blaenk/sites/domain.tld/
La început, am citit că toate fișierele/directoarele ar trebui să fie deținute de utilizatorul meu (blaenk) și să aibă permisiuni de scriere pentru acesta. Dar nu a funcționat, după multe ore de cercetare, cineva pe canalul IRC mi-a sugerat să încerc să setez totul ca proprietate www-data:www-data
și asta a funcționat. Nu mi s-a mai cerut informații FTP și instalarea plugin-urilor a funcționat automat.
Totuși, inițial am plasat fișierele site-ului în directorul meu home tocmai pentru a putea să le scriu/creez ca utilizator. Am adăugat chiar și utilizatorul meu la grupul www-data
conform acestui ghid.
Întrebare
Știu deja că fișierele ar trebui să aibă permisiunile 644 și directoarele 755. Dar problema pare mai degrabă legată de proprietate. Nu vreau să fie nevoie să setez www-data:www-data
pentru tot în instalarea WordPress, așa că mă întreb ce fișiere/directoare necesită în mod specific acest nivel de proprietate?
EDIT: Cred că motivul pentru care totul funcționează pe hosting-ul shared WordPress, în ciuda faptului că toate fișierele sunt deținute de utilizatorul meu, este că furnizorul de hosting shared folosește suexec care probabil rulează PHP ca mine, deci practic fișierele sunt deținute de serverul web, într-un fel.

Din câte înțeleg, problema nu este legată de permisiuni specifice - Actualizarea automată în general necesită ca proprietarul fișierelor să corespundă cu utilizatorul sub care rulează Apache. Dacă acest lucru nu este cazul, se utilizează alte metode de sistem de fișiere (FTP, SSH) și, prin urmare, solicită parola.
Puteți defini credentialele în constante în fișierul wp-config.php
astfel încât să nu vi se ceară să le introduceți.
Consultați Constantele de actualizare WordPress în Codex.

Mulțumesc Rarst. Am văzut acel articol din codex, însă nu doresc deloc să folosesc FTP/SSH. Motivul pentru aceasta este că, cumva, pe un site de shared-hosting unde am instalat WordPress manual, totul funcționează, chiar dacă toate fișierele sunt deținute de propriul meu utilizator. Fișierele sunt deținute de utilizatorul meu, dar și de un alt grup pe care nu l-am creat, așa că presupun că există ceva SETGUID în spate, ceea ce probabil explică cum procesul serverului web poate executa actualizările automate.

Presupunerea mea este că cealaltă configurație folosește suexec, astfel încât Apache rulează WordPress sub contul tău de utilizator și nu există o nepotrivire.

Haha, da, exact asta am spus. Dar îți acord puncte pentru că ești singurul care s-a obosit să răspundă. Mulțumesc :)

Ei bine, nici măcar nu a trecut o oră de la întrebarea ta și nu există un răspuns cu adevărat perfect - fie faci o potrivire a utilizatorului, fie folosești FTP/SSH. Apropo, în loc să adaugi soluția la întrebarea ta, poți să o scrii ca un răspuns cu câteva link-uri pe tema respectivă și altele asemenea? Astfel, și alții vor putea beneficia de ea în viitor.

Am vrut să fac asta inițial, dar am fost teamă că ai putea crede că am încercat să fur răspunsul de la tine sau să-ți irosesc timpul sau ceva de genul. O să fac asta acum.

În întrebarea mea, am menționat confuzia față de faptul că totul a funcționat perfect pe hosting-ul partajat, în ciuda faptului că toate fișierele erau deținute de utilizatorul meu, în timp ce pe VPS-ul meu, actualizarea automată nu funcționa decât dacă toate fișierele erau deținute de serverul web.
Sunt destul de sigur că acest lucru se datorează faptului că furnizorul meu de hosting partajat folosește suexec, care rulează scripturile ca și utilizatorul meu. Deci, în esență, fișierele de pe hosting-ul partajat erau deținute de 'serverul web' (de fapt, de daemonul CGI).
Pe VPS-ul meu rulez nginx și php-fpm, așa că nu am acces la suexec din Apache. Totuși, am configurat php-fpm să ruleze sub contul meu, pentru a testa teoria, și într-adevăr a funcționat perfect cu toate fișierele deținute de utilizatorul meu. Cred că acest lucru ar putea fi considerat un risc de securitate (nu sunt sigur), așa că voi investiga mai departe pentru a vedea ce pot face în acest sens pentru a evita rularea sub contul meu, dar măcar acum știu care este problema!

Experiențele tale 'mixte' probabil provin din faptul dacă cei doi utilizatori în cauză se află sau nu în același grup. Și, desigur, din drepturile de grup care s-au întâmplat să fie setate.
Tradițional în PHP, utilizatorul PHP (cunoscut și ca utilizatorul Apache sau utilizatorul web sau demonul CGI) nu are dreptul să modifice fișiere, drept pe care îl are doar utilizatorul FTP (denumit în unele descrieri din codex drept „contul tău de utilizator”), pentru a face mai dificilă modificarea scripturilor în cazul unor exploatări de securitate.
Ceea ce, desigur, face orice actualizare bazată pe PHP a fișierelor PHP imposibilă. Astfel, în PHP în general, este obișnuit să se schimbe proprietarul fișierelor de la utilizatorul FTP la utilizatorul PHP. Înainte de a face acest lucru, merită menționat că procesul de „actualizare” se întâmplă cu „picioarele în FTP” (deoarece introduci credențialele). Apoi despachetarea arhivelor ZIP descărcate se poate întâmpla, desigur, din nou prin scripturi... Ei bine, și apoi este directorul wp-content, care cu siguranță va fi atins și umplut prin intermediul scripturilor PHP... (Cred că toți am dat peste această problemă cel puțin o dată în WordPress) Lucrurile se pot complica.
pe scurt: Codex-ul WordPress oferă o privire de ansamblu foarte bună în Întărirea permisiunilor de fișiere pentru a fi cât mai 'zgârcit'/'sigur' cu permisiunile acordate fișierelor. Prin cont de utilizator
ei se referă la contul FTP (adică nu demonul CGI/utilizatorul PHP/...).

Presupunând că ai acces SSH, obține mai întâi utilizatorul "user". Adesea, serverul web rulează sub
www-data
, dar dacă nu ești sigur, ruleazătop
și poți vedea "USER" pentru php, nginx, etc.Acest pas este evident, dar găsește unde sunt fișierele tale. De obicei, fișierele tale sunt în
/home/www-data/
, dar am observat că nginx poate folosi implicit un alt director pe care nu-l mai țin minte momentan. În orice caz, foloseștecd
pentru a naviga în directorul care conține toate domeniile tale.chown -R www-data:www-data example.com
Această comandă schimbă recursiv proprietarul tuturor fișierelor din directorul example.com. Cel mai probabil, acest lucru nu va strica nimic.
De obicei, fișierele sunt deja setate cu permisiunile corecte, dar după ce am găzduit site-uri la zeci de companii, pot spune că permisiunile sunt ocazional schimbate din greșeală de către administratorii de sistem, este pur și simplu un fapt al vieții. De exemplu, montarea cu sshfs ar putea schimba proprietarul.
