RE: RANCID for server config

> -----Original Message-----
> From: Dashamir Hoxha [mailto:[email protected]]
> Sent: Tuesday, April 27, 2004 2:23 AM
> To: [email protected]
> Cc: [email protected]
> Subject: Re: RANCID for server config
>=20
>=20
> 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.
>=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.

I'm sure admins have re-invented this particular wheel repeatedly, simply=
,
and probably been better admins for it.  It's pretty simple to script stu=
ff
like this up.

I did a quick search a couple of years ago before I wrote my own scripts.=
  I
decided I didn't need most of the features or like the layout of the tool=
s I
found - the time spent learning the quirks of those was greater than the
time spent writing a set of scripts to do it myself, because it didn't ta=
ke
long.

I opted not to use cvs, but I did want long-term archiving of changes and
configs, so my script just keeps all the configs when they change, along
with a separate diff file of the changes.  The configs are indexed by
another script that also sets security so that specific users can see
specific files, exposed via Apache.

The script is basicly a framework for archiving changes to configs.  The
configs are just the output of other scripts, called 'dumpers' - there ar=
e
dumpers that collect router and switch configs, dumpers that just cat a t=
ext
file, dumpers that run a backup software report, etc.  Each dumper also g=
ets
its own filter, which makes it easier to ignore things that change all th=
e
time (only for comparisons, not for saving the config) - for example, the
ntp clock-period line changes all the time on a cisco device.

Each dumper also has a list of people who care about it - those people ge=
t
access to the saved configs and get sent changes in email.  The email the=
y
receive contains only those devices they care about.

The dumpers are usually shell scripts or expect scripts, nothing fancy.  =
I
don't do anything in parallel, and all the dumpers get checked on the sam=
e
schedule (once per hour), but so far that hasn't been a problem.  I have =
two
years worth of configs for a few hundred devices; each hourly run takes
about 10 minutes and the saved configs so far take about 500MB
(uncompressed).

> I have to document all the changes that I make in the server,
> when I did this, who did this and when, etc.

It *would* be nice to be able to note the "who and why" of each change, b=
ut
so far I haven't gone to that much effort.  It wouldn't be hard to
incorporate into the existing framework though - just allow users to add =
a
note to changes using the web interface and store the changes as .note
files.

You're welcome to my code under the GPL, but it's nothing much.  It's
certainly nothing compared to the sophistication of rancid.  I don't know
that it offers any advantages over rancid either - like I said, I opted t=
o
write my own rather than use someone else's. :-)