On Sat, 20 Oct 2012, Drew Northup wrote:
On Sun, Oct 14, 2012 at 12:57 AM, <da...@lang.hm> wrote:
On Sat, 13 Oct 2012, Junio C Hamano wrote:
I've got a directory tree that holds config data for all my
servers. This consists of one directory per server (which is updated
periodically from what is currently configured on that server), plus
higher level summary reports and similar information.
today I have just a single git tree covering everything, and I make a
commit each time one of the per-server directories is updated, and
again when the top-level stuff is created.
It is quite clear to me what you are keeping at the top-level files,
but if a large portion of the configuration for these servers are
shared, it might not be a bad idea to have a canonical "gold-master"
configuration branch, to which the shared updates are applied, with
a branch per server that forks from that canonical branch to keep
the machine specific tweaks as differences from the canonical stuff,
instead of having N subdirectories (one per machine).
In an ideal world yes, but right now these machines are updated by many
different tools (unforuntantly including 'vi'), so these directories aren't
the config to be pushed out to the boxes (i.e. what they should be), it's
instead an archived 'what is', the result of changes from all the tools.
The systems are all built with a standard image, but the automation tools I
do have tend to push identical files out to many of the systems (or files
identical except for a couple of lines)
Is there any particular reason you aren't using etckeeper?
not really, I've thought of that as a tool for managing a single system.
Some of the data in configs is sensitive (and much of it is not in /etc),
but I guess I should be able to work around those issues.
I can e-mail 'patches' to the central server, but I'm then back to the
same question that I started out with.
How can I sanely organize all these different, but similar sets of files
on the central server?
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html