Introduction

One of my primary motivations for adding support for template-based configuration data was its ability to easily allow object definitions to inherit various properties from other object definitions. Object property inheritence is accomplished through recursion when Nagios processes your configuration files.

This documentation attempts to explain recursion and inheritence in object definitions that is available when you compile Nagios with support for template-based object configuration data. It should be noted that the recursion and inheritence principles described here also apply to template-based extended information data.

If you are still confused about how recursion and inheritence work after reading this, take a look at the sample template-base config files provided in the distribution. If that still doesn't help, drop an email message with a detailed description of your problem to the nagios-users mailing list.

Basics

There are three variables affecting recursion and inheritence that are present in all object definitions. They are as follows...

	define someobjecttype{
		
		object-specific variables ...
		
		name		template_name
		use		name_of_template_to_use
		register	[0/1]
		}

The first variable is name. Its just a "template" name that can be referenced in other object definitions so they can inherit the objects properties/variables. Template names must be unique amongst objects of the same type, so you can't have two or more host definitions that have "hosttemplate" as their template name.

The second variable is use. This is where you specify the name of the template object that you want to inherit properties/variables from. The name you specify for this variable must be defined as another object's template named (using the name variable).

The third variable is register. This variable is used to indicate whether or not the object definition should be "registered" with Nagios. By default, all object definitions are registered. If you are using a partial object definition as a template, you would want to prevent it from being registered (an example of this is provided later). Values are as follows: 0 = do NOT register object definition, 1 = register object definition (this is the default).

Local Variables vs. Inherited Variables

One important thing to understand with inheritance is that "local" object variables always take precedence over variables defined in the template object. Take a look at the following example of two host definitions (not all required variables have been supplied):

	define host{
		host_name		bighost1
		check_command		check-host-alive
		notification_options	d,u,r
		max_check_attempts	5
		name			hosttemplate1
		}

	define host{
		host_name		bighost2
		max_check_attempts	3
		use			hosttemplate1
		}

You'll note that the definition for host bighost1 has been defined as having hosttemplate1 as its template name. The definition for host bighost2 is using the definition of bighost1 as its template object. Once Nagios processes this data, the resulting definition of host bighost2 would be equivalent to this definition:

	define host{
		host_name		bighost2
		check_command		check-host-alive
		notification_options	d,u,r
		max_check_attempts	3
		}

You can see that the check_command and notification_options variables were inherited from the template object (where host bighost1 was defined). However, the host_name and max_check_attempts variables were not inherited from the template object because they were defined locally. Remember, locally defined variables override variables that would normally be inherited from a template object. That should be a fairly easy concept to understand.

Inheritence Chaining

Objects can inherit properties/variables from multiple levels of template objects. Take the following example:

	define host{
		host_name		bighost1
		check_command		check-host-alive
		notification_options	d,u,r
		max_check_attempts	5
		name			hosttemplate1
		}

	define host{
		host_name		bighost2
		max_check_attempts	3
		use			hosttemplate1
		name			hosttemplate2
		}

	define host{
		host_name		bighost3
		use			hosttemplate2
		}

You'll notice that the definition of host bighost3 inherits variables from the definition of host bighost2, which in turn inherits variables from the definition of host bighost1. Once Nagios processes this configuration data, the resulting host definitions are equivalent to the following:

	define host{
		host_name		bighost1
		check_command		check-host-alive
		notification_options	d,u,r
		max_check_attempts	5
		}

	define host{
		host_name		bighost2
		check_command		check-host-alive
		notification_options	d,u,r
		max_check_attempts	3
		}

	define host{
		host_name		bighost3
		check_command		check-host-alive
		notification_options	d,u,r
		max_check_attempts	3
		}

There is no inherent limit on how "deep" inheritance can go, but you'll probably want to limit yourself to at most a few levels in order to maintain sanity.

Using Incomplete Object Definitions as Templates

It is possible to use imcomplete object definitions as templates for use by other object definitions. By "incomplete" definition, I mean that all required variables in the object have not been supplied in the object definition. It may sound odd to use incomplete definitions as templates, but it is in fact recommended that you use them. Why? Well, they can serve as a set of defaults for use in all other object definitions. Take the following example:

	define host{
		check_command		check-host-alive
		notification_options	d,u,r
		max_check_attempts	5
		name			generichosttemplate
		register			0
		}

	define host{
		host_name		bighost1
		address			192.168.1.3
		use			generichosthosttemplate
		}

	define host{
		host_name		bighost2
		address			192.168.1.4
		use			generichosthosttemplate
		}

Notice that the first host definition is incomplete because it is missing the required host_name variable. We don't need to supply a host name because we just want to use this definition as a generic host template. In order to prevent this definition from being registered with Nagios as a normal host, we set the register variable to 0.

The definitions of hosts bighost1 and bighost2 inherit their values from the generic host definition. The only variable we've chosed to override is the address variable. This means that both hosts will have the exact same properties, except for their host_name and address variables. Once Nagios processes the config data in the example, the resulting host definitions would be equivalent to specifying the following:

	define host{
		host_name		bighost1
		address			192.168.1.3
		check_command		check-host-alive
		notification_options	d,u,r
		max_check_attempts	5
		}

	define host{
		host_name		bighost2
		address			192.168.1.4
		check_command		check-host-alive
		notification_options	d,u,r
		max_check_attempts	5
		}

At the very least, using a template definition for default variables will save you a lot of typing. It'll also save you a lot of headaches later if you want to change the default values of variables for a large number of hosts.