[mrtg] config in a database? moves, adds, changes?

[Furnish, Trever G]

Has anyone done any work to put the mrtg config into a database and update
the mrtg tools to read the database for their config info instead of the
flat text files?

We have a *lot* of moves, adds, and changes for monitored devices and some
things that ought to be simple and quick are really painful with the cfg
files.

For example, renaming a switch means:
	- stop mrtg.
	- update the cfg file(s) with the targets for that device.
	- rename any relevant directories and files.
	- update any html pages.
	- restart mrtg.
	- check for syntax error warnings
	- wait 20 minutes and check the graphs to make sure things look
normal.

That's a *lot* of stuff to do when you have several hundred switches that
change frequently.

I suppose a database isn't what I'm really looking for - I just want to
facilitate maintenance.  What would be really nice is a set of commands that
enable common changes from the unix command line - something like the ideas
below - perhaps someone has already implemented this?

Ideas for commands to interface with the mrtg cfg and data files.
- mListTargets
	List all targets

- mRenameTarget oldname newname
	Rename a target from oldname to newname, renaming all relevant data
files as well.

- mMoveTarget targetname newdir
	Move a target's data files from its current location into newdir

-mRemoveTarget targetname
	Remove a target from the cfg and remove all its data files.

-mDisableTarget targetname / mEnableTarget
	Comment out / in a target.  Useful for connecting monitoring systems
into the picture - if Nagios knows a parent router is down, why not make it
easy for nagios to disable data collection in mrtg for that router and all
its children?

- mListTargetAttributes target
	List attributes defined for a target

- mDisplayTargetAttribute target attribute1 [attribute2 ...]
	Dump the value of an attribute of a target.

And one big one, something to compare a network device's current config to
its recorded config, in order to facilitate checking for changes.  If new
interfaces show up or existing ones disappear, it would be nice to know.  If
the device changes what it claims to be, we need to adjust our targets.

--
Unsubscribe mailto:mrtg-request at list.ee.ethz.ch?subject=unsubscribe
Archive     http://www.ee.ethz.ch/~slist/mrtg
FAQ         http://faq.mrtg.org    Homepage     http://www.mrtg.org
WebAdmin    http://www.ee.ethz.ch/~slist/lsg2.cgi