Re: Large-scale configuration backup with GIT?

Jan-Benedict Glaw [off-list ref] writes:

I'm just thinking about storing our whole company's configuration into
GIT, because I'm all too used to it. That is, there are configuration
...
In both cases, I'd be left with a good number of GIT repos, which
should probably be bound together with the GIT subproject functions.
However, one really interesting thing would be to be able to get the
diff of two machine's configuration files. (Think of machines that
*should* be all identical!)  For this, it probably would be easier to
not put each machine into its own GIT repo, but to use a single one
with a zillion branches, one for each machine.

Did anybody already try to do something like that and can help me with
some real-life experience on that topic?

This is something similar to what I and others in my group did
long time before git was even invented.  I'd suggest you go in
the opposite direction.

If you have 5 configurations, each of which have 20 machines
that _should_ share that configuration (modulo obvious
differences that come from hostname, IP address assignment,
etc), then

 - You keep track of 5 configurations; in git, you would
   probably maintain them as 5 branches.

 - You have a build mechanism to create systemic variation among
   20 machines that shares one configuration; this can be
   different per branch.  So if you have 20 solaris machines all
   should share logically the same configuration, you would:

	$ git checkout solarisconf

        ... tweak the config for machine #27, adjusting for
        ... hostname, IP address variation, etc...
        $ make target=solaris27 output=../solaris27.expect

   Make that makefile produce the output in named directory;

 - You get the config dump from your machines (your "staging
   area"), as you planned.  Then after running the above, you
   could:

	$ cd ..
        $ diff -r solaris27.expect solaris27.actual

   if your "staging area" for machine #27 is "solaris27.actual".

The difference you would see is something done by *hand* on the
machine, which you would want to propagate back to the solaris
configuration *source* you keep track in git.  For some changes,
you may even want to adjust that single manual change done on
machine #27 so that you do not have to do that on other 19
solaris boxes manually, by adjusting the build procedure in the
solarisconf branch.



 

On 9/3/07, Junio C Hamano [off-list ref] wrote:

This is something similar to what I and others in my group did
long time before git was even invented.  I'd suggest you go in
the opposite direction.

Agreed. The infrustructures.org crowd has been exploring this space
quite a bit, and developing tools like isconf that allow you to manage
a huge number of machines across various unixen.

And recently someone's integrated Debian APT with git tracking config
files (called IsiSetup http://www.isisetup.ch/ ). I haven't reviewed
it in detail, but it'd be first on my list.

If you have 5 configurations, each of which have 20 machines
that _should_ share that configuration (modulo obvious
differences that come from hostname, IP address assignment,
etc), then

Indeed. I ended up liking the makefile-stanzas approach it is
incredibly simple and flexible. Add debian/rpm packages, some of the
tools in the cfengine toolchain, git to track your
scripts/configuration and you are golden.

For the Windows side of things, see "Real Men Don't Click"
<http://isg.ee.ethz.ch/tools/realmen/> -- a bunch of unixy sysadmins
with the "infrastructures.org" background took on Windows
servers/desktops management -- and succeeded. PG-rated, fun for the
whole family. ;-)

HTH,



martin-who-survived-the-sysadmin-wars