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

Ton Voon ton.voon at altinity.com
Mon Apr 23 18:25:23 CEST 2007


I promised to start this discussion, so apologies for not doing it  

I think Nagios::Plugin is at a state where it is good enough to start  
using for the plugins in distribution. The main question is: how?

The current utils.pm has problems because of the parsing of the  
location of this module. We want to fix this so it is not an issue  
with N::P.

If N::P is installed in the perl system libraries, no paths need  
changing. If N::P is installed elsewhere, the perl plugins need to  
know where to find N::P.

I think it comes down to two choices:

1. Expect N::P to be installed from an external mechanism, either  
manually installed via CPAN, or using a OS specific package. We'd  
have to make sure the Nagios Plugins requires these packages (amend  
various spec files, update REQUIREMENTS file, etc)

2. Install N::P (and other dependent perl modules) in a (./configure  
chosen) location.

(1) is easier, though it pushes responsibility onto packagers. As  
N::P and the perl scripts in Nagios Plugins are updated, there is a  
dependency on packagers to make the newer version available for us to  
require on.

(2) is harder, though we would have control over what versions are  

Ideally we need to support both, so that packagers can include only  
the minimum software required for Nagios Plugins, but a "direct  
install" case will still work for most users.

My proposal is this:

./configure has two new options: --enable-local-perl-modules, -- 
disable-local-perl-modules. The default is to search for N::P and  
enable if not found or disable if found.

--disable-local-perl-modules does nothing beyond current

--enable-local-perl-modules will install N::P from a new top level  
subdirectory I'm calling "nanocpan". In this directory is the tar  
file from CPAN for N::P plus all the dependent perl modules. At make  
time, a "perl Makefile.PL PREFIX=$prefix" (and some other options  
that I'm not too sure of right now) and "make" will be run to compile  
all the required perl modules - this will be recursive, so other  
dependent perl modules will be included. At make install time, those  
perl modules will be installed into, say, $prefix/lib.

All perl scripts that require N::P will have 'use FindBin qw($Bin);  
use lib "$Bin/../lib"; use Nagios::Plugin'. This means that the  
script will expect to find N::P in $prefix/lib - unfortunately there  
is a limitation that the libexec/ directory needs to reside in the  
same dir as lib/.

If N::P is not installed in $prefix/lib, then the standard perl  
system libraries will be searched. If they aren't found there, then  
the script should fail (return code 2 on my perl 5.8.4).

As newer versions of N::P are developed, we can include them in the  
nagiosplug distribution. If more dependent plugins are needed, those  
could just be dropped into the nanocpan/ directory.

So I think the work is:

   a) amend configure scripts
   b) develop some "nanocpan" system where a directory holds all the  
possible perl modules that may be needed
   c) develop some "nanocpan-install" script where it installs a  
specified perl module (in our case, N::P) and recursively installs  
dependent ones if required (hopefully, this will be similar to  
already developed CPAN code)
   d) amend existing perl scripts to expect N::P in $Bin/../lib

I'm not aware of anything like (b) and (c), but would welcome  
enlightenment if there is. Otherwise I can see a "nanocpan" system  
being useful for other projects besides Nagios Plugins, that we can  
contribute back to the perl community.


BTW, if you have any doubts about why we should use perl modules, can  
I point you to this lightning talk presentation I gave at FOSDEM in  
Feburary: http://nagiosplugins.org/index.php? 


T: +44 (0)870 787 9243
F: +44 (0)845 280 1725
Skype: tonvoon

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.monitoring-plugins.org/archive/devel/attachments/20070423/62b816fb/attachment.html>

More information about the Devel mailing list