Page 1 of 1
NRDS SSL from linux client?
Posted: Tue Sep 10, 2013 11:50 am
by dave2492
I've been looking into passive checks and the various mechanisms available...
NRDS looks great and the auto updating of the client config files is a great feature!
However, it looks to me that SSL is not supported as yet on the linux client. Is this true? Is there a planned release of this feature?
I really have to encrypt the traffic from my monitored servers to the nagios xi server. So will probably go with NRDP if I can't encrypt with NRDS.
Thanks!
Dave.
Re: NRDS SSL from linux client?
Posted: Tue Sep 10, 2013 12:09 pm
by lmiltchev
So will probably go with NRDP if I can't encrypt with NRDS.
Actually NRDS uses NRDP... Yes, you can use SSL with NRDS.
Modify the "/usr/local/nrdp/server/config.inc.php" file by changing this line:
to this:
When you create your config (Admin->NRDS Config Manager->Create Config), enter "https" in the "URL" text field instead of "http".
Hope this helps.
Re: NRDS SSL from linux client?
Posted: Thu Oct 10, 2013 3:53 pm
by dave2492
Thanks, this was a big help!
When using nrds, I noticed that:
- I needed the latest version of nrds to use ssl, as there were changes to the scripts to not require valid certificates when calling curl or wget.
- I still needed to tweek the install instructions that you paste into the monitored server. I had to add --no-check-certificate to the wget call.
And then a couple of things unrelated to using SSL:
- I needed to enable host freshness checking, so I could get notified if a host became unreachable. There is documentation explaining this,
so it wasn't a big surprise. I modified the xiwizard_passive_host template as follows:
Code: Select all
check_freshness = 1
freshness_threshold = 700
check_command check_dummy!2!"Host is not reporting status."
- The nrds/nrdp mechanism caused my RHEL 6 monitored server to consume lots of 'free' memory. This had not occurred with nrpe. Turns out it was the dentry cache filling up which caused the check_custom_mem service to get upset. Ubuntu targets didn't have this problem at all. Centos had some slab growth, but reclamation occured at lower levels, so check_custom_mem was still happy.
RHEL seems particularly reluctant to reclaim slabs until memory gets quite full. Not really a problem, though, since it eventually reclaims them without incident. I ended up rewriting that service to just parse /proc/meminfo and add back the cache, buffer, and reclaimable slabs - so 'free' memory is now accurate.
Re: NRDS SSL from linux client?
Posted: Thu Oct 10, 2013 4:13 pm
by slansing
Excellent information, thanks for sharing what you did to resolve your local issues. That may be of great use if someone runs into the same issue in the future.. Do you have any more questions on this or shall we lock it up?
Re: NRDS SSL from linux client?
Posted: Thu Oct 10, 2013 4:46 pm
by dave2492
No more questions, but I did forget to include one other piece...
I have a couple of services that have many lines of output. I eventually had this working under nrpe, but it did not work initially with nrds/nrdp. Turned out I had to modify the output text to follow two rules:
- All the output has to be in one line (no embedded newlines).
There can be no tab (\t) characters in the output.
Tabs can be eliminated by piping the output thru expand. Newlines must be replaced by literal \n sequences. In bash you can do:
Code: Select all
# replace newlines with literal '\n's
mystatus="${mystatus//$'\n'/$'\\n'}"
After these changes, the output appears in Nagios XI. Nagios XI still does chop off the output after 60 lines or so, but that is the same behavior I saw with nrpe when I used check_by_ssh to get the long output back to nagios. I used check_by_ssh since vanilla nrpe chopped the output even sooner.
Now am quite satisfied using nrds/nrdp, as I can now monitor my firewall'd servers without having to use a VPN.
Re: NRDS SSL from linux client?
Posted: Fri Oct 11, 2013 10:56 am
by sreinhardt
Glad to hear its all working, and thanks for the notes, hopefully they will assist someone else in the future too!