Zones ignored if alphabetically behind master folder

I’m finally planning to upgrade production from 2.10.5 to 2.11.3 this weekend. In preparation, I loaded my production config into a test environment just to make sure icinga2 daemon -C passes. Something funny happened:

[2020-05-04 13:13:10 +0000] information/cli: Icinga application loader (version: 2.11.3-1)
[2020-05-04 13:13:10 +0000] information/cli: Loading configuration file(s).
[2020-05-04 13:13:10 +0000] warning/config: Ignoring directory '/etc/icinga2/zones.d/aussatellite' for unknown zone 'aussatellite'.
[2020-05-04 13:13:10 +0000] warning/config: Ignoring directory '/etc/icinga2/zones.d/bossatellite' for unknown zone 'bossatellite'.
[2020-05-04 13:13:10 +0000] warning/config: Ignoring directory '/etc/icinga2/zones.d/gersatellite' for unknown zone 'gersatellite'.
[2020-05-04 13:13:10 +0000] warning/config: Ignoring directory '/etc/icinga2/zones.d/lassatellite' for unknown zone 'lassatellite'.

Some explanation of my setup, on my two masters, in /etc/zones.conf I only have the details about the master zone. In /etc/icinga2/zones.d/master/satellite-zones.conf I defined the satellite zones with the intention of the config master pushing that to the secondary. First question, is this bad practice? Should I have been maintaining all satellite zones in /etc/zones.conf on both masters all along?

I noticed something interesting though; some of the satellite zones did load, and I was short about half my hosts. I listed the folder out checking for permission issues, and I noticed something, in alphabetical order, all zones before “master” were missing and all zones after “master” were pulled in just fine.

In the test environment, the config passes as I’d expect it to if I move the contents of satellite-zones.conf to zones.conf. The current state of my config has worked for about 2 years now. Is what I found here the way I should have been doing things, or is that icinga2 not iterating through the master folder first a bug in the new version?

You should have read the upgrade docs about zones with 2.11 :wink:

It clearly says

So move out your satellite zone config from master directory and put them into the zones.conf of every master or make a new include to this file/files (outside of zones.d) in icinga.conf.

Regards,
Carsten

1 Like

lol okay then, thanks Carsten. I’m guessing this also means i need to flush the api folder on the secondary master or seek & destroy the satellite-zones.conf file that lives in it before starting? If I purge that and the icinga2.state file for master2, that’ll sync in a few minutes right? That all makes sense to me but I’m super nervous about tipping this thing over.

Thanks for your help.

1 Like

Going to recreate this scenario instead of that scary thing I just said.

https://icinga.com/docs/icinga2/latest/doc/06-distributed-monitoring/#initial-sync-for-new-endpoints-in-a-zone

I’ve had issues where when master1 goes down, master2 doesn’t seem to know about all the downtimes and the pager goes batty. So something is clearly out of sync here anyway.

Marking resolved.

1 Like