Version Control for Important System Files?

TokyoCrusaders92 asks: "Like a lot of other organizations (800 staff, 5000 students) we have a mix of Windows, Novell & Linux (primarily Linux) for our IT infrastructure. We now have a multitude of config files, firewall rule bases, shell scripts, and so forth which are managed by multiple people and groups. Recently, we started using RCS for version control of the firewall rule-base, but this doesn't seem like it would scale up to larger groups of users. While thinking about this, it would seem that the critical features would include: version control; logging; multiple users; secure authentication; and integrity checking. What are other people using to manage their config files?"

One idea for Windows and Unix (shameless plug)

[DNAGuy]

For Windows, the default answer for deploying configuration is Group Policy [microsoft.com]. With the Group Policy Management Console [microsoft.com] you can back up your GPOs and store them in your version control system. Alternatively, you can use a specialized Group Policy version control and troubleshooting product like Group Policy Manager [quest.com] from Quest [quest.com] which allows offline editing and testing before deployment to your production environment.

You can actually extend Group Policy to your *nix and Novell machines as well using Vintela Group Policy (a part of Vintela Authentication Services [quest.com]), which also has features to allow your *nix machines to use your Active Directory accounts. If you use it in combination with Group Policy Manager, you can back up the *nix specific settings alongside the rest of your GPO. Also, the integration allows you to diff different versions of your *nix settings alongside the rest of your GPO.

[Disclaimer: I am a developer on the Group Policy Manager team at Quest. While I'm proud of my product, I'm not any kind of official spokesperson for my employer.]

rcs

[pe1chl]

On systems where it matters, I keep config files etc in RCS.
In each directory where config files live that I want to keep, I create an RCS directory and rcs -i the file(s).
Nightly, I job runs that finds all files for which an RCS entry exists and that are newer than that entry, and a copy is checked in.

No need to think about checking in/out all the time, no problem that the RCS seems to believe that you don't want to keep the actual file around.
It does not save every edit but at least I have a copy of each day's state of the file.

Re:Subversion

[xlv]

Subversion is the ideal solution - because it needs a lot of junk in .svn directories :( And it can mess with some scripts that do recursive grep or something similar.

That's true, but in practice is that such a huge problem? We use SVN already for all project code and have managed to make do with it. If you can grep and operate on a few megs of in-house development source, a comparatively tiny /etc directory shouldn't be too much hassle.

I've been using svn for a few years now for projects and system files. There's a few problems with the .svn directories for system files. For instance, modprobe on Linux will check and complain about the files in /etc/modprobe.d/.svn when they are parsed.

As explained by somebody else, using the export command is not that useful as then /etc is not directly under revision control and that opens the door for synchronization errors.

Re:A CVS server

[tzanger]

I tried CVS for that... it is too much of a pain in the ass to patch CVS to accept root users. I don't know about you, but screwing about with permissions just to appease CVS was not my idea of fun. Maybe next time I'll run svn or something to see if it works better for config file management.