[Nagiosplug-devel] Re: OF nagios plugins

[Andreas Ericsson]

Gavin Carr wrote:
> On Thu, Jun 09, 2005 at 03:29:40AM +0100, Paul L. Allen wrote:
> 
>>>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. 
> 
> 
> Depends how many machines you're talking. And then a new version of 
> nagios plugins is released, and all your customisations get wiped out.
> Hmmmm.
> 

man sed. If you're going to upgrade the plugin package you'll probably 
have it scripted anyway. I recommend sed 4.0.9 or later, as it supports 
in-place editing (-i flag) and makes such things a lot easier.

> 
>>>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. 
> 
> 
> Two problems with this: one, the smartest makefile in the world is still
> running at build time, not at install time. So with packages it captures
> the settings for the packager's system, not the installed system.
> 

Performance would drop to around 50% if each plugin needs to look for 
the programs it's supposed to execute. Feel free to fork the nagiosplug 
project yourself if you don't like it.

> Two, utils.pm is a library, so as above it gets upgraded with new versions
> and my customisations get wiped out. Sure such things should be abstracted,
> but into a config file of some kind that is explicitly not automatically
> upgraded.
> 

utils.pm is a bloody textfile. It might change, but variable names will 
not. man sed. Besides, what's the point of upgrading if things are 
already working fine? If you're just upgrading without needing/wanting 
any new features (or to get rid of bugs, obviously), you really should 
get yourself a hobby.

> 
>>>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. 
> 
> 
> Another part of the problem here is that for non-core things like qmail 
> there often is no 'normal'. It might be installed in /usr, /usr/local, 
> or in /var/qmail. You can try and define sensible defaults when building
> a package, but the installer must have the ability to override them.
> 

I'm not sure, but I think you can. Try
PATH_TO_QSTAT=/some/path ./configure
(bash-like shell). configure.in will tell you if this should or 
shouldn't work.

-- 
Andreas Ericsson                   andreas.ericsson at op5.se
OP5 AB                             www.op5.se
Lead Developer