Zones in Zones with Director with 2.11

Icinga 2
,
1

Hello,

we have the following infrastructure: We are providing our teams seperate Icinga2 clusters wich are managed via docker and running in kubernetes. The teams only have read-only access to Icinga2 via the Icinga2 API, and write access via Icingaweb2 and Director.
The teams are configuring their Zones for Satellites and Agents via Director, this worked fine until 2.11.

Now, if i am read the documentatin correct, 2.11 ignores every Zone in zones.d which is not configured in zones.conf. Because the teams can not edit the zones.conf, i think this breaks our concept.

Example:
Master zones.conf:

object Endpoint "master1"  {
  host = "master1"
}

object Endpoint "master2"  {
  host = "master2"
}

object Zone "master"  {
  endpoints = [ "master1", "master2", ]
}

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

Configured Satellite Zone via Director:
/var/lib/icinga2/api/zones/master/director/zones.conf

object Zone "satellite1" {
    parent = "master"
    endpoints = [ "satellite1" ]
}

Now, Icinga2, as stated in the 2.11 documentation, ignores the zone:

warning/config: Ignoring directory '/var/lib/icinga2/api/zones/satellite1' for unknown zone 'satellite1'.

I assume Icinga2 will also not sync the zone files under /var/lib/icinga2/api/zones/satellite1 to the sattelite host. Am i correct with that?

Is there any way to enable this again? This would restore that Icinga2 is completely configureable via the Webinterface, no shell access needed.

2

Hi,

the initial design for the cluster config sync expected the zones to be configured outside in zones.conf and as such, only including what’s inside zones.d. The limitation was not implemented before 2.11 and as such, every “crap” was included, no matter it had been defined in zones.conf or not. This resulted in broken configuration with renamed zones and so on.

With 2.11, the config sync now checks whether these zones have been defined and ignores them. This is explained here and here.

I know that the idea of managing everything via the web interface is what users want, unfortunately this was never supported this way. It somehow worked, we changed some bits for fixing long standing bugs, it doesn’t work anymore.

Re-enabling needs a different algorithm to not include zones.d configuration when the zone object really doesn’t exist. We’re going to re-evaluate this in the short term with https://github.com/Icinga/icinga2/issues/7530 (no promises made here, my limit is tomorrow since I have to prepare a GitLab workshop for OSMC as well while my colleagues work on IcingaDB), a long term idea is to really allow only master web based zone configuration and better deployments.

Cheers,
Michael

PS: Next time please test the RC which would allow us to discuss such things before they reach production.

3

Hi Michael,

you are right, we should have taken the time to test while the RC was out. I simply read the blogpost about the 2.11 RC and could not find any showstoppers for our setup in there, so i just let that slip though.

Please dont consider this as a bad feedback or a sad comment, i just wanted to point out what has worked for us before, and now dont. Overall, we are really happy with Icinga, it runs really smoothly in our setup. (And with 2.11 it will be much easier running it in our containers, thanks to the umbrella process :slight_smile: )

I wish i could help you with the task, but C and C++ are not my strengths.

1 Like
4

Hi Martin,

no worries, since I know you personally, I know where you are coming from. The thing with those zone directories simply was, that we expected it to work like documented with zones.conf everywhere. Those “workarounds” with zones in zones is something which we never suggested, but somehow users adopted it. That’s why we didn’t know about and as such, no extra highlight was shown in the changelog nor release blogposts.

Anyhow, long story short - RCs will continue to come and with everyone taking the chance to test and influence the final release, we can get better together.

I’ll continue my research in the code, the config compiler is a very fragile part and somehow complicated.

Cheers,
Michael

5

Short update: I haven’t found a way to make this work, the config compiler is very tricky and I am very tired after releasing 2.11 last week. I’ll take a break as already mentioned. Meanwhile I can only suggest to find a different way of configuring the zones in your environment, e.g. with Ansible (afaik you’re using this already).

Cheers,
Michael

6

Hey @dnsmichi - sorry to bump an old thread.

I can see you have merged the changes in https://github.com/Icinga/icinga2/pull/7546 which resolves https://github.com/Icinga/icinga2/issues/7530.

Does this resolve the problem of creating zones in Director?

7

Honestly I haven’t tested it with the Director. Probably yes, although I still advise against managing the zones for direct zone relations anywhere outside of the zones.conf on the server.

1 Like
8

No worries, I’ll test this out in the next RC.

Our use case is similar to @neubi - the team that actually uses Icinga in our organisation isn’t granted shell access, and create a zone per customer.

Creating zones in the web interface is a very useful aspect of Director for us, and although we could build our own tool to create these and import as external objects, it would be great to keep it all in one place.

We’re yet to Upgrade from 2.10.5 as we’re running a custom build with our OpenTSDB writer changes that got merged recently, so it hasn’t really been a problem for us yet.

If this is still a problem in the next RC we will look at storing them in GitLab setting up a CI/CD flow with Salt to sync them to the masters.

9

Just as an update - we’re running the latest RC of Icinga/IcingaDB and latest Icinga Web on fresh test cluster, and this appears to be working again.

1 Like