Using Icinga 2 with NSClient++ 0.3.9


#1

Hello together,

I’m using Icinga 2 and NSClient++ 0.5 to monitore some windows machines.
Now, I want to monitore a system where NSClient++ 0.3.9 is installed, but it can’t get updated because it is used by someone else for their monitoring.

For me, it wasn’t possible to execute any check on the 0.3.9-client. It always says:
CHECK_NRPE: Received 0 bytes from daemon. Check the remote server logs for error messages.

My question: is it generally possible to monitore an NSClient++ 0.3.9 with Icinga2? How did the syntax change between these versions?

Here is a part of NSC.ini from the system with 0.3.9 we want to integrate in our Icinga 2:

[Settings]
obfuscated_password=
password=
allowed_hosts=
use_file=1

[NRPE]
port=5666
allowed_hosts=
use_ssl=1
command_timeout=60
allow_arguments=1
allow_nasty_meta_chars=1
socket_timeout=30
performance_data=1
;socket_back_log
;string_length=1024
;script_dir=scripts
;bind_to_address=

These are the settings we’re using normally to connect with our Icinga 2 using 0.5:

[/settings/default]
allowed hosts =
encoding = UTF8
password = $GEN$

[/settings/NRPE/server]
allow arguments = true
allow nasty characters = 1
extended response = 1
insecure = 1
payload length = 8192
ssl options = no-sslv2,no-sslv3
string_length = 8192
use ssl = 1
verify mode = none

Thank you for your help!
Greetings from Germany
Huberson


(Michael Friedrich) #2

0.3.x compared to 0.4.x had lots of breaking changes. To my knowledge it is not supported anymore, and does not receive security fixes either. I’d highly recommend to upgrade those clients.

allowed_hosts is empty, which looks strange. I’d use strace on the check_nrpe call to trace what the command is doing internally (as it does not have any debug logging).


#3

I would like to upgrade the client, but unfortunately I can’t decide it.

The allowed_hosts is empty because i removed the IP’s before I uploaded this post. Should have told you that.

I haven’t worked with strace yet, I will try it and post my results here.

Thank you for your reply.


#4

I tried the following commands:

strace -e trace=open -o /usr/lib64/nagios/plugins/logfile.log ./check_nrpe8192 -H 10.5.158.35
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libssl.so.10", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libcrypto.so.10", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libnsl.so.1", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libgssapi_krb5.so.2", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libkrb5.so.3", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libcom_err.so.2", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libk5crypto.so.3", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libdl.so.2", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libz.so.1", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libkrb5support.so.0", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libkeyutils.so.1", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libresolv.so.2", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libpthread.so.0", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libselinux.so.1", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libpcre.so.1", O_RDONLY|O_CLOEXEC) = 3
open("/proc/filesystems", O_RDONLY) = 3
open("/etc/pki/tls/legacy-settings", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/dev/urandom", O_RDONLY|O_NOCTTY|O_NONBLOCK) = 3
open("/dev/urandom", O_RDONLY) = 4
+++ exited with 3 +++

strace -e trace=process -o /usr/lib64/nagios/plugins/logfile.log ./check_nrpe8192 -H 10.5.158.35
execve("./check_nrpe8192", ["./check_nrpe8192", “-H”, “10.5.158.35”], [/* 27 vars */]) = 0
arch_prctl(ARCH_SET_FS, 0x7fbc98b9c840) = 0
exit_group(3) = ?
+++ exited with 3 +++


(Michael Friedrich) #5

Just a guess to see if it maybe outputs something useful. NRPE itself is a pain to debug. IIRC such “0 byte” errors usually originate from a) wrong allowed_hosts b) SSL handshake not complete (or disabled at one end) c) the check plugin on the NRPE server throws some errors.

It is hard to tackle, NSClient++ logs and lots of trial and error are involved here. Nothing I would recommend these days, but if you are forced, those things above should help.


#6

I think the biggest problem is the syntax in NSClient.ini which has changed between the versions. Is there a documentation or anything which changes are done between 0.3.9 and 0.5 or something like that?

I do have a working solution with working settings for other clients. The question is, how do i put them into the old NSC.ini from 0.3.9

