[pkg-nagios-changes] [Git][nagios-team/pkg-icinga2][upstream] New upstream version 2.11.1
Bas Couwenberg
gitlab at salsa.debian.org
Fri Oct 18 08:05:42 BST 2019
Bas Couwenberg pushed to branch upstream at Debian Nagios Maintainer Group / pkg-icinga2
Commits:
bc1653db by Bas Couwenberg at 2019-10-18T05:46:54Z
New upstream version 2.11.1
- - - - -
12 changed files:
- AUTHORS
- CHANGELOG.md
- RELEASE.md
- VERSION
- doc/10-icinga-template-library.md
- doc/14-features.md
- doc/15-troubleshooting.md
- doc/16-upgrading-icinga-2.md
- etc/icinga2/zones.d/README
- lib/config/expression.cpp
- lib/icinga/checkable.cpp
- lib/remote/apilistener-filesync.cpp
Changes:
=====================================
AUTHORS
=====================================
@@ -167,6 +167,7 @@ Obihörnchen <obihoernchende at gmail.com>
Oleg Artenii <oleg at artenii.email>
Pall Sigurdsson <palli-github at minor.is>
Paolo Schiro <paolo.schiro at kpnqwest.it>
+Patrick <patrick.ihle at patteswelt.de>
Patrick Huy <frz at frz.cc>
Paul Richards <paul at minimoo.org>
Pawel Szafer <pszafer at gmail.com>
=====================================
CHANGELOG.md
=====================================
@@ -7,6 +7,29 @@ documentation before upgrading to a new release.
Released closed milestones can be found on [GitHub](https://github.com/Icinga/icinga2/milestones?state=closed).
+## 2.11.1 (2019-10-17)
+
+This release fixes a hidden long lasting bug unveiled with 2.11 and distributed setups.
+If you are affected by agents/satellites not accepting configuration
+anymore, or not reloading, please upgrade.
+
+### Bugfixes
+
+* Cluster Config Sync
+ * Never accept authoritative config markers from other instances #7552
+ * This affects setups where agent/satellites are newer than the config master, e.g. satellite/agent=2.11.0, master=2.10.
+* Configuration
+ * Error message for `command_endpoint` should hint that zone is not set #7514
+ * Global variable 'ActiveStageOverride' has been set implicitly via 'ActiveStageOverride ... #7521
+
+### Documentation
+
+* Docs: Add upgrading/troubleshooting details for repos, config sync, agents #7526
+ * Explain repository requirements for 2.11: https://icinga.com/docs/icinga2/latest/doc/16-upgrading-icinga-2/#added-boost-166
+ * `command_endpoint` objects require a zone: https://icinga.com/docs/icinga2/latest/doc/16-upgrading-icinga-2/#agent-hosts-with-command-endpoint-require-a-zone
+ * Zones declared in zones.d are not loaded anymore: https://icinga.com/docs/icinga2/latest/doc/16-upgrading-icinga-2/#config-sync-zones-in-zones
+
+
## 2.11.0 (2019-09-19)
[Issue and PRs](https://github.com/Icinga/icinga2/issues?utf8=%E2%9C%93&q=milestone%3A2.11.0)
=====================================
RELEASE.md
=====================================
@@ -12,7 +12,7 @@
- [5. Package Builds](#package-builds)
- [5.1. RPM Packages](#rpm-packages)
- [5.2. DEB Packages](#deb-packages)
-- [6. Build Server](#build-server)
+- [6. Build Server](#build-infrastructure)
- [7. Release Tests](#release-tests)
- [8. GitHub Release](#github-release)
- [9. Chocolatey](#chocolatey)
@@ -26,7 +26,7 @@
Specify the release version.
```
-VERSION=2.11.0-rc1
+VERSION=2.11.0
```
Add your signing key to your Git configuration file, if not already there.
@@ -68,17 +68,12 @@ sed -i "s/Version: .*/Version: $VERSION/g" VERSION
## Changelog <a id="changelog"></a>
-Link to the milestone and closed=1 as filter.
+Choose the most important issues and summarize them in multiple groups/paragraphs. Provide links to the mentioned
+issues/PRs. At the start include a link to the milestone's closed issues.
-Manually update the best of collected from the
-milestone description.
## Git Tag <a id="git-tag"></a>
-> **Major Releases**: Commit these changes to the `master` branch.
->
-> **Minor Releases**: Commit changes to the `support` branch.
-
```
git commit -v -a -m "Release version $VERSION"
```
@@ -106,145 +101,142 @@ git checkout -b support/2.12
git push -u origin support/2.12
```
-**For minor releases:** Push the support branch, cherry-pick the release commit
-into master and merge the support branch:
+
+## Package Builds <a id="package-builds"></a>
```
-git push -u origin support/2.11
-git checkout master
-git cherry-pick support/2.11
-git merge --strategy=ours support/2.11
-git push origin master
+mkdir $HOME/dev/icinga/packaging
+cd $HOME/dev/icinga/packaging
```
-## Package Builds <a id="package-builds"></a>
-
### RPM Packages <a id="rpm-packages"></a>
```
-git clone git at github.com:icinga/rpm-icinga2.git && cd rpm-icinga2
+git clone git at git.icinga.com:icinga/rpm-icinga2.git && cd rpm-icinga2
```
-#### Branch Workflow
-
-**Major releases** are branched off `master`.
+### DEB Packages <a id="deb-packages"></a>
```
-git checkout master && git pull
+git clone git at git.icinga.com:packaging/deb-icinga2.git && cd deb-icinga2
```
-**Bugfix releases** are created in the `release` branch and later merged to master.
+#### Raspbian Packages
```
-git checkout release && git pull
+git clone git at git.icinga.com:icinga/raspbian-icinga2.git && cd raspbian-icinga2
```
-#### Release Commit
-
-Set the `Version`, `Revision` and `changelog` inside the spec file.
+### Windows Packages
```
-VERSION=2.11.0-rc1
+git clone git at git.icinga.com:icinga/windows-icinga2.git && cd windows-icinga2
+```
-sed -i "s/Version: .*/Version: $VERSION/g" icinga2.spec
-vim icinga2.spec
+### Branch Workflow
-%changelog
-* Tue Mar 19 2019 Michael Friedrich <michael.friedrich at icinga.com> 2.10.4-1
-- Update to 2.10.4
-```
+Checkout `master` and create a new branch.
-```
-git commit -av -m "Release $VERSION-1"
-git push
-```
+* For releases use x.x[.x] as branch name (e.g. 2.11 or 2.11.1)
+* For releases with revision use x.x.x-n (e.g. 2.11.0-2)
-**Note for major releases**: Update release branch to latest.
-```
-git checkout release && git pull && git merge master && git push
-```
+### Switch Build Type
-**Note for minor releases**: Cherry-pick the release commit into master.
+Edit file `.gitlab-ci.yml` and comment variable `ICINGA_BUILD_TYPE` out.
+```yaml
+variables:
+ ...
+ #ICINGA_BUILD_TYPE: snapshot
+ ...
```
-git checkout master && git pull && git cherry-pick release && git push
-```
-
-### DEB Packages <a id="deb-packages"></a>
+Commit the change.
```
-git clone git at github.com:icinga/deb-icinga2.git && cd deb-icinga2
+git commit -av -m "Switch build type for $VERSION-1"
```
-#### Branch Workflow
+#### RPM Release Preparations
-**Major releases** are branched off `master`.
+Set the `Version`, `revision` and `%changelog` inside the spec file:
```
-git checkout master && git pull
-```
+sed -i "s/Version:.*/Version: $VERSION/g" icinga2.spec
-**Bugfix releases** are created in the `release` branch and later merged to master.
+vim icinga2.spec
-```
-git checkout release && git pull
+%changelog
+* Thu Sep 19 2019 Michael Friedrich <michael.friedrich at icinga.com> 2.11.0-1
+- Update to 2.11.0
```
-#### Release Commit
+#### DEB and Raspbian Release Preparations
-Set the `Version`, `Revision` and `changelog` by using the `dch` helper.
+Update file `debian/changelog` and add at the beginning:
```
-VERSION=2.10.4
+icinga2 (2.11.0-1) icinga; urgency=medium
-./dch $VERSION-1 "Update to $VERSION"
-```
+ * Release 2.11.0
+ -- Michael Friedrich <michael.friedrich at icinga.com> Thu, 19 Sep 2019 10:50:31 +0200
```
-git commit -av -m "Release $VERSION-1"
-git push
-```
-**Note for major releases**: Update release branch to latest.
+### Release Commit
+
+Commit the changes and push the branch.
```
-git checkout release && git pull && git merge master && git push
+git commit -av -m "Release $VERSION-1"
+git push origin 2.11
```
-**Note for minor releases**: Cherry-pick the release commit into master.
+GitLab will now build snapshot packages based on the tag `v2.11.0` of Icinga 2.
-```
-git checkout master && git pull && git cherry-pick release && git push
-```
+### Package Tests
-#### DEB with dch on macOS
+In order to test the created packages you can download a job's artifacts:
-```
-docker run -v `pwd`:/mnt/packaging -ti ubuntu:bionic bash
+Visit [git.icinga.com](https://git.icinga.com/packaging/rpm-icinga2)
+and navigate to the respective pipeline under `CI / CD -> Pipelines`.
-apt-get update && apt-get install git ubuntu-dev-tools vim -y
-cd /mnt/packaging
+There click on the job you want to download packages from.
-git config --global user.name "Michael Friedrich"
-git config --global user.email "michael.friedrich at icinga.com"
+The job's output appears. On the right-hand sidebar you can browse its artifacts.
-VERSION=2.11.0-rc1
+Once there, navigate to `build/RPMS/noarch` where you'll find the packages.
-./dch $VERSION-1 "Update to $VERSION"
+### Release Packages
+
+To build release packages and upload them to [packages.icinga.com](https://packages.icinga.com)
+tag the release commit and push it.
+
+```
+git tag -s 2.11.0-1
+git push origin 2.11.0-1
```
+Now cherry pick the release commit to `master` so that the changes are transferred back to it.
+
+**Attention**: Only the release commit. *NOT* the one switching the build type!
+
+
+## Build Infrastructure <a id="build-infrastructure"></a>
-## Build Server <a id="build-server"></a>
+https://git.icinga.com/packaging/rpm-icinga2/pipelines
+https://git.icinga.com/packaging/deb-icinga2/pipelines
+https://git.icinga.com/packaging/windows-icinga2/pipelines
+https://git.icinga.com/packaging/raspbian-icinga2/pipelines
* Verify package build changes for this version.
* Test the snapshot packages for all distributions beforehand.
-* Build the newly created Git tag for Debian/RHEL/SuSE.
- * Wait until all jobs have passed and then publish them one by one with `allow_release`
-* Build the newly created Git tag for Windows: `refs/tags/v2.10.0` as source and `v2.10.0` as package name.
+
+Once the release repository tags are pushed, release builds
+are triggered and automatically published to packages.icinga.com
## Release Tests <a id="release-tests"></a>
@@ -259,28 +251,34 @@ VERSION=2.11.0-rc1
docker run -ti centos:latest bash
yum -y install https://packages.icinga.com/epel/icinga-rpm-release-7-latest.noarch.rpm
+yum -y install epel-release
yum -y install icinga2
icinga2 daemon -C
```
-### Debian
+### Ubuntu
```
-docker run -ti debian:stretch bash
+docker run -ti ubuntu:bionic bash
+
+apt-get update
+apt-get -y install apt-transport-https wget gnupg
-apt-get update && apt-get install -y wget curl gnupg apt-transport-https
+wget -O - https://packages.icinga.com/icinga.key | apt-key add -
-DIST=$(awk -F"[)(]+" '/VERSION=/ {print $2}' /etc/os-release); \
- echo "deb https://packages.icinga.com/debian icinga-${DIST} main" > \
+. /etc/os-release; if [ ! -z ${UBUNTU_CODENAME+x} ]; then DIST="${UBUNTU_CODENAME}"; else DIST="$(lsb_release -c| awk '{print $2}')"; fi; \
+ echo "deb https://packages.icinga.com/ubuntu icinga-${DIST} main" > \
/etc/apt/sources.list.d/${DIST}-icinga.list
- echo "deb-src https://packages.icinga.com/debian icinga-${DIST} main" >> \
+ echo "deb-src https://packages.icinga.com/ubuntu icinga-${DIST} main" >> \
/etc/apt/sources.list.d/${DIST}-icinga.list
-curl https://packages.icinga.com/icinga.key | apt-key add -
+apt-get update
+
apt-get -y install icinga2
-icinga2 daemon
+icinga2 daemon -C
```
+
## GitHub Release <a id="github-release"></a>
Create a new release for the newly created Git tag: https://github.com/Icinga/icinga2/releases
=====================================
VERSION
=====================================
@@ -1,2 +1,2 @@
-Version: 2.11.0
+Version: 2.11.1
Revision: 1
=====================================
doc/10-icinga-template-library.md
=====================================
@@ -2576,8 +2576,10 @@ proxysql\_ignore\_hostgroup | **Optional.** ProxySQL hostgroup(s) to ignore (on
#### memcached <a id="plugin-contrib-command-memcached"></a>
-The [check_memcached](https://packages.debian.org/stretch/nagios-plugins-contrib) plugin
-is provided by the `nagios-plugin-contrib` package on Debian/Ubuntu.
+The [check_memcached](https://exchange.icinga.com/exchange/check_memcached) plugin
+checks the health of a running [memcached](https://memcached.org/) service.
+
+On Debian/Ubuntu, it is provided with the `nagios-plugin-contrib` package.
Custom variables passed as [command parameters](03-monitoring-basics.md#command-passing-parameters):
=====================================
doc/14-features.md
=====================================
@@ -34,7 +34,7 @@ files then:
* `/var/log/icinga2/icinga2.log` (requires `mainlog` enabled)
* `/var/log/icinga2/debug.log` (requires `debuglog` enabled)
-* `/var/log/icinga2/erorr.log`
+* `/var/log/icinga2/error.log`
By default, log files will be rotated daily.
=====================================
doc/15-troubleshooting.md
=====================================
@@ -1374,7 +1374,7 @@ the following (e.g. by invoking a forced check from the web interface):
* `/var/log/icinga2/icinga2.log` shows connection and execution errors.
* The ApiListener is not enabled to [accept commands](06-distributed-monitoring.md#distributed-monitoring-top-down-command-endpoint). This is visible as `UNKNOWN` check result output.
- * `CheckCommand` definition not found on the remote client. This is visible as `UNKNWON` check result output.
+ * `CheckCommand` definition not found on the remote client. This is visible as `UNKNOWN` check result output.
* Referenced check plugin not found on the remote agent.
* Runtime warnings and errors, e.g. unresolved runtime macros or configuration problems.
* Specific error messages are also populated into `UNKNOWN` check results including a detailed error message in their output.
@@ -1393,6 +1393,56 @@ $ curl -k -s -u root:icinga -H 'Accept: application/json' -X POST 'https://local
```
+#### Agent Hosts with Command Endpoint require a Zone <a id="troubleshooting-cluster-command-endpoint-errors-agent-hosts-command-endpoint-zone"></a>
+
+2.11 fixes bugs where agent host checks would never be scheduled on
+the master. One requirement is that the checkable host/service
+is put into a zone.
+
+By default, the Director puts the agent host in `zones.d/master`
+and you're good to go. If you manually manage the configuration,
+the config compiler now throws an error with `command_endpoint`
+being set but no `zone` defined.
+
+In case you previously managed the configuration outside of `zones.d`,
+follow along with the following instructions.
+
+The most convenient way with e.g. managing the objects in `conf.d`
+is to move them into the `master` zone.
+
+First, verify the name of your endpoint's zone. The CLI wizards
+use `master` by default.
+
+```
+vim /etc/icinga2/zones.conf
+
+object Zone "master" {
+ ...
+}
+```
+
+Then create a new directory in `zones.d` called `master`, if not existing.
+
+```
+mkdir -p /etc/icinga2/zones.d/master
+```
+
+Now move the directory tree from `conf.d` into the `master` zone.
+
+```
+mv conf.d/* /etc/icinga2/zones.d/master/
+```
+
+Validate the configuration and reload Icinga.
+
+```
+icinga2 daemon -C
+systemctl restart icinga2
+```
+
+Another method is to specify the `zone` attribute manually, but since
+this may lead into other unwanted "not checked" scenarios, we don't
+recommend this for your production environment.
### Cluster Troubleshooting Config Sync <a id="troubleshooting-cluster-config-sync"></a>
@@ -1485,6 +1535,150 @@ In order to solve this problem, remove the mentioned files from `zones.d` and us
of syncing plugin binaries to your satellites and agents.
+#### Zones in Zones doesn't work <a id="troubleshooting-cluster-config-zones-in-zones"></a>
+
+The cluster config sync works in the way that configuration
+put into `/etc/icinga2/zones.d` only is included when configured
+outside in `/etc/icinga2/zones.conf`.
+
+If you for example create a "Zone Inception" with defining the
+`satellite` zone in `zones.d/master`, the config compiler does not
+re-run and include this zone config recursively from `zones.d/satellite`.
+
+Since v2.11, the config compiler is only including directories where a
+zone has been configured. Otherwise it would include renamed old zones,
+broken zones, etc. and those long-lasting bugs have been now fixed.
+
+A more concrete example: Masters and Satellites still need to know the Zone hierarchy outside of zones.d synced configuration.
+
+**Doesn't work**
+
+```
+vim /etc/icinga2/zones.conf
+
+object Zone "master" {
+ endpoints = [ "icinga2-master1.localdomain", "icinga2-master2.localdomain" ]
+}
+```
+
+```
+vim /etc/icinga2/zones.d/master/satellite-zones.conf
+
+object Zone "satellite" {
+ endpoints = [ "icinga2-satellite1.localdomain", "icinga2-satellite1.localdomain" ]
+}
+```
+
+```
+vim /etc/icinga2/zones.d/satellite/satellite-hosts.conf
+
+object Host "agent" { ... }
+```
+
+The `agent` host object will never reach the satellite, since the master does not have
+the `satellite` zone configured outside of zones.d.
+
+
+**Works**
+
+Each instance needs to know this, and know about the endpoints first:
+
+```
+vim /etc/icinga2/zones.conf
+
+object Endpoint "icinga2-master1.localdomain" { ... }
+object Endpoint "icinga2-master2.localdomain" { ... }
+
+object Endpoint "icinga2-satellite1.localdomain" { ... }
+object Endpoint "icinga2-satellite2.localdomain" { ... }
+```
+
+Then the zone hierarchy as trust and also config sync inclusion is required.
+
+```
+vim /etc/icinga2/zones.conf
+
+object Zone "master" {
+ endpoints = [ "icinga2-master1.localdomain", "icinga2-master2.localdomain" ]
+}
+
+object Zone "satellite" {
+ endpoints = [ "icinga2-satellite1.localdomain", "icinga2-satellite1.localdomain" ]
+}
+```
+
+Once done, you can start deploying actual monitoring objects into the satellite zone.
+
+```
+vim /etc/icinga2/zones.d/satellite/satellite-hosts.conf
+
+object Host "agent" { ... }
+```
+
+That's also explained and described in the [documentation](06-distributed-monitoring.md#distributed-monitoring-scenarios-master-satellite-agents).
+
+The thing you can do: For `command_endpoint` agents like inside the Director:
+Host -> Agent -> yes, there is no config sync for this zone in place. Therefore
+it is valid to just sync their zones via the config sync.
+
+#### Director Changes
+
+The following restores the Zone/Endpoint objects as config objects outside of `zones.d`
+in your master/satellite's zones.conf with rendering them as external objects in the Director.
+
+[Example](06-distributed-monitoring.md#three-levels-with-masters-satellites-and-agents)
+for a 3 level setup with the masters and satellites knowing about the zone hierarchy
+outside defined in [zones.conf](#zones-conf):
+
+```
+object Endpoint "icinga-master1.localdomain" {
+ //define 'host' attribute to control the connection direction on each instance
+}
+
+object Endpoint "icinga-master2.localdomain" {
+ //...
+}
+
+object Endpoint "icinga-satellite1.localdomain" {
+ //...
+}
+
+object Endpoint "icinga-satellite2.localdomain" {
+ //...
+}
+
+//--------------
+// Zone hierarchy with endpoints, required for the trust relationship and that the cluster config sync knows which zone directory defined in zones.d needs to be synced to which endpoint.
+// That's no different to what is explained in the docs as basic zone trust hierarchy, and is intentionally managed outside in zones.conf there.
+
+object Zone "master" {
+ endpoints = [ "icinga-master1.localdomain", "icinga-master2.localdomain" ]
+}
+
+object Zone "satellite" {
+ endpoints = [ "icinga-satellite1.localdomain", "icinga-satellite2.localdomain" ]
+ parent = "master" // trust
+}
+```
+
+Prepare the above configuration on all affected nodes, satellites are likely uptodate already.
+Then continue with the steps below.
+
+> * backup your database, just to be on the safe side
+> * create all non-external Zone/Endpoint-Objects on all related Icinga Master/Satellite-Nodes (manually in your local zones.conf)
+> * while doing so please do NOT restart Icinga, no deployments
+> * change the type in the Director DB:
+>
+> ```sql
+> UPDATE icinga_zone SET object_type = 'external_object' WHERE object_type = 'object';
+> UPDATE icinga_endpoint SET object_type = 'external_object' WHERE object_type = 'object';
+> ```
+>
+> * render and deploy a new configuration in the Director. It will state that there are no changes. Ignore it, deploy anyways
+>
+> That's it. All nodes should automatically restart, triggered by the deployed configuration via cluster protocol.
+
+
### Cluster Troubleshooting Overdue Check Results <a id="troubleshooting-cluster-check-results"></a>
If your master does not receive check results (or any other events) from the child zones
=====================================
doc/16-upgrading-icinga-2.md
=====================================
@@ -29,14 +29,22 @@ The rewrite of our core network stack for cluster and REST API
requires newer Boost versions, specifically >= 1.66. For technical
details, please continue reading in [this issue](https://github.com/Icinga/icinga2/issues/7041).
-The package dependencies have been updated for RPM/DEB already.
-On platforms where EPEL or Backports cannot satisfy this dependency,
-we provide Boost as package on our [package repository](https://packages.icinga.com):
+Distribution | Repository providing Boost Dependencies
+---------------------|-------------------------------------
+RHEL/CentOS 7 | [EPEL repository](02-installation.md#package-repositories-rhel-epel)
+RHEL/CentOS 6 x64 | [packages.icinga.com](https://packages.icinga.com)
+Fedora | Fedora Upstream
+Debian 10 Buster | Debian Upstream
+Debian 9 Stretch | [Backports repository](02-installation.md#package-repositories-debian-backports) **New since 2.11**
+Debian 8 Jessie | [packages.icinga.com](https://packages.icinga.com)
+Ubuntu 18 Bionic | [packages.icinga.com](https://packages.icinga.com)
+Ubuntu 16 Xenial | [packages.icinga.com](https://packages.icinga.com)
+SLES 15 | SUSE Upstream
+SLES 12 | [packages.icinga.com](https://packages.icinga.com) (replaces the SDK repository requirement)
-* SLES 12 (this replaces the SDK requirement)
-* CentOS 6 x64
-* Debian Jessie
-* Ubuntu Xenial/Bionic
+On platforms where EPEL or Backports cannot satisfy this dependency,
+we provide Boost as package on our [package repository](https://packages.icinga.com)
+for your convenience.
After upgrade, you may remove the old Boost packages (1.53 or anything above)
if you don't need them anymore.
@@ -144,6 +152,22 @@ please let us know with an issue on GitHub.
### Cluster <a id="upgrading-to-2-11-cluster"></a>
+#### Agent Hosts with Command Endpoint require a Zone <a id="upgrading-to-2-11-cluster-agent-hosts-command-endpoint-zone"></a>
+
+2.11 fixes bugs where agent host checks would never be scheduled on
+the master. One definite requirement is that the checkable host/service
+is put into a zone.
+
+By default, the Director puts the agent host in `zones.d/master`
+and you're good to go. If you manually manage the configuration,
+the config compiler now throws an error with `command_endpoint`
+being set but no `zone` defined.
+
+The most convenient way with e.g. managing the objects in `conf.d`
+is to move them into the `master` zone. Please continue in the
+[troubleshooting docs](#troubleshooting-cluster-command-endpoint-errors-agent-hosts-command-endpoint-zone)
+for further instructions.
+
#### Config Sync <a id="upgrading-to-2-11-cluster-config-sync"></a>
2.11 overhauls the cluster config sync in many ways. This includes the
@@ -186,6 +210,22 @@ and trigger reload loops. In order to prevent such harm in production,
use infrastructure tools such as Foreman, Puppet, Ansible, etc. to install
plugins on the masters, satellites and agents.
+##### Config Sync: Zones in Zones <a id="upgrading-to-2-11-cluster-config-sync-zones-in-zones"></a>
+
+The cluster config sync works in the way that configuration
+put into `/etc/icinga2/zones.d` only is included when configured
+outside in `/etc/icinga2/zones.conf`.
+
+If you for example create a "Zone Inception" with defining the
+`satellite` zone in `zones.d/master`, the config compiler does not
+re-run and include this zone config recursively from `zones.d/satellite`.
+
+Since v2.11, the config compiler is only including directories where a
+zone has been configured. Otherwise it would include renamed old zones,
+broken zones, etc. and those long-lasting bugs have been now fixed.
+
+Please consult the [troubleshoot docs](15-troubleshooting.md#troubleshooting-cluster-config-zones-in-zones)
+for concrete examples and solutions.
#### HA-aware Features <a id="upgrading-to-2-11-cluster-ha-aware-features"></a>
=====================================
etc/icinga2/zones.d/README
=====================================
@@ -1,2 +1,2 @@
-This directory contains configuration files for cluster zones. If you're not
-running a cluster you can safely ignore this directory.
+Please check the documentation for more details:
+https://icinga.com/docs/icinga2/latest/doc/06-distributed-monitoring/
=====================================
lib/config/expression.cpp
=====================================
@@ -560,7 +560,7 @@ void WarnOnImplicitlySetGlobalVar(const std::unique_ptr<Expression>& setLhs, con
if (var && setLhsParent.IsObject()) {
auto ns (dynamic_pointer_cast<Namespace>(setLhsParent.Get<Object::Ptr>()));
- if (ns && ns == ScriptGlobal::GetGlobals()) {
+ if (ns && ns == ScriptGlobal::GetGlobals() && debug.Path.GetLength()) {
const char *opStr = nullptr;
switch (setOp) {
=====================================
lib/icinga/checkable.cpp
=====================================
@@ -53,7 +53,7 @@ void Checkable::OnAllConfigLoaded()
}
} else {
BOOST_THROW_EXCEPTION(ValidationError(this, { "command_endpoint" },
- "Command endpoint must not be set."));
+ "Checkable with command endpoint requires a zone. Please check the troubleshooting documentation."));
}
}
}
=====================================
lib/remote/apilistener-filesync.cpp
=====================================
@@ -450,6 +450,10 @@ Value ApiListener::ConfigUpdateHandler(const MessageOrigin::Ptr& origin, const D
<< "Stage: Updating received configuration file '" << path << "' for zone '" << zoneName << "'.";
}
+ // Parent nodes < 2.11 always send this, avoid this bug and deny its receival prior to writing it on disk.
+ if (Utility::BaseName(path) == ".authoritative")
+ continue;
+
// Sync string content only.
String content = kv.second;
View it on GitLab: https://salsa.debian.org/nagios-team/pkg-icinga2/commit/bc1653db9a747b279177bfce19ca794f12372a9b
--
View it on GitLab: https://salsa.debian.org/nagios-team/pkg-icinga2/commit/bc1653db9a747b279177bfce19ca794f12372a9b
You're receiving this email because of your account on salsa.debian.org.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/pkg-nagios-changes/attachments/20191018/3c4e9631/attachment-0001.html>
More information about the pkg-nagios-changes
mailing list