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
PGP.sig
Description: This is a digitally signed message part
_______________________________________________ mrtg mailing list [email protected] https://lists.oetiker.ch/cgi-bin/listinfo/mrtg
