Drush i uprawnienia użytkownika

10

Widzę, że mój użytkownik jest członkiem grupy Apache. Dodałem i potwierdziłem w następujący sposób

$ sudo usermod -a -G apache `whoami`  # add my user to apache group
$ sudo chmod -R g+w .                 # permit group members to write 
$ groups `whoami`                     # confirm I'm in the apache group

Jednak gdy próbuję uruchomić rdzeń aktualizacji drush, a nawet drush cron

$ drush cc all

unlink(sites/default/files/css/css_71ba7c25a8d3c47c68a8e05608ae525c.css):[warning]
Permission denied file.inc:482

wprowadź opis zdjęcia tutaj

I wygląda pamięć podręczna CSS w tej sytuacji

$ ll
total 1536
drwxrwxr-x.  2 apache apache  12288 Nov 26 10:12 .
drwxrwxr-x. 11 apache apache   4096 Nov 24 20:35 ..
-rw-rw-r--   1 apache apache 162269 Nov 26 10:06 css_00d5f4d7c5c92cd4f.css
-rw-rw-r--   1 apache apache 158090 Nov 26 10:02 css_0605989692a2119d305.css
-rw-rw-r--   1 apache apache 162269 Nov 26 10:02 css_0779dcac71ee9aa8e02d9e.css

wprowadź opis zdjęcia tutaj

Zakładam, że moje konto użytkownika, które ma dostęp do sudo, powinno być członkiem grupy apache (lub www-data) i że drzewo plików powinno pozwalać na grupowy dostęp do zapisu. Każda pomoc lub punkty we właściwym kierunku byłyby bardzo mile widziane.

drush files

— Stóg
źródło

2

biegnij newgrp apachebez sudo i spróbuj ponownie

— Hamid Nikmehr

2

Wylogowałeś się, a następnie ponownie zalogowałeś?

— mpdonadio

13

Prawdopodobnie o wiele prostszym podejściem jest w ogóle nie marnowanie przydziałów grupy użytkownika i zamiast tego uruchamianie drush jako użytkownik serwera WWW (tj. Apache, www-data).

Użyj sudo:

sudo -u apache drush

lub na debian / ubuntu:

sudo -u www-data drush

Utwórz alias polecenia:

Następnie, aby mieć pewność, że zawsze tak działa drush, dodaj alias:

echo "alias drush='sudo -u apache drush'" >> ~/.bash_aliases

lub na debian / ubuntu:

echo "alias drush='sudo -u www-data drush'" >> ~/.bash_aliases

Teraz, gdy uruchomisz dowolne polecenie drush, sudo wyświetli monit o podanie hasła, a polecenie będzie działać jako użytkownik serwera WWW. Nigdy więcej problemów z uprawnieniami do odczytu i zapisu plików.

— rcourtna
źródło

1

Kiedy uruchamiam „sudo -u www-data drush”, narzeka, że katalogu drush-backups nie można zapisać.

— Magmatic

1

@Magmatic wystarczy zmienić uprawnienia do tego folderu, umożliwić zapisywanie go dla danych www, sprawdzić, kto jest właścicielem.

— Beto Aveiga

3

Chociaż druga odpowiedź ma charakter informacyjny, teraz używam odpowiedniego uprawnienia użytkownika, jak opisano w

Zabezpieczanie uprawnień do plików i własności

https://www.drupal.org/node/244924

Który otwiera się za pomocą

System plików serwera powinien być tak skonfigurowany, aby serwer WWW (np. Apache) nie miał uprawnień do edytowania lub zapisywania plików, które następnie wykonuje. Oznacza to, że wszystkie twoje pliki powinny być „tylko do odczytu” dla procesu Apache i posiadać uprawnienia do zapisu przez osobnego użytkownika.

— Stóg
źródło

3

Artykuł, do którego linkujesz, nie wspomina o Drushie. Czy możesz wyjaśnić, którego użytkownika używasz do uruchamiania poleceń Drush i jak jest on skonfigurowany.

— JW.

2

Ciekawy! Myślę, że powinieneś również wspomnieć o 2 parach, które następują po tym, który już zacytowałeś ...

— Pierre.Vriens

1

W folderze plików Drupal serwer WWW musi nadawać się do zapisu, a na etapie rozwoju prawdopodobnie będziesz go potrzebować również w przypadku folderu funkcji.

— Beto Aveiga

1

Kiedy biegłem drush, ponieważ www-datadrush nie był już dostępny, ponieważ moja $ PATH się zmieniła .

Aby obejść ten problem, możesz wejść na całą ścieżkę drush.

Na przykład

sudo -u www-data /home/vagrant/.composer/vendor/bin/drush status

Aby uzyskać ścieżkę swojego drusha, możesz biegać:

which drush

Co oznacza, że możesz także uruchomić:

sudo -u www-data `which drush` status

co eliminuje konieczność twardego kodowania ścieżki w poleceniu.

— Felix Eve
źródło