Icinga Director placing Host in wrong zone

I originally had a single master server setup and working properly, but recently had to deploy a satellite server to monitor servers in a DMZ environment with a bit of an unreliable connection.
I created the zone and endpoints properly, however when creating the host it is deploying it to the master zones.conf instead for some reason.
Zone and Endpoint is in the proper zone:

object Zone “linux.dmz.corp” {
parent = “satellite”
endpoints = [ “linux.dmz.corp” ]


object Endpoint “linux.dmz.corp” {
port = “5665”
log_duration = 1d

However, the actual host object is being creating in the master zone:

object Host “linux.dmz.corp” {
import “linux_host”

address = "linux.dmz.corp"
vars.os = "RHEL Server 7.4"
vars.physical_host = false


I’m not really sure where to go from here. I can force the zones on the host object, but don’t think I should need to do that. If this is expected, then that’s fine, but I thought director is supposed to make those decisions automatically.

With the host being deployed to the master zone, I get this error message when attempting to add services to the host.

[2020-11-18 11:00:18 -0500] critical/config: Error: Validation failed for object ‘linux.dmz.corp!check_sssd’ of type ‘Service’; Attribute ‘command_endpoint’: Command endpoint must be in zone ‘master’ or in a direct child zone thereof.

This error message goes away when forcing the cluster zone of the object to the satellite zone.


does your template “linux_host” look like?

That depends how you configure your templates and import/sync rules. Because without any rule for this, the director don’t know where to push the hosts. So do you configure any rule about it?

Thanks for the reply. With regards to:

I guess I misunderstood this. I thought Icinga would match with Host object with the Endpoint object automatically somehow. If this isn’t the case, then I guess this means I would have to define a template for this location and set the cluster zone in that template, correct?

This is my template:

template Host “linux_host” {
import “generic-template”
template Host “generic-template” {
check_command = “ping4”
max_check_attempts = “3”
check_interval = 5m
retry_interval = 1m
check_timeout = 1m
enable_notifications = true
enable_active_checks = true
enable_passive_checks = true
enable_event_handler = true
enable_flapping = true
enable_perfdata = true
volatile = false

Again, if I understand this correctly, I will probably need to make a template for this location and manually define the cluster zone, right?

No, there’s no automatic match. Only Director automatically creates an Endpoint with the same name. If you go for the config file (which is often a good idea), you have to make sure to create Endpoints, Zones and Host for yourself.

endpoint and zone are only for communication, host are monitored objects. You can assign monitored objects more or less freely to zones - just make sure you’re not confusing yourself and have the right permissions and protocols to run the check. This comes basically down to having Hosts checked by their own endpoint or upstream zones.

Imagine you have more than 2 zones for satellite. What information should the director use to know what metadata to use to assign a host to a zone? So yes, you have to make sure that this works with rules and templates.
You can assign a zone directly in the sync rules. This is possible with a filter. You can create diffrent templates for diffrent zones. We for example created a standard template for linux hosts. We for example assign the zone directly in the sync rules via filter rules based on certain metadata contained in the import source.

Thanks, this all makes sense. I was just trying to simplify the setup so the cluster zone doesnt need to be selected. I am going to create a template for each location and work from there.

Part of the complication is I am not currently using sync rules as I don’t have an easy way to get the list of hosts for the specific location I am looking for. I can easily get the hosts from the vsphere environment, but not from the hyper-v environment and I have yet to work on a script to extract that info via WMI.