[Nagiosplug-help] check_nrpe build sucks

[Ralph.Grothe at itdz-berlin.de]

Here is my inetd and nrpe configuration which doesn't work for
now.


# grep nrpe /etc/{services,inetd.conf}
/etc/services:nrpe              5666/tcp
/etc/inetd.conf:nrpe    stream tcp nowait nagios
/usr/local/nagios/sbin/nrpe nrpe -c
/usr/local/nagios/etc/nrpe.cfg -i


So this looks pretty much the same apart from deviating paths.


Files are present, either readable or executable

# ll /usr/local/nagios/*/nrpe*          
-rw-r--r--   1 root       sys           5450 Jul 14 15:04
/usr/local/nagios/etc/nrpe.cfg
-rwxr-xr-x   1 root       sys         111152 Jul 14 14:14
/usr/local/nagios/sbin/nrpe

User nagios exists

# id nagios
uid=556(nagios) gid=666(tivoli)

# grep nagios /etc/passwd 
nagios:*:556:666:::/sbin/sh


This is the comment stripped content of nrpe.cfg

# grep '^[^#]' /usr/local/nagios/etc/nrpe.cfg 
dont_blame_nrpe=0
debug=0
command_timeout=60
command[check_tns_FREMD]=@libexecdir@/check_oracle --env
ORACLE_HOME=/app/oracle/product/9.2.0,PATH=/usr/bin:\$ORACLE_HOME
/bin --tns FREMD
command[check_db_FREMD]=@libexecdir@/check_oracle --env
ORACLE_HOME=/app/oracle/product/9.2.0,PATH=/usr/bin:\$ORACLE_HOME
/bin --db FREMD
command[check_login_FREMD]=@libexecdir@/check_oracle --env
ORACLE_HOME=/app/oracle/product/9.2.0,PATH=/usr/bin:\$ORACLE_HOME
/bin --login FREMD


Unfortunately you didn't reveal one or more of your command
definitios.
I'm not sure if the @libexecdir@ construct, which to me looks
like a macro placeholder,
really gets expanded correctly.
But I thought this was compiled in from the --prefix flag during
configure run.


What puzzles me is that you define server_port in nrpe.cfg
as it should be not needed since the port is registered in
/etc/services.
Also it says that nrpe_user and nrpe_group aren't required when
run under the auspice of inetd.
The nrpe_user is already in the server definition as 5th field in
inetd.conf.

That's what I mean with poorly documented.
This is all not clear to me from the comments since they even
seem to be contradicting.
It also nowhere says if and how the "macro" placeholders are
expanded,
or if the should be substituted with fixed values by the user.





> -----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 3: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 09:24
> >Subject: RE: [Nagiosplug-help] check_nrpe build sucks
> >
> >
> >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.
> 
> <Yoda> Patience, young Jedi. </Yoda>
> 
> >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.
> 
> Well, it still parses the config file. Then if it doesn't 
> need something
> (I'm inferring that you're running under inetd), it just
ignores the
> value -- but it still needs to get a valid value.
> 
> >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@
> 
> There's your first problem. Give it a port number -- you're 
> using 5666,
> so set it there. 
> 
> >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.
> 
> Let's compare notes. Here's my relevant inetd.conf line:
> 
> # Nagios Remote Program Execution daemon
> #
> nrpe stream tcp nowait nagios /usr/local/bin/nrpe nrpe -c
> /usr/local/etc/nrpe.cfg -i
> 
> And then the relevant lines from nrpe.cfg apart from my command
> configuration:
> 
> server_port=5666 (ignored, running from inetd)
> #server_address=192.168.1.1 (ignored)
> allowed_hosts=127.0.0.1 (ignored)
> nrpe_user=nagios
> nrpe_group=nagios
> dont_blame_nrpe=0
> debug=0
> command_timeout=60
> 
> I also have "nrpe 5666/tcp" in /etc/services. But that's it. 
> No amazing
> level of hoop-jumping apart from getting the blessed thing
compiled in
> the first place.
> 
> NRPE is a bit of a beast, true, but it can be tamed.
> 
> --Erwin
> ############################################################
> 
> 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
>