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

[Matthias Eble]

Olivier Raginel schrieb:
> On Tue, May 08, 2007 at 03:21:35PM +0200, Matthias Eble wrote:
>> Today, I set up N::P for testing purposes. And to me it was really 
>> annoying to resolve the dependencies (so my question was outdated a bit 
>> ) by hand since I cannot configure cpan to access the internet due to 
>> security policy.
> 
> Hum, I agree, but disagree too.
> Yes, having to resolve dependencies by hand is harsh, but you'll have to 
> do so for every CPAN module. Here, for N::P, when I tried it, I had to 
> add:
> Test-Simple-0.67.tar.gz
> Params-Validate-0.88.tar.gz
> Class-Accessor-0.30.tar.gz
Yes it were these three, but: Users try to install nagios plugins, not 
N::P which is a big difference to me.

> So that's 3 packages to download manually. Then you have several ways. 
> One is to install them on all your hosts (thus do something like:
> for host in YOUR HOST LIST;do
>   for package in *.tar.gz;do
>     scp $package $host:
>     ssh $host "tar zxf $package && cd ${package%.tar.gz} && perl \
>          Makefile.PL && make make test && && su -c 'make install'"
>   done
> done
if one likes that, ok. I personally dislike placing files in directories 
except /opt and /usr/local
without os packaging. OK sometimes it is needed, but requires good 
documentation.

> And in fact, looking at the dependencies, they're only .pm, so nothing 
> fancy like C-modules, so they might work anywhere.
Yes. Thats what I thought when I asked why they need to be build on 
compile time. But i guess this should be an approach capable of handling
future requirements, too. And so compiling is the cleanest way to me.

> Yes, I agree it's a bit of a pain, but honestly, it's not that hard to 
> do.
I agree, too.

> Oh and for the FindBin... Yes, it seems nice, but usually (correct me if 
> I'm wrong), @INC contains . as the last entry, so launching your modules 
> from the proper directory solves your PATH resolution.
> For example, I've installed all N::P and dependencies inside 
> ~/Nagios-Plugin-0.15/lib:
> drwxr-xr-x  3 nagios nagios 4096 2007-03-13 18:22 Class
> drwxr-xr-x  3 nagios nagios 4096 2007-03-13 18:22 Nagios
> drwxr-xr-x  2 nagios nagios 4096 2007-03-13 18:23 Params
> drwxr-xr-x  5 nagios nagios 4096 2007-03-13 18:23 Test
> 
> If I launch my plugins from there, doing something like 
> ~/check_tomcat.pl, the perl script finds all my modules.
> Again, not sure it's the default behavior for perl. According to the 
> documentation I found, "." is not appended if using taint mode:
> http://perldoc.perl.org/perlvar.html#@INC

This will work as long as your working directory is the same. If the 
plugin is executed by nrpe, you will get problems - which is already the 
case for utils.pm.

> Do you re-compile your plugins on all your hosts?
> If yes, for me, you ought to have to recompile all dependencies.
> Providing a lazy way to do it doesn't seem good to me.
> For now, dependencies are small and easy, but what will happen the day 
> we'll want to add more complex modules, like ones using bites of C-code?
I recompile them for every distro I am using. I'll have to compile all 
the modules, for these distros, too if bundling will not be implemented.
With bundling compiling and distributing is one step. And users need to 
care whether their installed version of N::P fits together with the np 
distribution.

> I think Gavin and Patrick already expressed all I think on this topic, 
> and as an admin having to install it on several machines too, I do think 
> it's easier and more flexible to install the packages system-wide OR 
> MANUALLY within the nagios plugin directory.

Ton's approach of automatically compiling them in the np-prefix 
directory if N::P is not found in @INC is the best to me since i don't 
think it is ok to let all the users do these steps (set up cpan/search 
for binary packages/install by hand) having to care to get this large 
part of the plugins running.


matthias