One of the most powerful features of Nagios is that it allows you to use object inheritance in your configuration files. Items can be defined as templates, allowing other items to inherit properties from them. Individual object properties can override the inherited ones. This considerably facilitates maintenance of the Nagios configuration.

An example:

Here we define a template named 'generic-host'. Setting 'register' to '0' means that the template itself will not be visible as a host within Nagios:

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

    define host{
        host_name               localhost
        use                     generic-host
        address                 127.0.0.1
        max_check_attempts      3
    }

The host 'localhost' inherits the properties 'check_command' and 'notification_options' from the template, but overrides the 'max_check_attempts' value from the template with a value of its own.

Templates can be chained to create a hierarchical structure of inheritance. Properties can also be inherited from multiple templates.

For a detailed description of Nagios templates, refer to the Nagios Objects Inheritance manual.

Templates are a feature that was introduced in NConf 1.2.6. NConf allows you to define host- and service-templates: host-templates can be assigned either to hosts or other host-templates (chaining). Likewise, service-templates can be assigned either to services or other service-templates.

Additionally, both host- and service-templates can be linked with timeperiods, nagios-collectors and nagios-monitors. These linked templates will then be assigned to all hosts / services who are linked with any of those items. Previous to NConf 1.2.6, some properties were statically copied from timeperiods / collectors / monitors onto hosts and services. This 'static inheriting' has now been replaced by templates.

We assume there are two main kinds of NConf users:

A) users who do not use templates and who assign certain attributes statically to all their hosts & services via timeperiod / collector / monitor (this was the case for everyone prior to NConf 1.2.6)

B) users who work with template based attributes and assign templates to each host & service directly

Information concerning “type A)” users:
For reasons of reverse-compatibility, we kept the static attributes under timeperiods / collectors. I'm referring to “max check attempts”, “check interval”, “active checking” etc. under timeperiods / collectors / monitors. If these attributes are still set, they will in every case override any values coming from a template. These attributes are DEPRECATED though, and will be removed in a future release.

As a replacement for these static attributes, we introduced the possibility for users to link a template with a timeperiod, a collector or monitor. These templates will then be assigned to all hosts / services who are linked with any of those items. Our goal is for users, who want to continue using the old static attributes, to switch to these new templates under timeperiods / collectors / monitors.

Information concerning “type B)” users:
If instead you want to assign templates to hosts and services individually, do the following:

1. Make sure you remove all static values from your timeperiods / collectors / monitors such as “max check attempts”, “check interval”, “active checking” etc.
2. Make sure you unlink all templates from your timeperiods / colelctors / monitors
3. Create new host- & service-templates containing exactly those attributes that you need
4. Assign them individually to your hosts or services (can be done using the 'multi-modify' feature)

The following sequence illustrates in which order of precedence attributes are applied to a host (the same order naturally also applies to services):

1. highest priority have attributes defined on a host level directly
   (or statically inherited from timeperiod / collector [DEPRECATED])
2. priority 2 have attributes defined in a host-template, that is directly linked to a host
3. priority 3 have attributes defined in a host-template, that is linked to the host over its 'notification_period'
4. priority 4 have attributes defined in a host-template, that is linked to the host over its 'check_period'
5. priority 5 have attributes defined in a host-template, that is linked to the host over a collector / monitor