[Nagiosplug-help] check_nrpe problem
Mark Grafing
mgrafing at voyence.com
Mon Jan 30 11:45:09 CET 2006
Turn off selinux....
-----Original Message-----
From: nagiosplug-help-admin at lists.sourceforge.net
[mailto:nagiosplug-help-admin at lists.sourceforge.net] On Behalf Of Robert
Lowe
Sent: Monday, January 30, 2006 1:41 PM
To: gh
Cc: nagiosplug-help at lists.sourceforge.net
Subject: Re: [Nagiosplug-help] check_nrpe problem
gh wrote:
> This is a list of all things NRPE related that I do for a remote
client.
> One thing that is easily missed is to update the /etc/services file.
> After you have checked / changed things to match this, make sure to
> restart xinetd (/etc/init.d/xinetd restart).
All of these matched for me... but after I modified /etc/nrpe.cfg to
turn on debugging there, what shows up in syslogd?
Jan 30 13:23:14 netreg nrpe[32294]: Error: NRPE daemon cannot be run as
user/group root!
This only shows up when run run [x]inetd, apparently, because I ran it
as root in daemon mode, e.g. nrpe -d -c <conffile>. Perhaps this check
has only recently been added!? Perhaps in daemon mode it just drops
privs -- I haven't looked at the code.
Anyway, I modified the xinetd nrpe file to use 'nobody' instead of
'root', and all is well. BTW, is there a good reason to create a
'nagios' user/group on a remote box? If not, 'nobody' seems as good as
any other user to me.
This should probably be added to the FAQ entry.
> Let me know if this gives you any luck..
>
> BTW: What versions of NRPE, Nagios, and the Nagios Plugins are you
> running?
NRPE 2.3
Nagios 2.0rc2
Nagios Plugins 1.4 (IIRC).
Thanks leading me towards the solution!
-r
> [root at host /]# grep nrpe /etc/services
> nrpe 5666/tcp # nrpe
>
> [root at host /]# ls -la /etc/xinetd.d/ |grep -e fam -e nrpe
> -rw-r--r-- 1 root root 325 Jul 1 2005 nrpe
> -rw-r--r-- 1 root root 392 Oct 4 2004 sgi_fam
>
> [root at host /etc/xinetd.d]$ cat sgi_fam service sgi_fam # default: on #
> description: FAM
>
> {
> type = RPC UNLISTED
> socket_type = stream
> user = root
> group = nobody
> server = /usr/bin/fam
> wait = yes
> protocol = tcp
> rpc_version = 2
> rpc_number = 391002
> bind = 127.0.0.1
> }
>
> [root at host /etc/xinetd.d]$ cat nrpe
> # default: on
> # description: NRPE
>
> service nrpe
> {
> flags = REUSE
> socket_type = stream
> wait = no
> user = nagios
> server = /usr/sbin/nrpe
> server_args = -c /home/nagios/nrpe.cfg --inetd
> log_on_failure += USERID
> disable = no
> only_from = 192.168.1.4
> }
>
> [root at host /# ls -la /usr/sbin/nrpe
> -rwxr-xr-x 1 root root 70476 Sep 16 12:54 /usr/sbin/nrpe
>
> [root at host /]# chkconfig --list |grep -e xinetd -e fam -e nrpe
> xinetd 0:off 1:off 2:off 3:on 4:on 5:on 6:off
> xinetd based services:
> nrpe: on
> sgi_fam: on
>
> [root at host /]# ls -la /home/nagios/nrpe.cfg
> -rw-r--r-- 1 root root 6054 Sep 16
> 14:08 /home/nagios/nrpe.cfg
>
> [root at host /]# cat /home/nagios/nrpe.cfg
> server_port=5666
> nrpe_user=nagios
> nrpe_group=nagios
> dont_blame_nrpe=1
> debug=0
> command_timeout=60
> command[check_dummy]=/home/nagios/libexec/check_dummy 0
>
>
> On Mon, 2006-01-30 at 12:12 -0600, Robert Lowe wrote:
>
>>gh wrote:
>>
>>>What system is this running on? And to be clear, this system is a
>>>remote host that your nagios server is checking, correct?
>>
>>Yes.
>>
>>
>>>Please send the
>>>output of `uname -a`
>>
>>Linux <hostname> 2.4.18-3 #1 Thu Apr 18 07:37:53 EDT 2002 i686 unknown
>>
>>The nagios server is running RedHat FC4 with a 2.6.11-1 kernel.
>>
>>-Robert
>>
>>
>>>On Mon, 2006-01-30 at 11:02 -0600, Robert Lowe wrote:
>>>
>>>
>>>>Hi,
>>>>
>>>>I'm having trouble starting nrpe via xinetd. It starts but quickly
>>>>fails; trying to run check_nrpe reveals an error about which there
>>>>is a FAQ (SSL handshake). However, I think I'm seeing something
>>>>different than what the FAQ describes. I can run nrpe on the remote
>>>>host in daemon mode, and all is fine. If xinetd launches it, it
>>>>fails.
>>>>I run xinetd in debug mode and get:
>>>>
>>>>Service defaults
>>>> Instances = 60
>>>> CPS = 30 25
>>>> Logging to syslog. Facility = authpriv, level = info
>>>> Log_on_success flags = HOST PID
>>>> Log_on_failure flags = HOST
>>>>
>>>>Service configuration: nrpe
>>>> id = nrpe
>>>> flags = REUSE IPv4
>>>> socket_type = stream
>>>> Protocol (name,number) = (tcp,6)
>>>> Groups = 0
>>>> Server = /usr/sbin/nrpe
>>>> Server argv = nrpe -i -c /etc/nrpe.cfg
>>>> Only from: 143.44.4.13(NUMERIC)
>>>> Logging to syslog. Facility = authpriv, level = info
>>>> Log_on_success flags = HOST PID
>>>> Log_on_failure flags = HOST USERID
>>>>
>>>>Service configuration: sgi_fam
>>>> id = sgi_fam
>>>> flags = IPv4
>>>> type = RPC UNLISTED
>>>> socket_type = stream
>>>> Protocol (name,number) = (tcp,6)
>>>> Groups = 0
>>>> Bind = localhost
>>>> Server = /usr/bin/fam
>>>> Server argv = fam
>>>> RPC data
>>>> program number = 391002
>>>> rpc_version = 2
>>>> Logging to syslog. Facility = authpriv, level = info
>>>> Log_on_success flags = HOST PID
>>>> Log_on_failure flags = HOST
>>>>
>>>>Service configuration: ftp
>>>> id = ftp
>>>> flags = IPv4
>>>> socket_type = stream
>>>> Protocol (name,number) = (tcp,6)
>>>> Nice = 10
>>>> Groups = 0
>>>> Server = /usr/sbin/in.ftpd
>>>> Server argv = in.ftpd -l -a
>>>> Logging to syslog. Facility = authpriv, level = info
>>>> Log_on_success flags = HOST DURATION PID
>>>> Log_on_failure flags = HOST
>>>>
>>>>06/1/30 at 09:45:00: DEBUG: {cnf_start_services} Started service: nrpe
>>>>06/1/30 at 09:45:00: ERROR: {activate_rpc} pmap_set failed.
>>>>service=sgi_fam
>>>>program=391002 version=2
>>>>06/1/30 at 09:45:01: DEBUG: {activate_rpc} Registered 0 versions of
>>>>sgi_fam
>>>>06/1/30 at 09:45:01: DEBUG: {cnf_start_services} Started service: ftp
>>>>06/1/30 at 09:45:01: DEBUG: {cnf_start_services} mask_max = 7,
>>>>services_started = 2
>>>>06/1/30 at 09:45:01: NOTICE: {main} Started working: 2 available
>>>>services
>>>>06/1/30 at 09:45:01: DEBUG: {main_loop} active_services = 2
>>>>06/1/30 at 09:45:39: DEBUG: {main_loop} select returned 1
>>>>06/1/30 at 09:45:39: DEBUG: {server_start} Starting service nrpe
>>>>06/1/30 at 09:45:39: DEBUG: {main_loop} active_services = 2
>>>>06/1/30 at 09:45:39: DEBUG: {exec_server} duping 9
>>>>06/1/30 at 09:45:39: DEBUG: {main_loop} active_services = 2
>>>>06/1/30 at 09:45:39: DEBUG: {main_loop} select returned 1
>>>>06/1/30 at 09:45:39: DEBUG: {check_pipe} Got signal 17 (Child exited)
>>>>06/1/30 at 09:45:39: DEBUG: {child_exit} waitpid returned = 31672
>>>>06/1/30 at 09:45:39: DEBUG: {server_end} nrpe server 31672 exited
>>>>06/1/30 at 09:45:39: DEBUG: {child_exit} waitpid returned = -1
>>>>06/1/30 at 09:45:39: DEBUG: {main_loop} active_services = 2
>>>>
>>>>...with no indication of a problem in syslog.
>>>>
>>>>My nrpe xinet configuration looks like:
>>>>
>>>># default: on
>>>># description: NRPE
>>>>service nrpe
>>>>{
>>>> disable = no
>>>> flags = REUSE
>>>> socket_type = stream
>>>> wait = no
>>>> user = root
>>>> server = /usr/sbin/nrpe
>>>> server_args = -i -c /etc/nrpe.cfg
>>>> log_on_failure += USERID
>>>>}
>>>>
>>>>I'm running it as 'root' for testing purposes only.
>>>>
>>>>The FAQ covers five cases:
>>>>
>>>>1. Different versions.
>>>> If this were the case, I could not run nrpe in daemon mode.
>>>>
>>>>2. SSL is disabled.
>>>> Again, I'm able to successfully run nrpe in daemon mode, and I
>>>> have not turned off SSL on either end via CLI switches.
>>>>
>>>>3. Incorrect file permissions.
>>>> Running as root.
>>>>
>>>>4. Pseudo-random device files are not readable.
>>>> Running as root.
>>>>
>>>>5. Unallowed address.
>>>> Not a factor... no tcp_wrappers that I can tell, and
host.allow/.deny
>>>> look fine to me. If it were rejected because of this, I'd see
some
>>>> evidence of it in syslog.
>>>>
>>>>What else can it be?? The two lines from the xinetd startup concern
>>>>me, but I've never seen them before, and don't seem to be able to
>>>>find out any information about them:
>>>>
>>>>06/1/30 at 09:45:00: ERROR: {activate_rpc} pmap_set failed.
>>>>service=sgi_fam
>>>>program=391002 version=2
>>>>06/1/30 at 09:45:01: DEBUG: {activate_rpc} Registered 0 versions of
>>>>sgi_fam
>>>>
>>>>Or am I just overlooking something? Any clues greatly appreciated!
>>>>
>>>>-Robert
>>>>
>>>>
>>>>-------------------------------------------------------
>>>>This SF.net email is sponsored by: Splunk Inc. Do you grep through
>>>>log files for problems? Stop! Download the new AJAX search engine
>>>>that makes searching your log files as easy as surfing the web.
DOWNLOAD SPLUNK!
>>>>http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=12
>>>>1642 _______________________________________________
>>>>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
>>
>>
>>-------------------------------------------------------
>>This SF.net email is sponsored by: Splunk Inc. Do you grep through log
>>files for problems? Stop! Download the new AJAX search engine that
>>makes searching your log files as easy as surfing the web. DOWNLOAD
SPLUNK!
>>http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=1216
>>42 _______________________________________________
>>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
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log
files for problems? Stop! Download the new AJAX search engine that
makes searching your log files as easy as surfing the web. DOWNLOAD
SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
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