[Nagiosplug-devel] Re: OF nagios plugins

Paul L. Allen pla at softflare.com
Wed Jun 8 19:32:40 CEST 2005

Gavin Carr writes: 

> The main thing I was after was the ability to check _all_ raid devices,
> not to have to test them individually. The contrib one couldn't do that.

Ummm, I don't remember the contrib one having that problem.  But it was
a long time ago that I hacked it into something that worked for me.  The
things I remember were it didn't recognize some of the resynching states
and didn't recognize some down states.  If I remember correctly (it is
now very, very late and I am completely de-stressed). 

> Yeah, I tried check_mailq first, but couldn't get it to work. The problem
> I hit was that I'm typically using DAG's nagios-plugins RPM package, and 
> that doesn't set $PATH_TO_QMAIL_QSTAT in utils.pm,

Yeah, I had that problem too, but I didn't do a full 1.4 install, just
grabbed the plugin, so figured it was because I'd cheated.  Actually,
I think it also needs the path to the various utilities that qmail-qstat
invokes (as I said, it's very late here, but I'm fairly sure that without
that path it falls over, at least on any Red Hat release I've used it on). 

> I gave up on it when I couldn't figure out a way to fix that on multiple 
> machines cleanly.

Hack utils.pm, copy over the hacked version after installing the plugins.
That's what I do.  It's not ideal, but it's not a major pain. 

> Hardcoded paths in libaries (except maybe as defaults) are 
> way dumb!

It's not dumb if the makefile is smart enough to figure out the correct
paths needed for each plugin.  In that case it's much easier because the
makefile only has to twiddle utils.pm instead of many plugins. 

> How about adding an etc/nagios/plugins.cfg for such things, so 
> that sites can override site-local settings like that?

I don't see the point.  That just adds extra overheads.  If you can edit
plugins.cfg to change paths you can edit utils.pm.  Yeah, if you're
building the plugins on different distros you might have to alter utils.pm
on a per-distro basis, but the same would be true of plugins.cfg.  The only
way plugins.cfg would be useful is if any entries in it over-rode utils.pm.
Then you could happily copy utils.pm everywhere and use plugins.cfg to
over-ride it.  But I still think having configure/Makefile do it
automatically is a cleaner method because you're going to have to run those
anyway if you're dealing with a different-from-normal distro/architecture. 

The real issue here is that some of the qmail stuff in check_mailq works
only on the systems the authors have tested it on.  No disrespect meant -
until about a month ago I didn't know of the Bruce Guenther patch that
made qmail-qstat usable by unprivileged users and none of our servers have
it.  If you don't have that then the pathing stuff, and the suexec or sudo
stuff, becomes necessary. 

Paul Allen
Softflare Support 

More information about the Devel mailing list