Melhor caminho para arquivos nginx

Question

Sempre lutei com vários pathsarquivos nginxe onde eles deveriam ser posicionados. Como sabemos, podemos mudar onde podemos estacionar tanto owwwdiretórios para nosso arquivo web app, bem como os logarquivos associados.

O problema que descobri é que tenho bashscripts Rubyde usuário tanto para SSHchamadas quanto para crontabscripts que precisam de acesso a várias partes desses nginxarquivos, bem como cópias de rede agendadas de vários arquivos, sem falar nas atualizações desses arquivos.

Eu segui os caminhos estáticos recomendados pela instalação do pacote nginxem várias distros, mas muitas vezes tive permissionsproblemas porque pathnão era o ideal no que diz respeito à acessibilidade. Então eu pesquisaria os vários linuxcaminhos principais e escolheria algo que fosse pensado pensando em tudo isso, mantendo um bom nível de segurança. Já vi vários locais e agora que estou pensando nisso novamente ( crontabsnão funciona, permissionsproblemas com vários itens, etc.), pensei em perguntar onde tudo isso deveria estar localizado.

Meus aplicativos não são staticaplicativos HTML padrão. Eu tenho um Rackaplicativo com um app serverarquivo em execução, um arquivo Gemfile, bem como qualquer upload recebido, etc.

Os dois locais que estou avaliando são:

• /usr/locallinuxfoundation.org
• /usr/compartilharlinuxfoundation.org

No entanto... isto é o que li para o /usrdiretório:

/usr é a segunda seção principal do sistema de arquivos. /usr são dados compartilháveis ​​e somente leitura. Isso significa que /usr deve ser compartilhável entre vários hosts compatíveis com FHS e não deve ser gravado nele. Qualquer informação específica do host ou que varie com o tempo é armazenada em outro lugar.

Grandes pacotes de software não devem utilizar um subdiretório direto na hierarquia /usr.

Então estou perdido. Alguém pode recomendar um local para arquivos legíveis/graváveis ​​que me proporcionem o mínimo de trabalho ao tentar criar scripts e cron?

Answer 1

O local "certamente" adequado para hospedar arquivos de sites é /srv/www. A partir daí, normalmente "particiono" isso em diretórios relacionados ao domínio.

Então, em suma, /srv/www/example.comtem esta estrutura/subdiretórios:

• publicarmazena quaisquer arquivos publicamente acessíveis vinculados a esse domínio/site
• logsarmazena quaisquer arquivos de log (seja NGINX, PHP-FPM, etc.) vinculados a esse domínio
• sessionsarmazena sessões específicas do usuário, por exemplo, sessões PHP

Quer você use PHP-FPM ou qualquer outro "daemon de script", você deseja definir as permissões corretamente, ajustando as configurações do daemon e chmod/chown os arquivos corretamente. Não existe um local mágico que proteja você de ter queconfigurar modelo de permissões. VerNGINX e PHP-FPM. Quais devem ser minhas permissões?- isso se aplica muito bem à maioria das configurações de sites, independentemente do PHP-FPM:

• Adicione um usuário separado para cada site, para isolamento adequado, por exemploexample
• Configure seu daemon de script para ser executado como esse usuário
• Faça com que o usuário do seu servidor web (NGINX) seja o membro do grupo do usuário do seu site: usermod -a -G example nginx. Isso permite que o NGINX leia arquivos que tenham permissão de grupo definida para leitura, e você pode proteger os arquivos que não deseja ler (arquivos de configuração) simplesmente removendo o bit de permissão de grupo dechmod

No final de tudo, nunca há um problema de permissão: tudo pertence e é “executado” pelo mesmo usuário!

Answer 2

Votando para encerrar isso porque a questão é muito vaga. Além disso, você está tentando culpar suas ferramentas pela situação, quando elas não são a fonte do problema. Você está, até certo ponto, limitado no que pode/deve fazer pelo susbsystem MAC e também em como o sistema de gerenciamento de pacotes lida com os arquivos de configuração. No entanto, como você não nos disse que distro era essa, não sabemos se isso é relevante e muito menos se estamos em condições de fazer sugestões.

Você deve COMEÇAR ao tentar resolver esse problema criando listas abrangentes de quais contas de usuário precisam de acesso a quais arquivos (antes de considerar onde esses arquivos estão localizados) e elaborando um modelo de permissões apropriado.

Certamente, é ALTAMENTE improvável que seja apropriado armazenar qualquer script ou conteúdo em /usr