11

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

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.

2
  • 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
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 [email protected]: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.

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

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.

2
  • 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
-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.

3
  • 1
    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

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .