Parece que você esqueceu de conceder permissões de gravação em grupo:
$ sudo chmod g+w /srv/www/mysite.com
Estou gerenciando uma instalação do WordPress com o Capistrano e o Composer. Tudo está configurado e funcionando bem, é bem rápido na configuração ngix / php-fpm.
No entanto, me deparei com um problema ao tentar atualizar plugins da área de administração, o WordPress pede credenciais de FTP. Um rápido google, e é claro que isso é porque o WordPress pode acessar serviços da web no meu servidor.
Eu usei SSD no meu servidor e fiz o seguinte:
ps aux | grep 'nginx'
O nginx está sendo executado sob o usuário www-data. Isso é normal.
Aqui está o meu problema: para usar o Capistrano, você cria um usuário deploy e concede privilégios de sudo sem senha. Ok, tudo bem. Eu fiz isso. Capistrano funciona bem.
O problema é que os arquivos devem pertencer a este usuário deploy . Para fazer isso eu apenas chow assim:
sudo chown -R deploy:www-data /srv/www/mysite.com
Depois disso, quis ter certeza de que todos os novos arquivos e diretórios herdariam a propriedade do grupo:
sudo chmod g+s /srv/www/mysite.com
Dessa forma, quando o capistrano adiciona novos arquivos, todos eles herdam as permissões corretas.
Também adicionei o usuário deploy ao grupo www-data na tentativa de evitar o problema que estou tendo com o WordPress.
Eu confirmei isso executando groups deploy
Quando eu recursivamente chown o diretório para www-data:www-data tudo funciona bem. Eu posso atualizar e baixar plugins do backend, mas não posso implantar com o Capistrano.
O que devo fazer para acessar o nginx no meu wordpress install e resolver esse problema?
Obrigado.
Se você usar chmod g+s em vez de g + w, todas as futuras criações de arquivo usarão o grupo especificado como padrão. Mas isso é uma correção manual, o que não é realmente o objetivo de usar o Capistrano.
Eu tive o mesmo problema e com uma pequena ajuda de stackoverflow Eu consegui ligar uma tarefa após o término da implantação para modificar as permissões apenas do diretório atual / www (deixando o resto da estrutura de implantação intocada.
Isso precisa estar no namespace de implementação:
task :mod_group do
on roles(:all) do
execute "chown -R :#{fetch(:group)} #{fetch(:deploy_to)}/current/www && chmod -R g+s #{fetch(:deploy_to)}/current/www"
info "Group permission of #{fetch(:deploy_to)}/current/www modified to #{fetch(:group)}"
end
end
after :finished, 'deploy:mod_group'
Você também precisa set :group, 'www-data' ou o nome do grupo que você deseja nas configurações antes da execução da tarefa. Como outras pessoas sugeriram, eu também recomendo usar o usuário deploy em vez do root.
No caso do Wordpress, pode ser o caminho do aplicativo, não o www que você deseja modificar - o que provavelmente significa que você pode definir roles(:app) também.
Edit: Como comentei, uma alternativa é usar within release_path do para mudar para o caminho específico para executar os comandos. No entanto, descobri que o método não funciona bem com o comando formatado como uma string, então você tem uma vírgula separada dos argumentos para executar. Como segue:
task :mod_group do
on roles(:all) do
within release_path do
execute 'chown', '-R', ':www-data', 'www'
execute 'chmod', '-R', 'g+s', 'www'
info "Group permission of www modified to www-data"
end
end
end
Nesse exemplo, eu também defino o nome do grupo em linha, porque é um pouco redundante usando uma configuração genérica que você só chama uma vez.
altere a propriedade para www-data: www-data
sudo chown www-data:www-data /path/to/wp -R
adicione seu usuário de implantação ao grupo de dados www
sudo usermod -a -G www-data deploy
Tags nginx wordpress capistrano