Wednesday, 6 December 2017

Nagios Remote Plugin Executor (NRPE) and xinetd on Red Hat Enterprise Linux

As per a few previous posts, I'm tinkering ( there's that word again, I must think of another simile ) with Nagios.

This time I'm looking to have my Nagios monitoring server ( which runs on Ubuntu ) execute an agent on a remote boxen running Red Hat Enterprise Linux (RHEL).

Having installed the pre-requisites ( and I do need to document those steps more clearly ), I setup a NRPE script to be started using xinetd ( A Powerful Replacement For Inetd )

cat /etc/xinetd.d/nrpe 

# default: on
# description: NRPE (Nagios Remote Plugin Executor)
service nrpe
{
        flags           = REUSE
        socket_type     = stream    
port = 5666    
        wait            = no
        user            = nagios
group = nagios
        server          = /usr/local/nagios/bin/nrpe
        server_args     = -c /usr/local/nagios/etc/nrpe.cfg --inetd
        log_on_failure  += USERID
        disable         = no
# only_from       = 192.168.153.130
}


Having started the service: -

systemctl restart xinetd.service

I was expecting to see NRPE listening on port 5666: -

netstat -aon | grep LISTEN | grep 5666

but saw nothing alas.

I checked the logs: -

tail -f /var/log/messages

Dec  6 14:00:01 mfp systemd: Starting Session 222 of user root.
Dec  6 14:00:14 mfp xinetd[5771]: unexpected signal: 18 (Continued) in signal pipe
Dec  6 14:00:14 mfp systemd: Stopping Xinetd A Powerful Replacement For Inetd...
Dec  6 14:00:14 mfp xinetd[5771]: Exiting...
Dec  6 14:00:14 mfp systemd: Starting Xinetd A Powerful Replacement For Inetd...
Dec  6 14:00:14 mfp systemd: PID file /var/run/xinetd.pid not readable (yet?) after start.
Dec  6 14:00:14 mfp xinetd[6205]: service/protocol combination not in /etc/services: nrpe/tcp
Dec  6 14:00:14 mfp xinetd[6205]: xinetd Version 2.3.15 started with libwrap loadavg labeled-networking options compiled in.
Dec  6 14:00:14 mfp xinetd[6205]: Started working: 0 available services
Dec  6 14:00:14 mfp systemd: Started Xinetd A Powerful Replacement For Inetd.

which makes sense.

Following this: -


I updated the services table: -

vi /etc/services

and changed it from: -

...
cfengine        5308/tcp                        # CFengine
cfengine        5308/udp                        # CFengine
cvsup           5999/tcp        CVSup           # CVSup file transfer/John Polstra/FreeBSD
cvsup           5999/udp        CVSup           # CVSup file transfer/John Polstra/FreeBSD

...

to: -

...
cfengine        5308/tcp                        # CFengine
cfengine        5308/udp                        # CFengine

nrpe            5666/tcp                        # NRPE

cvsup           5999/tcp        CVSup           # CVSup file transfer/John Polstra/FreeBSD
cvsup           5999/udp        CVSup           # CVSup file transfer/John Polstra/FreeBSD

...

Once I again restarted xinetd : -

systemctl restart xinetd.service

the nrpe service started listening on port 5666: -

netstat -aon | grep LISTEN | grep 5666

tcp6       0      0 :::5666                 :::*                    LISTEN      off (0.00/0/0)

with no issues in the logs: -

tail -f /var/log/messages

Dec  6 14:09:54 mfp systemd: Starting Xinetd A Powerful Replacement For Inetd...
Dec  6 14:09:54 mfp systemd: PID file /var/run/xinetd.pid not readable (yet?) after start.
Dec  6 14:09:54 mfp xinetd[6803]: xinetd Version 2.3.15 started with libwrap loadavg labeled-networking options compiled in.
Dec  6 14:09:54 mfp xinetd[6803]: Started working: 1 available service
Dec  6 14:09:54 mfp systemd: Started Xinetd A Powerful Replacement For Inetd.


Thanks, Google, you again served me well ...

No comments:

Yay, VMware Fusion and macOS Big Sur - no longer "NAT good friends" - forgive the double negative and the terrible pun ...

After macOS 11 Big Sur was released in 2020, VMware updated their Fusion product to v12 and, sadly, managed to break Network Address Trans...