Re: RANCID for server config

john heasley <[email protected]> Tue, 27 Apr 2004 18:26:02 +0000
Newsgroups gmane.network.toolmakers
Message-ID <[email protected]>
Tue, Apr 27, 2004 at 09:22:35AM +0200, Dashamir Hoxha:
> On Monday 26 April 2004 10:51 pm, joshua sahala wrote:
> > On (26/04/04 13:33), Dashamir Hoxha wrote:
> > > I think that RANCID can be used as well for keeping track
> > > of the changes in the configuration files of a server.
> > > Has anybody tried to modify RANCID for this purpose,
> > > or do you know any tool that does a similiar job?
> > > Because I don't want to reinvent the wheel.
> >
> > i would recommend tripwire (www.tripwire.org) for this
>=20
> I know tripwire, but I think it is not what I need; I don't think
> tripwire is integrated with CVS, is it?
>=20
> What I need is this: I want to keep track of all the modifications=20
> made in configuration files (by me or by any authorized person)=20
> so that I can review them and revert them back if neccessary.
>=20
> When I install a server, I usually do a standard installation.
> Services and the other things have a default configuration
> (which is made by RedHat or whoever prepared the distribution),
> which is fine for me most of the times.  However, I need to
> customize the configuration for some services, to install any
> new packages etc.  Then, time after time, I make some modifications
> to improve them, install new packages that are needed, etc.
> (because I can't always do things right, in the first time).
>=20
> I have to document all the changes that I make in the server,
> when I did this, who did this and when, etc.  After all, I need
> the final state of the modified config files, in case I have to
> re-install the server from the scratch.  Not having them is
> disastrous for me because I will have to spend the same time
> that I spent in the beginning for installing them.  However,
> I find a little bit hard to keep notes for all the changes that
> I make in the server.  CVS would be ideal for this purpose, but
> how?

It is our intention to add something like this, what we were calling
a "unix" device type.  But, what we need first, to make this practical,
is a way for users to define their own device types, filters, etc.