IFW: 'Last zone sync stage validation failed' because of 'Check Command redefined'


after installation of IfW version 2.14.0 we get ‘Last zone sync stage validation failed’. And in the logs we get

[2023-11-30 16:46:39 +0100] information/cli: Icinga application loader (version: v2.14.0)
[2023-11-30 16:46:39 +0100] information/cli: Loading configuration file(s).
[2023-11-30 16:46:39 +0100] critical/config: Error: Object ‘fail2ban’ of type ‘CheckCommand’ re-defined: in C:/ProgramData/icinga2/var/lib/icinga2/api/zones-stage/director-global/director/commands.conf: 105:1-105:30; previous definition: in C:/Program Files/ICINGA2//share/icinga2/include/plugins-contrib.d/network-services.conf: 88:1-88:30
Location: in C:/ProgramData/icinga2/var/lib/icinga2/api/zones-stage/director-global/director/commands.conf: 105:1-105:30
C:/ProgramData/icinga2/var/lib/icinga2/api/zones-stage/director-global/director/commands.conf(103): }
C:/ProgramData/icinga2/var/lib/icinga2/api/zones-stage/director-global/director/commands.conf(105): object CheckCommand “fail2ban” {
C:/ProgramData/icinga2/var/lib/icinga2/api/zones-stage/director-global/director/commands.conf(106): import “plugin-check-command”
C:/ProgramData/icinga2/var/lib/icinga2/api/zones-stage/director-global/director/commands.conf(107): command = [ PluginDir + “/check_fail2ban.sh” ]
[2023-11-30 16:46:39 +0100] critical/cli: Config validation failed. Re-run with ‘icinga2 daemon -C’ after fixing the config.

Over the years we’ve integrated a lot of public available check for at first Nagios, then Icinga and during the last 7 years for Icinga2. And we’ve build also our own checks if needed. And one of the checks we use for our linux systems is fail2ban.

As a result only the ‘internal’ checks of the windows client are available. For checks from the framework we get messages like ‘Check command ‘Invoke-IcingaCheckUptime’ does not exist.’.

When I remove the “director-global” zone from the configuration (like suggested in another post), the error disappears. But the client doesn’t get any configuration updates.

If I mask fail2ban in network-services.conf, everything works as expected. But I fear, a manipulation of this file will be deleted during the next update.

Server OS: RHEL 8.9
Icinga2: r2.14.0-1 (Build from Source)
Icinga Web 2: 2.11.4
Icinga Director: 1.10.2

Client OS: Windows Server 2022
IfW Version: 2.14.0

WIndows client zones.conf is the default created by the installer:

object Endpoint “mecmtest” {}
object Endpoint “server1” {}
object Endpoint “server2” {}
object Zone “master” {
endpoints = [ “server1”, “server2” ];
object Zone “mecmtest” {
parent = “master”;
endpoints = [ “mecmtest” ];
object Zone “director-global” { global = true; }
object Zone “global-templates” { global = true; }

And there is more, somehow related:

We still have some RHEL 7 systems with Icinga2 2.13.6. Version 2.14.0 can’t be build for RHEL 7 because of dependencies to boost. When we import ifw-api in the ‘PowerShell Base’ command, we get ‘Last zone sync stage validation failed’ on all our 2.13.6 clients because then ifw-api is undefined on those systems.

zones.conf of our linux clients (parameters defined in a constants.conf):

object Zone “director-global” {
global = true
object Endpoint NodeName {
host = NodeName
object Zone ZoneName {
parent = ParentZoneName
endpoints = [ ZoneName ]
for (endpoint in ParentZoneEndpoints) {
object Endpoint endpoint use(endpoint){
host = endpoint
object Zone ParentZoneName {
endpoints = ParentZoneEndpoints

zones.conf of the master

object Zone “director-global” {
global = true
for (endpoint in ZoneEndpoints) {
object Endpoint endpoint use(endpoint){
host = endpoint
object Zone ZoneName {
endpoints = ZoneEndpoints

constants.conf for all our linux clients:

const NodeName = “”
const ZoneName = NodeName
const ParentZoneName = “master”
const ParentZoneEndpoints = [ “server1”,“server2” ]

We have four zones defined: director-global, master, and 2 satellite zones.

One possible problem might be, that we started years ago with an early version of director. I don’t remember how the zones were defined and the guy that made the initial setup isn’t available anymore.
In the director the zones part shows: ‘4 objects have been defined, 4 have been externaly defined and will not be deployed’. When I select one of those zones I get: ‘This is an external object. It has been imported from Icinga 2 through the Core API and cannot be managed with the Icinga Director.’

Is there any solution or workaround for this kind of problem?

Thanks in advance!


could you just rename your command in Director to avoid the duplicate?



This did work. Although I don’t understand why the IfW client is evaluating local definitions, when he should use the configuration deployed by api.