Como configurar um repositório mercurial para um site público no apache?

Question

Temos um servidor apache que serve um site de public_html / site / Gostaríamos de ter um repositório mercurial no mesmo diretório, para que pudéssemos enviar nossas alterações diretamente para o servidor.

Até agora eu configurei um script hgweb.wsgi e posso empurrar e puxar do repositório sem problemas.

Os problemas começam quando quero adicionar uma autenticação. O acesso de leitura e gravação ao repositório deve ser proibido para usuários não autorizados. A ajuda do Mercurial menciona o uso da autenticação HTTP, bem, eu posso criar o .htaccess com o .htpasswd e colocá-las em public_html / site /, mas isso não tornaria o site acessível.

Por favor ajude.

Atualização (solução): Talvez a solução de hosts virtuais pudesse funcionar também, mas encontrei uma mais simples. Você não precisa colocar autenticação no diretório do site, você tem que colocá-lo onde seu script hgweb reside. Então apenas proibir o acesso ao diretório .hg no diretório do site e pronto!

Agora, puxar e empurrar funciona somente através do script hgweb, com autenticação.

    

Answer 1

Você pode configurar dois vhosts no servidor que apontam para a mesma raiz do documento. Um vhost serve o site e o outro o repositório mercurial com o hgweb.wscgi. Dessa forma, você pode configurar a autenticação dentro da segunda configuração do vhost.

<VirtualHost *:80>
  ServerName www.example.com
  ServerAlias example.com 
  DocumentRoot /www/domain/public_html/site/
</VirtualHost>

<VirtualHost *:80>
  ServerName repo.example.com
  DocumentRoot /www/domain/public_html/site/

 # auth setup
 ....
</VirtualHost>

Se você preferir usar o .htaccess, também poderá usar nomes diferentes para os arquivos htaccess usando a diretiva AccessFileName na configuração vhost.
Por exemplo:

AccessFileName .acl

    

Answer 2

A maneira que eu costumo fazer isso é usar o SSH ao invés do hgweb para push e pull. O esquema também funciona se você enviar diretamente para o diretório do site, no entanto, eu recomendo isso por alguns motivos. Primeiro, empurrar para um repositório nonbare ainda precisaria de um checkout de qualquer maneira (isso pode ser facilmente corrigido com um hook de entrada), segundo se você bagunçar a implementação, é muito mais fácil de corrigir se o diretório do site for separado do diretório de repositório, diretórios separados permitem que você envie para o repositório compartilhado sem implementar (por exemplo, quando você precisar mover códigos que não estão prontos para serem executados de uma máquina de desenvolvimento para outra máquina de desenvolvimento).

Então o esquema funciona assim:

1. servidor
   1. diretório de repositório "bare": repositório compartilhado
   2. diretório do site "ao vivo": hg pull / path / to / bare (crie uma entrada [paths] para isso em hgrc)
   3. script / alias para ir do bare para o live e fazer outras tarefas de implantação
   4. ~ / .ssh / authorized_keys contém chave pública para acesso ssh
2. Local
   1. diretório de desenvolvimento "local": hg push ssh: //[email protected]/path/to/bare (crie uma entrada [paths] para isso em hgrc)
   2. ~ / .ssh / rsa_id é usado para envio seguro sem senha

O uso do SSH também seria mais seguro do que o uso do hgweb, já que o processo do Apache não deveria ser capaz de gravar no diretório do site "ao vivo" nem no diretório "bare" do repositório. Atravessar o SSH significa que apenas o usuário do SSH precisa ter acesso de gravação a esses diretórios.

Sem um repositório nu, parece um pouco mais simples assim:

1. servidor
   1. diretório do site "ao vivo"
   2. ~ / .ssh / authorized_keys contém chave pública para acesso ssh
2. Local
   1. diretório de desenvolvimento "local": hg push ssh: //[email protected]/path/to/live (crie uma entrada [paths] para isso em hgrc)
   2. ~ / .ssh / rsa_id é usado para envio seguro sem senha

mas você perde as vantagens que mencionei acima.