Sistemas de controle de versão, ou VCS ou SCM (source code management), como são mais conhecidos, são ferramentas fundamentais para programadores. Com um SCM, o programador — ou toda a equipe de programadores — pode fazer alterações nos arquivos-fonte que compõem um programa e, caso o resultado não seja o desejável, retornar a qualquer uma das versões anteriores.

Contudo, o grupo dos administradores de sistemas logo percebeu que os SCMs também têm uma utilidade muito importante em seus trabalhos diários. Geralmente, nós sysadmins de sistemas GNU/Linux e outros derivados de Unix editamos frequentemente os arquivos de configuração localizados no diretório /etc/. Um princípio do Unix que nos deixa muito felizes é o uso de arquivos de texto puro para armazenar configurações.

Portanto, SCMs são perfeitos para controlar as versões dos próprios arquivos de configuração abrigados no /etc/. Genial, não?

Qual SCM?

Mais uma das do Software Livre: o enorme leque de opções. Temos SCMs para todos os gostos, e os mais indicados são aqueles capazes de armazenar apenas as diferenças entre os arquivos, em vez de armazenar um arquivo inteiro a cada vez que ele é alterado.

Imagine um arquivo que costuma ter apenas um caractere alterado; ele seria copiado por inteiro a cada vez que o SCM detectasse uma alteração. Grande desperdício, não? Por isso, vamos dar preferência àqueles SCMs que só gravam as linhas que foram alteradas. Isso também é TI Verde! ;)

As escolhas de SCM mais comuns na atualidade são:

• Git [Na wikipédia]
• Mercurial [Na wikipédia em inglês]
• Bazaar [[Na wikipédia em inglês http://en.wikipedia.org/wiki/Bazaar_(software)]]
• Darcs [Na wikipédia em inglês]

Todos estes funcionam basicamente da mesma forma: o usuário marca um diretório (o /etc/, no nosso caso) como repositório e começa a fazer commit dos arquivos contidos nesse diretório. Cada commit calcula e armazena apenas as diferenças entre a versão mais atual dos arquivos e a versão anterior. Desta forma, em qualquer momento, é possível recuperar a versão de qualquer um dos arquivos do repositório, pois o SCM simplesmente aplica e "desaplica" as diferenças conforme necessário.

A própria Wikipédia também contém um comparativo de todos os SCMs disponíveis hoje em dia, incluindo as diferenças entre os comandos de cada um deles.

Git

O Git tem grande presença no mercado do Software Livre. Criado originalmente pelo próprio Linus Torvalds, é extremamente rápido e seus usuários, segundo o website, incluem o frenético kernel Linux, o ambiente desktop Gnome, o sistema operacional Android e as distribuições GNU/Linux Fedora e Debian, entre outros.

Uma desvantagem teórica do Git é sua "composição": shell script, Perl e C. Porém, seu ótimo desempenho mostra que esse design de fato não acarreta problemas.

Por esses motivos, este artigo usará o Git como SCM para criar nossa solução de versionamento do /etc/.

Técnica "sujinha" e rápida: cronjob

A primeira técnica que vou apresentar é a mais "sujinha". Ela consiste em "bater fotografias" do /etc/ em intervalos regulares. Como o Git sempre verifica se há diferenças entre a última versão dos arquivos e a versão atual, não corremos o risco de gravar "fotografias" desnecessariamente; elas só serão gravadas quando houver diferenças.

Dependendo do seu ritmo de alterações no /etc/, é possível ajustar os intervalos de "fotografias" do /etc/. Se você sofre de ansiedade :) (como eu), talvez seja melhor capturar as alterações a cada hora. Caso contrário, uma vez por dia deve ser suficiente.

A sequência de comandos do Git (e seus resultados) para inicializar um repositório é:

  $ cd /etc
  $ git init
  Initialized empty Git repository in /etc/.git/
  $ git add .
  $ git commit -a -m "Primeiro commit"
  [master (root-commit) 417e323] Primeiro commit
  54 files changed, 8171 insertions(+), 0 deletions(-)
  (...)

Feito isso, seu /etc/ já pode começar a ser avaliado pelo Git.

Passadas algumas alterações em seus arquivos de configuração, você só precisa de um único comando para armazená-las no Git:

  $ git commit -a -m "$(date '+%Y-%m-%d--%H:%M')"
  [master bda8047] 2010-10-07--14:46
  (...)

Git não (re)conhece arquivos novos!

Porém, se você tiver instalado um novo pacote, que por sua vez criou um novo arquivo de configuração no /etc/, o Git ainda não o conhecerá. Para resolver isso, é importante apresentá-los um ao outro antes do commit, da seguinte forma:

  $ git add .
  $ git commit -a -m "$(date '+%Y-%m-%d--%H:%M')"
  [master bda8047] 2010-10-07--14:46
  (...)

Agora no Cron

Agora que já sabemos como adicionar novos arquivos ao "repositório" gerenciado pelo Git, basta mandarmos o Cron se encarregar disso.

Adicione ao diretório /etc/cron.daily/ (ou /etc/cron.hourly/, para capturar as alterações a cada hora) um arquivo (sugiro o nome gitetc) com o seguinte conteúdo:

  #!/bin/sh
  
  # Executar 'git commit -a' no /etc
  # Esta é uma ótima forma de manter versões
  # de todos os arquivos de configuração.
  
  cd /etc/
  git add .
  git commit -a -m "Commit automático em $(date '+%d/%m/%Y às %H:%M:%S')"
  
  exit 0

Por último, não se esqueça de tornar o seu script executável!

  $ chmod a+x /etc/cron.daily/gitetc

A partir de agora, o seu script entrará em ação uma vez por dia (ou por hora, caso você tenha usado o diretório /etc/cron.hourly/) para capturar as alteerações do /etc/ com o Git.

Problemas à frente!

Esta abordagem é "sujinha" por conta de um tipo muito comum de problema: imagine que seu sistema esteja instalando um pacote no momento em que o script gitetc é disparado. O /etc/ pode conter apenas alguns arquivos do pacote, pois os demais ainda não foram gravados naquele momento.

Outro problema: se você estiver testando várias alterações em um arquivo do /etc/, o script só vai entrar em ação a cada hora (no máximo), a menos que você o faça ser executado com maior frequência editando diretamente o arquivo /etc/crontab.

Se esses problemas não parecem ruins demais para você, esta abordagem é simples e prática.

Tamanho e manutenção do repositório

Com o passar do tempo, o Git pode acabar acumulando arquivos desnecessários, que posteriormente venham a ser apagados, por exemplo. Ele não apaga esse "lixo" sozinho. Porém, há um comando exatamente para isso: git gc (de garbage collector).

O Git também é econômico quanto ao espaço em disco — um resultado do armazenamento apenas das linhas alteradas. Para dar um exemplo, o diretório /etc/ em meu laptop ocupa 12 MB e é controlado pelo Git pelo método "sujinho". Após um mês de execuções do script a cada hora, os arquivos do repositório Git ocupam apenas 2,6 MB.

Sujinho com outros SCMs

Como você já deve ter imaginado, substituir o Git pelo Mercurial ou Bazaar ou Darcs no método "sujinho" é muito fácil: basta conferir os comandos equivalentes nesses SCMs. A Wikipédia é muito amiga nessas horas. ;)

