The following is added documentation for NRPE 3.0. It will change as the project stabilize and approaches some sort of upstream-like state.

This is a so far unofficial version of NRPE, dubbed 3.0 by yours truly. It implements IPv6 support and does a general cleanup. The version-number 3.0 was chosen because it differs vastly from previous versions, but is subject to change.

It is quite likely that several key features are broken at the moment, thus any feedback is welcome. This applies particularly to non-standard configs.

NRPE "3.0" uses getaddrinfo() both for listening and connecting, which makes it agnostic to IPv4 vs IPv6. However, it does present a challenge with dual-stack: I have yet to implement support for listening to both IPv4 and IPv6. Connecting is no problem though: getaddrinfo() returns a list of possible addresses to use and the correct way of using it is to iterate over it until it connects. This will leave the choice of prioritization to the operating system, which should return a sorted list.

An other flaw is that I have not verified how connection-filtering works at the moment. This likely breaks for IPv6, thus you'll need to allow all, then use firewall techniques. Frankly, this might be the Correct solution anyway.

I've moved away from the "what the heck is this?"-system and to plain autotools for "3.0". This should allow easier maintainability and makes everything less magic. However, this is likely to have broken several key features. I've only tested it on Debian (though the result has been tested on other systems), but it shouldn't be that hard to adapt.

The general build process from scratch is:

./autogen.sh
./configure
make
make install # may require root. e.g: sudo make install

If you require a package, you can use:

./autogen.sh
./configure
make dist

Which will build a proper tar-ball (which doesn't require you to run ./autogen.sh)

To build, you will need:

• Basic build utilities (make, a C compiler/linker, etc)
• automake, autoconf, autoheader (i.e., autotools. This is only required if you do not have a tar-ball generated by make dist)
• pkg-config and openssl if using ssl, or pass --without-ssl to ./configure

There are no dependencies to run the nrpe-server or use check_nrpe except OpenSSL if you are using SSL.

The following is the (reformatted) documentation that shipped with NRPE 2.*. It may not apply verbatim to the current version, but is left for completeness.

It was written by Ethan Galstad ([email protected]).

For installation instructions and information on the design overview of the NRPE addon, please read the PDF documentation that is found in this directory: NRPE.pdf

The purpose of this addon is to allow you to execute Nagios plugins on a remote host in as transparent a manner as possible.

There are two pieces to this addon:

1. NRPE

   • This program runs as a background process on the remote host and processes command execution requests from the check_nrpe plugin on the Nagios host. Upon receiving a plugin request from an authorized host, it will execute the command line associated with the command name it received and send the program output and return code back to the check_nrpe plugin

2. check_nrpe

   • This is a plugin that is run on the Nagios host and is used to contact the NRPE process on remote hosts. The plugin requests that a plugin be executed on the remote host and wait for the NRPE process to execute the plugin and return the result. The plugin then uses the output and return code from the plugin execution on the remote host for its own output and return code.

The check_nrpe plugin should be placed on the Nagios host along with your other plugins. In most cases, this will be in the /usr/local/nagios/libexec directory.

The nrpe program and the configuration file (nrpe.cfg) should be placed somewhere on the remote host. Note that you will also have to install some plugins on the remote host if you want to make much use of this addon.

Sample config files for the NRPE daemon are located in the sample-config/ subdirectory.

If you plan on running nrpe under inetd or xinetd and making use of TCP wrappers, you need to do the following things:

Add a line to your /etc/services file as follows (modify the port number as you see fit):

nrpe            5666/tcp        # NRPE

Add entries for the NRPE daemon to either your inetd or xinetd configuration files. Which one your use will depend on which superserver is installed on your system. Both methods are described below. NOTE: If you run nrpe under inetd or xinetd, the server_port and allowed_hosts variables in the nrpe configuration file are ignored.

If your system uses the inetd superserver WITH tcpwrappers, add an entry to /etc/inetd.conf as follows:

nrpe    stream  tcp     nowait  <user> /usr/sbin/tcpd <nrpebin> -c <nrpecfg> --inetd

If your system uses the inetd superserver WITHOUT tcpwrappers, add an entry to /etc/inetd.conf as follows:

nrpe    stream  tcp     nowait  <user> <nrpebin> -c <nrpecfg> --inetd

• Replace <user> with the name of the user that the nrpe server should run as. Example: nagios
• Replace <nrpebin> with the path to the nrpe binary on your system. Example: /usr/local/nagios/nrpe
• Replace <nrpecfg> with the path to the nrpe config file on your system. Example: /usr/local/nagios/nrpe.cfg

If your system uses xinetd instead of inetd, you'll probably want to create a file called 'nrpe' in your /etc/xinetd.d directory that contains the following entries:

# default: on
# description: NRPE
service nrpe
{
        flags           = REUSE
        socket_type     = stream
        wait            = no
        user            = <user>
        server          = <nrpebin>
        server_args     = -c <nrpecfg> --inetd
        log_on_failure  += USERID
        disable         = no
        only_from       = <ipaddress1> <ipaddress2> ...
}

• Replace <user> with the name of the user that the nrpe server should run as.
• Replace <nrpebin> with the path to the nrpe binary on your system.
• Replace <nrpecfg> with the path to the nrpe config file on your system.
• Replace the <ipaddress> fields with the IP addresses of hosts which are allowed to connect to the NRPE daemon. This only works if xinetd was compiled with support for tcpwrappers.

Restart inetd or xinetd will the following command (pick the on that is appropriate for your system:

/etc/rc.d/init.d/inet restart

/etc/rc.d/init.d/xinetd restart

OpenBSD users can use the following command to restart inetd:

kill -HUP `cat /var/run/inet.pid`

Add entries to your /etc/hosts.allow and /etc/hosts.deny file to enable TCP wrapper protection for the nrpe service. This is optional, although highly recommended.

Examples for configuring the nrpe daemon are found in the sample nrpe.cfg file included in this distribution. That config file resides on the remote host(s) along with the nrpe daemon. The check_nrpe plugin gets installed on the Nagios host. In order to use the check_nrpe plugin from within Nagios, you'll have to define a few things in the host config file. An example command definition for the check_nrpe plugin would look like this:

define command {
        command_name    check_nrpe
        command_line    /usr/local/nagios/libexec/check_nrpe -H $HOSTADDRESS$ -c $ARG1$
}

In any service definitions that use the nrpe plugin/daemon to get their results, you would set the service check command portion of the definition to something like this (sample service definition is simplified for this example):

define service{
        host_name               someremotehost
        service_description     someremoteservice
        check_command           check_nrpe!yourcommand
        ... etc ...
}

where "yourcommand" is a name of a command that you define in your nrpe.cfg file on the remote host (see the docs in the sample nrpe.cfg file for more information).

If you have questions about this addon, or problems getting things working, first try searching the nagios-users mailing list archives. Details on searching the list archives can be found at http://www.nagios.org

If all else fails, you can email me and I'll try and respond as soon as I get a chance.

-- Ethan Galstad ([email protected])