Error: 'Zone' re-defined - using top-down

This forum was archived to /woltlab and is now in read-only mode. Please register a new account on our new community platform.

You can create a thread on the new site and link to an archived thread. This archive is available as knowledge base, safe and secured.

More details here.
  • Hi,

    I switched from bottom-up to top-down and removed the files from repository.d. Currently I struggle with the exact syntax for new hosts.

    Then I created the following files:




  • well it says where the problem is.

    What is the content of the zones.conf in /etc/icinga2/?

    Most likely the zone is defined two times, which would explain your error.

    Linux is dead, long live Linux

    Remember to NEVER EVER use git repositories in a productive environment if you CAN NOT control them

  • Yes, there is but I thought it should be fine there instead of the sync'ed files, beacuse the setup wizard created those entries.

    I have now removed the lines from zones.conf, renamed the master-Zone to match the hostname and removed hosts.conf and services.conf.

    Is this the correct way? Should I remove all files under conf.d or do I need to comment out the include line in icinga2.conf?

  • it depends on what you want to do, for my setup I removed all files expect the API users as I do need them and redefined everything in a proper folder.

    Linux is dead, long live Linux

    Remember to NEVER EVER use git repositories in a productive environment if you CAN NOT control them

  • Now I get "Zone 'server02.example.local' is not connected. Log lag: less than 1 millisecond".

    The service started just fine and he pulled the latest config into "C:\ProgramData\icinga2\var\lib\icinga2\api\zones\server02.example.local\_etc".

    Master is defined as parent in:


    Same problem found here:…ng_all_services_but_zone/


    I removed


    check_command = "cluster-zone"

    ...from host object. The error is gone but is this the correct solution?

    The post was edited 2 times, last by syfy323 ().

  • Nice that it works for you.

    Are there open Problems / Questions or did you fix it all alone ?

    It seems to work very well after I figured out how to setup the director.

    The config layout is a bit different but it works very well on my clients, even after a fresh install of a client node.

    My last open topic is Win Server 2003 as some clients still need to run it for old software.

    We would like to monitor them while migration is in progress. I tried V2.4 release but the setup wizard crashs when receiving the cert.

    The docs state that 2003 / XP is not supported - so we knew it before we chose Icinga2 over other solutions.

  • Windows Server 2003 is EOL for many years now, and security issues are not fixed by its vendor. We as an open source project cannot take the burden to support systems which are not maintained anymore, or where bugs would cause Icinga 2 not to work or introduce security leaks. On the other hand, 2k3 and XP use legacy interfaces which harden the code maintenance in Icinga 2 itself. No-one pays you for doing so, that is why we only support official supported versions by vendor/upstream.

    You'll also recognize that RHEL5 was EOL early this year. v2.7 won't receive any package builds for it.

    If you really need monitoring on such legacy Windows systems, look into older NSClient++ versions which may still be run. Or wmi as remote plugin.

  • RHEL5 was EOL early this year

    From here we see an extended support expiring end 2020/11.

    You are completely right with your decisions, but i am forced to run that OS for at least 2018/12.

    I would take the burdon to self compile it for myself, and you know i would not go on your nerves if that failes.


    Do you already know that this attempt must / would fail ?

  • It compiles since we recently fixed an openssl 0.9.8 compile issue. Extended support is something we cannot stem with our build infrastructure relying on open source mirrors. CentOS 5 is slowly fading out, and our Docker builds started to fail due to gone mirrors.

    2.6 packages should work just fine with 2.7, but keep in mind - the sooner you upgrade your infrastructure, the more benefits you will gain. I doubt that we will continue to take care about RHEL5 library versions in git master. RHEL5 is one of the reasons for really defensive code in Icinga 2, you're relying on 10 year old software interfaces.

    TL;DR - don't bet on extended support, but keep your applications safe and plan upgrades soon enough. I know this sounds easy, but I already hear users whining about the fact that v2.7 does not provide any RHEL5 packages. And I cannot hear this anymore ...