Método elegante

O "jeito certo" de colocar o /etc/ sob supervisão de um SCM é usar o etckeeper. Trata-se de um conjunto de ferramentas que se associam ao gerenciador de pacotes (apt, yum ou pacman-g2) e, a cada vez que o gerenciador instala ou atualiza um pacote, o SCM cadastra eventuais novos arquivos no /etc/ e armazena qualquer alteração feita aos já existentes.

O etckeeper sabe utilizar todos os quatro SCMs que este artigo cita: Git, Mercurial, Bazaar e Darcs. Ele já conta com um pacote na maioria das distribuições, bastando um apt-get ou yum para instalá-lo.

A configuração do etckeeper é simples: abra o arquivo /etc/etckeeper/etckeeper.conf e escolha a opção de SCM (ou VCS — Version Control System, como o arquivo chama) que mais lhe agradar:

  # The VCS to use.
  #VCS="hg"
  VCS="git"
  #VCS="bzr"
  #VCS="darcs"
  (...)

Em seguida, informe o gerenciador de pacotes de alto nível (yum no caso do Fedora e Red Hat, apt no caso do Ubuntu e Debian) e de baixo nível (respectivamente, rpm e dpkg):

  (...)
  # The high-level package manager that's being used.
  # (apt, pacman-g2, yum etc)
  HIGHLEVEL_PACKAGE_MANAGER=yum
  
  # The low-level package manager that's being used.
  # (dpkg, rpm, pacman-g2, etc)
  LOWLEVEL_PACKAGE_MANAGER=rpm

Esse arquivo de configuração já mostra o bom trabalho de integração realizado pelo etckeeper: ele se acopla aos gerenciadores de pacotes para saber quando há novos arquivos no /etc/ e quando eles podem ter sido alterados.

E as alterações manuais?

