[mrtg] Large Master Config Vulnerability

[Rob Dover]

I run primarily individual config files with multiple cron jobs.  Most
of my configs run every minute.

I use the sleep command within the cron to stagger the time that each
config runs. This spreads out the IO over the full minute.

 

E.G.

* * * * * root sleep 15; /usr/bin/mrtg /etc/mrtg/avail/Node1.cfg >&
/dev/null

* * * * * root sleep 30; /usr/bin/mrtg /etc/mrtg/avail/Node2.cfg >&
/dev/null

* * * * * root sleep 45; /usr/bin/mrtg /etc/mrtg/avail/Node3.cfg >&
/dev/null   

2-59/5 * * * * root /usr/bin/mrtg /etc/mrtg/Node4.cfg >& /dev/null

3-59/5 * * * * root /usr/bin/mrtg /etc/mrtg/Node5.cfg >& /dev/null

4-59/5 * * * * root /usr/bin/mrtg /etc/mrtg/Node6.cfg >& /dev/null  

 

I am polling several hundred nodes, some with 200+ interfaces. 

The ones running every minute are a simple mrtg-ping-probe config while
the ones running every 5 minutes are a full blown traffic poll on a
switch stack.

All this on a single 3.2GHz dual Xeon HP server.

 

________________________________

From: Mersberger, Robert [mailto:robert.mersberger at goldenliving.com] 
Sent: April 17, 2008 10:12 AM
To: Anson Rinesmith; Brad Lodgen; mrtg at lists.oetiker.ch
Subject: Re: [mrtg] Large Master Config Vulnerability

 

I have all my configs in one directory and run mrtg as a cron job with
the following script.

 

#! /bin/bash

 

for fn in /etc/mrtg/*.cfg; do
        env LANG=C /usr/bin/mrtg "$fn" &
done

 

Maybe this will would for you.  I have been down the include route and I
agree it does cause problems.

 

 

________________________________

From: mrtg-bounces at lists.oetiker.ch
[mailto:mrtg-bounces at lists.oetiker.ch] On Behalf Of Anson Rinesmith
Sent: Thursday, April 17, 2008 11:47 AM
To: 'Brad Lodgen'; mrtg at lists.oetiker.ch
Subject: Re: [mrtg] Large Master Config Vulnerability

You could always limit the number of retries.

A second option is to break up the master config file into other smaller
files, and therefore when something breaks only that smaller portion is
broken and the rest of your polls proceed without error.

 

________________________________

From: mrtg-bounces at lists.oetiker.ch
[mailto:mrtg-bounces at lists.oetiker.ch] On Behalf Of Brad Lodgen
Sent: Thursday, April 17, 2008 11:39 AM
To: mrtg at lists.oetiker.ch
Subject: [mrtg] Large Master Config Vulnerability

 

Hi everyone,

I'm running a master config with hundreds of include lines and thousands
of targets. This type of setup is vulnerable to errors in config files
and/or changes made in the field not being immediately updated within
the configs. If there are a few errors or changes out in the field to
ports causing them to become 'unpollable', it causes the MRTG polling
interval to go over five minutes because it's retrying those interfaces.
At the moment, with only about 30 error lines in my log(equating to
about 15 interfaces/targets), it's causing MRTG to take 7-9 minutes to
complete polling. As this is a very small percentage compared to the
total amount of targets being polled, I'm trying to figure out a way to
get around this, if possible, or at least to minimize the effects.

Is anyone else running a system like this or does anyone have
suggestions to try?

Thanks in advance for any help!
Brad

Please consider the environment before printing this e-mail. 

CONFIDENTIAL NOTICE:
This e-mail message and any attachment(s) (collectively, this 'Email')
are intended 
only for the confidential use of the recipient(s) named above. If the
reader of this 
message is not the intended recipient named above or an agent
responsible for 
delivering it to the intended recipient named above, you have received
this Email in error. 
Please notify the sender immediately and permanently delete this Email
and any copies thereof.



"This email is intended only for the addressee.  It may contain confidential or proprietary information that cannot be disclosed without British Columbia Lottery Corporation's permission.  If you have received this email in error, please notify the sender immediately and delete the email."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.oetiker.ch/pipermail/mrtg/attachments/20080417/3efc9ebb/attachment.html