¿Es posible usar etckeeper con un único repositorio git compartido?

Noté que varias personas me han recomendado usar etckeeper para aplicar el control de versiones a mi directorio / etc.

Me parece que la instalación predeterminada coloca un repositorio en la misma máquina que el / etc que está tratando de administrar. Esto funciona bien para el control de versiones, pero no brinda el beneficio adicional de hacer una copia de seguridad de los archivos fuera del servidor, ni me permite duplicar partes de / etc de una máquina fuente a otra.

¿Es posible compartir un único repositorio git en una máquina de administración central, de modo que etckeeper en cada servidor almacene sus datos en el mismo lugar?

(Estoy haciendo algo similar ahora con svn y algunos scripts personalizados para confirmar y revertir archivos, pero tengo que acordarme de confirmarlos cuando realice cambios).

Primero, use install etckeeper, configurado para git en /etc/etckeeper/etckeeper.conf. Siga el método de instalación de etckeeper para su distribución o desde la fuente.

Pronto tendrás un /etc/.git

Ahora en su servidor, asegúrese de tener un repositorio (seguro) para impulsar ...

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

Ahora en el host inicial, envíe su repositorio local al servidor a través de ssh:

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

Somedir, por supuesto, puede ser relativo en este caso (siguiendo la convención ssh)

Haga esto cada vez que realice un cambio que afecte a / etc (y etckeeper lo agregue a /etc/.git) y tendrá repositorios locales y fuera de la máquina para su máquina.

O configure ssh sin contraseña y realice un enlace en /etc/etckeeper/commit.d/ para que ocurra automáticamente si la máquina siempre está conectada.

Es posible agregar una configuración de bifurcación remota para asignar la bifurcación maestra del repositorio etckeeper de cada servidor a una bifurcación en el repositorio remoto. Para hacerlo, puede ejecutar los siguientes comandos en 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

Después de esta configuración, los siguientes git pushenviarán cambios desde cada rama maestra del servidor a la rama del servidor dedicado en el repositorio central.

Aunque las ramas no tendrán un punto de partida común, esto permite comparar fácilmente el mismo archivo de dos ramas diferentes, que representan dos servidores diferentes, ejecutando:

git diff origin/server1 origin/server2 -- file

Esto se puede combinar con la configuración automática sugerida por jojoo .

Cómo hacerlo automáticamente, la historia completa:

Cree el archivo /etc/etckeeper/commit.d/60-push (no olvide chmod + x) en los clientes.

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

central_server se define en la configuración ssh, ver más abajo. /var/git/client_name.git es el directorio en el servidor central, que contiene el repositorio git.

El ~ / .ssh / config de root (!) Debería contener algo como esto:

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

Luego debe iniciar el repositorio git en el servidor central

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

Pruébelo con una edición menor en / etc y luego un etckeeper comete "test push'ing".

Ese no es el punto. Si desea distribuir ampliamente la configuración, configure otro repositorio además del repositorio local de cada máquina, y haga que cada máquina elija según sea necesario. Lo que esto hace es permitir que cada máquina se desvíe (se ramifique, realmente) y retenga el control de revisión.

Realmente no desea que etckeeper sea su política de respaldo. Si bien tener una copia de sus archivos de configuración sería bueno, no es suficiente para calificar como un plan de recuperación ante desastres.

Concéntrese en tener copias de seguridad reales de su sistema. El simplista podría ser un cronjob para alimentar un tarball a la cinta ... oh, cierto. Ya nadie usa cintas. Bien, un trabajo temporal para sincronizar todos sus archivos a un NAS dedicado . Para obtener soluciones de respaldo más sólidas, eche un vistazo a Amanda y Bacula .

Y para el caso de los académicos, pude llevar mi repositorio etckeeper a github como cualquier otro repositorio git.