[Nagiosplug-devel] Integrating Nagios::Plugin into the distribution

[Ton Voon]

On 28 Apr 2007, at 13:25, Gavin Carr wrote:

> Why? What's the advantage of not using the standard perl library
> locations?
>
> N::P and every other module you're installing _are_ standard CPAN
> modules, that out-of-the-box (perl Makefile.PL; make; make install)
> install into the perl lib directories. You're having to jump through
> extra hoops for them to _not_ install there, and then jump through
> more hoops for your plugins to work because they aren't there. I
> don't understand the rational/benefit of all that extra hoopage?
>
> I guess I'm seeing the benefit of bundling being not having to jump
> through setting up the CPAN configuration stuff on every box you
> want to use N::P on. It sounds like you're seeing the isolation itself
> as being a benefit?

I hadn't thought of it like this, but the isolation (or bundling of  
functionality) is, I think, a benefit because it allows easier  
installation on remote servers.

And we already do "bundling"! The ./configure script, for instance,  
checks if getopt_log is available in the OS. If not, it statically  
links in the gnu version. If a target system has gnu upgraded  
(admitedly, a lot less likely than upgrading N::P), then the plugin  
will continue to work with the compiled in getopt_long.

But the principle is the same - if the functionality is not available  
(on the build server), use a local copy instead.

To me, the main advantage is that a plugin developer knows that  
certain functionality will always be available to them.

A thought experiment: What about libmysqlclient? We could bundle  
libmysqlclient with Nagios Plugins - I don't think there are  
technical nor legal reasons that would stop us. This guarantees that  
check_mysql will compile as the dependencies will be there, thus  
overcoming the need to check for mysql in ./configure.

But I'm pretty sure most people would think that's a silly idea -  
mysqlclient is (a) too big a piece of code to bundle, and (b) is not  
central to what the plugins is about. But N::P is on both counts, so  
I think merits bundling with the distribution.


>> I haven't found the search path to be a problem. I guess lower
>> versions of perl may pose a problem - I don't have a handle on this
>> yet. There may need to be some extra work done there to support those
>> lower levels.
>
> It's just a problem in the sense that the plugins won't work without
> some explicit lib path tweaking. I dislike your FindBin/use lib code
> on the grounds that it's only required to support a particular
> deployment decision - you're polluting the plugins with installation
> policy. (It would be much cleaner, for instance, to see if we can just
> get PERL5LIB set in the environment if we do go this way).

This is a worthwhile point. I see the whole "FindBin/use lib" code is  
analogous to adding $prefix/bin to the start of PATH. Yes, it is a  
deployment decision. The alternative of using PERL5LIB means that the  
setup is outside of the plugins code - maybe setup in NRPE and Nagios  
startup scripts or as a variable for the nagios user's profile? I  
guess this is no different to needing to use crle or LD_LIBRARY_PATH  
for ssl setup on some OSes.

> I just think duplication is a bit like denormalising a database
> schema - it's generally bad practice, but sometimes the benefits
> make it worthwhile.

Interesting analogy! However, I don't think there will be duplication  
- in most cases, I think an implementor would choose to either  
provide a local copy of the perl modules or install in system  
directories (I'm guessing that packagers will opt for the latter).  
 From our point of view, we need to be able to support both.

Ton

http://www.altinity.com
T: +44 (0)870 787 9243
F: +44 (0)845 280 1725
Skype: tonvoon