My /etc/xinetd.d/nrpe is below:
# /etc/xinetd.d/nrpe
# description: NRPE
# default: on
service nrpe
{
flags = REUSE
socket_type = stream
port = 5666
wait = no
# user = nobody
user = daemon
# group = nobody
group = wheel
server = /usr/local/sbin/nrpe
server_args = -c /etc/nagios/nrpe.cfg --inetd
log_on_failure += USERID
disable = no
only_from = 127.0.0.1 10.1.1.170
}
Originally, it was set to nobody:nobody. As a test, I set it to
daemon:wheel. In all cases, it gives the "cannot run as root" error. I
guess I can try making a Nagios user & group and testing with that.
A. Davis
Email: ncc...@gmail.com
"There is no limit to what a man can accomplish
if he doesn't care who gets the credit." - Ronald Reagan
Allan Clark wrote:
Reply is bottom-posted.
On Wed, Mar 18, 2009 at 16:57, Andrew Davis <ncc...@gmail.com
<mailto:ncc...@gmail.com>> wrote:
If I'm reading this correctly, the line about "NRPE daemon cannot
be run as user/group root!" is directly from the source code of
NRPE. Its not an xinetd thing. I've confirmed that xinetd is
running and listening on port 5666. I tried changing the
owner/group from nobody:nobody to another unprivileged user, but
it didn't work. Same results. It appears that despite my
configuring the /etc/nagios/nrpe.cfg and the /etc/xinetd.d/nrpe
files to use a user other than root, it still tries to start it as
the root user and thus when an incoming connection comes in, it
gives the "NRPE daemon cannot be run as user/group root!" error.
Any thoughts on how to rectify this? Since NRPE is working fine on
Linux, is this just a Mac OS X thing? Any help would be immensely
appreciated.
AD
Andrew Davis wrote:
FYI: /var/log/system.log on the client shows:
Mar 18 16:08:07 shu xinetd[29066]: START: nrpe pid=557
from=10.1.1.170
Mar 18 16:08:07 shu nrpe[557]: Error: NRPE daemon cannot be run
as user/group root!
whether I do the default test (with SSL) or use the -n flag to
test w/o SSL. The odd thing is that the nrpe config in
/etc/xinetd.d is set to run as nobody:nobody and
/etc/nagios/nrpe.cfg is owned by nobody:nobody. Only
/usr/local/sbin/nrpe is owned by root (as it should be), but is
also set to 755 perms. I've compared to a Linux box I have with
NRPE and xinetd working properly and the permissions are identical.
I'm stumped...
Andrew Davis wrote:
I have two Mac OS X servers, one running 10.3, the other running
10.4. Neither can be upgraded to 10.5 due to third party s/w
constraints. Both are PPC based XServe's.
Trying to compile nrpe with:
./configure --sysconfdir=/etc/nagios --enable-ssl
Initially, I got the "cannot find ssl libraries" error:
~
checking for SSL headers... SSL headers found in /usr/local/ssl
checking for SSL libraries... configure: error: Cannot find
ssl libraries
I downloaded the latest openssl and built it with:
./config --prefix=/usr/local shared
--openssldir=/usr/local/openssl
make
make test
make install
I then had to edit ~/src/nrpe/configure and change the reference
from libssl.so to libssl.dylib
After that, nrpe compiled cleanly and I was able to move
~src/nrpe/src/nrpe to /usr/local/sbin and start xinetd up. I've
confirmed that port 5666 is open and xinetd is running:
/usr/local/src/nrpe-2.12/src root# ps waux|grep xinet|grep
-v greproot 29066 0.0 -0.0 27484 308 ?? Ss
3:53PM 0:00.02 /usr/sbin/xinetd -pidfile
/var/run/xinetd.pid -stayalive
/usr/local/src/nrpe-2.12/src root# netstat -an|grep
5666tcp4 0 0 *.5666
*.* LISTEN
However, when connecting from the remote server, I get:
/usr/local/nagios/libexec/check_nrpe -H host.mydomain.org
<http://host.mydomain.org>
CHECK_NRPE: Error - Could not complete SSL handshake.
The same test but w/o SSL gives yields:
[nag...@nephilim src]$ /usr/local/nagios/libexec/check_nrpe
-n -H host.mydomain.org <http://host.mydomain.org>
CHECK_NRPE: Received 0 bytes from daemon. Check the remote
server logs for error messages.
So two questions:
1) I'm a UNIX guy, but obviously Mac's are A) different and B) a
tad different being BSD-based. So what's the proper way to
stop/restart the xinetd daemon?
2) Any thoughts on SSL handshake error? I've googled it, but I'm
not getting very far.
Anyone have a step-by-step for compiling nagios plugins and NRPE
from source on OS X 10.x (specifically 10.3 and 10.4)? I'm using
NRPE for all other internal hosts, so I prefer to use it for the
Mac's too. I know I could do it via check_by_ssh and get around
this, but I prefer to use NRPE if I can.
--
On a Mac, your xinetd is a bolt-on over the launchd that's there by
default; you've obviously got it running. Since you're in
/etc/xinetd.d/<something>, you need to cnfigure a different username
via xinetd's config. Look for a /etc/xinetd.d/nrpe file, or similar,
containing the config for your nrpe service. I tend to grep for the
port number in order to find the file. Remember to check /local/*
The time service has an example with juicy comments:
service time
{
# This is for quick on or off of the service
disable = yes
...
...
# External services must fill out the following
# user =
# group =
...
...
}
Take a look there, see if you can choose a better username and/or
group and if your port of xinetd honours it. I don't know if you have
a nrpe user, or run it as nobody.
A better option would be a proper launchd config, allowing you to
shutdown xinetd if you're installing it there for this purpose only,
but then it's a Mac-only thing, and would be more difficult to
maintain for non-Mac people.
Allan
------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
Nagios-users mailing list
Nagios-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-users
::: Please include Nagios version, plugin version (-v) and OS when reporting
any issue.
::: Messages without supporting info will risk being sent to /dev/null
