Git é legal, é bacana, mas impõe também uma certa dose de trabalho ao administrador dos repositórios centralizados. Bom, antes de continuar com o assunto deste artigo, deixe-me somente esclarecer que o conceito de "repositório centralizado" não existe em Git, per se. Todo e qualquer repositório, seja ele "bare" ou "working" (veja os detalhes neste post), é apenas um repositório a mais na rede de repositórios associados a um projeto. Somos nós, seres humanos, que impomos as regras e declaramos: "Este aqui é o repositório central. O resto é firula!"

Pois bem, voltando ao assunto, o administrador do sistema onde os repositórios ditos centralizados serão instalados deve executar uma certa quantidade de tarefas, de maneira a manter a ordem mundial. No setup que foi escolhido para a atual VM webserver (e para a futura VM git.cefala.org), um dado repositório será acessado pelos diversos contribuidores através da conta de um único usuário não-humano do sistema. Não confunda não-humano com desumano. Este tal usuário te tratará muito bem, contanto que o administrador do sistema faça a sua parte.

E o assunto carga de trabalho do coitado do administrador volta à tona. Primeiro, ele tem que criar a conta daquele usuário não-humano, levando-se em conta tudo o que a sua não-humanidade exige, como proibir login, apagar eventuais senhas, etc. Em seguida, o nosso pobre administrador tem que criar os repositórios nos lugares certos e com as boas permissões. como exige a boa etiqueta do mundo Unix. Enfim, deve-se também garantir que este usuário não-humano se comunicará polidamente com os usuários mais humanos que compartilharão os repositórios.

Está confuso? Fique tranquilo, eu também fiquei, no início. Após matutar bastante, a maneira mais simples que encontrei para o compartilhamento de repositórios centrais foi através de autentificação por pares de chave SSH. Neste caso as chaves públicas RSA dos contribuidores deverão ser instaladas na conta do usuário não-humano que detém o repositório centralizado. Veja um exemplo de uso em um outro artigo que escrevi.

De modo a simplificar a vida do administrador do servidor git, eu criei uma série de scripts, que coloquei, obviamente, sob controle Git:

$ git clone cefala-admin@git.cefala.org:git-scripts

(N.B.: Você não precisa rodar o comando acima para poder usar os scripts da maneira descrita abaixo na VM git.cefala.org. Rode o git clone acima somente se você estiver curioso para saber como eu escrevi os scripts, ou se você encontrou algum bug e deseja corrigi-lo.)

No momento, existem quatro scripts disponíveis. O primeiro deles permite a criação do tal usuário não-humano:

# add-git-user usuario

Note que este comando deve ser rodado como root ou através do sudo. A conta do usuário será criada, com diretório home /var/git/usuario/, com login shell /usr/bin/git-shell, com senha desabilitada e com números UID et GID maiores que 2000. Esta última medida é necessária para evitar os conflitos futuros, quando as informações das contas dos usuários dos servidores CEFALA serão centralizadas, usando NSS+LDAP ou o que quer que seja.

Em seguida, existe um script para criar o repositório centralizado:

# add-git-repo usuario repositorio.git

O repositório será criado em /var/git/usuario/repositorio.git/. Um outro script permite a instalação das chaves RSA autorizadas:

# add-authorized-keys usuario id_rsa.pub

O arquivo id_rsa.pub é aquele obtido através do comando ssh-keygen e enviado pelo contribuidor. Enfim, o script git_multimail.py também foi incluído no projeto. Este script pode ser utilizado no hook post-receive do repositório centralizado para o envio de notificações automáticas de git push.

Para instalar os scripts no $PATH do sistema, basta rodar make de dentro do repositório clonado git-scripts. Como diria maravilhosamente o Dadá, a vida do administrador agora virou mamão com açúcar.

Update: O script add-authorized-keys aceita agora a opção -r, que força o acesso read-only para a chave sendo adicionada. Neste caso, a pessoa que é proprietária da chave SSH só pode executar os comandos git clone, git pull e git fetch, sendo o git push interditado.