[Nagiosplug-help] check_nrpe build sucks

Ralph.Grothe at itdz-berlin.de Ralph.Grothe at itdz-berlin.de
Thu Jul 14 06:28:09 CEST 2005


Hello Erwin,

glad I found someone at last who got this beast working on HPUX.

So far I'm not too convinced of the NRPE stuff.

This all is very poorly documented, and where it is documented it
even seems to lie, partly.

Take alone all the comments in the nrpe.cfg file that pretend
that if nrpe is not run as stand-alone daemon but under the reign
of inetd that this and that parameter is ignored,
which definetly isn't the truth.

e.g.

# sed -n '/PORT NUMBER/,/server_port/p'
/usr/local/nagios/etc/nrpe.cfg
# PORT NUMBER
# Port number we should wait for connections on.
# NOTE: This must be a non-priviledged port (i.e. > 1024).
# NOTE: This option is ignored if NRPE is running under either
inetd or xinetd

server_port=@nrpe_port@


Mind you, I have also compiled the nrpe stuff from the sources on
the HPUX node by now,
and swremoved and threw away the prebuilt depot.

If I leave the above line uncommented nrpe moans in syslog.log

# /usr/local/nagios/libexec/check_nrpe -H 127.0.0.1 -p 5666 -c
check_tns_FREMD
CHECK_NRPE: Received 0 bytes from daemon.  Check the remote
server logs for error messages.

# tail -2 /var/adm/syslog/syslog.log 
Jul 14 15:03:12 terra nrpe[21770]: Invalid port number specified
in config file '/usr/local/nagios/etc/nrpe.cfg' - Line 20
Jul 14 15:03:12 terra nrpe[21770]: Config file
'/usr/local/nagios/etc/nrpe.cfg' contained errors, bailing out...


But when I comment the line (and all others that are claimed to
be ignored)

# sed -n '/PORT NUMBER/,/server_port/p'
/usr/local/nagios/etc/nrpe.cfg
# PORT NUMBER
# Port number we should wait for connections on.
# NOTE: This must be a non-priviledged port (i.e. > 1024).
# NOTE: This option is ignored if NRPE is running under either
inetd or xinetd

#server_port=@nrpe_port@


This crap is happening (although I now run only from source
compiled binaries)

# /usr/local/nagios/libexec/check_nrpe -H 127.0.0.1 -p 5666 -c
check_tns_FREMD
CHECK_NRPE: Response packet had invalid CRC32.

# echo $?
3

I'm so sick of these debugging sessions while I need things
working in an overlookable time
with other tasks that call for action.

Please reveal to me what problems the CRC32 error disguise and
how you accomplished the trick.





> -----Original Message-----
> From: nagiosplug-help-admin at lists.sourceforge.net
> [mailto:nagiosplug-help-admin at lists.sourceforge.net]On Behalf
Of
> Mascardo, Erwin
> Sent: Thursday, July 14, 2005 2:44 PM
> To: nagiosplug-help at lists.sourceforge.net
> Subject: RE: [Nagiosplug-help] check_nrpe build sucks
> 
> 
> 
> 
> >-----Original Message-----
> >From: Ralph.Grothe at itdz-berlin.de 
> [mailto:Ralph.Grothe at itdz-berlin.de] 
> >Sent: Thursday, 14 July, 2005 07:23
> >To: ae at op5.se; nagiosplug-help at lists.sourceforge.net
> >Subject: RE: [Nagiosplug-help] check_nrpe build sucks
> >
> >
> >Found another time gap to further fiddle with NRPE.
> >
> >Since ldd check_nrpe listed libssl and libcrypt to be linked
> >against
> >(what I had assumed to having had avoided by simply not
supplying
> >the --enable-ssl switch to caonfigure)
> >I recleaned and reconfigured, this time explicitly passing
> >--disable-ssl
> >
> >Then make all finished without errors.
> >
> >But when I now run the newly built executable it claims not to
> >pass a CRC check.
> >
> >Where the hack is this coming from?
> >
> ># src/check_nrpe -H terra -p 5666 -c check_tns_FREMD
> >CHECK_NRPE: Response packet had invalid CRC32.
> >
> ># ldd src/check_nrpe
> >/usr/lib/libc.a(pse.o)
> >/usr/lib/libtli.a(shr.o)
> >/usr/lib/libpthreads.a(shr_comm.o)
> >/usr/lib/libpthreads.a(shr.o)
> >/usr/lib/libpthreads_compat.a(shr.o)
> >/usr/lib/libnsl.a(shr.o)
> >src/check_nrpe
> >/usr/lib/libcrypt.a(shr.o)
> >/usr/lib/libc.a(shr.o)
> >
> >
> >Hm, there's still libcrypt involved.
> >
> >Do have to rebuild with additional switch --disable-crypto ?
> >
> >configure --help doesn't mention such an option.
> >
> >Should I try to build the nrpe daemon on the HPUX remote host
as
> >well from the sources,
> >explicitly disabling any crypto links?
> >Remember that I download the prebuilt nrpe depot for HPUX
11.00
> >PARISC.
> 
> Yes. Definitely. There's nothing inherently wrong with having
libcrypt
> linked in, but you're running HP-UX...and given the wide
variation of
> possible configurations for that abomination, it's a good idea
to
> compile everything from source if you have a choice.
> 
> I run NRPE on a mixture of 10.20, 11.0, and 11.11 HP boxen, all
of it
> compiled locally with SSL disabled. It all works perfectly 
> well, and the
> only CRC errors I see are signs of problems.
> ############################################################
> 
> Intelsat is a global communications provider offering flexible
and 
> secure services to customers in over 220 countries and
territories.  
> Intelsat has maintained a leadership position for over 40 years
by 
> distributing video, voice, and data for television and 
> content providers, 
> government and military entities, major corporations, 
> telecommunications carriers, 
> and Internet service providers. Intelsat's reach, power and 
> expanding solutions 
> portfolio deliver information reliably and quickly to every 
> corner of the globe.  
> 
> For more information, visit www.intelsat.com.
> 
> ############################################################
> This email message is for the sole use of the intended
> recipient(s) and may contain confidential and privileged
> information.  Any unauthorized review, use, disclosure or 
> distribution is prohibited.  If you are not the intended 
> recipient, please contact the sender by reply email and 
> destroy all copies of the original message.  Any views 
> expressed in this message are those of the individual 
> sender, except where the sender specifically states them 
> to be the views of Intelsat, Ltd. and its subsidiaries.
> ############################################################
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by the 'Do More With Dual!' 
> webinar happening
> July 14 at 8am PDT/11am EDT. We invite you to explore the 
> latest in dual
> core and dual graphics technology at this free one hour event 
> hosted by HP, 
> AMD, and NVIDIA.  To register visit
http://www.hp.com/go/dualwebinar
> _______________________________________________
> Nagiosplug-help mailing list
> Nagiosplug-help at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nagiosplug-help
> ::: Please include plugins version (-v) and OS when reporting 
> any issue. 
> ::: Messages without supporting info will risk being sent to
/dev/null
> 




More information about the Help mailing list