È possibile usare etckeeper con un singolo repository git condiviso?

Ho notato che molte persone hanno raccomandato di usare etckeeper per applicare il controllo della versione alla mia directory / etc.

Mi sembra che l'installazione predefinita inserisca un repository sullo stesso computer del file / etc che stai cercando di gestire. Funziona bene per il controllo della versione, ma non offre l'ulteriore vantaggio di eseguire un backup off-server dei file, né mi consente di duplicare parti di / etc da un computer di origine a un altro.

È possibile condividere un singolo repository git su una macchina di amministrazione centrale, in modo che etckeeper su ciascun server memorizzi i suoi dati nello stesso posto?

(Sto facendo una cosa simile ora con svn e alcuni script personalizzati per eseguire il commit e il ripristino dei file, ma devo ricordare di impegnarli quando apporto le modifiche.)

Innanzitutto, usa install etckeeper, configurato per git in /etc/etckeeper/etckeeper.conf. Segui il metodo di installazione di etckeeper per la tua distribuzione o dalla fonte.

Presto avrai un /etc/.git

Ora sul tuo server, assicurati di avere un repository (sicuro) da inviare a ...

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

Ora sull'host iniziale, invia il repository locale al server tramite ssh:

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

Naturalmente Somedir può essere relativo in questo caso (seguendo la convenzione SSH)

Fallo ogni volta che apporti una modifica che influisce su / etc (e viene inserito in /etc/.git da etckeeper) e avrai repository locali e off-machine per la tua macchina.

Oppure imposta ssh senza password e aggancia /etc/etckeeper/commit.d/ in modo che accada automagicamente se la macchina è sempre connessa.

È possibile aggiungere una configurazione di ramo remoto per mappare il ramo principale del repository etckeeper da ciascun server a un ramo sul repository remoto. Per fare ciò è possibile eseguire i seguenti comandi su ciascun server:

cd /etc
git branch -m master $HOSTNAME
git remote add origin git@git.example.com:path/to/single/repo.git
git push -u origin master:$HOSTNAME

Dopo questa configurazione, successivamente git pushinvierà le modifiche da ciascun ramo principale del server al ramo del server dedicato sul repository centrale.

Sebbene i rami non abbiano un punto di partenza comune, ciò consente di confrontare facilmente lo stesso file da due rami diversi, che rappresentano due server diversi, eseguendo:

git diff origin/server1 origin/server2 -- file

Questo può essere combinato con la configurazione automatica suggerita da jojoo .

Come farlo automaticamente, la storia completa:

Crea il file /etc/etckeeper/commit.d/60-push (non dimenticare di chmod + x esso) sui client.

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

central_server è definito nella configurazione di ssh, vedi sotto. /var/git/client_name.git è la directory sul server centrale, contenente il repository git.

~ / .Ssh / config da root (!) Dovrebbe contenere qualcosa del genere:

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

Quindi è necessario avviare il repository git su central_server

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

Provalo con una modifica minore in / etc e poi un etckeeper commette "test push'ing".

Non è questo il punto. Se si desidera distribuire ampiamente la configurazione, è necessario impostare un altro repository in aggiunta al repository locale di ogni macchina e fare in modo che ogni macchina scelga da esso come necessario. Quello che fa è consentire a ogni macchina di deviare (diramare, realmente) e mantenere il controllo di revisione.

Non vuoi davvero rendere etckeeper la tua politica di backup. Avere una copia dei file di configurazione sarebbe utile, ma non è abbastanza per qualificarsi come piano di ripristino di emergenza.

Concentrati invece sull'avere veri backup del tuo sistema. Il semplicista potrebbe essere un cronjob per alimentare un tarball su nastro ... oh, giusto. Nessuno usa più i nastri. Ok, un cronjob per risincronizzare tutti i tuoi file su un NAS dedicato . Per soluzioni di backup più robuste, dai un'occhiata ad Amanda e Bacula .

E nel caso degli accademici, sono stato in grado di spingere il mio repo etckeeper su github proprio come qualsiasi altro repo git.