From 77851c0a48c1a85b4d855e12fdf3691d79f32708 Mon Sep 17 00:00:00 2001
From: Michael Friedrich <michael.friedrich@icinga.com>
Date: Wed, 15 Nov 2017 11:10:52 +0100
Subject: [PATCH] Fix wrong anchors in the documentation
refs #5732
---
doc/06-distributed-monitoring.md | 4 ++--
doc/08-advanced-topics.md | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/doc/06-distributed-monitoring.md b/doc/06-distributed-monitoring.md
index 63cc15230..b90f0aae0 100644
--- a/doc/06-distributed-monitoring.md
+++ b/doc/06-distributed-monitoring.md
@@ -258,7 +258,7 @@ that all nodes trust each other in a distributed monitoring environment.
This CA is generated during the [master setup](06-distributed-monitoring.md#distributed-monitoring-setup-master)
and should be the same on all master instances.
-You can avoid signing and deploying certificates [manually](#06-distributed-monitoring.md#distributed-monitoring-advanced-hints-certificates)
+You can avoid signing and deploying certificates [manually](06-distributed-monitoring.md#distributed-monitoring-advanced-hints-certificates-manual)
by using built-in methods for auto-signing certificate signing requests (CSR):
* [CSR Auto-Signing](06-distributed-monitoring.md#distributed-monitoring-setup-csr-auto-signing) which uses a client ticket generated on the master as trust identifier.
@@ -1575,7 +1575,7 @@ Specify the master node `icinga2-master2.localdomain` with the CA private key an
Port [5665]:
In case you cannot connect to the master node from your clients, you'll manually need
-to [generate the SSL certificates](06-distributed-monitoring.md#distributed-monitoring-advanced-hints-certificates)
+to [generate the SSL certificates](06-distributed-monitoring.md#distributed-monitoring-advanced-hints-certificates-manual)
and modify the configuration accordingly.
We'll discuss the details of the required configuration below.
diff --git a/doc/08-advanced-topics.md b/doc/08-advanced-topics.md
index a5060ba7e..0b130a0ef 100644
--- a/doc/08-advanced-topics.md
+++ b/doc/08-advanced-topics.md
@@ -433,7 +433,7 @@ host or service is considered flapping until it drops below the low flapping thr
> Note: There is no distinctions between hard and soft states with flapping. All state changes count and notifications
> will be sent out regardless of the objects state.
-### How it works <a id="how-it-works"></a>
+### How it works <a id="check-flapping-how-it-works"></a>
Icinga 2 saves the last 20 state changes for every host and service. See the graphic below:
@@ -450,7 +450,7 @@ considered flapping.
If the next seven check results then would not be state changes, the flapping percentage would fall below the lower threshold
of 25% and therefore the host or service would recover from flapping.
-# Volatile Services <a id="volatile-services"></a>
+## Volatile Services <a id="volatile-services"></a>
By default all services remain in a non-volatile state. When a problem
occurs, the `SOFT` state applies and once `max_check_attempts` attribute