Est-il possible d'utiliser etckeeper avec un seul dépôt git partagé?

J'ai remarqué que plusieurs personnes ont recommandé d'utiliser etckeeper pour appliquer le contrôle de version à mon répertoire / etc.

Il me semble que l'installation par défaut place un référentiel sur la même machine que le / etc que vous essayez de gérer. Cela fonctionne bien pour le contrôle de version, mais ne donne pas l'avantage supplémentaire de faire une sauvegarde hors serveur des fichiers - ou me permet de dupliquer des parties de / etc d'une machine source à une autre.

Est-il possible de partager un seul dépôt git sur une machine d'administration centrale, de sorte que etckeeper sur chaque serveur stocke ses données au même endroit?

(Je fais maintenant une chose similaire avec svn et certains scripts personnalisés pour valider et restaurer des fichiers, mais je dois me rappeler de les valider lorsque j'apporte des modifications.)

Tout d'abord, utilisez install etckeeper, configuré pour git dans /etc/etckeeper/etckeeper.conf. Suivez la méthode d'installation de etckeeper pour votre distribution ou depuis la source.

Bientôt, vous aurez un /etc/.git

Maintenant sur votre serveur, assurez-vous d'avoir un dépôt (sûr) à pousser pour ...

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

Maintenant sur l'hôte initial, envoyez votre dépôt local au serveur via ssh:

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

Somedir peut bien sûr être relatif dans ce cas (suivant la convention ssh)

Faites-le chaque fois que vous apportez une modification qui affecte / etc (et est intégrée dans /etc/.git par etckeeper) et vous aurez à la fois des référentiels locaux et hors machine pour votre machine.

Ou configurez ssh sans mot de passe et créez un hook dans /etc/etckeeper/commit.d/ afin que cela se produise automatiquement si la machine est toujours connectée.

Il est possible d'ajouter une configuration de branche distante pour mapper la branche principale du référentiel etckeeper de chaque serveur à une branche du référentiel distant. Pour ce faire, vous pouvez exécuter les commandes suivantes sur chaque serveur:

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

Après cette configuration, les suivantes git pushenverront les modifications de chaque branche principale de serveur à la branche de serveur dédiée sur le référentiel central.

Bien que les branches n'aient pas de point de départ commun, cela permet de comparer facilement le même fichier de deux branches différentes, représentant deux serveurs différents, en exécutant:

git diff origin/server1 origin/server2 -- file

Ceci peut être combiné avec la configuration automatisée suggérée par jojoo .

Comment le faire automatiquement, l'histoire complète:

Créez le fichier /etc/etckeeper/commit.d/60-push (n'oubliez pas de chmod + x it) sur les clients.

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

central_server est défini dans la configuration ssh, voir ci-dessous. /var/git/client_name.git est le répertoire du serveur central, contenant le dépôt git.

La configuration ~ / .ssh / de root (!) Devrait contenir quelque chose comme ceci:

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

Ensuite, vous devez lancer le dépôt git sur le serveur central

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

Testez-le avec une modification mineure dans / etc puis un etckeeper commit "test push'ing".

Ce n'est pas le propos. Si vous souhaitez diffuser largement la configuration, vous configurez un autre référentiel en plus du référentiel local de chaque machine, et vous avez le choix entre chaque machine si nécessaire. Cela permet à chaque machine de dévier (branche, vraiment) et de conserver le contrôle des révisions.

Vous ne voulez vraiment pas faire de etckeeper votre politique de sauvegarde. Bien qu'il soit bien d'avoir une copie de vos fichiers de configuration, ce n'est guère suffisant pour être considéré comme un plan de reprise après sinistre.

Concentrez-vous plutôt sur de véritables sauvegardes de votre système. Le simpliste pourrait être un cronjob pour alimenter une tarball sur bande ... oh, c'est vrai. Personne n'utilise plus de bandes. D'accord, un cronjob pour rsync tous vos fichiers sur un NAS dédié . Pour des solutions de sauvegarde plus robustes, jetez un œil à Amanda et Bacula .

Et pour le cas des universitaires, j'ai pu pousser mon repo etckeeper jusqu'à github comme tout autre git repo.