Re: [mrtg] Large Master Config Vulnerability

#1 (**permalink**) 04-17-2008

This is a multi-part message in MIME format.

--===============1541675544==
Content-Type: multipart/alternative;
boundary="----=_NextPart_000_00EC_01C8A087.1A5F2010"

This is a multi-part message in MIME format.

------=_NextPart_000_00EC_01C8A087.1A5F2010
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit

>From the cfgmaker manual.

The next example demonstrates how to use the --community, --snmp-options and
--dns-domain to make the command line simpler. All the equipment will use
the community hidden, except for the ppp-server which use community access.
All equipment uses these SNMP options: 1s timeout, 1 retry and SNMP version
2
cfgmaker --global "WorkDir: /home/tobi" \
--global "Options[_]: growright,bits" \
--dns-domain=place.xyz \
--community=hidden \
--snmp-options=::1:1::2

So you can limit your retries and the timeout. The cfgmaker default is
:::::2.

>From the references manual.

timeout

initial timeout for SNMP queries, in seconds (default: 2.0)

retries

number of times a timed-out request will be retried (default: 5)

backoff

factor by which the timeout is multiplied on every retry (default: 1.0).

_____

From: Mersberger, Robert [mailto:robert.mersberger@goldenliving.com]
Sent: Thursday, April 17, 2008 12:12 PM
To: Anson Rinesmith; Brad Lodgen; mrtg@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@lists.oetiker.ch [mailto:mrtg-bounces@lists.oetiker.ch]
On Behalf Of Anson Rinesmith
Sent: Thursday, April 17, 2008 11:47 AM
To: 'Brad Lodgen'; mrtg@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@lists.oetiker.ch [mailto:mrtg-bounces@lists.oetiker.ch]
On Behalf Of Brad Lodgen
Sent: Thursday, April 17, 2008 11:39 AM
To: mrtg@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.

------=_NextPart_000_00EC_01C8A087.1A5F2010
Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:x=3D"urn:schemas-microsoft-com:office:excel" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">

<style>

</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

From the cfgmaker =
manual.<o:p></o:p>

<pre>The next example demonstrates how to use the =
--community, --snmp-options and --dns-domain to make the command line =
simpler. All the equipment will use the community hidden, except for the ppp-server =
which use community access. All equipment uses these =
SNMP options: 1s =
timeout, 1 =
retry and SNMP =
version =
2<o:p></o:p></pre><pre>cfgmaker =
--global "WorkDir: =
/home/tobi"      &nbs p;  &nb=
sp; \<o:p></o:p></pre><pre>      & nbsp;&nbs=
p;  --global "Options[_]: =
growright,bits"    =
\<o:p></o:p></pre><pre>      & nbsp;&nbs=
p;  =
--dns-domain=3Dplace.xyz     &n bsp;  &=
nbsp;       &nb sp;  =
\<o:p></o:p></pre><pre>      & nbsp;&nbs=
p;  =
--community=3Dhidden     &n bsp;  &nbsp=
;        & nbsp;   =
  \<o:p></o:p></pre><pre>      & nbsp;&nbs=
p;  --snmp-options=3D::1:1::2<o:p></o:p></pre>

<o:p> </o:p>

<o:p> </o:p>

So you can limit your retries and =
the
timeout. The cfgmaker default is :::::2.<o:p></o:p>

From the references =
manual.<o:p></o:p>

timeout<o:p></o:p>

initial timeout for SNMP queries, in seconds =
(default:
2.0)<o:p></o:p>

retries<o:p></o:p>

number of times a timed-out request will be =
retried
(default: 5)<o:p></o:p>

backoff<o:p></o:p>

factor by which the timeout is multiplied on =
every
retry (default: 1.0).<o:p></o:p>

<o:p> </o:p>

<o:p> </o:p>

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabindex=3D-1>

</div>

From: =
Mersberger,
Robert [mailto:robert.mersberger@goldenliving.com] 
Sent: Thursday, April 17, =
2008
12:12 PM 
To: Anson Rinesmith; Brad =
Lodgen;
mrtg@lists.oetiker.ch 
Subject: RE: [mrtg] Large =
Master
Config Vulnerability<o:p></o:p>

</div>

<o:p> </o:p>

I have all my configs in one =
directory and
run mrtg as a cron job with the following =
script.<o:p></o:p>

 <o:p></o:p>

#! =
/bin/bash<o:p></o:p>

<div>

 <o:p></o:p>

</div>

for fn in /etc/mrtg/*.cfg; do 
        env LANG=3DC /usr/bin/mrtg
"$fn" & 
done<o:p></o:p>

 <o:p></o:p>

Maybe this will would for =
you.  I
have been down the include route and I agree it does cause =
problems.<o:p></o:p>

 <o:p></o:p>

<o:p> </o:p>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabIndex=3D-1>

</div>

From:</spa=
n>
mrtg-bounces@lists.oetiker.ch [mailto:mrtg-bounces@lists.oetiker.ch] =
On Behalf Of Anson Rinesmith 
Sent: Thursday, April 17, =
2008
11:47 AM 
To: 'Brad Lodgen';
mrtg@lists.oetiker.ch 
Subject: Re: [mrtg] Large =
Master
Config Vulnerability<o:p></o:p>

You could always limit the number =
of
retries.<o:p></o:p>

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.<o:p></o:p>

<o:p> </o:p>

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabIndex=3D-1>

</div>

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

</div>

<o:p> </o:p>

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<o:p></o:p>

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.<o:p></o:p>

</div>

</body>

</html>

------=_NextPart_000_00EC_01C8A087.1A5F2010--

--===============1541675544==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
mrtg mailing list
mrtg@lists.oetiker.ch
https://lists.oetiker.ch/cgi-bin/listinfo/mrtg

--===============1541675544==--

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode