Slashdot Mirror
Software for Tracking System Configuration Changes?
DingleyDon asks: "I am currently administering a growing Unix environment and am interested in better documenting changes such as upgrades, software installs, configuration changes, etc. to the hardware and software on those servers from a SysAdmin's point of view. Obviously, this could be done with something as simple as a text file stored on each system, or a spreadsheet, or any other number of ways. But what I envision is a database app (web-enabled) where I can easily keep all of this information in a centralized location and query on the history of any given server. Is there any such package out there? (free=even better!) What do other SysAdmins use to document changes made to their environment?"
Linux journal just did an article where the guy talks about using CVS to track all changes on his computer
here is the link
http://linuxjournal.com/article.php?sid=5976
Sigs are dangerous coy things
You should really look into tripwire for this -- the open source version is awesome, but the commercial version kicks much bootay. They have a central console, which, much like quicken requires you to "Reconcile" any difference between what's on the server and what you show as the last good state (like if your checkbook doesn't match the bank statement). VERY cool stuff -- check out http://www.tripwire.com. (Specifically, Tripwire for Servers and Tripwire Manager)
;)
We evaluated it for use at my place of business, and we are going to end up using it, IMHO. VERY responsive, and they **get** it too.
Besides, Gene Kim (Tripwire's original author!) is a really nice guy
I've yet to try it but it seems to me Bugzilla could easily be much more if you just changed some names, just mentally think of changes as bugs and machines as products. Bugzilla already has systems to track when and who entered stuff and can email people as needed.
I think other features could work well too but no software package is going to make up for the fact that a good system adminstrator has to have the discipline to document even trivial changes.
Every configuration change on the UNIX systems gets a Bugzilla ticket. This helps track our rational for making the change, who requested it, and who was involved in making the decision.
/etc, or any script we use, is in CVS. This is most useful for programs who's configuration constantly changes (Nagios, for instance).
/etc, we're not doing a terribly good job at this. At my last place, every config file was in CVS.
I also normally do one of these in the ticket to reference it:
* log the commands run to make the change. Not only is this great search engine fodder later, but it helps peer review.
* If it's a config file or script change, I often paste or attach a diff (depending on it's size) into the ticket.
For instance, I just closed one request for adding some developers to the sudoers file. I pasted the lines added into there.
The second thing that happens is any file in
The CVS usage gets a little fuzzy with configuration files outside of
I've written a cute wrapper around cvs for maintaining unix config files, so that non-UNIX folks can safely edit the files in a revision control environment without knowing that CVS is being used. I plan to release "revedit" once I can get this VaultHost stuff going.
Our shop needed something like this. Actually, it wasn't for the unix machines (I'm the main unix admin and I just keep a file /etc/LOG on all my unix boxes), but rather for the support personnel who were working with user desktop machines (this is an office, so obviously these were not unix machines but rather Windows and MacOS).
We just ended up writing our own system, one bit at a time. We now have a somewhat complex system that integrates our main employee database (used for accounting and whatnot, a lot of accounting apps having moved to the web), our computer inventory database, and our support workorders database (and various miscellaneous other web apps). The workorders database allows one to tie a request to a particular machines, so one can query and find out the history of a particular desktop machine (as machines get moved around a lot).
Look into php+mysql, as these make web apps extremely easy (much faster to write than perl, and I'm an experienced perl programmer, written XS extensions, etc - I like perl very much and do quite a bit of it, but web databases are much easier to do in php). If you haven't done any php, first look at some GOOD php code to learn how to do things as it's very easy to come up with unmaintainable crap (see www.horde.org for examples of good php).
Also, if any admin is reading this and not doing it already - log your changes somewhere. I use /etc/LOG, but anything immediately recognizable as an important document obviously written by the previous admin will very much help the machine's next admin when you get a better job. This has also very much helped me when I need to duplicate a machine's configuration, upgrade a server, etc ("what were the apache configuration flags I used on this machine again?"). Don't put it off until you get some snazzy web database, but start documenting anything you do as root right now.
I haven't found one I like yet, but this one was close. At least, it worked well in an unstructured sort of way that made using it very easy:
http://freshmeat.net/projects/bartleby/
And it could track any kind of system since you really just free-form the change data. We need something a bit more formal, though. But, it may be just the ticket for you.
Amateurs discuss tactics. Professionals discuss logistics.
we have this.. basically one of the guys I work with wrote it. It is basically like cvs only it locks files when you check them out. It also has a database where it stores what version was checked out and what was checked in and other such information like the comment and the date and who did the change. You can then use isql to view the info. Then I have a script that can diff 2 revisions. I am thinking that this would be useful to others and maybe seeing if we can sell this solution.
Only 'flamers' flame!