Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
Unix Operating Systems Software

Software for Tracking System Configuration Changes? 22

Posted by Cliff from the journals-good-enough-for-an-uber-rollback dept.
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?"
This discussion has been archived. No new comments can be posted.

Software for Tracking System Configuration Changes? More

Software for Tracking System Configuration Changes?

Comments Filter:

  • CVS (Score:4, Informative)

    by peripatetic_bum ( 211859 ) on Friday September 13, 2002 @12:08AM (#4249308) Homepage Journal
    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
    • A friend of mine does similar though he uses RCS instead. I'm not all that familiar with RCS, but I'm sure there is porbably some reason why he uses it over CVS.

      • I'm sure there is porbably some reason why he uses [RCS] over CVS.
        My guess is because he knows RCS and doesn't know CVS; I'll stick my neck out further and guess that's because he used RCS first, and never had a reason to switch to CVS.

    • If you want to see how tracking your config from CVS would look, the BSD folks have the entire source for their systems in CVS.

      Here's the complete history of all changes to the default /etc/crontab since OpenBSD was forked.

      OpenBSD webCVS interface [openbsd.org]
      • If you want to see how tracking your config from CVS would look, the BSD folks have the entire source for their systems in CVS.

        <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)

    by roachmotel3 ( 543872 ) <paul AT isaroach DOT com> on Friday September 13, 2002 @12:27AM (#4249392)
    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 thought Tripwire was geared more toward security than anything else. To me, it seems like the question was about tracking changes bewteen versions of a document. CVS or RCS is a perfect fit for this.

      So, maybe Tripwire and CVS?
      • Actually, I think in the latest versions of the commercial software, CVS is exactly how this is done. The commercial version of tripwire is a LOT more than just md5sums and hashes in a database to detect file changes. The central console can automatically rollback to previous revisions AND push new revisions at the touch of a button. You cant automatically rollback without a central repository of changes, and I think this is done with CVS.

        And no, I'm not a salesman or employee for tripwire ;)
  • I've yet to try it but it seems to me Bugzilla [mozilla.org] 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.

  • Mailing List perhaps (Score:1, Interesting)

    by Anonymous Coward
    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

  • Have alook at IRM (Score:1, Interesting)

    by freakkster ( 211106 )
    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 [schoenefeld.org]
  • 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.

    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 /etc, or any script we use, is in CVS. This is most useful for programs who's configuration constantly changes (Nagios, for instance).

    The CVS usage gets a little fuzzy with configuration files outside of /etc, we're not doing a terribly good job at this. At my last place, every config file was in CVS.

    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.

  • Database-enabled web app - write it yourself.

    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.
  • 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.
  • 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.
  • 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.

Slashdot Top Deals

Get hold of portable property. -- Charles Dickens, "Great Expectations"

Close