[Nagiosplug-devel] Re: OF nagios plugins
Andreas Ericsson
ae at op5.se
Thu Jun 9 05:38:49 CEST 2005
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
More information about the Devel
mailing list