Drush et autorisations utilisateur

Je vois 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

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

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

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

Utilisez 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, vous serez invité à saisir votre mot de passe par sudo, 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.

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

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

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.

Quand j'ai couru drush car www-datadrush 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.