Procurando por uma boa configuração de usuário / grupo para sites no servidor httpd apache

Question

nós temos uma configuração onde várias pessoas desenvolvem em suas máquinas locais, para depois confirmar as mudanças em um repositório de servidores local.

Para sincronizar as alterações em nosso servidor de produção externo, executamos um script que rsyncs uma exportação de subversão local para ele.

Enfrentamos um problema ao fazer esta sincronização, porque para funcionar, o usuário que faz a sincronização no servidor remoto precisa ser o proprietário dos arquivos remotos.

Nossa solução foi:

Criar um usuário no servidor remoto (proprietário do site) Dando-lhe a propriedade do site (chown siteowner.siteowner / var / www / site) Adicionando o apache ao grupo do proprietário do site (tivemos alguns problemas com as verificações do htaccess, e não podemos chown siteowner.apache porque quando o rsync faz a sincronização ele altera as permissões para siteowner.siteowner)

Minha pergunta é ... essa configuração parece razoável? Você conhece algum outro melhor? Obrigado antecipadamente!

    

Answer 1

usamos o seguinte fluxo de trabalho para nossos sites baseados em PHP.

Os usuários comprometem seu trabalho com o Subversion. Nós não permitimos que os desenvolvedores manualmente implantem código para Staging e Live. Por que não encenar? Porque queremos que ele simule de perto o Live. As implementações são feitas através do Webistrano , que é uma interface web para o conhecido e poderoso Capistrano ferramenta de implantação. Criamos as chamadas receitas que registram a implantação. Ele faz aproximadamente o seguinte:

• O Webistrano efetua login no servidor por meio do ssh como usuário 'implantar'
• Atualiza um cache de cópia de trabalho remota
• Ele copia a cópia de trabalho resultante para uma pasta // de releases, usando hardlinks (para economizar espaço em disco e velocidade).
• Links simbólicos dos dados do cliente (ou seja, arquivos não armazenados no subversion) para os locais apropriados.
• A nova versão é chmodded para 775 para dar permissões de gravação ao grupo.
• Se todas as etapas acima forem bem-sucedidas, o link "atual" será alterado para / releases //.
• Executa um 'apache2ctl gracioso' para liberar caches (como o caminho real () do php que ainda estão armazenando em cache a versão anterior.
• Se mais de um determinado número de releases forem armazenados, o mais antigo será removido.

O servidor web está configurado para que o docroot do host virtual aponte para o link simbólico 'atual', portanto, durante a implantação, o site antigo fica visível e, após a implantação bem-sucedida, o novo site aparece instantaneamente.

O código é de propriedade da implantação: implantar, mas os diretórios de dados do cliente são de propriedade da implantação: o upload e têm o bit SGID definido na criação.

O usuário do www-data da Apache é membro de grupos 'deploy' e 'upload'. Os desenvolvedores têm contas scp pessoais no servidor e são membros do grupo 'upload'. Essa configuração funciona muito bem para nós, já que os desenvolvedores não podem interagir com o código, exceto via Webistrano. Impede 'quickfixes ao vivo', exceto pelos administradores e reduziu tremendamente os acidentes. O recurso interno de retrocesso do Webistrano agiliza a reversão de uma implantação defeituosa.

Os desenvolvedores recebem acesso de gravação aos dirs de dados do cliente (por causa do grupo de uploads), para que possam fazer upload de conteúdo de espaço reservado ou ajudar o cliente a preencher o site. Afinal, nenhum conteúdo do cliente é armazenado no svn. O bit SGID nos diretórios garante que apenas a propriedade do usuário dos arquivos enviados seja definida para o usuário que está fazendo o upload (fornecendo um pouco de responsabilidade). A propriedade do grupo permanece definida como 'upload' pelo SGID, para que o Apache ou outros desenvolvedores ainda possam ler e ler os arquivos e diretórios criados.

A interface clara do Webistrano se mostrou muito útil e, como o Capistrano vem com a maioria das funcionalidades acima, nossas receitas de implantação são apenas duas dúzias de linhas. A maioria está substituindo os padrões específicos do Ruby-on-Rails.

    

Answer 2

você pode reconsiderar o fluxo de trabalho desta maneira:

• Todas as pessoas podem se comprometer com o servidor SVN E, em vez de brincar com os direitos do apache, criar um usuário no servidor de produção e adicionar um servidor SFTP.

• Todos trabalham em seus arquivos, e quando o commit do servidor SVN é feito, eles usam seu cliente SFTP para colocar em produção seus arquivos (porque todos usarão o mesmo usuário que você não vai incomodar com direitos)

Na verdade, antes de colocar em produção, você deve ter um servidor extra para a pré-produção.
Antes de cada confirmação para o servidor de produção, eles incluirão seus arquivos no servidor de pré-produção, que deve ser idealmente a replicação exata do servidor de produção. Quando as alterações são validadas, elas podem colocar os arquivos em produção.