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?"
I'm serious.
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.
I'm going over the same thing at my workplace now. We run a change management system but using it is a bit of a kludge. What I'm looking for is a way of tracking the requests without having to go through the whole approval process (which is a good thing for a serious change management system).
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
Is not IRM something to look into and if it has the basics, to develop it further. I have looked at it and you could track software installed, although it needs humans entering the data.
Having said that, you could write an update script to update on installation of any new software.
irm.schoenefeld.org
make sig make: *** No rule to make target `sig'. Stop
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.
Yup, we built it. But as others have mentioned, you have to religiously enter all your changes or it is all junk.
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).
No, really - hear me out. The desire to find a system to do the work for you has the tendency to overshadow the work that needs to be done. Some coworkers and myself use a file called /etc/logbook.txt in which we simply document changes to the system. At least by writing down these changes, they become known. By being known, they become useful - I can't begin to tell you how useful! Make the effort to try this, then look at a package solution. We found that this suits our needs perfectly.
main(){char I,l,O[]={'-',1-1,0,(1<<5)-1,0+'-',-10-1,-10,11-0,
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!
I read somewhere that all new software should be install in /usr/local to make sure that you could track the changes. Of course this would not help for configuration files, but maybe you could do a cron job to backup or diff /etc. I don't really know because I'm not a sysadmin (for anyone but myself) and not even that knowledgable about *nix. Anyway, that's my 2 cents.