[Nagiosplug-devel] Re: OF nagios plugins

[Paul L. Allen]

Gavin Carr writes: 

> On Thu, Jun 09, 2005 at 03:29:40AM +0100, Paul L. Allen wrote:
>> 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.

Hmmm indeed.  Further on you talk about building on one machine and
then copying the plugins to other machine.  If you do it that way then
instead of "build, copy" it becomes "build, hack utils.pm, copy."  If
you do a build and install on each machine then first you have to copy
the tarball around anyway, so it's not that much harder to copy a hacked
utils.pm around, and even easier if you have a tool that does these
things for you.  The most sensible way of doing it if you do a build and
install on each machine is to first unpack the tarball, make your changes
to utils.pm then repackage it with a variation on the tarball name to
indicate it's a local modification. 

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

Some of us have to cope with different CPUs and different versions of OS
and libraries.  There's always a chance that the compiled code from an
Intel 686 will have problems on AMD or Celeron.  It's more than likely
that code compiled on RHEL4 will not run on RH 7.3 because the libraries
have changed (doing it the other way around should work because of the
compatibility libraries in RHEL4).  Unless you have a homogeneous set
of machines one or other of those problems will eventually bite you. 

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

That is a sensible reason for having an external config file if you have
machines where the location of, say, qmail differs from box to box. 

-- 
Paul Allen
Softflare Support