[Mimedefang] HUGE problem with mimedefang

[James Ebright]

On Fri, 22 Apr 2005 12:00:53 -0400, Paul Whittney wrote

> This method came about due to using a monitoring server on our site.
> 
> It's not pretty, nor perfect, but I'd appreciate any comments.

Would not this be a whole lot simpler using the new PING/PONG fucntions in MD?
Also getting a response from MD means  it is up AND responding, whereas simply
checking a pipes existance does not guarantee that MD is still operational.
Heck, I check for and manually remove stale pipes when recovering from a
multiplexor crash (though it has not happened in a long time) as that has
happened to me before.

Personally, we monitor it via snmp, kind of an ugly hack (our mib scripts) but
it works very well so I have not bothered to "fix" them; we monitor message
avg per min/5 min,  spam and viri this way too and gragph trends in MRTG.

A little known function in net_snmp lets you create your own OIDs and populate
em via scripts. We are currently using space under the UC-DAVIS/Redhat OID
namespace but I have requested my own space, so when that happens I might
change the scripts around.

put this in your snmpd.conf:

pass .1.3.6.1.4.1.2021.2600 /root/scripts/MIBSCRIPTS/mailStatus


This will make anything under the 1.3.6.1.4.1.2021.2600.x-x(n) OID return values..

The script takes the last OID val as an arg and can do anything and needs to
return a final MIB values like:
echo ".1.3.6.1.4.1.2021.2600.0"
echo "integer"
echo $stat

This is a very simplistic overview but the net-snmp docs are pretty good and
easy to follow. The only gotcha is to make sure your script always returns
something, esp under high loads... perhaps check load first and dump back last
results if load over a settable threshhold. snmp expects an answer and
according to the rfc it is perfectly legal to return stale values due to
load... it is not supposed to put its own load on systems.

Jim
--
EsisNet.com Webmail Client