Nagios, NRPE, and mixed SSL environments

Over on the LinkedIn Nagios Users group, Michael Sverdlik asked an interesting question about how to handle a mixed NRPE environment, where some hosts require SSL and others do not. The first recommendation is a custom script that basically executes the command twice, the first one looks for an error, then falls back to using non-ssl mode… I came up with a different way of handling it, without falling back to using custom scripts.

This method takes advantage of custom host variables, and templates. There are two ways you can go about this, the first is to edit the base template you are using, and create a secondary template to override, the second method is to create two templates that can be used on either type of host, but is more intrusive as it requires you to modify all your hosts to add either of the templates rather than just modifying the hosts that require the non-ssl option. The first method is least intrusive, so we’ll be using that…

The first thing is pick a variable name, I’m going to use NRPESSL as it’s fairly self explanatory. We then modify the base template, mine is called generic_host. I’m going to leave all the other variables out, and just show my addition:

define host {
    register    0
    name        generic_host
    _NRPESSL
}

define host {
    register    0
    name        nrpe_nossl
    _NRPESSL    -n
}

In the first template, I’ve added the variable, but left the value empty. This is very important, and I’ll show you why later. The second is an almost entirely empty template, with the name defined, and the value for the macro set to -n.

Now for modifying the command…

define command {
    command_name     check_by_nrpe
    command_line     $USER1$/check_nrpe -H $HOSTADDRESS $_HOSTNRPESSL$ -c $ARG1$ -a $ARG2$
}

From this, you can see I’ve used a custom macro $_HOSTNRPESSL$. This macro is an expansion from the custom object variable, and includes the content of the macro on the host. So, for the generic hosts, it is an empty macro, for non-ssl hosts, it now includes -n (this is the option used to disable SSL on the check plugin). I mentioned at the start that it was important to define the macro, even with an empty value. This is because Nagios cannot do a replacement in the value if it cannot find the macro in the output, this results in a single $ appearing instead of a blank spot. This would alter your check command to look like this for SSL hosts:

./check_nrpe -H 192.168.1.1 $ -c check_disk -a -w 80 -c 90

This will obviously cause an error, so the empty macro must be defined.

Next, we play with object inheritance. This is a very powerful feature in Nagios 3, and makes templates all the more useful. Below we have two hosts, one is a generic host, where NRPE supports SSL, and one is a host that does not support SSL.

define host {
    use         generic_host
    host_name   test1
    address     192.168.1.1
    hostgroups  linux,web
}

define host {
    use         nrpe_nossl,generic_host
    host_name   test2
    address     192.168.1.2
    hostgroups  linux,web
}

Because of how inheritance works in Nagios, the use statement on the second host makes the contents of the nrpe_nossl override whatever values are in generic_host. The only value the same is the custom variable we created for the SSL options. The service definitions is then identical for both hosts, and no custom commands are needed to handle the different SSL states.

I hope others find this little trick helpful, it can probably be used in all kinds of other places too, but this was a perfect example of toggling a command option based on a host variable.

Do you have any questions or comments? Throw them in the comment section, I’d love to hear from you!