it seems that there is a bug with syncing this file to other endpoints. I might have fixed this with 2.11 and the stages.
* Read the given file and store it in the config information structure.
* Callback function for Glob().
* @param config Reference to the config information object.
* @param path File path.
* @param file Full file name.
void ApiListener::ConfigGlobHandler(ConfigDirInformation& config, const String& path, const String& file)
// Avoid loading the authoritative marker for syncs at all cost.
if (Utility::BaseName(file) == ".authoritative")
CONTEXT("Creating config update for file '" + file + "'");
<< "Creating config update for file '" << file << "'.";
std::ifstream fp(file.CStr(), std::ifstream::binary);
The main intention of this file is the following:
As you know, there’s only one config master with /etc/icinga2/zones.d
This endpoint must not receive configuration from the secondary master, this would result in a loop
Therefore the configuration is copied from /etc/icinga2/zones.d to /var/lib/icinga2/api/zones*
The .authoritative file marker is added in there
On reconnect, everything except for the .authoritative file marker is synced to the connecting endpoints (master in the same zone, satellites in the child zone).
Whenever this config master receives a configuration from the other master, it checks for having the config authority for this zone. If that’s true, you’ll see a message like this:
Ignoring config update from endpoint 'master2.localdomain' for zone 'master' because we have an authoritative version of the zone's config.
That’s information level, so totally valid to ignore it. Whenever some of your satellites logs that, that’s suspicious.
Agreed, this is hard to debug, but also hard to write a troubleshooting entry.
I also have seen users which manually rsync/copy
/var/lib/icinga2/api/zones* from the config master and then run into this behaviour.