4. svnserve, um servidor customizado

O programa svnserve é um servidor leve, capaz de comunicar-se com clientes através de TCP/IP utilizando um protocolo customizado. Clientes podem contatar um servidor svnserve através de URLs iniciadas por svn:// ou svn+ssh://. Neste tópico iremos explorar as diferentes maneiras de executar o svnserve, como os clientes se autenticam com esse servidor e como configurar controles de acessos apropriados para seus repositórios.

4.1. Iniciando o servidor

Há algumas maneiras diferentes de iniciar o programa svnserve. Se iniciado sem opções, somente será mostrado uma mensagem de ajuda. No entanto, se pretendemos que o inetd inicie o processo, então podemos passar a opção -i (--inetd):

$ svnserve -i ( success ( 1 2 ( ANONYMOUS ) ( edit-pipeline ) ) )

Quando iniciado com a opção --inetd, o svnserve espera comunicar-se com um cliente Subversion através da entrada e saída padrão (stdin e stout) utilizando um protocolo customizado, um comportamento padrão para programas executados via inetd. A IANA (Internet Assigned Numbers Authority) reservou a porta 3690 para o protocolo Subversion, então em um sistema UNIX podemos adicionar as seguintes linhas ao arquivo /etc/services (se já não estiverem lá):


E se o o sistema está usando um daemon inetd UNIX clássico, podemos adicionar esta linha ao /etc/inetd.conf:


Certifique que o usuário "svnowner" tem permissões apropriadas para acesso aos repositórios. Agora, quando uma conexão de um cliente chegar ao servidor na porta 3690, o inetd irá iniciar um processo do svnserve para atendê-la.

Uma segunda opção é rodar o svnserve como um "daemon" standalone. Para tal, utilize a opção -d:

$ svnserve -d

(svnserve agora está rodando, escutando a porta 3690)

Ao rodar o svnserve em modo daemon, você pode usar a opção --listen-port e --listen-host para customizar a porta e hostname nos quais o "bind" será efetuado.

Há ainda uma terceira maneira para invocar o svnserve, em modo "tunelamento", com a opção -t. Este modo assume que um programa de serviço remoto como RSH ou SSH autenticou com sucesso um usuário e está invocando um processo svnserve privado como aquele usuário.

O programa svnserve atua de maneira normal, assumindo que o tráfego está sendo automaticamente redirecionado por algum tunelamento para o cliente. Quando o svnserve for invocado por um tunelamento, como descrito, certifique-se de que o usuário autenticado tem permissão total de leitura e escrita no repositório.

É essencialmente o mesmo procedimento de um usuário local acessando o repositório através do método file:///. /> Autenticação e autorização integrada Quando um cliente se conecta a um processo svnserve, as seguintes situações acontecem:

• O cliente seleciona um repositório específico;
• O servidor processa o arquivo conf/svnserve.conf e aplica quaisquer políticas de autenticação e autorização lá definidas;
• Dependendo da situação e das políticas de autorização:
  1. o cliente pode ser autorizado a fazer requisições anonimamente, sem autenticação;
  2. o cliente deverá autenticar-se;
  3. se operando em modo de tunelamento, o cliente irá declarar que já foi autenticado externamente.

Até o momento, o svnserve só é compatível com o método de autenticação CRAM-MD5. Essencialmente, o servidor envia um pacote de dados ao cliente, que usa um algoritmo de hash MD5 para criar uma assinatura dos dados e da senha combinados, e então a envia como resposta. O servidor calcula a assinatura em conjunto com a senha local para verificar que o resultado é idêntico. Em nenhum momento a senha do usuário atravessa a rede.

Obviamente, também é possível que o cliente seja autenticado externamente através de um agente de tunelamento, como o SSH. Neste caso, o servidor simplesmente examina o usuário com o qual está executando e o utiliza para acessar o repositório.

Como você já deve ter desconfiado, o arquivo svnserve.conf de um repositório é o mecanismo central de controle de autenticação e autorização. O arquivo tem o seguinte formato: seções são identificadas por colchetes - [], comentários são iniciados por cerquilha - #, e cada seção contém variáveis que podem ser ajustadas - variável = valor.

4.2. Criando um arquivo e domínio 'users'

Por ora, a seção [general] do arquivo svnserve.conf contém todas as variáveis de nosso interesse. Defina inicialmente um arquivo contendo usuários e senhas, bem como um domínio de autenticação:


O domínio é um nome definido pelo administrador que indica aos clientes o domínio de autenticação ao qual estão se conectando; o cliente Subversion mostra esse domínio no prompt de autenticação, e o utiliza como uma chave (juntamente com o hostname do servidor e a porta) para fazer cache de credenciais no disco. A variável password-db aponta para um arquivo em separado que contém uma lista de usuários e senhas, utilizando o mesmo formato. Por exemplo:


O valor de password-db pode ser qualquer caminho absoluto ou relativo de diretórios até o arquivo users. Para muitos administradores, é conveniente manter o arquivo dentro do diretório conf/ do repositório, juntamente com svnserve.conf.

Por outro lado, é possível que você deseje que dois ou mais repositórios compartilhem o mesmo arquivo users, caso em que o arquivo provavelmente deveria ficar em um local de acesso mais irrestrito. Os repositórios compartilhando o arquivo users poderiam ainda ser configurados para ter o mesmo domínio, já que uma lista de usuários define essencialmente um domínio.

Qualquer que seja o diretório onde se encontra o arquivo, certifique-se de que as permissões de leitura e escrita estão ajustadas corretamente.

4.3. Ajuste de controle de acesso

Há ainda duas variáveis interessantes a serem ajustadas em svnserve.conf: elas determinam o que usuários não-autenticados (anônimos) e usuários autenticados poderão fazer no repositório. As variáveis anon-access e auth-access podem ser ajustadas para os valores none, read ou write. Ajustando o valor para none restringe qualquer tipo de acesso; read permite acesso somente de leitura e write permite acesso completo de leitura e escrita ao repositório. Por exemplo:


Essas configurações de exemplo são, de fato, os valores padronizados para as variáveis, caso não sejam definidas. Se você deseja ser ainda mais conservativo, você pode bloquear acesso anônimo por completo:


Observe que o svnserve suporta apenas controle de acesso por usuário. Um usuário pode ou ter acesso universal de leitura e escrita, acesso universal de leitura ou nenhum acesso. Não há controle detalhado sobre diretórios específicos do repositório, o que, para muitos projetos, é suficiente e adequado. No entanto, se você necessita de controle de acesso por diretório, será necessário utilizar o mod_authz_svn do Apache (a ser visto no tópico seguinte), ou utilizar um hook pre-commit para controlar acesso de escrita.

O controle de acesso via tunelamento é bastante semelhante ao descrito anteriormente, mas, dada a especificidade do tema, deixamos aqui o link do SVN Book que explica esse tópico em maior detalhe aos alunos interessados nesse tipo de configuração:

• http://svnbook.red-bean.com/nightly/en/svn.serverconfig.svnserve.html