For example, do you know which “allowed hosts” is used, in 0.3.9 i see one in [Settings] and one in [NRPE]?


#7

You might want to take a look at the “Reference Manual” of 0.3.9
NSClient_Ref_Man.zip (623.0 KB)


#8

Thanks, that could really help! Is there a similar document for version 0.5?


(Michael Friedrich) #9

http://docs.nsclient.org/ isn’t sufficient?


#10

I liked this one because it has the deifferent options for nsc.ini in one table


#11

I changed NSC.ini, now looks like this:

[Settings]
obfuscated_password=
password=
allowed_hosts=127.0.0.1,10.151.66.227/24
use_file=1

[NRPE]
port=5666
allowed_hosts=127.0.0.1,10.151.66.227/24
use_ssl=1
command_timeout=60
allow_arguments=1
allow_nasty_meta_chars=1
socket_timeout=30
performance_data=1
;socket_back_log
string_length=8192
;script_dir=scripts
;bind_to_address=

The error message on the web interface now looks like this:
CHECK_NRPE: Error receiving data from daemon.

Any ideas?


#12

As @dnsmichi already mentioned (stated here as well):

CHECK_NRPE: Received 0 bytes from daemon. Check the remote server logs for an error message."

First thing you should do is check the remote server logs for an error message. Seriously. :slight_smile: This error could be due to the following problem:

◦The check_nrpe plugin was unable to complete an SSL handshake with the NRPE daemon. An error message in the logs should indicate whether or not this was the case. Check the versions of OpenSSL that are installed on the monitoring host and remote host. If you’re running a commercial version of SSL on the remote host, there might be some compatibility problems.


#13

Yes i know, but i thougth there could be a difference between “CHECK_NRPE: Received 0 bytes from daemon. Check the remote server logs for an error message.” and “CHECK_NRPE: Error receiving data from daemon.”


#14

I recognized, that the check_nrpe-request had -n for disabled SSL. I removed it, so the error is the following:
CHECK_NRPE: Socket timeout after 10 seconds.

On google, the only advice i could find on this is that Firewall/ Ports aren’t opened or something.
On Icinga-Server-side i think it can’t be the problem because the server is working fine with other client.
On client-side, windows firewall isn’t active and port 5666 seems to be opened, i tried netstat -an:
TCP 0.0.0.0:5666 0.0.0.0:0 ABHÖREN

I remember having similar issues when i was configuring the other hosts ca 1 year ago. If i remember correctly, we fixed it with nsclient.ini options like verify mode or ssl-options, but they arent available in 0.3.9 …


#15

NSClient.log says the following:
2018-03-08 10:15:09: message:modules\NRPEListener\NRPEListener.cpp:363: Could not read NRPE packet from socket :Unhandeled socket exception


#16

I solved my problem. icinga-server and nsclient used a different string length.


#17

Please elaborate on that.

Edit: The other thread gives the explanation.


(Josue Quiros) #18

From Monitoring Server to ckeck NSClient++:

/usr/lib64/nagios/plugins/check_nt -H [IPSERVER] -s [PASSWORD] -v CLIENTVERSION
NSClient++ 0.5.0.62 2016-09-14

Configuration file on windows remote server:

Apply this changes C:\Program Files\NSClient++\nsclient.ini

; ALL
[/settings/default]

; Undocumented key
password = XXXXXXXXXXXX

; Undocumented key
allowed hosts = {IP MONITOR SERVER}

; ALL
[/settings/NRPE/server]
allow arguments=true
port = 5666
use SSL = true
ssl options = no-sslv2,no-sslv3
insecure = true

[/settings/external scripts]
allow arguments=true

[/settings/external scripts/scripts]
test=scripts\test.bat <---- to exec a .bat
test_ps1=cmd /c echo scripts\check_groupstest2.ps1; exit($lastexitcode) | powershell.exe -command - <---- to exec a power Shell
test_ps2=cmd /c echo scripts\check_groupstest2.ps1 “–argument” “$ARG1$” --foo --bar; exit($lastexitcode) | powershell.exe -command - <---- to exec a powerShell with param


#19

@Rquiros23
How is your answer related to the OP?