O CVS (Concurrent Version System) é uma ferramenta para desenvolvimento colaborativo, largamente utilizada no mundo opensource. Neste artigo eu mostro como configurar um servidor CVS no Fedora Core habilitando acesso remoto ao repositório.
Instalação
É necessário instalar o servidor xinetd e o pacote cvs.
# yum install xinetd cvs
Criar usuário e grupo para o cvs
Edite o arquivo /etc/passwd e adicione a seguinte linha:
cvs:*:287:287::0:0:CVS account:/var/cvsroot:/sbin/nologin
Depois edite o arquivo /etc/group e adicione:
cvs:*:287:
Eu estou usando 287 como UID e GUI, mas você pode usar qualquer um. O diretório do usuário também pode e deve ser alterado para o local onde vai ficar o repositório.
Criar a estrutura de diretórios para o repositório
# mkdir /var/cvsroot
# chown cvs.cvs /var/cvsroot
# chmod 771 /var/cvsroot
Vamos definir o stick bit para o grupo no diretório do repositório, assim tudo que for criado dentro deste diretório vai ter o grupo setado para cvs. Mais detalhes sobre segurança e permissões serão explanados adiante.
#chmod g+s /var/cvsroot
Iniciar o serviço cvs no xinetd
Vamos criar o serviço cvs no arquivo /etc/xinet.d/cvs. Adicione as seguinte linhas:
service cvspserver
{
#disable = true
port = 2401
socket_type = stream
protocol = tcp
wait = no
user = root
passenv = PATH
server = /usr/bin/cvs
env = HOME=/var/cvsroot
server_args = -f –allow-root=/var/cvsroot pserver
# bind = 127.0.0.1
}
Recarregue o serviço e verifique se tudo ocorreu bem nos logs:
#service xinetd reload
#tail /var/log/messages
Inicializar o repositório
Agora vamos inicializar o repositório CVS. Vamos definir a variável CVSROOT que é usada pelo comando cvs. Caso ela não for declarada é necessário passar o parâmetro “-d /path/repo” nas chamadas ao comando cvs.
# export CVSROOT=/var/cvsroot
# cvs init
Após a inicialização será criado um diretório CVSROOT onde ficarão arquivos de controle e configuração do repositório. Vamos alterar as permissões para o usuário cvs poder alterar estes arquivos.
#chmod u+w -R /var/cvsroot/CVSROOT
Testar o repositório
Vamos criar um diretório com um ou dois arquivos para testar o cvs.
# mkdir testecvs && cd testecvs && touch arq1 && touch arq2
Agora vamos importar este diretório para o repositório cvs sob o nome “testecvs”
# cvs import -m “release inicial” testecvs vendortag releasetag
N testecvs/arq1
N testecvs/arq2
No conflicts created by this import
Após este comando será criado um diretório “testecvs” em /var/cvsroot.
Testar o acesso remoto
Agora vamos tentar acessar o repositório a partir de outro computador na rede. Nossa configuração inicial está preparada para ser acessada via “pserver”, que por padrão permite que qualquer usuário com uma conta no sistema possa acessar o repositório. A seguir veremos como mudar isso, mas antes vamos testar a configuração padrão.
O comando abaixo vai fazer um “checkout” do módulo que criamos antes para o computador local. Lembrando que podemos definir uma variável de ambiente CVSROOT para não ter que informar o parâmetro -d. Aqui vou fazer sem para exemplificar.
# cvs -d :pserver:neimar@SERVIDOR:/var/cvsroot co testecvs
cvs checkout: CVS password file /home/neimar/.cvspass does not exist – creating a new file
cvs checkout: authorization failed: server SERVIDOR rejected access to /VAR/cvsroot for user neimar
cvs checkout: used empty password; try “cvs login” with a real password
O erro acima ocorre pois temos que fazer login no cvs antes de fazer checkout. Vamo lá:
# cvs -d :pserver:neimar@SERVIDOR:/var/cvsroot login
CVS password:
cvs login: CVS password file /home/neimar/.cvspass does not exist – creating a new file
Agora estamos logados no servidor, vamos repetir o comando de checkout.
# cvs -d :pserver:SERVIDOR:/var/cvsroot co testecvs
cvs checkout: failed to create lock directory for `/data/var/cvs/CVSROOT’ (/data/var/cvs/CVSROOT/#cvs.history.lock): Permission denied
cvs checkout: failed to obtain history lock in repository `/data/var/cvs’
cvs checkout: Updating testecvs
cvs checkout: failed to create lock directory for `/data/var/cvs/testecvs’ (/data/var/cvs/testecvs/#cvs.lock): Permission denied
cvs checkout: failed to obtain dir lock in repository `/data/var/cvs/testecvs’
cvs [checkout aborted]: read lock failed – giving up
O erro acima ocorre porque as permissões iniciais que foram dadas ao diretório cvs foram para apenas o usuário/grupo cvs gravarem. Neste caso o usuário que acessou o repositório foi “neimar” e este usuário não tem acesso para gravar. Uma solução simples neste caso seria adicionar o meu usuário ao grupo cvs no servidor.
# usermod -G cvs neimar
Desta forma o meu usuário vai poder criar arquivos.
Como mencionado anteriormente a configuração padrão do cvs permite que qualquer usuário com conta no sistema acesse o repositório mas isso nem sempre é o desejável. A seguir vou demonstrar como configurar os usuários do cvs isoladamente dos usuários do sistema.
Configurando Acesso ao Repositório
Na configuração inicial deste repositório foram definidas permissões de leitura e escrita para o usuário cvs e para o grupo cvs, quaisquer usuários que queiram acessar e manipular dados no repositório devem ser adicionados ao grupo cvs, caso contrário não vão conseguir acessar ou criar dados.
Quando um usuário criar um novos arquivos ou alterar arquivos já existentes no repositório, esses arquivos/diretórios vão ser criados tendo como dono o próprio usuário que fez o acesso e o grupo será sempre cvs, isso porque ao criar o diretório do repositório definimos o stick bit para o grupo.
Da forma como está configurado agora o nosso servidor cvs controla o acesso, de forma bem rudimentar e limitada, através do grupo cvs. Usuários neste grupo tem acesso total ao repositório. Os demais usuários do sistema também terão acesso mas não conseguirão fazer checkout dos arquivos pois para isso é necessário criar arquivos de lock no diretório CVSROOT e eles não tem essas permissões.
Neste ponto já temos um servidor cvs funcional, pele menos para um ambiente simples, o que é geralmente suficiente para a maioria dos desenvolvedores que trabalham sozinhos ou em grupos pequenos.
A seguir vamos configurar o servidor cvs para que possamos controlar os usuários e as permissões de acesso independente dos usuários e da segurança do sistema operacional.
Controle de Acesso e Segurança Avançados
Vamos configurar o nosso servidor cvs para que ele mesmo gerencie os usuários que tem acesso ao repositório.
# vi /var/cvsroot/CVSROOT/config
Temos que descomentar a linha abaixo para desabilitar a autenticação via sistema.
SystemAuth=no
Neste momento o servidor cvs já não vai mais aceitar o acesso como antes. Faça um teste a partir de outro computador.
# cvs -d:pserver:neimar@SERVIDOR:/var/cvsroot login
cvs login: authorization failed: server SERVIDOR rejected access to var/cvs for user neimar
Agora o cvs vai utilizar o arquivo /var/cvsroot/CVSROOT/passwd para gerenciar o acesso. Esse arquivo tem o seguinte formato:
USUARIO_CVS:SENHA:USUARIO_SISTEMA
O primeiro campo é o nome do usuário no cvs (que vai ser usado para conectar), o segundo é a senha, criptografada como em /etc/shadow e o terceiro campo é o usuário do sistema relacionado a este usuário, ou seja, o usuário do cvs vai servir para login mas vai ser com as permissões do usuário do sistema que os arquivos serão manipulados.
Além do arquivo passwd, existem outros dois arquivos interessantes, são o readers e o writers. Nestes arquivos serão informados os usuários com permissão somente leitura e escrita, respectivamente.
Vamos criar estes arquivos:
# cd /var/cvsroot/CVSROOT/
# touch passwd
# vi readers
# vi writers
Vamos adicionar usuários para testar o acesso.
# vi passwd
—-
neimar:
testecvs:xx:cvs
—–
Vamos manter o usuário “neimar” liberado para o cvs, com a mesma senha do sistema. A primeira linha acima (sem informar senha ou usuário do SO) permite que isso seja feito. Já a segunda linha cria o usuário “testecvs” que na verdade atua como o usuário cvs no sistema.
Vamos fazer novo teste de acesso com ambos:
# cvs -d:pserver:neimar@SERVIDOR:/var/cvsroot login
O login deve acontecer normalmente.
# cvs -d:pserver:testecvs@SERVIDOR:/var/cvsroot login
Já o login acima não vai ocorrer porque não definimos a senha para o usuário “testecvs”. Façamos isso da seguinte forma:
??????????????????
cvs -d:pserver:testecvs@ramses:/data/var/cvs co testecvscvs checkout: Updating testecvs
U testecvs/a1
U testecvs/a2
Altere um dos arquivos e vamos enviar de volta para o repositório:
neimar@neimar:~/var/testecvs$ cvs -d:pserver:testecvs@ramses:/data/var/cvs commit
cvs commit: Examining .
Log message unchanged or not specified
a)bort, c)ontinue, e)dit, !)reuse this message unchanged for remaining dirs
Action: (continue) c
? arq2
cvs [server aborted]: “commit” requires write access to the repository
Nosso usuário testecvs tem acesso somente leitura, se tentarmos um “commit” o erro acima vai ocorrer, caso queiramos que ele grave no repositório temos que adicioná-lo ao arquivo writers.
# echo testecvs >> writers
Tente novamente agora e vai funcionar.
Se verificarmos as permissões nos arquivos diretamente no repositório veremos que o dono dos arquivos modificados será o “cvs” pois o usuário testecvs está relacionado ao usuário “cvs” no arquivo passwd.
Configurando um usuário para acesso Anônimo
Em breve …
Configurando o Acesso via SSH
Em breve …
Referências
http://kelvinchufei.blogspot.com/2007/03/how-to-setup-cvs-server-on-fedora-core.html
http://www.linuxfromscratch.org/blfs/view/svn/server/cvsserver.html
