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?