Tux

...making Linux just a little more fun!

Version control for /etc

Rick Moen [rick at linuxmafia.com]


Tue, 25 Dec 2007 03:24:57 -0800

[[[ This is a followup to "Version control for /etc" in http://linuxgazette.net/144/lg_mail.html -- Kat ]]]

A promising solution to the exact problem discussed earlier -- put together by my friend Joey Hess. See: http://kitenet.net/~joey/code/etckeeper/ One key ingredient is David H?rdeman's "metastore" (http://david.hardeman.nu/software.php), used to capture metadata that git would otherwise ignore.

----- Forwarded message from Jason White <jason@jasonjgw.net> -----

Date: Tue, 25 Dec 2007 19:07:59 +1100
From: Jason White <jason@jasonjgw.net>
To: luv-main <luv-main@luv.asn.au>
Subject: etckeeper
For those who are running Debian or debian-derived distributions, there is a relatively new package, etckeeper, which I have found rather useful: it maintains a revision history of /etc in a Git repository, including file permissions and other metadata not normally tracked by Git.

It is also invoked by Apt, using standard Apt mechanisms, to commit changes introduced into /etc when packages are installed or removed.

I don't know whether there exist any similar tools for non-Debian distributions.

----- End forwarded message -----


Top    Back


Rick Moen [rick at linuxmafia.com]


Thu, 3 Jan 2008 04:04:10 -0800

I wrote:

> A promising solution to the exact problem discussed earlier -- put together
> by my friend Joey Hess.  See:  http://kitenet.net/~joey/code/etckeeper/
> One key ingredient is David H<a4>rdeman's "metastore"
> (http://david.hardeman.nu/software.php), used to capture metadata that
> git would otherwise ignore.

Here's Joey's announcement and explanation of the software (explaining in particular how it avoids some of the drawbacks of IsiSetup): http://kitenet.net/~joey/blog/entry/announcing_etckeeper/ Particularly winning is its close integration (on Debian and similar) into apt, so that changes to /etc/ resulting from package operations get checked in automatically.

etckeeper being an excellent idea whose time has definitely come, Mathieu Clabaut has also adapted it to use the increasingly popular revision control system Mercurial (hg) as its back-end storage, instead of git (although, as built locally on my Xubuntu iBook, v. 0.6 still ends up needing package "git-core"). See:

http://hg.sharesource.org/etckeeperhg http://sharesource.org/project/etckeeperhg/

I notice that Ubuntu does package etckeeper (but not yet the Mercurial variant) in its "Hardy Heron" development branch's "universe" collection.

By the way, here's a nice little user tutorial on git: http://hwasungmars.wordpress.com/2007/11/25/journey-to-a-backup-solution-git/

And a separate Nov. 2007 analysis of the need for something like etckeeper (mentioning it only in a followup) that cites an earlier solution by Michael Prokop using Mercurial (http://michael-prokop.at/blog/2007/03/14/maintain-etc-with-mercurial-on-debian/), which itself points to Enrico Zini's method of doing similar things in svk (a superset of subversion that supports decentralised operation and in general improves it): http://lists.debian.org/debian-devel/2005/02/msg00495.html

(As I believe was noted in earlier go-rounds of this subject in TAG, one still rather rare quality in revision control systems is the ability to not have metadata rubbish sitting around in .CVS, .svn, or equivalent directories/files in one's working areas, and svk is among the few that solve that problem.)

Another, and related, recent contribution from Joey is "mr" (http://kitenet.net/~joey/code/mr/):

The mr(1) command can checkout, update, or perform other actions on a set of repositories as if they were one combined respository. It supports any combination of subversion, git, cvs, mecurial, bzr and darcs repositories, and support for other revision control systems can easily be added.


Top    Back


Rick Moen [rick at linuxmafia.com]


Thu, 3 Jan 2008 16:52:40 -0800

Reminder about the GIT_DIR variable, for git.

----- Forwarded message from Jason White <jason@jasonjgw.net> -----

Date: Fri, 4 Jan 2008 10:10:43 +1100
From: Jason White <jason@jasonjgw.net>
To: luv-main@luv.asn.au
Subject: Re: etckeeper
On Thu, Jan 03, 2008 at 10:31:53AM -0800, Rick Moen wrote:

> (As I believe was noted in earlier go-rounds of this subject in TAG,
> one still rather rare quality in revision control systems is the
> ability to not have metadata rubbish sitting around in .CVS, .svn,
> or equivalent directories/files in one's working areas, and svk is
> among the few that solve that problem.)

I haven't tried it, but apparently the GIT_DIR environment variable allows you to refer to a git repository directory anywhere in the file system. Provided you set it before invoking git, the problem noted by Rick should be overcome.

This could be useful with etckeeper if your /etc happens to be in a small root partition in which you don't want space to be consumed by a .git directory.

----- End forwarded message -----


Top    Back


Peter Knaggs [peter.knaggs at gmail.com]


Thu, 3 Jan 2008 23:27:31 -0800

On Jan 3, 2008 4:52 PM, Rick Moen <rick@linuxmafia.com> wrote:

> Reminder about the GIT_DIR variable, for git.

The GIT_DIR does work, but there's a small quirk to be aware of:

It seems that the last component of the path specified in the GIT_DIR variable needs to be the word ".git", otherwise "git-add" won't work properly:

e.g.:

mkdir -p /tmp/git_metadata/test
export GIT_DIR=/tmp/git_metadata/test
 
mkdir /tmp/git_testdir && cd /tmp/git_testdir
 
git-init
Initialized empty Git repository in /tmp/git_metadata/test/
 
ls -l
. ..
 
touch file1
git-add file1
fatal: add must be run in a work tree
whereas when the GIT_DIR variable ends with the word ".git", all is fine:
mkdir -p /tmp/git_metadata/.git
export GIT_DIR=/tmp/git_metadata/.git
 
mkdir /tmp/git_testdir && cd /tmp/git_testdir
 
git-init
Initialized empty Git repository in /tmp/git_metadata/test/
 
ls -a
.  ..
 
touch file1
git-add file1
git-commit
warning: unable to read /etc/mailname: Success
 
warning: unable to read /etc/mailname: Success
 
 
warning: unable to read /etc/mailname: Success
 
warning: unable to read /etc/mailname: Success
 
Created initial commit fc652c0: Add
 0 files changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 file1
The tutorials here seem to be quite readable:

http://www.kernel.org/pub/software/scm/git/docs/tutorial.html http://www.kernel.org/pub/software/scm/git/docs/tutorial-2.html http://www.kernel.org/pub/software/scm/git/docs/everyday.html

Cheers, Peter.


Top    Back