On Thu, Feb 14, 2008 at 05:02:02PM +0000, Richard Wilson wrote: > Increasingly, I find that I have many servers, especially OpenBSD > servers, where the only bit of the hard drive worth backing up is /etc. > Good examples are routers or spamtrap boxes where everything is part of > base. If a hard drive goes pop, all I need is to install the OS, and > re-populate /etc. > > Currently I back up /etc on these machines using variants on rsync and > rsnapshot, and it works OK. However, I've got it into my head to shift > to using CVS to back up /etc on these machines. Advantages I think I see: [snip 5 advantages] > Before I embark on this, I have a couple of questions: > > 1) Can anyone think of an idea why I'm being dumb? I hope not, but it > doesn't hurt to ask. > > 2) How will /etc, and the things that read it, react to /etc becoming a > working copy, with CVS, Entries, et al? I'm thinking of things that eg > "Include /etc/appname/*" barfing on unexpected files left by CVS. > > > To any and all who have read all the way through my disjointed waffle, I > thank you. I'll report back once I give it a go :-)
Limoncelli and Hogan (__The_Practice_of_system_and_network_administration__) in chapter 10 on change management recommend something like this. Elsewhere, they also discuss the "push" method and the "pull" method. What you are describing is the "pull" method. Make a change to the file in /etc and have a central CVS pull that into the repository. I wonder about a "push" method instead. Have the definitive version of /etc stored on the central server. Use CVS to change that central authoritative version and have a process then push the changes to the target box. It could alert you to unathorized changes that have occurred on the target box, and you no longer have to back up that target box at all since all of /etc is in the CVS. If a new file needs to be installed on the target (perhaps during a package install or something), then use CVS to pull in the new file to be managed. Doug.
