[Nagiosplug-devel] Re: OF nagios plugins

[Gavin Carr]

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.

> >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.

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.

> >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.

Cheers,
Gavin