É possível usar o etckeeper com um único repositório git compartilhado?

Question

Notei que várias pessoas recomendaram usar o etckeeper para aplicar o controle de versão ao meu diretório / etc.

Parece-me que a instalação padrão coloca um repositório na mesma máquina que o / etc que você está tentando gerenciar. Isso funciona bem para o controle de versão, mas não oferece o benefício adicional de fazer um backup fora do servidor dos arquivos - ou permitir que eu duplique partes de / etc de uma máquina de origem para outra.

É possível compartilhar um único repositório git em uma máquina admin central, para que o etckeeper em cada servidor armazene seus dados no mesmo lugar?

(Eu estou fazendo uma coisa semelhante agora com svn e alguns scripts personalizados para confirmar e reverter arquivos, mas eu tenho que lembrar de comê-los quando eu fizer alterações.)

    

Answer 1

Primeiro, use install etckeeper, configurado para git em /etc/etckeeper/etckeeper.conf. Siga o método de instalação do etckeeper para sua distro ou da fonte.

Em breve, você terá um /etc/.git

Agora, no servidor, verifique se você tem um repositório (seguro) para enviar para ...

 # ssh faruser@farhost     
 # mkdir somedir cd somedir && git init && chmod 700 .git    
 # exit

Agora, no host inicial, envie seu repositório local para o servidor via ssh:

# cd /etc && git push faruser@farhost:somedir

O Somedir pode ser relativamente relativo neste caso (seguindo a convenção ssh)

Faça isso sempre que fizer uma alteração que afete o / etc (e seja inserido em /etc/.git pelo etckeeper) e você terá repositórios locais e fora da máquina para a sua máquina.

Ou configure o ssh sem senha e crie um gancho em /etc/etckeeper/commit.d/, de modo que isso acontece automaticamente se a máquina estiver sempre conectada.

    

Answer 2

É possível adicionar uma configuração de ramificação remota para mapear a ramificação principal do repositório do etckeeper de cada servidor para uma ramificação no repositório remoto. Para fazer isso, você pode executar os seguintes comandos em cada servidor:

cd /etc
git branch -m master $HOSTNAME
git remote add origin [email protected]:path/to/single/repo.git
git push -u origin master:$HOSTNAME

Após essa configuração, o git push subseqüente enviará as alterações de cada ramificação principal do servidor para a ramificação do servidor dedicado no repositório central.

Embora as ramificações não tenham um ponto de partida comum, isso permite comparar facilmente o mesmo arquivo de duas ramificações diferentes, representando dois servidores diferentes, executando:

git diff origin/server1 origin/server2 -- file

Isso pode ser combinado com a configuração automatizada sugerida por jojoo .

    

Answer 3

Esse não é o ponto. Se você deseja distribuir a configuração amplamente, você configura outro repositório além do repositório local de cada máquina, e tem cada máquina cherry -pique , conforme necessário. O que isto faz é permitir que cada máquina desvie (ramifique-se, na verdade) e retenha o controle de revisão.

    

Answer 4

Como fazer isso automaticamente, a história completa:

Crie o arquivo /etc/etckeeper/commit.d/60-push (não esqueça de chmod + x ele) nos clientes.

#!/bin/sh
git push central_server:/var/git/client_name.git master

central_server é definido na configuração ssh, veja abaixo. /var/git/client_name.git é o diretório no servidor central, contendo o repositório git.

O ~ / .ssh / config da raiz (!) deve conter algo assim:

host central_server
Hostname 192.168.0.1
User etckeeper #a user on the central server 
IdentityFile ~/.ssh/custom_key # key is in authorized_keys in
             #etcpeeper@central_server:~/.ssh/authorized_keys

Então você precisa iniciar o repositório do git no central_server

mkdir /var/git/client_name.git
su etckeeper
cd /var/git/client_name.git
git --bare init

Teste-o com uma edição menor em / etc e depois um commit do etckeeper "test pushing".

    

Answer 5

Você realmente não quer tornar o etckeeper sua política de backup. Embora ter uma cópia dos seus arquivos de configuração seja legal, não é o suficiente para se qualificar como um plano de recuperação de desastres.

Concentre-se em ter backups reais do seu sistema. O simplista poderia ser um cronjob para alimentar um tarball para gravar ... oh, certo. Ninguém mais usa fitas. Ok, um cronjob para rsync todos seus arquivos para um NAS dedicado . Para soluções de backup mais robustas, dê uma olhada em Amanda e Bacula .

E, para o caso dos acadêmicos, eu pude pressionar meu etckeeper repo para github como qualquer outro repositório do git.