[Nagiosplug-devel] Integrating Nagios::Plugin into the distribution
Ton Voon
ton.voon at altinity.com
Mon Apr 23 18:25:23 CEST 2007
Hi!
I promised to start this discussion, so apologies for not doing it
earlier.
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
recommended.
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.
Opinions?
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?
option=com_docman&task=cat_view&gid=28&Itemid=28
Ton
http://www.altinity.com
T: +44 (0)870 787 9243
F: +44 (0)845 280 1725
Skype: tonvoon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://nagios-plugins.org/archive/devel/attachments/20070423/62b816fb/attachment.html>
More information about the Devel
mailing list