Am 06.10.2016 um 00:05 schrieb Barry Quiel:
Hi Barry,
sorry for the late reply. I got the same problem and solved it finally.
> So I was going to go on a long diatribe about the necessity for
> dependencies across zones, but I found, really by accident, that most
> of what I was looking for was already in place. My goal is to have
> the master zone send notifications based on dependency enforcement and
> not the child zones. So I just have one follow up/question:
>
> The problem is only the master zone knows about dependencies in all
> the child zones. When the config gets pushed to Zone A, it doesn't
> know about host object Z in Zone B and can't create the dependency. It
> creates a critical error and the config fails to lode. Some sample
> config:
>
> On the config master node.
>
> in /etc/icinga2/zones.d/zoneA/hostX.conf
> object Host "hostX" {
> address = "XXX.XXX.XXX.XXXX"
> vars.nexthop = "hostZ"
> }
>
> apply Dependency "child-of" to Host {
> parent_host_name = host.vars.nexthop
> child_host_name = host.name
> assign where host.vars.nexthop
> }
>
> in /etc/icinga2/zones.d/zoneB/hosyZ.conf
> object Host "hostZ" {
> address = "YYY.YYYY.YYYY.YYY"
> }
>
> When you run icinga2 daemon -C in the master zone, everything is fine,
> because it knows about all the objects across all the zones. But when
> you run icinga2 daemon -C in zoneA it complains that it can't create
> the Dependency object because the parent object doesn't exist.
>
> Now having said that, I do have a work around. I create a dummy
> object in the child zone. Then I use some of that great Icinga config
> magic.
>
> apply Dependency "child-of" to Host {
> parent_host_name = host.vars.nexthop
> if( !get_host(host.vars.nexthop ) {
> parent_host_name = "dummy_host"
> child_host_name = host.name
> assign where host.vars.nexthop
> }
>
> When this runs in the master zone it compiles fine because
> host.var.nexthop is a host object that exists. It also work in the
> child zone because it substitutes dummy_host for host.vars.nexthop. It
> seems like there should be a better way to do this. I use this dummy
> object trick in several places, and it adds a noticeable about of time
> to the config compile stage. I'm wondering if changing the object not
> existing error from a critical to a warning may solve a lot of this.
> If the object doesn't exist just spit out a warning and don't create
> the dependency.
I have a custom Host variable called vars.parents that contains excactly
that. Since many of my hosts are distributed over the world and thus in
my setup in different zones, I also have the need to set the inter zone
dependency. This of course only works in the master zone, which also
sends the notifications.
On my master node I have the following config:
apply Dependency "parent" for (parent in host.vars.parents) to Host {
parent_host_name = parent
child_host_name = host.name
disable_checks = true
assign where typeof(host.vars.parents) == typeof([]) && ZoneName ==
"mymaster.example.com"
}
Somewhere on the node, you have to set ZoneName. It usually is set to
NodeName, thus the FQDN above. That might need adjustment in a multi
master setup.
Hope this helps,
Stephan
_______________________________________________
icinga-users mailing list
icinga-users@lists.icinga.org
https://lists.icinga.org/mailman/listinfo/icinga-users
