web-dev-qa-db-fra.com

Drush et autorisations utilisateur

Je constate que mon utilisateur est membre du groupe Apache. J'ai ajouté et confirmé via ce qui suit

$ 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

Cependant, lorsque j'essaie d'exécuter un noyau de mise à jour drush ou même drush cron

$ drush cc all

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

enter image description here

Et le cache CSS dans cette situation ressemble

$ 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

enter image description here

Je suppose que mon compte d'utilisateur, qui a un accès Sudo, devrait être un membre du groupe d'Apache (ou www-data) et que l'arborescence de fichiers devrait permettre l'accès en écriture au groupe. Toute aide ou point dans la bonne direction serait très apprécié.

drushfiles
10
Rick

Bien que l'autre réponse soit informative, j'utilise maintenant l'autorisation utilisateur appropriée, comme décrit dans

Sécurisation des autorisations et de la propriété des fichiers

Qui s'ouvre avec

Le système de fichiers du serveur doit être configuré de sorte que le serveur Web (par exemple Apache) ne soit pas autorisé à modifier ou à écrire les fichiers qu'il exécute ensuite. Autrement dit, tous vos fichiers doivent être en lecture seule pour le processus Apache et détenus avec des autorisations d'écriture par un utilisateur distinct.

3
Rick

Sans doute, une approche beaucoup plus simple consiste à ne pas se moquer du tout des affectations de groupe de votre utilisateur et à la place exécuter drush en tant qu'utilisateur du serveur Web (par exemple: Apache, www-data).

tilisez Sudo:

Sudo -u Apache drush

ou sur debian/ubuntu:

Sudo -u www-data drush

Créez un alias de commande:

Ensuite, pour vous assurer que vous exécutez toujours drush comme ça, ajoutez un alias:

echo "alias drush='Sudo -u Apache drush'" >> ~/.bash_aliases

ou sur debian/ubuntu:

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

Maintenant, lorsque vous exécutez une commande drush, Sudo vous demandera votre mot de passe et la commande s'exécutera en tant qu'utilisateur du serveur Web. Plus de problème de permissions pour lire et écrire des fichiers.

13
rcourtna

Quand j'ai couru drush comme www-data drush n'était plus disponible car mon $ PATH avait changé .

Comme solution de contournement, vous pouvez entrer tout le chemin pour drush.

Par exemple.

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

Pour obtenir le chemin de votre drush, vous pouvez exécuter:

which drush

Ce qui signifie que vous pouvez également simplement exécuter:

Sudo -u www-data `which drush` status

ce qui supprime la nécessité de coder en dur le chemin dans la commande.

1
Felix Eve