1

Behold the Awesome Power of Template Inheritance!

Several members of the OP5 team contribute to our blog with short articles providing information about how to maximize the capabilities of OP5 Monitor. In this blog post, Dante Blando, Technical Support Americas at OP5, contributes a short article about “The Awesome Power of Template Inheritance”.

I’ve now been at OP5 for a year and a half. It has been a while since I wrote a blog post for you good folks. My original premise was to use my new employee mindset to bring you along on my journey. I still want to bring you along, but I also now have the cruft from digging into all sorts of problems. I have ditched my fear of losing that sight, because I have also had to learn lots of things even in this week.

Today I am going to talk about something very simple in OP5, but something that can build layers of intrigue and intense configuration. Chess has nothing compared to the small set of rules around templates and their inheritance.

Templates aren’t even separate files in OP5. They come from our history in Nagios, where a set of directives (a directive definition) could be marked with “register 0” as a directive and therefore not be registered as an object (host, service, contact, time period, etc.). Then any other object that can use those directives (the variables specific to an object type) can simply call “use template-name” to get directive values not otherwise defined.

This is easier to understand in an example. I have created a host template names Alberta. It only sets a value for one directive, as templates do not have to have values for everything mandated in a registered object. Then I have a host named ‘flipsydoo’ which uses the new Alberta template. If I look at ‘/opt/monitor/etc/hosts.cfg’ on my OP5 Monitor server, I see these entries:

define host {

name                                          Alberta
retry_interval                           4
register                                       0
}

define host {

host_name                                 flipsydoo
use                                               Alberta
address                                       192.168.1.201
}

There is only one problem with the above: if I ran a Naemon verification on the above (which happens every time anyone restarts the Monitor service), I would get an error about the host. Why? Because I have only defined three things about the host and skipped a bunch of other required directives. We can solve this using the power of inheritance.

We could get around my host error by calling another template that does have values for the required directives. We do exactly this by defining a default host template:

define host{

check_command                     check-host-alive
max_check_attempts             3
check_interval                          5
retry_interval                           0
check_period                            24×7

register                                       0
name                                          default-host-template
}

In Nagios, we would simply list the templates in the order that we want them loaded and separate them with commas. For example:

use                                             default-host-template,Alberta

The default host template would provide a set of values, then Alberta would override only the items it handles since it gets called next, then the host definition would override with anything it has. If we go back to ‘flipsydoo’, it would have Alberta’s retry_interval value of 4 instead of the default of 5, then it would set an IP address no matter what either of the other templates provided.

However this could confuse an administrator and slow down the GUI. Thus OP5 sets only one template as the one in use. Good news: you can create that template within Monitor, and the new template can use another template as its parent for inheritance. While Nagios allows a user to do this manually, our tools make it clear what you will get when you save your configuration changes. Here is a new template with its clear inheritance of the default template:

define host {

name                                      Flanders
use                                          default-host-template
retry_interval                      4
register                                  0
}

When you create a new object or object group, you will see the template drop-down at the start of the main section. You can also click on the “Show template values” button to the right and see the final set of template values that will get applied.

Think about your own environments. You may already a subnet that requires intense security restrictions, so tight that even ICMP is no longer allowed. However the default check command for any object is ‘check_host_alive’, which runs ping (an ICMP call).

Right now, you may have been changing that on a per-host basis, by changing the check command from the dropdown in the middle of a host’s configuration page. However you can make this change as part of a template that calls another template:

  1. Go to “Manage -> Configure” from the drop-down menu at the top of any OP5 screen;
  2. Click on “host templates”, then click on the New button in the next page to make a new template;
  3. Give the new template a relevant name without spaces, such as ‘no-ICMP-allowed’;
  4. In the Template drop-down field below the name, select an existing template that will provide the defaults. If you’ve never created a template before, you will only see ‘default-host-template’. Be sure to select that at least, so you have a baseline of values;
  5. Click on the “View template values” button. This will open a panel to the right of the screen and show what you will inherit from the existing template you just selected;
  6. Select some hosts or a hostgroup to be assigned this new template;
  7. Scroll down to the check_command drop-down menu. Replace the default ‘check-host-alive’ with some other command, such as ‘check_snmp_v3’ if these servers expect to listen via authenticated SMNP instead, or ‘check_ssh’ to make sure the SHH daemon is listening;
  8. Add any extra command arguments in the next field. For now, we can accept defaults just to make sure our hello-world version of the changes will work;
  9. Click Submit, then click save on the right-side manner of the next page to change the configuration files.Try a few cases on your test environment. Running through your own examples will help your mind see the potential dimensions of this. Every weird set of servers or networking components in your world will soon become clear classes of compliant computer combinations. Any time period for a special shutdown can be implemented handily and in a timely fashion.

Try a few cases on your test environment. Running through your own examples will help your mind see the potential dimensions of this. Every weird set of servers or networking components in your world will soon become clear classes of compliant computer combinations. Any time period for a special shutdown can be implemented handily and in a timely fashion.

Download this Article

by Jim Greenway 15 January Support