10

I noticed that several people have recommended using etckeeper to apply version control to my /etc directory.

It appears to me that the default install puts a repository on the same machine as the /etc you are trying to manage. This works fine for version control, but doesn't give the added benefit of making an off-server backup of the files - or allow me to duplicate portions of /etc from one source machine to another.

Is it possible to share a single git repository on a central admin machine, so that etckeeper on each server stores its data in the same place?

(I am doing a similar thing now with svn and some custom scripts to commit and revert files, but I have to remember to commit them when I make changes.)

quanta
  • 50,327
  • 19
  • 152
  • 213
Brent
  • 22,219
  • 19
  • 68
  • 102

5 Answers5

8

First, use install etckeeper, configured for git in /etc/etckeeper/etckeeper.conf. Follow etckeeper's install method for your distro or from source.

Soon, you'll have a /etc/.git

Now on on your server, make sure you have a (safe) repo to push to...

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

Now on the initial host, push your local repo to the server via ssh:

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

Somedir can of course be relative in this case (following ssh convention)

Do this any time you make a change that affects /etc (and is snarfed into /etc/.git by etckeeper) and you'll have both local and off-machine repos for your machine.

Or set up passwordless ssh and make a hook in /etc/etckeeper/commit.d/ so it happens automagically if the machine is always connected.

quanta
  • 50,327
  • 19
  • 152
  • 213
  • 2
    This looks great. Is there a way to have the local repository stored in a subdirectory of the remote one? I'd like to do something similar, using a single remote repository to store the (separate) configurations for several servers. – Andrew Ferrier May 24 '10 at 18:00
  • can `git push` works towards your created git repo ? probably you need create bare repo in somedir the hook under commit.d is really good idea, I like it – larrycai May 15 '12 at 06:37
4

It is possible to add a remote branch configuration to map the master branch of etckeeper repository from each server to a branch on the remote repository. To do that you can run the following commands on each 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

After this setup, subsequent git push will send changes from each server master branch to the dedicated server branch on the central repository.

Although the branches will not have a common starting point, this allows to easily compare the same file from two different branches, representing two different servers, by running:

git diff origin/server1 origin/server2 -- file

This can be combined with the automated setup suggested by jojoo.

TTT
  • 41
  • 2
  • git push -u origin master:$HOSTNAME does not work here. Remote repo is an empty bare repo. error: src refspec master does not match any. – Bertl Oct 07 '16 at 08:38
2

How to do it automatically, the full story:

Create the file /etc/etckeeper/commit.d/60-push (dont forget to chmod+x it) on the clients.

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

central_server is defined in the ssh config, see below. /var/git/client_name.git is the directory on the central server, containing the git repo.

The ~/.ssh/config from root(!) should contain something like this:

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

Then you need to init the git repo on the central_server

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

Test it with a minor edit in /etc and then a etckeeper commit "test push'ing".

jojoo
  • 444
  • 3
  • 10
1

That's not the point. If you want to distribute configuration widely, you set up another repository in addition to each machine's local repo, and have each machine cherry-pick from it as needed. What this does is allow each machine to deviate (branch, really) and retain revision control.

Anthony Geoghegan
  • 2,800
  • 1
  • 23
  • 34
jldugger
  • 14,122
  • 19
  • 73
  • 129
  • Not sure how to do this (second repository). Can you elaborate? – Brent Jun 20 '09 at 04:03
  • You probably need to clone one of the repos onto your "central repo"; you only need one. From there you can make changes, and then each of the servers can cherry-pick the patches stored in a revision. How you set it up initially varies between DSCMs. For git, see http://www.kernel.org/pub/software/scm/git-core/docs/gittutorial.html – jldugger Jun 20 '09 at 07:17
-2

You really don't want to make etckeeper your backup policy. While having a copy of your config files would be nice, it's hardly enough to qualify as a disaster recovery plan.

Focus on having real backups of your system instead. The simplist could be a cronjob for feeding a tarball to tape... oh, right. No one uses tapes anymore. Okay, a cronjob to rsync all your files to a dedicated NAS. For more robust backup solutions, take a look at Amanda and Bacula.

And for the case of academics, I was able to push my etckeeper repo up to github just like any other git repo.

Shazburg
  • 634
  • 4
  • 11
  • Nobody's talking about making this a backup policy. But in my experience it IS convenient to have everything in one place, on a more secure server. – Brent Jun 20 '09 at 12:57
  • 1
    Then I misunderstood. If what you're really looking for is a means to centrally store and distribute your systems configuration, then maybe Puppet (http://reductivelabs.com/products/puppet) would be of some help there. – Shazburg Jun 21 '09 at 01:25
  • for an example: we're pushing all our configurations to one host. there runs a trac, which is used for visualizing the config changes (and of course write tickets, if something doesn't work, ...) imo it's super-convinient, i can for an example compare the crontabs from all our hosts with a few clicks. – jojoo Feb 02 '13 at 08:29