Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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.)

share|improve this question

4 Answers 4

up vote 7 down vote accepted

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.

share|improve this answer
    
Thanks Tony, I think this is what I am looking for. –  Brent Jul 8 '09 at 17:22
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 6:37

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.

share|improve this answer
    
Not sure how to do this (second repository). Can you elaborate? –  Brent Jun 20 '09 at 4: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 kernel.org/pub/software/scm/git-core/docs/gittutorial.html –  jldugger Jun 20 '09 at 7:17

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".

share|improve this answer

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.

share|improve this answer
    
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 (reductivelabs.com/products/puppet) would be of some help there. –  Shazburg Jun 21 '09 at 1: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 2 '13 at 8:29

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.