[mrtg] MRTG/RRDTOOL integration

[Niall O'Reilly]

On 31 Jan 2008, at 01:36, Steve Shipway wrote:

> You might want to take another look at routers2, as it has alot of  
> additional customisation available for people who want to use it in  
> different ways.

	I've been quietly doing that, and discovering that it's not so
	monolithic as it first seemed to me.

	[ I did say in another mail that it's impressive, didn't I? ]

> Firstly, it supports authentication and authorisation, so you can  
> have multiple users who have visibility of different subsets  
> of .cfg files (this helps in the integration of multiple MRTG  
> instances you mention).

	I noticed.  I don't need this for the foreseeable future.
	If and when I do, I expect to integrate it with our (future,
	and by then hopefully working) Shibboleth environment.

> Secondly, it has 'distributed MRTG' support, which means you can  
> have MRTG running on multiple servers, but with one integrated  
> frontend (it hands off between servers as and when necessary).   
> This is a bit more complex to implement but we are running it here  
> with no problem.

	If that fits the information architecture we're using, or
	can be implemented without too much disruption, it may be
	a way to go.  My priority is to avoid appearing to "break"
	anything for our network team as I migrate to rrdtool.

> Thirdly, if you need to extract just the images (for example, as  
> graphs embedded in a different web page, or as popups on a  
> weathermap) then it has a mode to achieve this (add '&page=image'  
> to the graph URL) without the surrounding pages and frames.

	I've managed to find the bit about that in your FAQ, and like
	the flexibility it allows.

> I think that (particularly the second) these

	Actually, the third one is a much more significant win.

> might well cover your missing requirements.

	I'm putting together a set of demonstration displays driven each by
	one of traditional MRTG (rateup, static images), 14all, mrtg-rrd,
	and routers2.  For now, this is in the simpler environment of my
	domestic network at <http://bark.no8.be/mrtg/home/servers/bark/>.
	This pilot will give me reasons for selecting one or other
	display front-end, and help me identify whether any of our design
	decisions, made in the original context of traditional MRTG, will
	need to be revised.

> However, if you have any more specific problems, then feel free to  
> email me directly or post to the routers2 forum at  
> www.steveshipway.org/forum to ask if a specific thing can be done.   
> The HOWTO document as shipped with routers2 also has a lot of  
> helpful information.

	Sure. Thanks.

> Steve (author of routers2 so of course slightly biased)

	I appreciate full disclosure.  8-)

	Thanks again.


	Best regards,

	Niall O'Reilly
	University College Dublin IT Services

	PGP key ID: AE995ED9 (see www.pgp.net)
	Fingerprint: 23DC C6DE 8874 2432 2BE0 3905 7987 E48D AE99 5ED9



-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://lists.oetiker.ch/pipermail/mrtg/attachments/20080131/1191d3c8/attachment.bin