[Nagiosplug-help] check_nrpe problem

Robert Lowe Robert.H.Lowe at lawrence.edu
Mon Jan 30 11:43:02 CET 2006


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=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
>>
>>
>>-------------------------------------------------------
>>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