Drush e permissões de usuário

10

Vejo que meu usuário é um membro do grupo apache. Eu adicionei e confirmei através do seguinte

$ 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

No entanto, quando tento executar um núcleo de atualização drush ou até mesmo cron cron

$ drush cc all

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

insira a descrição da imagem aqui

E o cache CSS nessa situação parece

$ 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

insira a descrição da imagem aqui

Eu suporia que minha conta de usuário, que tem acesso ao sudo, deveria ser um membro do grupo do apache (ou www-data) e que a árvore de arquivos deveria permitir o acesso de gravação do grupo. Qualquer ajuda ou orientação na direção certa seria muito apreciada.

drush files

— Rick
fonte

2

executar newgrp apachesem sudo e tente novamente

— Hamid Nikmehr

2

Você saiu e depois voltou a entrar?

— mpdonadio

13

Indiscutivelmente, uma abordagem muito mais direta é não atrapalhar as atribuições de grupo do usuário e executar o drush como usuário do servidor da web (ex: apache, www-data).

Use sudo:

sudo -u apache drush

ou no debian / ubuntu:

sudo -u www-data drush

Crie um alias de comando:

Em seguida, para garantir que você sempre execute drush assim, adicione um alias:

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

ou no debian / ubuntu:

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

Agora, ao executar qualquer comando drush, sua senha será solicitada pelo sudo, e o comando será executado como usuário do servidor da web. Não há mais problemas com permissões para ler e gravar arquivos.

— rcourtna
fonte

1

Quando executo "sudo -u www-data drush", ele reclama que o diretório drush-backups não é gravável.

— Magmatic

1

@ Magmatic apenas altere as permissões para essa pasta, torne-a gravável para www-data, verifique quem é o proprietário.

— Beto Aveiga 28/04/19

3

Embora a outra resposta seja informativa, agora uso a permissão adequada do usuário, conforme descrito em

Protegendo permissões e propriedade de arquivos

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

Que abre com

O sistema de arquivos do servidor deve ser configurado para que o servidor da Web (por exemplo, Apache) não tenha permissão para editar ou gravar os arquivos que serão executados. Ou seja, todos os seus arquivos devem ser 'somente leitura' para o processo Apache e pertencentes a permissões de gravação por um usuário separado.

— Rick
fonte

3

O artigo ao qual você vincula não menciona Drush. Você poderia, por favor, esclarecer qual usuário está usando para executar comandos Drush e como esse usuário está configurado.

— JW.

2

Interessante! Eu acho que você também deve mencionar os 2 pargs que seguem o que você já citado ...

— Pierre.Vriens

1

Nos arquivos do Drupal, a pasta precisa ser gravável pelo servidor da web e, no desenvolvimento, você provavelmente precisará disso também para a pasta de recursos.

— Beto Aveiga 28/04/19

1

Quando eu corria drush, já que o www-datadrush não estava mais disponível, pois meu $ PATH havia mudado .

Como solução alternativa, você pode inserir todo o caminho para drush.

Por exemplo

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

Para obter o caminho do seu drush, você pode executar:

which drush

O que significa que você também pode executar:

sudo -u www-data `which drush` status

o que elimina a necessidade de codificar o caminho no comando.

— Felix Eve
fonte