1

To kill some possible confusion right form the start, I'm not looking to define me own fields within host definitions, but instead to create a variable that I can use across multiple host definitions to fill in one of the standard fields.

When I add a VM to our Nagios server I add the machines in our virtualisation cluster as the parents of that machine, because if any one of those servers is up, the VM should be accessible. This results in an entry in the definition of each VM of the form:

define host{
        host_name               xxx1
        alias                   xxx1.domain.tld
        address                 xxx.xxx.xxx.xxx
        parents                 dom0_1, dom0_2, dom0_3, dom0_4, dom0_5, dom0_6
        ...
}

The thing is, our cluster keeps changing and expanding, and it's a pain in the backside to have to update this entry in every VM, I want to be able to change it in just one place, and have that change affect the definitions for all our VMs.

3 Answers 3

1

Agree with using templates but you need a slight different syntax for templating. A template is a host/service definition with "register 0" added, then you inherit the template in the actual host definition with use, don't forget to inherit the system default-host in your new template

define host {
  name host-template1
  use generic-host
  parents dom0_1,dom0_2
  register 0
 }

 define host {
   use host-template1
   host_name .....
   ....
  }
2
  • I'd hoped to avoid having to use templates because we already use templates and you can't have multiple inheritance, so I've had to chain the inheritance and duplicate the list twice - it's not pretty, but it does work.
    – Bart B
    Sep 23, 2011 at 13:07
  • But you can have multiple inheritance - just add use template1,template2. Variable conflicts are solved by predecence. In my example, if both template1 and template2 defined a parents field, the one from template1 would be used. You can read about this almost at the end of the object inheritance section from Nagios docs.
    – Nupraptor
    Sep 27, 2011 at 14:57
3

Nagios calls these "macros", and defines them in resource.cfg, which you'll find in your Nagios installation's /etc directory. Something like:

 $USER5$=dom0_1,dom0_2,dom0_3,dom0_4,dom0_5,dom0_6

Added to resource.cfg should do the job ($USER1$ through $USER4$ are already taken); you may have to play about with backslashes and stuff to escape all the commas/spaces, though. Then you can define your hosts like:

define host{
        host_name               xxx1
        alias                   xxx1.domain.tld
        address                 xxx.xxx.xxx.xxx
        parents                 $USER5$
        ...
}
3
  • I take it I can't give the macros names of my own, and I have to stick with the cryptic '$USERn$' naming?
    – Bart B
    Sep 22, 2011 at 16:12
  • As far as I can tell, yes; feel free to experiment, though.
    – RainyRat
    Sep 22, 2011 at 17:01
  • Nuts! Doesn't work - it seems Macros are no accepted in the parents field :(
    – Bart B
    Sep 23, 2011 at 13:06
0

I think you want to use a template:

define template {
    parents dom0_1, dom0_2
    name cluster_parents_tmpl
}

define host {
    use cluster_parents_tmpl
    host_name               xxx1
    alias                   xxx1.domain.tld
    address                 xxx.xxx.xxx.xxx
    ...
}
2
  • since you can only have linear inheritance, this is not a good solution, because we already inherit from a bunch of different templates depending on the type of monitoring we want. If it were possible to have multiple use statements in the same host definition it would be a good solution, but from my reading of the docs it's not.
    – Bart B
    Sep 22, 2011 at 16:11
  • according to nagios.sourceforge.net/docs/3_0/objectinheritance.html you could probably get around this using inheritance chaining.
    – malcolmpdx
    Sep 23, 2011 at 15:41

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .