Error in Director created configuration: Command endpoint must be in zone 'example-masters' or in a direct child zone thereof

[kbucheli]

This issue respects the following points:

• This is a bug, not a question or a setup/configuration issue.
• This issue is not already reported on Github (I've searched it).
• I use the latest release of the Monitoring Plugins (https://github.com/Linuxfabrik/monitoring-plugins/releases).
• I agree to follow Monitoring Plugins's Code of Conduct.

Which variant of the Monitoring Plugins do you use?

• .rpm/.deb package from repo.linuxfabrik.ch
• Compiled for Linux (.tar/.zip from download.linuxfabrik.ch)
• Compiled for Windows (from download.linuxfabrik.ch)
• Source Code from GitHub

Bug description

We have a 3-tier Icinga2 monitoring setup using satellites according to the Distributed Monitoring documentation.

I imported the command definitions et al. into the Director according to ICINGA.rst -> All Plugins, I also followed

If you did not name your master zone master during the initial icinga2 node wizard, find and replace "zone": "master" with "zone": "your-master-zone-name" in the icingaweb2-module-director-basket.json file.

When trying to apply these service templates on a test host, icinga2 refused the configuration:

critical/config: Error: Validation failed for object 'lx-test-01.example.com!Load' of type 'Service'; Attribute 'command_endpoint': Command endpoint must be in zone 'example-masters' or in a direct child zone thereof.

At some point remembering that there are special zones for Director configuration deployment. So I set there "global-templates" and turned out to be happy. Next I tried with an empty zone configuration, so it ended up in the "director-global" zone, but still all fine.

Can you please improve the documentation accordingly?

Steps to reproduce - Plugin call

N/A

Steps to reproduce - Data

No response

Environment

icinga2 r2.14.0-1
Icinga Web 2 2.11.4
Director 1.10.2
OS: RHEL 8.8

Plugin Version

2023051201

Python version

No response

List of Python modules

No response

Additional Information

No response

[markuslf]

We will have a look, thank you!

[thesefer]

critical/config: Error: Validation failed for object 'lx-test-01.example.com!Load' of type 'Service'; Attribute 'command_endpoint': Command endpoint must be in zone 'example-masters' or in a direct child zone thereof.

At some point remembering that there are special zones for Director configuration deployment. So I set there "global-templates" and turned out to be happy. Next I tried with an empty zone configuration, so it ended up in the "director-global" zone, but still all fine.

Hi, I know this issue is kinda old but running with a (still not working) master -> satellite -> agent setup that if I assign the 2 templates to the master-zone I receive the same error. I tried following your advice and changed them to "global-templates" but I am just getting

Error: Validation failed for object 'agent.example.com!tpl-service-ping' of type 'Service'; Attribute 'command_endpoint': Command endpoint must be in zone 'global-templates' or in a direct child zone thereof.

All clients (master, satellite, agent) have

object Zone "director-global" {
  global = true
}

object Zone "global-templates" {
  global = true
}

and

object ApiListener "api" {
  accept_config = true
  accept_commands = true
}

On the agent I see the template in /var/lib/icinga2/api/zones/global-templates/director/service_templates.conf

[NavidSassan]

Reversing this in #1332.

#721 moved tpl-service-generic and tpl-host-generic to the global zone so distributed setups deploy without per-host zone changes. The cost is that a credential set on a host or service object is then rendered into the global zone and copied to every agent's on-disk config. We decided a silent credential leak to all agents is a worse default than a loud, documented config rejection.

#1332 pins the two base templates back to the master zone and lets every other template inherit from them, so those two are the single control point for the whole tree's zone. Single-node and flat master to agent setups keep working and now keep configuration on the master. Distributed setups with satellite- or agent-authoritative hosts fail loudly at deploy (Import references unknown template: '...' or Command endpoint must be in zone '...' or in a direct child zone thereof) and are documented to unset the zone on the two base templates, accepting the credential distribution that entails. See the rewritten Distributed Monitoring section in ICINGA.md.