[Nagiosplug-devel] Integrating Nagios::Plugin into the distribution
Matthias Eble
matthias.eble at mailing.kaufland-informationssysteme.com
Thu May 10 09:20:01 CEST 2007
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
More information about the Devel
mailing list