AIX version is: 7100-04-01-1543

I have recently attempted to update our nrpe agent/daemon on our AIX systems.

Previously we were running:
Version: 2.5.1
Last Modified: 04-09-2006

Now, we are running:
Version: nrpe-3.0
Last Modified: 07-12-2016

When starting the nrpe daemon, it stays running as "root" regardless of the nrpe_user in the nrpe.cfg file. This issue seems very similar to: Issue #40 , but seems that RC2 was supposed to have the fix (and John Frickson confirmed).

As shown here, on startup, the nrpe process starts as "root", but the contents of the nrpe.cfg file have nrpe_user and nrpe_group as nagios.

The only way (seemingly) that I can get it to run as nagios is if I do a su.

root@hostname:/root>/etc/rc.d/init.d/nrpe start
Starting NRPE daemon... done.
root@hostname:/root>ps -ef | grep nrpe
    root 18808878        1   0 17:47:05      -  0:00 /usr/local/nagios/bin/nrpe -n -c /usr/local/nagios/etc/nrpe.cfg -d
root@hostname:/root>cat /usr/local/nagios/etc/nrpe.cfg | egrep 'nrpe_user|nrpe_group'
nrpe_user=nagios
nrpe_group=nagios
root@hostname:/root>/etc/rc.d/init.d/nrpe stop
Stopping NRPE daemon... done.
root@hostname:/root>su - nagios -c "/etc/rc.d/init.d/nrpe start"
Starting NRPE daemon... done.
root@aubues1:/root>ps -ef | grep nrpe
  nagios 13238330        1   0 17:48:14      -  0:00 /usr/local/nagios/bin/nrpe -n -c /usr/local/nagios/etc/nrpe.cfg -d

Hi!

When you define a hostname at "allowed_hosts" which can't be resolved by dns, all the other allowed_hosts can't request checks.

Startup:
Allowing connections from: notavalidhost.domain.de,icinga-wn04.domain.de,icinga-wn05.domain.de

nslookup notavalidhost
Server: our.dns.server.xxx
Address: our.dns.server.xxx#53

** server can't find stupidhost: NXDOMAIN

nslookup icinga-wn04
Server: our.dns.server.xxx
Address: our.dns.server.xxx#53

Name: icinga-wn04.domain.de
Address: xxx.xxx.194.64

nrpe[7072]: Host xxx.xxx.194.64 is not allowed to talk to us!

When I remove notavalidhost.domain.de from allowed_hosts and make a restart everything is working fine.

Best regards,
Patrick

I have had a problem as described here and I already submitted a bug to the bug tracker about this.

However, it might be better to write a str_split function and use that instead of using strtok (which is not re-entrant and thus leads to problems). While this STILL uses strtok is does not need to be re-entrant as it is one function call. It also works on the system in problem.

Consider to use (see below for further code fragments in how to apply):

