Drush e autorizzazioni utente

10

Vedo che il mio utente è un membro del gruppo apache. Ho aggiunto e confermato tramite quanto segue

$ 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

Tuttavia, quando provo a eseguire un core di aggiornamento drush o addirittura cron drush

$ drush cc all

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

inserisci qui la descrizione dell'immagine

E la cache CSS in questa situazione sembra

$ 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

inserisci qui la descrizione dell'immagine

Suppongo che il mio account utente, che ha accesso sudo, dovrebbe essere un membro del gruppo di apache (o www-data) e che l'albero dei file dovrebbe consentire l'accesso in scrittura al gruppo. Qualsiasi aiuto o punto nella giusta direzione sarebbe molto apprezzato.

drush files

— pagliaio
fonte

2

corri newgrp apachesenza sudo e riprova

— Hamid Nikmehr,

2

Ti sei disconnesso e poi di nuovo di nuovo?

— mpdonadio

13

Probabilmente, un approccio molto più semplice è quello di non confondere affatto con le assegnazioni di gruppo dell'utente e invece eseguire drush come l'utente del server web (cioè: apache, www-data).

Usa sudo:

sudo -u apache drush

o su debian / ubuntu:

sudo -u www-data drush

Crea un alias di comando:

Quindi, per assicurarti di eseguire sempre drush in questo modo, aggiungi un alias:

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

o su debian / ubuntu:

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

Ora, quando esegui un comando drush, ti verrà richiesta la password da sudo e il comando verrà eseguito come utente del server web. Nessun problema con le autorizzazioni di lettura e scrittura dei file.

— rcourtna
fonte

1

Quando eseguo "sudo -u www-data drush" mi lamento che la directory drush-backups non è scrivibile.

— Magmatic,

1

@Magmatic basta cambiare le autorizzazioni per quella cartella, renderla scrivibile per i dati www, controllare chi è il proprietario.

— Beto Aveiga,

3

Sebbene l'altra risposta sia informativa, ora utilizzo l'autorizzazione utente corretta come descritto in

Protezione delle autorizzazioni e della proprietà dei file

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

Che si apre con

Il file system del server deve essere configurato in modo tale che il server Web (ad es. Apache) non disponga dell'autorizzazione per modificare o scrivere i file che viene quindi eseguito. Cioè, tutti i tuoi file dovrebbero essere "sola lettura" per il processo Apache e posseduti con autorizzazioni di scrittura da un utente separato.

— pagliaio
fonte

3

L'articolo a cui ti colleghi non menziona Drush. Potresti, per favore, chiarire quale utente stai usando per eseguire i comandi Drush e come è impostato quell'utente.

— JW.

2

Interessante! Penso che dovresti anche menzionare i 2 parg che seguono quello che hai già citato ...

— Pierre.Vriens

1

Nella cartella dei file Drupal deve essere scrivibile dal server web, e in fase di sviluppo sarà probabilmente necessario anche per la cartella delle funzionalità.

— Beto Aveiga,

1

Quando ho eseguito Drush in quanto www-dataDrush non era più disponibile poiché il mio $ PATH era cambiato .

Per ovviare al problema, puoi inserire l'intero percorso per scavare.

Per esempio

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

Per ottenere il percorso della tua droga puoi correre:

which drush

Ciò significa che puoi anche semplicemente eseguire:

sudo -u www-data `which drush` status

che elimina la necessità di codificare il percorso nel comando.

— Felix Eve
fonte