Software for Tracking System Configuration Changes? 22
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?"
CVS (Score:4, Informative)
here is the link
http://linuxjournal.com/article.php?sid=5976
Re:CVS (Score:1)
Re:CVS (Score:2)
Re:CVS (Score:2)
Here's the complete history of all changes to the default
OpenBSD webCVS interface [openbsd.org]
Re:CVS (Score:2)
<SHAMELESS PLUG>
You might also try OpenCM [opencm.org] for this.
</SHAMELESS PLUG>
Todd Fries of the OpenBSD project has been working on OpenCM quite a bit, and hopefully someday fairly soon (by which I mean a year if we're lucky), OpenBSD will be using OpenCM instead of CVS.
Tripwire is VERY good at this (Score:3, Informative)
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
Re:Tripwire is VERY good at this (Score:1)
So, maybe Tripwire and CVS?
Re:Tripwire is VERY good at this (Score:1)
And no, I'm not a salesman or employee for tripwire
Re:Tripwire is VERY good at this (Score:1)
Bugzilla maybe (Score:2)
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.
Mailing List perhaps (Score:1, Interesting)
All up I came up with using mailing list software to receive changes, and then have them archived on a web site, with a nightly mailout to all support staff of an index of the days changes logged. I'm wanted to break the change notes down by host in which case I would get users to enter the hostname in [] brackets as the first part of the subject line.
I'm still evaluating how I'm going to do this. Most good mailing list is on *nix, but we're a mostly MS shop here. The only thing I'd look at doing is writing a collection --> posting program to bring email from the MSExchange mailbox over to the *nix system.
If anyone has done something like this and has the software under GPL, I'd love to know.
HTH
Have alook at IRM (Score:1, Interesting)
Having said that, you could write an update script to update on installation of any new software.
irm.schoenefeld.org [schoenefeld.org]
The system here at Bell & Howell (Score:2)
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.
DIY (Score:2)
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.
Haven't Found One Yet, But... (Score:2)
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.
religiously log (Score:1)
One more thing, we found it helpful when you delegate to other staff persons is to have them log in and have the system track the changes they make (and how long was that lunch break).
/etc/logbook.txt (Score:1)
in house solution (Score:2)
/usr/local? (Score:1)