Nagios Support Forum

I just started a trial of Nagios XI, to re-familiarize myself with it since we're purchasing an NMS platform next month (likely Nagios XI) and I'm having some issues with the first host I added.

I started out by adding our biggest switch stack using an SNMP v3 user/password I created for Nagios monitoring. I went through the switch/router wizard fine and added roughly 250 services between the various port status checks and port bandwidth monitoring, after I added everything only the bandwidth monitoring and ping services were succeeding, every port status service displayed an error stating the command exit code was 127. After troubleshooting the status 127 error I wound up trying to run the check myself from an SSH session I got the command info from the CCM>Services, and when I tried to run it snmpwalk returned "Error: passphrase chosen is below the length requirements of the USM (min=8)..." I though that was weird since mine is 10 characters until I realized it contains * and & and wasn't surrounded with quotes so I re-tried the command surrounding the password with quotes and it ran fine.

The check_rrdtraf plugin works fine with my password but check_ifoperstatnag fails because the password doesn't get surrounded by quotes.

To save me the hassle of re-adding this host (it was at least 40 minutes worth of sorting through interfaces) is there a way to either:
a) Change the template for that service command and add the quotes in myself?
b) Mass-change the password for those services?

Thanks in advance!

motoxrdr21 wrote: a) Change the template for that service command and add the quotes in myself?

This would be the easier route. Under Configure -> Core Config Manager, you will want to go to the Commands section, search for the relevant command, and click the command name to edit. Then wrap the quotes around the appropriate $ARGX$ value and hit Save, then Apply Configuration. Bear in mind, if your password itself has a similar quotation mark this might cause issues later on. Also of note is that if you don't have a separate $ARGX$ for the password (for instance, if the whole thing is $ARG1$) this will not work since the whole thing will be quoted.

tmcdonald wrote: Also of note is that if you don't have a separate $ARGX$ for the password (for instance, if the whole thing is $ARG1$) this will not work since the whole thing will be quoted.

Unfortunately that's the case, all of the authentication options(user/pass/encryption) for the check_xi_service_ifoperstatusnag command are contained in one $ARG$ variable.

What you could do is compare the command with an already defined service's $ARG1$ slot and see where the password is entered, then split the command up to take multiple arguments, unfortunately, you will likely want to copy the command out and change it's name as mucking about with pre-defined commands that XI uses in wizards can cause havoc down the road when trying to run that wizard again, since it expects what we have for the command defaults.

Anyways, once you have split the new command into multiple arguments, (making sure at least one is for your password) you can simply go to your service(s) and swap the new command in, then define your arguments. Should be as simple as that, then apply configuration of course.

With that much manual work involved to fix the issue of a special character in the password, I wound up just deleting the services and host, changing the SNMP password so there were no special characters, and re-creating everything.

However this seems to be a common trend, I just ran into the same issue again with the check_xi_service_nsclient command, since the service for a MS SQL named-instance is named "MSSQL$[instance name]" they all have a $ in them so when I just went through and added all of my Windows Servers and associated services I had a handful of service checks fail due to the $ character. Thankfully I only have three or four SQL Instances that are named so I just manually edited the ARG that the monitoring wizard generated to include quotes around the service name, but maybe you guys should issue something to your plugin/monitoring wizard developers reminding them to double quote any strings derived from user input to prevent this kind of issue.

Depending on the plugin, dollar signs can be escaped with: $$, \$, or \\$$.
EDIT: or, put the string in quotes as you did. (only works for checks that allow quotes - i.e. you cannot do so with embedded nrpe args)

So now it gets a little more interesting...after I surrounded the service name with quotes yesterday all of the services worked and displayed the correct status. This morning I came in and noticed that all of the SQL Named Instance service monitors are again displaying critical with the error "MSSQL: Not found", so I went back in to CCM and did a Test Check of one of them and it succeeded returning an OK status. I noticed in the output of the test check that "\$" was being inserted in place of $ (it is NOT entered into the ARG box this way) so I figured maybe quoting and adding the \ was breaking it, and I removed the quotes from the ARG value, again it successfully ran with a CCM test check but after applying the configuration and forcing an immediate check of the service the service still displayed critical with "MSSQL: Not found"

So when I do a test check in CCM the correct status is returned (seen below) but in Service Details the status is Critical with an error message listed.

COMMAND: /usr/local/nagios/libexec/check_nt -H 0.0.0.0 -s "********" -p 12489 -v SERVICESTATE -l MSSQL\$SOFTWAREHOUSE -d SHOWALL
OUTPUT: MSSQL$SOFTWAREHOUSE: Started

It is worth noting that, due to being a PHP page, there is some escaping done on certain characters when you use the Test Check Command button, particularly the dollar sign. Many checks will work just fine, but not all. The best test is to save the config, apply, and force an immediate check in the service details page. If it is working there you can be pretty confident it will work as intended.

I think you have it backwards, the Test Check is working fine, it's the service page that shows the incorrect status. Test Check returns that the Windows Service is running, the Service detail page displays an error that the Windows Service name cannot be found.

motoxrdr21 wrote:the Test Check is working fine, it's the service page that shows the incorrect status

Ah, if that is the case, copy the escaping done by the "test check command" and duplicate the escaping the check command args. Test check will no longer work (as it will be double escaped), but the scheduled check itself should work.