Date: Mon, 26 Feb 2007 00:42:32 +0200 From: Giorgos Keramidas <keramida@ceid.upatras.gr> To: Rob <freebsd@deathbeforedecaf.net> Cc: freebsd-questions@freebsd.org Subject: Re: Using source control to manage system configs Message-ID: <20070225224231.GC5630@kobe.laptop> In-Reply-To: <2D57E1E1-DDD0-41AA-9CE2-000B830B5798@deathbeforedecaf.net> References: <2D57E1E1-DDD0-41AA-9CE2-000B830B5798@deathbeforedecaf.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2007-02-26 07:01, Rob <freebsd@deathbeforedecaf.net> wrote: > Dear List, > > I'd like some advice on managing config files on multiple servers > with a source control system. The idea is to update files locally, > and commit them back to a central repository. > > I know that CVS is the usual choice, but there are a couple of things > that I can't get CVS to do. > > Overlapping directories > ----------------------- > > Some files (/etc/ntp.conf, /etc/resolv.conf) are identical across a > site. Instead of duplicating these in the repository, I'd like to > create a module like > > hosts/shared/etc > > that gets installed on every server. > > Then each server has a module like > > hosts/$HOST/etc > > that adds to or overwrites these files. If a file is updated locally, > it is committed back to the correct module. > > CVS (quite reasonably) won't checkout 2 modules to the same working > directory. > > Filemodes & symlinks > -------------------- > > CVS only works with regular files, and doesn't preserve permissions. > I can work around this with mtree(8) and module programs, but it > would be nice to have it built-in. > > So... has anyone come up with a neat way to do these things in CVS, > or an SCM system that does it better? With modern SCM systems, which support easy distribution and update tracking over distributed collections of 'workspaces', it's very tempting to attempt to do this. I'm still not convinced it's a good idea though. I prefer a more controlled model of a workspace hierarchy where changes are made by trusted people and then a separate "install" process, which publishes, or "pushes" if you prefer, the modified files to the deployment hosts. I know this is now the answer you are looking for, but when evaluating this sort of thing even a "don't do it" option should be evaluated. - Giorgos
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070225224231.GC5630>