char** str_split(char* a_str, const char a_delim)
{
char** result = 0;
size_t count = 0;
char* tmp = a_str;
char* last_comma = 0;
char delim[2];
delim[0] = a_delim;
delim[1] = 0;
/* Count how many elements will be extracted. _/
while (_tmp) {
if (a_delim == tmp) {
count++;
last_comma = tmp;
}
tmp++;
}
/ Add space for trailing token. /
count += last_comma < (a_str + strlen(a_str) - 1);
/ Add space for terminating null string so caller
knows where the list of returned strings ends. /
count++;
result = malloc(sizeof(char) * count);
if (result) {
size_t idx = 0;
char* token = strtok(a_str, delim);
while (token) {
assert(idx < count);
*(result + idx++) = strdup(token);
token = strtok(0, delim);
}
assert(idx == count - 1);
*(result + idx) = 0;
}
return result;
}

which then can be called in
I added a few more debugging statements to see the flow.
When you use it this way, the function adds correctly all items in the allowed_hosts list.

void parse_allowed_hosts(char allowed_hosts) {
char *hosts = strdup( allowed_hosts); / Copy since strtok* modifies original /
char *saveptr;
char *tok;
const char delim[2] = ",\0";
char *trimmed_tok;
char* tokens;

tokens = str_split(hosts, ',');
if (tokens)
{
int i;
for (i = 0; (tokens + i); i++)
{
syslog(LOG_INFO, "Current Token, trying one >%s<\n", *(tokens + i));
one=add_ipv4_to_acl((tokens + i));
syslog(LOG_INFO,"parse_allowed_hosts: one >%d<\n", one);
if(!one)
{
syslog(LOG_INFO,"parse_allowed_hosts: trying two >%s<\n", (tokens + i));
two=add_ipv6_to_acl((tokens + i));
syslog(LOG_INFO,"parse_allowed_hosts: two >%d<\n", two);
if(!two)
{
syslog(LOG_INFO,"parse_allowed_hosts: trying three >%s<\n", (tokens + i));
three=add_domain_to_acl((tokens + i));
if(!three)
{
syslog(LOG_INFO,"Can't add to ACL this record (%s). Check allowed_hosts option!\n",* (tokens + i));
syslog(LOG_ERR,"Can't add to ACL this record (%s). Check allowed_hosts option!\n",(tokens + i));
}
}
}
free((tokens + i));
}
free(tokens);
}
free( hosts);
}

After upgrading to 3.0, I can no longer pass arguments to NRPE commands. The log indicates:

nrpe[32827]: Error: Request contained command arguments!
nrpe[32827]: Client request from was invalid, bailing out...

A fully IPv6 dual stack enabled network is monitored by Nagios 3.5.1 installed from EPEL on a CentOS 6.7 server. Monitored hosts run NRPE agents, all of which are configured to run as daemons (not via xinetd) with the configuration line

allowed_hosts=bombur.example.com

where bombur.example.com is the Nagios server's FQDN which resolves in DNS to both the IPv4 and IPv6 addresses:

% host bombur
bombur.example.com has address 192.0.2.28
bombur.example.com has IPv6 address 2001:db8:f00:ba8::28

This works fine for hosts running NRPE releases before 2.15 which lack IPv6 support and ony accept IPv4 connections. But on hosts with NRPE 2.15, which does support IPv6, connections from the Nagios server are rejected with the log message:

nrpe[21665]: Host 2001:db8:f00:ba8::28 is not allowed to talk to us!

Apparently the allowed_hosts=<hostname> directive allows only the IPv4 address of the given host, not its IPv6 address.

skrueger8 commented in issue #68 about compiler warnings. Opening a new issue for this.

there are some compiler warnings though (I'm building with Oracle Developer Studio 12.5):

• "./nrpe.c", line 241: warning: initializer does not fit or is out of range: 2148535295

  241 int ssl_opts = SSL_OP_ALL | SSL_OP_SINGLE_DH_USE, vrfy;

ssl_opts has to be long, not int; see man SSL_CTX_set_options:

OpenSSL                                          SSL_CTX_set_options(3openssl)

NAME
       SSL_CTX_set_options, SSL_set_options, SSL_CTX_clear_options,
       SSL_clear_options, SSL_CTX_get_options, SSL_get_options,
       SSL_get_secure_renegotiation_support - manipulate SSL options

SYNOPSIS
        #include <openssl/ssl.h>

        long SSL_CTX_set_options(SSL_CTX *ctx, long options);

• "./nrpe.c", line 264: warning: implicit function declaration: RAND_status
• "./nrpe.c", line 265: warning: implicit function declaration: RAND_file_name
• "./nrpe.c", line 266: warning: implicit function declaration: RAND_load_file
• "./nrpe.c", line 267: warning: implicit function declaration: RAND_write_file
• "./nrpe.c", line 277: warning: implicit function declaration: RAND_seed
• "./nrpe.c", line 317: warning: implicit function declaration: ERR_get_error
• "./nrpe.c", line 319: warning: implicit function declaration: ERR_error_string
• "./nrpe.c", line 1752: warning: implicit function declaration: ERR_get_error_line_data
• "./nrpe.c", line 1754: warning: implicit function declaration: ERR_reason_error_string

missing includes in include/common.h:

#include <openssl/err.h>
#include <openssl/rand.h>

• "./nrpe.c", line 2156: warning: initializer will be sign-extended: -1
• "./nrpe.c", line 2157: warning: initializer will be sign-extended: -1

  2156          uid_t     uid = -1;
  2157          gid_t     gid = -1;

uid_t and gid_t are unsigned on Solaris:

grep uid_t /usr/include/sys/types.h

typedef unsigned int uid_t;             /* UID type             */
typedef uid_t   gid_t;                  /* GID type             */

• "./nrpe.c", line 2385: warning: statement not reached
• "./nrpe.c", line 2683: warning: statement not reached
• "./nrpe.c", line 2013: Warning: Likely out-of-bound read: *(output[1035]) in function my_system

No idea...

• "./acl.c", line 79: warning: statement not reached
• "./acl.c", line 82: warning: statement not reached
• "./acl.c", line 85: warning: statement not reached
• "./acl.c", line 88: warning: statement not reached

No idea

• "./check_nrpe.c", line 60: warning: initializer does not fit or is out of range: 2147486719

60  int ssl_opts = SSL_OP_ALL;

Same as nrpe.c, s/int/long/.

• "./check_nrpe.c", line 305: warning: statement not reached
• "./check_nrpe.c", line 314: warning: statement not reached
• "./check_nrpe.c", line 451: warning: statement not reached

No idea

• "./check_nrpe.c", line 924: warning: implicit function declaration: ERR_get_error_line_data
• "./check_nrpe.c", line 926: warning: implicit function declaration: ERR_reason_error_string

Missing openssl include, see above

hi everyone
I have 3 Server. 1 Nagios Core 2 Nagios Remote
1 one of 2 Nagios Remote have fault when i make all nrpe

And the nagios Remote serrver i setup now is faults have OUTPUT
_________________________________________

...............................
General Options:

NRPE port: 5666
NRPE user: nagios
NRPE group: nagios
Nagios user: nagios
Nagios group: nagios

Review the options above for accuracy. If they look okay,
type 'make all' to compile the NRPE daemon and client.

[canhdx@DANANG nrpe-2.13]$ sudo make all
cd ./src/; make ; cd ..
make[1]: Entering directory /home/canhdx/nrpe-2.13/src' gcc -g -O2 -I/usr/include/openssl -I/usr/include -DHAVE_CONFIG_H -o nrpe nrpe.c utils.c acl.c -L/usr/lib64 -lssl -lcrypto -lnsl nrpe.c: In function ‘main’: nrpe.c:218:7: warning: assignment discards ‘const’ qualifier from pointer target type [enabled by default] meth=SSLv23_server_method(); ^ gcc -g -O2 -I/usr/include/openssl -I/usr/include -DHAVE_CONFIG_H -o check_nrpe check_nrpe.c utils.c -L/usr/lib64 -lssl -lcrypto -lnsl check_nrpe.c: In function ‘main’: check_nrpe.c:126:7: warning: assignment discards ‘const’ qualifier from pointer target type [enabled by default] meth=SSLv23_client_method(); ^ make[1]: Leaving directory/home/canhdx/nrpe-2.13/src'

*** Compile finished ***

If the NRPE daemon and client compiled without any errors, you
can continue with the installation or upgrade process.

Read the PDF documentation (NRPE.pdf) for information on the next
steps you should take to complete the installation or upgrade.

And the nagios Remote serrver i setup before not faults is OUTPUT
_________________________________________

.......
*** Configuration summary for nrpe 2.13 11-11-2011 ***:

General Options:

NRPE port: 5666
NRPE user: nagios
NRPE group: nagios
Nagios user: nagios
Nagios group: nagios

Review the options above for accuracy. If they look okay,
type 'make all' to compile the NRPE daemon and client.

[canhdx@KHANHHOA_MO nrpe-2.13]$ sudo make
cd ./src/; make ; cd ..
make[1]: Entering directory /home/canhdx/nrpe-2.13/src' gcc -g -O2 -I/usr/include/openssl -I/usr/include -DHAVE_CONFIG_H -o nrpe nrpe.c utils.c acl.c -L/usr/lib64 -lssl -lcrypto -lnsl nrpe.c: In function ‘main’: nrpe.c:218: warning: assignment discards qualifiers from pointer target type gcc -g -O2 -I/usr/include/openssl -I/usr/include -DHAVE_CONFIG_H -o check_nrpe check_nrpe.c utils.c -L/usr/lib64 -lssl -lcrypto -lnsl check_nrpe.c: In function ‘main’: check_nrpe.c:126: warning: assignment discards qualifiers from pointer target type make[1]: Leaving directory/home/canhdx/nrpe-2.13/src'

*** Compile finished ***

If the NRPE daemon and client compiled without any errors, you
can continue with the installation or upgrade process.

Read the PDF documentation (NRPE.pdf) for information on the next
steps you should take to complete the installation or upgrade.

Is SSL? because i check in nagios Core
[canhdx@KHANHHOA_MO ~]$ /usr/local/nagios/libexec/check_nrpe -H 10.58.37.176 -n
NRPE v2.13
OK ------------------ but
[canhdx@KHANHHOA_MO nrpe-2.13]$ /usr/local/nagios/libexec/check_nrpe -H 10.58.37.176
CHECK_NRPE: Socket timeout after 10 seconds.

Faults

Have been informed of at least one security issue. I will be searching for others and get them addressed ASAP.

When attempting to execute an empty file with the execute bit set using sh -c, sh returns 0 (even though the execve(2) call fails). Since NRPE executes the check plugins using sh -c, nagios will think everything is fine, while in reality nothing is checked.

I recently deployed a faulty build of one of our checks (with an empty file instead of the actual check), which we didn't immediately notice because nagios was still happy.

Is there any way around this? Would stuff break if NRPE were to execute the plugin directly, instead of using sh (so NRPE can check the execve return code itself)?

See the tracker for potential patch:
http://tracker.nagios.org/view.php?id=90

Hi,

I would like to use option in -a argument like that:

/usr/local/nagios/libexec/check_nrpe -2 -P 8192 -H 10.50.1.15 -c check_cpu -a --foo

Something like. I don't know if it's working and you can attach next values to "-a" argument:

/usr/local/nagios/libexec/check_nrpe -2 -P 8192 -H 10.50.1.15 -c check_cpu -a -- --foo test --test2

Thanks

Hi

When check_nrpe runs it fills the log quickly with "Remote %s accepted a Version %s Packet".
There is no way to turn it off other then excluding it in source, then recompiling it.
If you have lots of machines, the logs is filled quickly.

It would be nice if this would have a "debug" inclusion instead of printed all the time.
It is useful when debugging and finding out which service is Version 2 or 3, but not all the time.

Jobst

John

During my last couple of days to find my problem one thing I noticed: missing debug statements.

I have attached two files nrpe.cfg and acl.c that show were I added "syslog(....)" statements to make debugging a little easier. I would have found the bugs earlier wasn't it for the missing syslog(..)'s.

Also, the function show_acl_list should be part of of the printout "if(debug==TRUE)" right AFTER the parsing of the allowed_hosts varaible! It, too, should syslog the information instead of printf them!.

You can easily find the changed/added code by searching /* jobst added/changed */ in both files.
I had to add these to figure out what was wrong.

Please use it so the next poor soul has an easier time!

twofiles.zip

I've identified this on CentOS 5.11 x86 and x86_64.

[root@centos22 nrpe-3.0]# service nrpe status
Checking for nrpe daemon...nrpe (pid 5781) is running...
/etc/init.d/nrpe: line 147: _set_rc: command not found

[root@centos22 nrpe-3.0]# service nrpe stop
/etc/init.d/nrpe: line 111: _set_rc: command not found     [  OK  ]

[root@centos22 nrpe-3.0]# service nrpe start
/etc/init.d/nrpe: line 96: _set_rc: command not found      [  OK  ]

[root@centos22 nrpe-3.0]# service nrpe restart
/etc/init.d/nrpe: line 111: _set_rc: command not found     [  OK  ]

/etc/init.d/nrpe: line 96: _set_rc: command not found      [  OK  ]

Regardless of the error message, the daemon is correctly being stopped, started, restarted, status

NRPE v3.0

This took a fair while to debug.
When I run "configure --sysconfdir ..... --enable-ssl" I can see the following lines:

checking for strstr... yes
checking for strtoul... yes
checking for strtok_r... yes
checking for initgroups... yes`

but when I add a debug line using "syslog(..)" to the function "parse_allowed_hosts()" as such:

ifdef HAVE_STRTOK_R

syslog(LOG_INFO,"parse_allowed_hosts strtok_r\n");
tok = strtok_r(hosts, delim, &saveptr);

else

syslog(LOG_INFO,"parse_allowed_hosts strtok\n");
tok = strtok(hosts, delim);

endif`

then in the syslog I see:

Aug 29 14:42:37 NRPE_CLIENT nrpe[3200]: parse_allowed_hosts strtok

which, off course, indicates that strtok is used although strtok_r is available.

This, off course, has a massive problem for me as "strtok" is NOT re-entrant and leads to problems I have initially described here.

Jobst

Hi
The debug declaration in the file nrpe.cfg needs to be higher up, if not FIRST!

Reason: when parsing the file and the debug declaration is too late, the check "if(debug==TRUE)" in functions that are used BEFORE (for example parse_allowed_hosts) returns the incorrect value as it has NOT been declared early enough.

This issue has been automatically migrated from http://tracker.nagios.org/view.php?id=0000419 - Please follow that link for details.
Originally submitted on 2013-02-05 by mfrost

In our environment, we don't have root access or generally control over how syslog is working on our servers. Because syslog is the means by which NRPE writes out logs, this means that sometimes when troubleshooting we can't see the logs where relevant information goes.

It would be handy to be able to configure NRPE to log all activity directly to a specified log file rather than to syslog (or, I guess conditionally switch where logging goes to).

Thanks

The help output from nrpe -h does not provide the correct usage for config files. The usage line states:

Usage: nrpe [-n] -c <config_file> [-4|-6]

Whereas the options section does not list -c <config_file>:

Options:
-n = Do not use SSL
<config_file> = Name of config file to use

Not a big deal, but would be nice to resolve.

Hello,

Commands like check_procs seems to fail when used through check_nrpe / nrpe when the output parsed by the command executed exceeds some length. That is - we're not talking about the output returned by check_nrpe, nor check_procs for that matter, but the output parsed by the command called by nrpe. (check_procs in this example).

See the following example:
We're first executing check_procs directly without the involvement of nrpe, which succeeds.
Then we're executing check_procs through nrpe, passing the exact same arguments, which fails when the output parsed by the command execeeds a certain length. This is the case even though the output parsed by check_procs isn't returned to nrpe. This "size theory" is based on the fact that check_procs works properly with check_nrpe when the output parsed by check_procs is smaller.

succeeds - check_procs executed directly without the involvement of nrpe

xxx-s971:/usr/local/nagios/libexec # ./check_procs -C java -a fmsmaster_FSC_BCA_TCUA_PMM_PROD_infodba.xml -vv
CMD: /bin/ps axwo 'stat uid pid ppid vsz rss pcpu cgroup:256 comm args'
Matched: uid=5000 vsz=705568 rss=208800 pid=6287 ppid=1 pcpu=0.00 stat=Sl etime= prog=java args=/usr/java/jdk1.7.0_75/jre/bin/java -d64 -server -Xms256M -Xmx256M -Dcom.sun.management.jmxremote -Dfms.config=./fmsmaster_FSC_BCA_TCUA_PMM_PROD_infodba.xml -Dfsc.config=./FSC_BCA_TCUA_PMM_PROD_infodba.xml -classpath jar/fmsservercache.jar:jar/fmsutil.jar:jar/fscjavaclientproxy.jar:third_party/commons-collections/3.0/commons-collections-3.0.jar:third_party/commons-logging/commons-logging-1.0.4/commons-logging.jar:third_party/commons-httpclient/commons-httpclient-3.1/commons-httpclient-3.1.jar:third_party/commons-codec/commons-codec-1.3/commons-codec.jar:third_party/javamail/1.3/mail.jar:third_party/mld/tc9.1.0.20120806/plmJMXmonitor.jar:third_party/mld/tc9.1.0.20120806/log4j-1.2.13.jar:third_party/mld/tc9.1.0.20120806/jmxtools.jar:third_party/mld/tc9.1.0.20120806/jmxri.jar:third_party/mld/tc9.1.0.20120806/logwriter.jar:third_party/OnionNetworks/webraid-2.6.8_01/lib/onion-common.jar:third_party/OnionNetworks/webraid-2.6.8_01/lib/onion-wantransport-tools.jar:third_party/OnionNetworks/webraid-2.6.8_01/lib/onion-webraid.jar:third_party/OnionNetworks/webraid-2.6.8_01/lib/onion-webraidutil-tools.jar:third_party/OnionNetworks/webraid-2.6.8_01/lib/onion-webraidutil.jar:third_party/OnionNetworks/webraid-2.6.8_01/lib/jdom.jar:third_party/jetty/9.2.0/jetty-server-9.2.0.v20140526.jar:third_party/jetty/9.2.0/jetty-util-9.2.0.v20140526.jar:third_party/jetty/9.2.0/jetty-http-9.2.0.v20140526.jar:third_party/jetty/9.2.0/jetty-io-9.2.0.v20140526.jar:third_party/jetty/9.2.0/servlet-api-3.1.jar:third_party/TcSS/2009.1_20120207/jars/teamcenter_sso_common.jar:third_party/TcSS/2009.1_20120207/jars/teamcenter_sso_proxy.jar:third_party/TcSS/2009.1_20120207/jars/teamcenter_sso_webtoolkit.jar:third_party/TcSS/2009.1_20120207/jars/teamcenter_sso_applib.jar -Djava.library.path=./lib -Dsun.net.client.defaultConnectTimeout=90000 -Dsun.net.client.defaultReadTimeout=90000 -Dcom.teamcenter.mld.logging.prefix=FSC_BCA_TCUA_PMM_PROD_infodba com.teamcenter.fms.servercache.FMSServerCache cgroup_hierarchy=(null)
PROCS OK: 1 process with command name 'java', args 'fmsmaster_FSC_BCA_TCUA_PMM_PROD_infodba.xml' | procs=1;;;0;

fails - check_procs executed with nrpe

xxx-s971:/usr/local/nagios/libexec # ./check_nrpe -H 127.0.0.1 -c check_procs -a "-C java -a fmsmaster_FSC_BCA_TCUA_PMM_PROD_infodba.xml -vv"
CMD: /bin/ps axwo 'stat uid pid ppid vsz rss pcpu cgroup:256 comm args'
PROCS OK: 0 processes with command name 'java', args 'fmsmaster_FSC_BCA_TCUA_PMM_PROD_infodba.xml' | procs=0;;;0;

We're only passing $ARG1$ to check_procs in nrpe.cfg.

Thanks!

reported by kaushalshriyan @ https://support.nagios.com/forum/viewtopic.php?f=7&t=39776

I am seeing this issue make: *** No rule to make target `install-daemon-config'. Stop. while i run rpmbuild -ba nrpe.spec while creating NRPE version 3 rpm binaries for CentOS 6.x.

rpmbuild -ba nrpe.spec -> https://paste.fedoraproject.org/406628/09947601/
cat nrpe.spec -> https://paste.fedoraproject.org/406629/94804147/
cat /etc/redhat-release
CentOS release 6.7 (Final)

With the following config:

Sep 11 16:30:41 web1 nrpe[28726]: SSL Certificate File: None
Sep 11 16:30:41 web1 nrpe[28726]: SSL Private Key File: None
Sep 11 16:30:41 web1 nrpe[28726]: SSL CA Certificate File: None
Sep 11 16:30:41 web1 nrpe[28726]: SSL Cipher List: ALL:!aNULL:!MD5
Sep 11 16:30:41 web1 nrpe[28726]: SSL Allow ADH: Allow
Sep 11 16:30:41 web1 nrpe[28726]: SSL Client Certs: Don't Ask
Sep 11 16:30:41 web1 nrpe[28726]: SSL Log Options: 0x2f
Sep 11 16:30:41 web1 nrpe[28726]: SSL Version: TLSv1_2 And Above
Sep 11 16:30:41 web1 nrpe[28726]: INFO: SSL/TLS initialized. All network traffic will be encrypted.

NRPE segfaults on requests:
Sep 11 16:30:41 web1 kernel: nrpe[28726]: segfault at 66d18a1d ip 00007f0f6616bdec sp 00007ffe6b93c290 error 4 in libc-2.12.so[7f0f66124000+18a000]

When using one of the 2 example cipher lists no crash happens, when changing it to any other cipher list, for example "ALL:!aNULL:!MD5" the segfault occurs.

System information:
OS: up2date CentOS release 6.8 (Final)
OpenSSL: OpenSSL 1.0.1e-fips 11 Feb 2013
NRPE: 3.0.1
NRPE run through xinetd

The function "printf" does not belong to the list of async-signal-safe functions.
I guess that a different design will be needed for your function "alarm_handler".

When I run check_nrpe against a host where it isn't allowed or doesn't hear back from it, there needs to be a new line added at the end.

Example 1:

[root@xitest libexec]# ./check_nrpe -H ub01
connect to address 10.25.13.5 port 5666: Connection refused
connect to host ub01 port 5666: Connection refused[root@xitest libexec]# 

Example 2:

[root@xitest libexec]# ./check_nrpe -H win2008r2-01
connect to address 10.25.14.2 port 5666: No route to host
connect to host win2008r2-01 port 5666: No route to host[root@xitest libexec]# 

Here is an example where the host is not allowed but adds the correct new line:

[root@xitest libexec]# ./check_nrpe -H W8DEV
CHECK_NRPE: Received 0 bytes from daemon.  Check the remote server logs for error messages.
[root@xitest libexec]# 

Since our primary development platform for NRPE is GitHub, I am going to move the issue over here regarding the 1024 byte payload limit.

The initial issue was opened on the tracker here: http://tracker.nagios.org/view.php?id=564
A forum thread regarding the issue can be found here: https://support.nagios.com/forum/viewtopic.php?f=34&t=35082&p=156472&hilit=nrpe#p156472
Another highly referenced forum thread: https://support.nagios.com/forum/viewtopic.php?f=34&t=25221
A potential patch was provided here:https://web.archive.org/web/20120309192252/http://labs.opsview.com/2008/08/enhancing-nrpe-for-large-output
Another post outlining the issue: http://serverfault.com/questions/613288/truncating-return-data-as-it-is-bigger-then-nrpe-allows

There is also a branch of NRPE by abrist that patches this as well.

Hi

The evaluation of "if(debug==true)" in acl.c is always incorrect as acl.c does not have access to "int debug".
There needs to be a variable declaration in acl.c like so:

extern int debug;

This will yield correct output for statements like

if(debug==TRUE) syslog(LOG_INFO,"debug now has a correct value of >%d<\n",debug);

Hi,

I think there's an off-by-one error in this call to strncat():

https://github.com/NagiosEnterprises/nrpe/blob/master/src/nrpe.c#L2114

for (;;) {
    bytes_read = read(fd[0], buffer, sizeof(buffer) - 1);
    ...
    if (tot_bytes < output_size)           /* If buffer is full, discard the rest */
        strncat(*output, buffer, output_size - tot_bytes);
    tot_bytes += bytes_read;

In the case where bytes_read is greater than output_size - tot_bytes then strncat() will append output_size - tot_bytes + 1 bytes to output (+1 for the trailing zero byte).

Linux man page strcat(3):

   If src contains n or more characters, strncat() writes n+1 characters
   to  dest (n from src plus the terminating null byte).  Therefore, the
   size of dest must be at least strlen(dest)+n+1.

Correct similar example from elsewhere in the same file https://github.com/NagiosEnterprises/nrpe/blob/master/src/nrpe.c#L175:

strncat(config_file, buffer, sizeof(config_file) - strlen(config_file) - 1);

(All other calls in the project also take this format).

This zeroes one single heap byte so unlikely to be exploitable.

While testing the new 3.0 release, I noticed the following oddity:

$ /usr/lib64/nagios/plugins/check_nrpe -H localhost
NRPE vnrpe-3.0

This is compared to the result for version 2.15:

$ /usr/lib64/nagios/plugins/check_nrpe -H localhost
NRPE v2.15

I assume the name shouldn't be part of the version string?

Comparing the sources:

nrpe-2.15/configure:PKG_VERSION="2.15"
nrpe-2.15/include/common.h:#define PROGRAM_VERSION "2.15"

nrpe-3.0/configure.ac:AC_INIT([nrpe],[nrpe-3.0],[[email protected]],[nrpe],[https://www.nagios.org/downloads/nagios-core-addons/])
nrpe-3.0/configure.ac:PKG_VERSION="nrpe-3.0"
nrpe-3.0/include/common.h.in:#define PROGRAM_VERSION "nrpe-3.0"

https://github.com/NagiosEnterprises/nrpe/tags

2.15 tag is missing

Import from the forums: http://support.nagios.com/forum/viewtopic.php?t=28250#105778

As you can read at this two URLS:

http://tracker.nagios.org/view.php?id=305
and
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=744936

nrpe is sending two RST flags and for us that means that every query via nrpe causes an error in our firewall installed on the nagios server.
Would it be possible to fix this in a future version? So that it may will be fixed in a future debian version?

Hello,

Can you please specified which is the main license for nrpe?
On the following site https://exchange.nagios.org/directory/Addons/Monitoring-Agents/NRPE--2D-Nagios-Remote-Plugin-Executor/details it's stated that the main license ins GPL. But the version isn't specified (1.0, 2.0 or 3.0).
Also in the package I didn't find the COPYING with the GPL full listed which is a required by the GPL-1.0, 2.0 or 3.0.

Alex

It seems to me that nrpe_user directive in nrpe.cfg doesn't work as supposed for nrpe-3.0-beta1. I have a 64bit Gentoo Linux distribution. When I build nrpe from latest sources and configure

nrpe_user=nagios
command[check_id]=/usr/bin/id

and start nrpe via default init script it seems that the nrpe daemon is running with nagios user privileges - at least according to list of system processes:

$ ps -ef | grep nrpe
nagios   14141     1  0 06:44 ?        00:00:00 /usr/bin/nrpe -c /etc/nrpe.cfg -d

But when I call the prepared check_id command (check_nrpe -H localhost -c check_id) I get root UID and nagios GID:

uid=0(root) gid=1002(nagios) groups=1002(nagios)

I would expect that I will get nagios UID. Am I doing something wrong or is there really some bug in nrpe?

From the server that is executing check_nrpe plugin, the command line arguments are getting quite long, for example:

./check_nrpe -H 192.168.10.219 -C /usr/local/nagios/etc/ssl/client_certs/nag_serv.pem -K /usr/local/nagios/etc/ssl/client_certs/nag_serv.key -A /usr/local/nagios/etc/ssl/ca/ca_cert.pem -c check_mem

It might be handy if we allow the check_nrpe plugin to use a config file for any settings. It might look at a default file name/location, but also the option to define what config file could be used as this might help in multi tenant scenarios.

We need to dig through the old commits/change logs and create the attribution files.

Reported here:

http://tracker.nagios.org/view.php?id=231

Description:

To receive a list of processes the check_procs plug-in uses:

/bin/ps axwo 'stat uid pid ppid vsz rss pcpu etime comm args'

ps limits its output in regard to the current value of the environment variable COLUMNS. If COLUMNS is set to a small value and the command line arguments of the process is very long (e.g. >1000 characters for a java command with many properties), a required command line argument (-a option) might not be found.

Additional Information:

Debugging becomes tricky as the value of COLUMNS depends on the current environment, when NRPE/check_procs is started. If the NRPE Daemon is started by init, the COLUMNS value might be a lot smaller (96 in my case) than if NRPE Daemon is restarted manually using /etc/init.d/nrpe restart. Actually it depends on the current xterm/putty windows size if the check turns green after a manual restart or not.

Hi,

there's a typo in startup/default-xinetd.in.

--- nrpe-3.0/startup/default-xinetd.in.typo
+++ nrpe-3.0/startup/default-xinetd.in
@@ -4,7 +4,7 @@ service nrpe
 {
     disable         = yes
     socket_type     = stream
-    port            = @npre_port@
+    port            = @nrpe_port@
     wait            = no
     user            = @nrpe_user@
     group           = @nrpe_group@

Kind regards

Philippe

Hi,

it would be nice to set a openssl engine in nrpe.cfg (e.g. ssl_engine=pkcs11)

Using one is rather easy (some error checking would be nice though):

https://github.com/apache/httpd/blob/fbc5e20ead005fd3a2bec05924f9e90dfd195406/modules/ssl/ssl_engine_init.c#L403

#include <openssl/engine.h>
struct _SSL_PARMS {
    ....
    char *ssl_engine;
};

ENGINE *e;
e = ENGINE_by_id(ssl_engine);
ENGINE_set_default(e, ENGINE_METHOD_ALL);
ENGINE_free(e);

ICSs BIND has some configure checks, too, see https://source.isc.org/cgi-bin/gitweb.cgi?p=bind9.git;a=blob;f=configure.in;hb=af05768c0e9b25a562c4f667ec051cea6e298785#l1979

check_nrpe constantly logging NOTICE to syslog on successful connect. I have had to roll back to 2.15 to reduce the logging on my nagios host as I cannot discard INFO syslog on that host for other application requirements.

Would it be possible to change the success logging to ONLY happen when cascading down from a failed? or if Debug option is active?

starting Line 171, or just before final result return in Main()
if (result != -1)
syslog(LOG_NOTICE, "Remote %s accepted a Version %d Packet", rem_host, packet_ver);

return result;

Subject line explains it all: config.h not included into acl.c
NONE of the information that is found in "./include/config.h" is available in "./src/acl.c"

So please, either add the following line in file ./include/acl.h

include "config.h"

OR add the following line to ./src/acl.c:

include "../include/config.h"

This has been a horrible debugging session, see https://support.nagios.com/forum/viewtopic.php?f=7&t=39960

Hi,

I am using check_nrpe command from version nrpe-2.15 together
with Ubuntu Linux 14 together with NSclient++ (version NSCP-0.4.3.143-x64.msi)

Because the in openssl on ubuntu the length of DH Parameters must be > 768 Bits
(See https://wiki.ubuntu.com/SecurityTeam/Kn ... ase/LogJam for example)
this configuration stopped working, because nrpe-2.15 and NSCP-0.4.3.143-x64.msi use DH parameters
of lenght 512 Bits.

To fix my problems

1. I changed on NSclient++ the File security\nrpe_dh_512.pem to a 1024 Bit Version using "openssl dhparam -C 1024"
2. I changed in sourcetree of nrpe-2.15 File check_nrpe.c to make use of the cipher the command "openssl s_client" did in testconnection handshake.

//SSL_CTX_set_cipher_list(ctx,"ADH");
SSL_CTX_set_cipher_list(ctx,"DHE-RSA-AES256-GCM-SHA384");

and got a working setup:

unilab@sattelit01:~/nrpe_plugin/nrpe-2.15/src$ ./check_nrpe -H 10.100.1.21
I (0.4.3.143 2015-04-29) seem to be doing fine...

Question: I think there is a general need to reflect the "disable insecure ciphers in SSL libraries"
to the nrpe-client and server by using "secure" ciphers or making the choosing of used ciphers
more configureable.

Can this be done in upstream?

Best Regards,
Achim

I see with nrpe installed from epel rpm's that startup is very different because of systemd changes.

For all our el4/5/6 systems nrpe.cfg is obeyed for nrpe_user and nrpe_group, but because of the startup on el7 its based on /usr/lib/systemd/system/nrpe.service. So we tweak this file (change nrpe to something else). Then reload systemctl, and then restart nrpe. Thats all good, but maybe some documentation updates are needed or the changes need to be communicated? I did not find anything in the rpm about these changes.

# cat /usr/lib/systemd/system/nrpe.service
[Unit]
Description=NRPE
After=network.target
Requires=network.target

[Service]
Type=forking
User=nrpe
Group=nrpe
EnvironmentFile=/etc/sysconfig/nrpe
ExecStart=/usr/sbin/nrpe -c /etc/nagios/nrpe.cfg -d $NRPE_SSL_OPT

[Install]
WantedBy=multi-user.target

# systemctl daemon-reload
# systemctl restart nrpe

Most commonly on Ubuntu where /bin/sh links to dash, users are experiencing errors with the check_cpu_stats.sh script out-of-the-box. It is suggested that the shebang be changed to #!/bin/bash

Hi,

./configure is not able to correctly detect Solaris 11:

if test "$dist_type" = solaris -a "$dist_ver" != smf11; then
    $as_echo "#define SOLARIS_10 yes" >>confdefs.h

fi

$dist_ver is defined is as:

  solaris) :
    dist_ver=`echo $OSTYPE | cut -d'.' -f2` ;; #(

OSTYPE seems to be only defined when using bash

[email protected]:~ $ echo $OSTYPE
solaris2.11

but not when using /bin/sh (the default shell for configure):

[email protected]:~ $ echo $OSTYPE

So checking for 'smf11' is wrong, and $OSTYPE is undefined when not using bash...

Hi,

a future version of Solaris (Solaris 12) will include a b64_decode function in string.h/libc, which will conflict with nrpe's own b64_decode() in include/utils.h and src/utils.c.

Standard C Library Functions                                    b64_encode(3C)

NAME
       b64_encode,  b64_decode,  b32_encode,  b32_decode - encode and decode a
       string in base64 or base32

SYNOPSIS
       #include <string.h>

       ssize_t b64_encode(char restrict *outbuf, size_t outbufsz,
                const void restrict *inbuf, size_t inbufsz,
                const char *alphabet, uint64_t flags);

       ssize_t b64_decode(void *outbuf, size_t outbufsz,
                const char *inbuf, const char *alphabet, uint64_t flags);

       ssize_t b32_encode(char restrict *outbuf, size_t outbufsz,
                const void restrict *inbuf, size_t inbufsz,
                const char *alphabet, uint64_t flags);

       ssize_t b32_decode(void *outbuf, size_t outbufsz,
                const char *inbuf, const char *alphabet, uint64_t flags);

       const char *BASE64_URL_ALPHABET;
       const char *BASE32_HEX_ALPHABET;

Renaming nrpe's b64_decode to nrpe_b64_decode (or smth else) should make this code compile again.

PS: is b64_decode() dead code? it's not used anywhere in nrpe/check_nrpe...

Hi,

Right now, nasty_metachars is configured in 'nrpe.c'. Could you add an option in 'nrpe.cfg' to override the harded configuration ?

Thanks for the work.

I think the application should display an error message to stderr/stdout and exit.
OS: RHEL5
Let me know if you need additional information.

I updated the check_nrpe to version 3.0 on my monitoring server and tried to reach out to the clients that still run nrpe 2.15.

Even if I adapt the monitoring config to use the "-2" option, the old nrpe daemons can not be reached to the new check_nrpe.

Example command definition in Nagios:

define command{
command_name nrpe-check_ntp_with_port
command_line $USER1$/check_nrpe $ARG1$ -2 -t 120 -c check_ntp
}

Output from the check in the WebUI:
CHECK_NRPE: Receive header underflow - only 0 bytes received (4 expected).

This seems like a somewhat obscure problem that might be related to running against NSClient++, but the behavior seems entirely enclosed within check_nrpe. Here is my environment:

OS: CentOS 7
Nagios Version: 5.3.0
check_nrpe plugin version: 3.0.1
OpenSSL version: 1.0.1e

I am using a config file with the following options as part of my test:

-A {path to ca_cert.pem} -C {path to client_cert.pem} -K {path to client_cert.key}

When I use this file with the -f option, check_nrpe appears to ignore the -a option, if also provided. For example, executing this command...

./check_nrpe -H {remote_nscp_host} -f {path to config-file} -c check_cpu -a "warn=load > 85" "crit=load > 95"

returns the following response:

OK: CPU load is ok.|'total 5m'=0%;80;90 'total 1m'=0%;80;90 'total 5s'=0%;80;90
(note that the warn and critical thresholds are 80% and 90% respectively, not 85% and 95% as specified by the arguments)

However, when I don't use the config file, and instead specify my certificate paths in the command itself, the behavior is different.

Command:

./check_nrpe -H {remote_nscp_host} -A {path to ca_cert.pem} -C {path to client_cert.pem} -K {path to client_cert.key} -c check_cpu -a "warn=load > 85" "crit=load > 95"

Response:

OK: CPU load is ok.|'total 5m'=0%;85;95 'total 1m'=0%;85;95 'total 5s'=0%;85;95
(observe that the warn and crit thresholds are 85% and 95% respectively, as specified by the arguments)

The takeaway is that, regardless of what's going on with NSClient++ on the remote host, it appears very likely that the check_nrpe plugin on the nagios server is treating the -a option differently if the -f option is provided.

Hi,

when running nrpe in debug mode, the command name is not shown:

nrpe[27752]: Host x.x.x.x is asking for command '' to be run...

This should fix it:

--- nrpe-3.0/src/nrpe.c.debug
+++ nrpe-3.0/src/nrpe.c
@@ -1546,7 +1546,7 @@ void handle_connection(int sock)
        /* log info to syslog facility */
        if (debug == TRUE)
                syslog(LOG_DEBUG, "Host %s is asking for command '%s' to be run...",
-                          remote_host, receive_packet.buffer);
+                          remote_host, command_name);

        /* if this is the version check command, just spew it out */
        if (!strcmp(command_name, NRPE_HELLO_COMMAND)) {

Kind regards

Philippe