The configuration attribute "zone" does not work as a configuration attribute

This forum was archived to /woltlab and is now in read-only mode.
  • Hi,

    If I correctly understand the zone attribute, it has no function in the object definition and should therefore be moved to the run-time variables. The zone to which the object belongs is set by inserting the object definition into the appropriate directory in zones.d.

    Can anyone please confirm the accuracy of my presumption?

  • runtime variables are stateful, and cannot be modified. You may set the "zone" attribute in PUT requests for config objects inside the REST API for example.

    You can use it in special scenarios inside a static configuration too, as mentioned in the distributed montoring docs. Anything else should be done with care. For the sake of completeness it is documented in the main tables for object types :)

    Still, it is a really really advanced technique. If you don't trust it, rely on zones.d and config sync only.

  • Thank you for the quick reply.

    I found only one scenario with the zone attribute setting in the documentation:

    1. [root@dinga2-master1.localdomain /] # cd /etc/icinga2/zones.d/usinga2-client2.localdomain
    2. [root@icinga2-master1.localdomain /etc/icinga2/zones.d/icinga2-client2.localdomain]# vim hosts.conf
    3. object Host "icinga2-client2.localdomain" {
    4. check_command = "hostalive"
    5. address = ""
    6. zone = "master" // optional trick: sync the required host object to the client, but enforce the "master" zone to execute the check
    7. }

    but I'm thinking about the opposite - I want to have a host defined in the master zone and the replicated to client zone or multiple client zones. For example:

    - automatic assignment to the correct zone based on IP address:


    - monitoring the availability of one host from different locations

    1. ZONES = ["NewYork", "Prague", "Tokio"]
    2. for (zone_name in ZONES) {
    3. object Host "Some Server from" + zone_name use (zone_name) {
    4. address = ""
    5. zone = zone_name
    6. }
    7. }

    but this unfortunately does not work because client replication is dependent on the location of the host definition in the correct directory in zones.d.

    Or am i wrong?

    Or is there another way to achieve the required functionality?

  • Those examples are a kind wish, but won't work in reality. As said, configuration sync is controiled via zones.d and you should use just that.

  • Given the workload shared between 3 developers and one trainee for Icinga 2, I honestly doubt it. Your best bet is to focus on what's currently working and how to make it fit into your requirements. E.g. by moving into the automated way with Puppet, Ansible, etc.