No entanto, não são somente os gerenciadores de pacotes que fazem alterações nos seus arquivos do /etc/, certo? Você também as faz. Portanto, é importante que o etckeeper execute com alguma frequência o commit do SCM subjacente.

Dê uma olhada no diretório /etc/cron.daily/ e veja que existe um arquivo chamado etckeeper lá dentro. Esse é o script que chama o programa uma vez por dia para armazenar evetuais alterações.

Da mesma forma que podemos escolher a frequência dos commits no jeito "sujinho", o etckeeper também permite isso: basta mover o script do diretório /etc/cron.daily/ para o diretório /etc/cron.hourly/.

Ao terminar de preparar o etckeeper, inicialize seu repositório com o comando etckeeper init. Isso é necessário para que o etckeeper consiga começar a acompanhar as alterações.

Recuperação

Então quer dizer que você finalmente conseguiu: alterou tanto algum arquivo de configuração que já não sabe mais como ele era quando funcionava. Parabéns! :)

Por sorte, você já está usando uma das ferramentas de controle de versões no /etc/ e pode recuperar qualquer arquivo para praticamente qualquer estado anterior. Vamos lá.

Até que dia e hora o arquivo funcionava? Ontem? Confira os seus últimos commits com:

  $ cd /etc
  $ git log

Esse comando retornará toda a lista de commits mais recentes. Note que cada commit possui um longo número que parece um hash:

  commit 86640ba783d97ca1b55fc8bef50c7d4cc3272813

Quer ver o que esse commit tem de diferente do anterior? Basta um git show:

  $ git show 86640ba783d97ca1b55fc8bef50c7d4cc3272813

Para recuperar o estado do /etc/ logo após aquele commit, use o git checkout:

  $ git checkout 86640ba783d97ca1b55fc8bef50c7d4cc3272813
  Note: checking out '86640ba783d97ca1b55fc8bef50c7d4cc3272813'.
  
  You are in 'detached HEAD' state. You can look around, make experimental
  changes and commit them, and you can discard any commits you make in this
  state without impacting any branches by performing another checkout.
  
  If you want to create a new branch to retain commits you create, you may
  do so (now or later) by using -b with the checkout command again. Example:
  
    git checkout -b new_branch_name
  
  HEAD is now at 7b811da... Automatic commit on 07/10/2010 at 00:03:03
  $ _

Feito isso, todos os arquivos do /etc/ estarão no estado em que se encontravam no momento daquele commit. Você pode criar um novo ramo (branch), dar nomes a ramos específicos (ação chamada de tag) e até recuperar arquivos apagados por engano e muito mais:

  $ cd /etc
  $ rm um_arquivo
  $ ls um_arquivo
  ls: impossível acessar um_arquivo: Arquivo ou diretório não encontrado
  $ git checkout um_arquivo
  $ ls um_arquivo
  um_arquivo
  $ _

Nada mal, hein?

Conclusão

Nas atividades diárias do sysadmin, provavelmente o checkout de versões anteriores do arquivo e a recuperação de arquivos apagados serão os recursos mais importantes e mais usados.

Porém, tanto o Git quanto os outros SCMs podem fazer muito mais do que isso.

Confira a documentação de cada SCM para desfrutar de todo o poder que eles oferecem.

Até a próxima!

Outros artigos deste autor

• Servidores atacados: culpa do distribuidor do kernel?
• Dica rápida: calendário anual no OpenOffice.org- Prompt de Bash mais útil
• Bê-á-bá do SSH, parte 9: Controle de acesso
• O planeta inteligente, na visão da IBM. Temos tempo até a Copa do Mundo?
• As novidades do kernel Linux 2.6.35
• Bê-á-bá do SSH, parte 8: Proxy HTTP em túnel
• Bê-á-bá do SSH, parte 7: Túneis
• Snapshots COW para os menos favorecidos: cron, rsync e hardlinks
• Bê-á-bá do SSH, parte 6: X remoto
• Bê-a-bá do SSH, parte 5: O uso da randomart
• Bê-a-bá do SSH, parte 4: Execução de comandos remotos
• Bê-á-bá do SSH, parte 3: Trabalhando com chaves criptográficas públicas e privadas
• Be-a-bá do SSH, parte 2: Cópia de arquivos pela rede
• Bê-á-bá do SSH, parte 1: Apresentação do SSH
• As novidades do kernel Linux 2.6.34
• Tux3, o sistema de arquivos que (mais uma vez) não aconteceu
• Compiladores melhorados pela genética
• TI Verde com Linux e Software Livre

Marcações:  git