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.