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

5 Answers 5


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.

  • 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. May 24, 2010 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, 2012 at 6:37

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.

  • 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 7, 2016 at 8:38

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.

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
User etckeeper #a user on the central server 
IdentityFile ~/.ssh/custom_key # key is in authorized_keys in

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


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.

  • Not sure how to do this (second repository). Can you elaborate?
    – Brent
    Jun 20, 2009 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, 2009 at 7:17

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.

  • 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, 2009 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, 2009 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, 2013 at 8:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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