[Nagiosplug-help] How to verify if nagios was built with embperl?

[Ralph.Grothe at itdz-berlin.de]

Hi Thomas,

> -----Original Message-----
> From: Thomas Guyot-Sionnest [mailto:dermoth at aei.ca]
> Sent: Tuesday, September 25, 2007 5:29 AM
> To: Grothe, Ralph
> Cc: nagiosplug-help at lists.sourceforge.net
> Subject: Re: [Nagiosplug-help] How to verify if nagios was
built with
> embperl?
> 
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 24/09/07 09:22 AM, Ralph.Grothe at itdz-berlin.de wrote:
> > Hello,
> > 
> > this is a follow-on to my posting to this list about
inexplicable
> > UNKNOWN state determination
> > by nagios of a custom plugin.
> > 
> > [...]
> > 
> > So, how can I verify that my nagios binary indeed is
precaching
> > Perl plugins
> > and executing them via embperl?
> > 
> > When I look at the shared libs there is a reference to some
> > libperl
> > which to me looks like I do run an embperl enabled nagios.
> 
> There you have it. You can also look at the output of configure
> (embedded Perl is a configure option).

I was suspecting this
but was unaware of it until I tripped over my signal handler.
As I said, for the sake of laziness, I simply installed Nagios
and plugins
as well as NRPE and NSCA from prebuilt RPM packages.
But as usual these packages lack the config or spec file of their
build
(I suppose one is expected to download them separately from the
packager,
so I will have to look at their site)

# rpm -ql nagios|egrep conf\|spec
/etc/httpd/conf.d/nagios.conf
/usr/lib/nagios/cgi-bin/config.cgi
/usr/share/nagios/html/docs/config.html
/usr/share/nagios/html/docs/configcgi.html
/usr/share/nagios/html/docs/configextinfo.html
/usr/share/nagios/html/docs/configmain.html
/usr/share/nagios/html/docs/configobject.html
/usr/share/nagios/html/docs/images/cgi-config.png
/usr/share/nagios/html/docs/verifyconfig.html
/usr/share/nagios/html/stylesheets/config.css

# rpm -q --qf %{packager}\\n nagios
Fedora Project <http://bugzilla.redhat.com/bugzilla>


Although it is in general sensible to refrain from usage of
globals
(not only for ePN or mod_perl and the likes)
I can imagine that there are some situations where one can make
good use of them,
or even hardly avoid them.
For instance when setting timers in Perl it is common practice
to define an eval block wherein one would also define a SIGALRM
handler
and start it by a syscall to alarm().
Once the critical code has been executed one would reset the
alarm by a second syscall.
Should on the other hand the critical code could not have be
executed within the secs passed to the
first alarm call a SIGALRM would be raised and caught by the
handler which mostly would
only undieably die() in producing some output that perl would
store in $@ for further reference.
("perldoc -f alarm" gives a much better description)
I wonder what peculiar results constructs like this exhibit when
run under ePN?
(well, one can easily find out by experiment...)

> 
> You can skip the embedded Perl execution by calling the Perl
binary
> within Nagios. I.e. in your command definition:
> 
> command_line    /usr/bin/perl $USER1$/check_stuff.pl
<some_args>


Yes, good to know fallback for difficult to reconcile with ePN
code.
Thanks for reminding me.

> 
> While this is an option it is always better to fix your Perl
script as
> embedded Perl execution is much faster (the plugin is 
> compiled only once
> and there's no forking necessary).
> 
> This is a good guideline fro writing ePN plugins:
>
http://nagiosplug.sourceforge.net/developer-guidelines.html#PERLP
LUGIN

Yes, I have already come accross this but haven't sticked to them
as I erroneously assumed they would not apply to my installed
nagios.

> 
> You can also use Nagios::Plugins which can make your life 
> much easier...

Same with this one, I haven't tried it yet but will give it a
look...


Ralph