On Sat, Oct 20, 2012 at 10:34 PM, <david@xxxxxxx> wrote: > On Sat, 20 Oct 2012, Drew Northup wrote: >> On Sun, Oct 14, 2012 at 12:57 AM, <david@xxxxxxx> wrote: >>> On Sat, 13 Oct 2012, Junio C Hamano wrote: >>>> david@xxxxxxx writes: >>>>> >>>>> 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. >>>> >>>> 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 >>> >>> 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, it's >>> instead an archived 'what is', the result of changes from all the tools. So you need to save what is there before pulling changes from the master. That's no different from doing development work on an active code base. >> David, >> 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. .gitignore and symlinks have been employed at times to deal with that. > How can I sanely organize all these different, but similar sets of files on > the central server? The reason I asked about etckeeper is that you could, with proper security in place, push those up to branches in a shared repository (set up using gitolite, for instance) and not loose information about the files in the process. This would allow you to make your changes on one system using vi or whatever else is convenient, push the change up to the shared repo, cherry-pick it into the other branches (using a full check-out of all of the branches someplace safe as a workspace), and pull that change out to the other systems. If you are just looking to gather configuration information in the large and don't want to engage in any shared management schemes (which may involve symlinks in seemingly odd places to /etc and such) you may wish to look at the System Configuration Collector [1] [2] which is a nicely organized tool designed specifically to gather just the important (and not highly confidential) information about common software on a server and present it (and changes to it) to the admin in a sensible manner. It is outside of the "Git Universe" but it does what it sounds like you are doing now (if not what you wish to be doing). (1) http://www.qnh.eu/scc/ (2) http://sourceforge.net/projects/sysconfcollect/ -- -Drew Northup -------------------------------------------------------------- "As opposed to vegetable or mineral error?" -John Pescatore, SANS NewsBites Vol. 12 Num. 59 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html