Update documentation

diff --git a/doc/12-troubleshooting.md b/doc/12-troubleshooting.md
index b86e08e4961ccd80459aee407ab691917ab6072d..9d7d717b99b0ee24708fc8bee15c2d90b4bd858e 100644 (file)
--- a/doc/12-troubleshooting.md
+++ b/doc/12-troubleshooting.md
@@ -109,7 +109,7 @@ or similar.
 * Check the debug log to see if the check command gets executed
 * Verify that failed depedencies do not prevent command execution
 * Make sure that the plugin is executable by the Icinga 2 user (run a manual test)
-* Make sure the [checker](8-cli-commands.md#features) feature is enabled.
+* Make sure the [checker](7-cli-commands.md#features) feature is enabled.
 
 Examples:
 
@@ -131,7 +131,7 @@ Verify the following configuration
 * Do the notification attributes `states`, `types`, `period` match the notification conditions?
 * Do the user attributes `states`, `types`, `period` match the notification conditions?
 * Are there any notification `begin` and `end` times configured?
-* Make sure the [notification](8-cli-commands.md#features) feature is enabled.
+* Make sure the [notification](7-cli-commands.md#features) feature is enabled.
 * Does the referenced NotificationCommand work when executed as Icinga user on the shell?
 
 If notifications are to be sent via mail make sure that the mail program specified exists.
@@ -164,7 +164,7 @@ or modify these attributes in the current object.
 
 ## <a id="troubleshooting-cluster"></a> Cluster Troubleshooting
 
-You should configure the [cluster health checks](7-monitoring-remote-systems.md#cluster-health-check) if you haven't
+You should configure the [cluster health checks](8-monitoring-remote-systems.md#cluster-health-check) if you haven't
 done so already.
 
 > **Note**
@@ -218,7 +218,7 @@ If the cluster zones do not sync their configuration, make sure to check the fol
 * Within a config master zone, only one configuration master is allowed to have its config in `/etc/icinga2/zones.d`.
 ** The master syncs the configuration to `/var/lib/icinga2/api/zones/` during startup and only syncs valid configuration to the other nodes
 ** The other nodes receive the configuration into `/var/lib/icinga2/api/zones/`
-* The `icinga2.log` log file will indicate whether this ApiListener [accepts config](7-monitoring-remote-systems.md#zone-config-sync-permissions), or not
+* The `icinga2.log` log file will indicate whether this ApiListener [accepts config](8-monitoring-remote-systems.md#zone-config-sync-permissions), or not
 
 
 ## <a id="debug"></a> Debug Icinga 2

diff --git a/doc/14-migrating-from-icinga-1x.md b/doc/14-migrating-from-icinga-1x.md
index 550b285a6a8da0be2c0cd6db7ca229d9f1846c33..890e8273693d57cdf1aa5594932f774367aa6b26 100644 (file)
--- a/doc/14-migrating-from-icinga-1x.md
+++ b/doc/14-migrating-from-icinga-1x.md
@@ -721,9 +721,9 @@ daemon for passing check results between instances.
 * Icinga 2 does not support any 1.x NEB addons for check load distribution
 
 * If your current setup consists of instances distributing the check load, you should consider
-building a [load distribution](7-monitoring-remote-systems.md#cluster-scenarios-load-distribution) setup with Icinga 2.
+building a [load distribution](8-monitoring-remote-systems.md#cluster-scenarios-load-distribution) setup with Icinga 2.
 * If your current setup includes active/passive clustering with external tools like Pacemaker/DRBD
-consider the [High Availability](7-monitoring-remote-systems.md#cluster-scenarios-high-availability) setup.
+consider the [High Availability](8-monitoring-remote-systems.md#cluster-scenarios-high-availability) setup.
 * If you have build your own custom configuration deployment and check result collecting mechanism
 you should re-design your setup and re-evaluate your requirements, and how they may be fulfilled
 using the Icinga 2 cluster capabilities.
@@ -777,7 +777,7 @@ Icinga 2 only uses a small set of [global constants](15-language-reference.md#co
 you to specify certain different setting such as the `NodeName` in a cluster scenario.
 
 Aside from that, the [icinga2.conf](4-configuring-icinga-2.md#icinga2-conf) should take care of including
-global constants, enabled [features](8-cli-commands.md#features) and the object configuration.
+global constants, enabled [features](7-cli-commands.md#features) and the object configuration.
 
 ### <a id="differences-1x-2-include-files-dirs"></a> Include Files and Directories
 
@@ -1436,7 +1436,7 @@ Unlike Icinga 1.x the Icinga 2 daemon reload happens asynchronously.
 * parent process continues with old configuration objects and the event scheduling
 (doing checks, replicating cluster events, triggering alert notifications, etc.)
 * validation NOT ok: child process terminates, parent process continues with old configuration state
-(this is ESSENTIAL for the [cluster config synchronisation](7-monitoring-remote-systems.md#cluster-zone-config-sync))
+(this is ESSENTIAL for the [cluster config synchronisation](8-monitoring-remote-systems.md#cluster-zone-config-sync))
 * validation ok: child process signals parent process to terminate and save its current state
 (all events until now) into the icinga2 state file
 * parent process shuts down writing icinga2.state file
@@ -1491,6 +1491,6 @@ distribution out-of-the-box. Furthermore comments, downtimes, and other stateful
 not synced between the master and slave nodes. There are addons available solving the check
 and configuration distribution problems Icinga 1.x distributed monitoring currently suffers from.
 
-Icinga 2 implements a new built-in [distributed monitoring architecture](7-monitoring-remote-systems.md#distributed-monitoring-high-availability),
+Icinga 2 implements a new built-in [distributed monitoring architecture](8-monitoring-remote-systems.md#distributed-monitoring-high-availability),
 including config and check distribution, IPv4/IPv6 support, SSL certificates and zone support for DMZ.
 High Availability and load balancing are also part of the Icinga 2 Cluster setup.

diff --git a/doc/15-language-reference.md b/doc/15-language-reference.md
index ab3affd441848b0cf2cecbe3f8ae1494bf89ec02..76c73d8b00c6c29b34ee12bfb723ef5896c4e41a 100644 (file)
--- a/doc/15-language-reference.md
+++ b/doc/15-language-reference.md
@@ -487,7 +487,7 @@ Note the use of angle brackets instead of double quotes. This causes the
 config compiler to search the include search paths for the specified
 file. By default $PREFIX/share/icinga2/include is included in the list of search
 paths. Additional include search paths can be added using
-[command-line options](8-cli-commands.md#config-include-path).
+[command-line options](7-cli-commands.md#config-include-path).
 
 Wildcards are not permitted when using angle brackets.
 

diff --git a/doc/2-getting-started.md b/doc/2-getting-started.md
index 87e9bae52566e84bf200d1d0fbc0889875c2202d..6bf32cfd0792f8984c4f5e6704b18826222c148e 100644 (file)
--- a/doc/2-getting-started.md
+++ b/doc/2-getting-started.md
@@ -112,7 +112,7 @@ Icinga 2 installation:
 * `notification` for sending notifications
 * `mainlog` for writing the `icinga2.log` file
 
-You can verify that by calling `icinga2 feature list` [CLI command](8-cli-commands.md#cli-command-feature)
+You can verify that by calling `icinga2 feature list` [CLI command](7-cli-commands.md#cli-command-feature)
 to see which features are enabled and disabled.
 
     # icinga2 feature list
@@ -491,7 +491,7 @@ The `systemctl` command supports the following actions:
   status              | The `status` action checks if Icinga 2 is running.
   enable              | The `enable` action enables the service being started at system boot time (similar to `chkconfig`)
 
-If you're stuck with configuration errors, you can manually invoke the [configuration validation](8-cli-commands.md#config-validation).
+If you're stuck with configuration errors, you can manually invoke the [configuration validation](7-cli-commands.md#config-validation).
 
     # systemctl enable icinga2
 

diff --git a/doc/3-monitoring-basics.md b/doc/3-monitoring-basics.md
index b8c0f26280d180d0e85112e02b8738eed1862c63..461ca6604d49c0d945d2a7c059fc8ac09731efde 100644 (file)
--- a/doc/3-monitoring-basics.md
+++ b/doc/3-monitoring-basics.md
@@ -248,8 +248,8 @@ dictionaries](#using-apply-for) for example provided by
 > **Tip**
 >
 > Building configuration in that dynamic way requires detailed information
-> of the generated objects. Use the `object list` [CLI command](8-cli-commands.md#cli-command-object)
-> after successful [configuration validation](8-cli-commands.md#config-validation).
+> of the generated objects. Use the `object list` [CLI command](7-cli-commands.md#cli-command-object)
+> after successful [configuration validation](7-cli-commands.md#config-validation).
 
 
 #### <a id="using-apply-expressions"></a> Apply Rules Expressions
@@ -437,8 +437,8 @@ This can be achieved by wrapping them into the [string()](15-language-reference.
 > **Tip**
 >
 > Building configuration in that dynamic way requires detailed information
-> of the generated objects. Use the `object list` [CLI command](8-cli-commands.md#cli-command-object)
-> after successful [configuration validation](8-cli-commands.md#config-validation).
+> of the generated objects. Use the `object list` [CLI command](7-cli-commands.md#cli-command-object)
+> after successful [configuration validation](7-cli-commands.md#config-validation).
 
 
 #### <a id="using-apply-object attributes"></a> Use Object Attributes in Apply Rules
@@ -594,7 +594,7 @@ Details on troubleshooting notification problems can be found [here](12-troubles
 
 > **Note**
 >
-> Make sure that the [notification](8-cli-commands.md#features) feature is enabled on your master instance
+> Make sure that the [notification](7-cli-commands.md#features) feature is enabled on your master instance
 > in order to execute notification commands.
 
 You should choose which information you (and your notified users) are interested in
@@ -895,7 +895,7 @@ using the `check_command` attribute.
 
 > **Note**
 >
-> Make sure that the [checker](8-cli-commands.md#features) feature is enabled in order to
+> Make sure that the [checker](7-cli-commands.md#features) feature is enabled in order to
 > execute checks.
 
 #### <a id="command-plugin-integration"></a> Integrate the Plugin with a CheckCommand Definition
@@ -1156,7 +1156,7 @@ interfaces (E-Mail, XMPP, IRC, Twitter, etc).
 
 > **Note**
 >
-> Make sure that the [notification](8-cli-commands.md#features) feature is enabled on your master instance
+> Make sure that the [notification](7-cli-commands.md#features) feature is enabled on your master instance
 > in order to execute notification commands.
 
 Below is an example using runtime macros from Icinga 2 (such as `$service.output$` for
@@ -2437,7 +2437,7 @@ chapter. Details on the configuration can be found in the
 [IdoMysqlConnection](5-object-types.md#objecttype-idomysqlconnection) and
 [IdoPgsqlConnection](5-object-types.md#objecttype-idopgsqlconnection)
 object configuration documentation.
-The DB IDO feature supports [High Availability](7-monitoring-remote-systems.md#high-availability-db-ido) in
+The DB IDO feature supports [High Availability](8-monitoring-remote-systems.md#high-availability-db-ido) in
 the Icinga 2 cluster.
 
 The following example query checks the health of the current Icinga 2 instance

diff --git a/doc/4-configuring-icinga-2.md b/doc/4-configuring-icinga-2.md
index 355f0d309beb8767fdd188721bf7b7e4f84fb957..2cf975102ab6644cb13af318a3927f2d4316a4a4 100644 (file)
--- a/doc/4-configuring-icinga-2.md
+++ b/doc/4-configuring-icinga-2.md
@@ -1,5 +1,12 @@
 # <a id="configuring-icinga2-first-steps"></a> Configuring Icinga 2: First Steps
 
+This chapter prodides an introduction to the configuration files which are automatically created
+when installing the Icinga 2 packages.
+
+If you're interested in a detailed explanation of each language feature used in those
+configuration files you can find more information in the [Language Reference](15-language-reference.md#language-reference)
+chapter.
+
 ## <a id="icinga2-conf"></a> icinga2.conf
 
 An example configuration file is installed for you in `/etc/icinga2/icinga2.conf`.
@@ -49,7 +56,7 @@ The `include` directive can be used to include other files.
 
 This `include` directive takes care of including the configuration files for all
 the features which have been enabled with `icinga2 feature enable`. See
-[Enabling/Disabling Features](8-cli-commands.md#features) for more details.
+[Enabling/Disabling Features](7-cli-commands.md#features) for more details.
 
     /**
      * The repository.d directory contains all configuration objects
@@ -59,7 +66,7 @@ the features which have been enabled with `icinga2 feature enable`. See
 
 This `include_recursive` directive is used for discovery of services on remote clients
 and their generated configuration described in
-[this chapter](7-monitoring-remote-systems.md#icinga2-remote-monitoring-master-discovery-generate-config).
+[this chapter](8-monitoring-remote-systems.md#icinga2-remote-monitoring-master-discovery-generate-config).
 
 
     /**
@@ -586,8 +593,8 @@ objects such as hosts, services or notifications.
 
 ### <a id="satellite-conf"></a> satellite.conf
 
-Ships default templates and dependencies for [monitoring remote clients](7-monitoring-remote-systems.md#icinga2-remote-client-monitoring)
-using service discovery and [config generation](7-monitoring-remote-systems.md#icinga2-remote-monitoring-master-discovery-generate-config)
+Ships default templates and dependencies for [monitoring remote clients](8-monitoring-remote-systems.md#icinga2-remote-client-monitoring)
+using service discovery and [config generation](8-monitoring-remote-systems.md#icinga2-remote-monitoring-master-discovery-generate-config)
 on the master. Can be ignored/removed on setups not using this features.
 
 

diff --git a/doc/5-object-types.md b/doc/5-object-types.md
index 59f6fd13c107962036f939edc936d7a51b2e71b2..4c08c4272492db999665573a13f0aa13748727b8 100644 (file)
--- a/doc/5-object-types.md
+++ b/doc/5-object-types.md
@@ -805,8 +805,8 @@ Attributes:
   table\_prefix   |**Optional.** MySQL database table prefix. Defaults to "icinga\_".
   instance\_name  |**Optional.** Unique identifier for the local Icinga 2 instance. Defaults to "default".
   instance\_description|**Optional.** Description for the Icinga 2 instance.
-  enable_ha       |**Optional.** Enable the high availability functionality. Only valid in a [cluster setup](7-monitoring-remote-systems.md#high-availability-db-ido). Defaults to "true".
-  failover_timeout | **Optional.** Set the failover timeout in a [HA cluster](7-monitoring-remote-systems.md#high-availability-db-ido). Must not be lower than 60s. Defaults to "60s".
+  enable_ha       |**Optional.** Enable the high availability functionality. Only valid in a [cluster setup](8-monitoring-remote-systems.md#high-availability-db-ido). Defaults to "true".
+  failover_timeout | **Optional.** Set the failover timeout in a [HA cluster](8-monitoring-remote-systems.md#high-availability-db-ido). Must not be lower than 60s. Defaults to "60s".
   cleanup         |**Optional.** Dictionary with items for historical table cleanup.
   categories      |**Optional.** The types of information that should be written to the database.
 
@@ -894,8 +894,8 @@ Attributes:
   table\_prefix   |**Optional.** PostgreSQL database table prefix. Defaults to "icinga\_".
   instance\_name  |**Optional.** Unique identifier for the local Icinga 2 instance. Defaults to "default".
   instance\_description|**Optional.** Description for the Icinga 2 instance.
-  enable_ha       |**Optional.** Enable the high availability functionality. Only valid in a [cluster setup](7-monitoring-remote-systems.md#high-availability-db-ido). Defaults to "true".
-  failover_timeout | **Optional.** Set the failover timeout in a [HA cluster](7-monitoring-remote-systems.md#high-availability-db-ido). Must not be lower than 60s. Defaults to "60s".
+  enable_ha       |**Optional.** Enable the high availability functionality. Only valid in a [cluster setup](8-monitoring-remote-systems.md#high-availability-db-ido). Defaults to "true".
+  failover_timeout | **Optional.** Set the failover timeout in a [HA cluster](8-monitoring-remote-systems.md#high-availability-db-ido). Must not be lower than 60s. Defaults to "60s".
   cleanup         |**Optional.** Dictionary with items for historical table cleanup.
   categories      |**Optional.** The types of information that should be written to the database.
 

diff --git a/doc/8-cli-commands.md b/doc/7-cli-commands.md
similarity index 97%
rename from doc/8-cli-commands.md
rename to doc/7-cli-commands.md
index f30786b889cd9e12616da695a305191314fee2c3..2912e88c288c9a94269bf24da49060a15c44864f 100644 (file)
--- a/doc/8-cli-commands.md
+++ b/doc/7-cli-commands.md
@@ -132,7 +132,7 @@ added.
 ### <a id="cli-command-daemon"></a> CLI command: Daemon
 
 The CLI command `daemon` provides the functionality to start/stop Icinga 2.
-Furthermore it provides the [configuration validation](8-cli-commands.md#config-validation).
+Furthermore it provides the [configuration validation](7-cli-commands.md#config-validation).
 
     # icinga2 daemon --help
     icinga2 - The Icinga 2 network monitoring daemon (version: v2.1.1-299-gf695275)
@@ -176,7 +176,7 @@ Icinga 2 automatically falls back to using the configuration file
 
 The `--validate` option can be used to check if your configuration files
 contain errors. If any errors are found the exit status is 1, otherwise 0
-is returned. More details in the [configuration validation](8-cli-commands.md#config-validation) chapter.
+is returned. More details in the [configuration validation](7-cli-commands.md#config-validation) chapter.
 
 
 ### <a id="cli-command-feature"></a> CLI command: Feature
@@ -195,8 +195,8 @@ feature will only bring up all enabled features.
 ### <a id="cli-command-node"></a> CLI command: Node
 
 Provides the functionality to install and manage master and client
-nodes in a [remote monitoring ](7-monitoring-remote-systems.md#icinga2-remote-client-monitoring) or
-[distributed cluster](7-monitoring-remote-systems.md#distributed-monitoring-high-availability) scenario.
+nodes in a [remote monitoring ](8-monitoring-remote-systems.md#icinga2-remote-client-monitoring) or
+[distributed cluster](8-monitoring-remote-systems.md#distributed-monitoring-high-availability) scenario.
 
 
     # icinga2 node --help
@@ -281,7 +281,7 @@ Provides the CLI commands to
 * request a signed certificate from the master
 * generate a new ticket for the client setup
 
-This functionality is used by the [node setup/wizard](8-cli-commands.md#cli-command-pki) CLI commands too.
+This functionality is used by the [node setup/wizard](7-cli-commands.md#cli-command-pki) CLI commands too.
 
     # icinga2 pki --help
     icinga2 - The Icinga 2 network monitoring daemon (version: v2.1.1-299-gf695275)
@@ -370,7 +370,7 @@ cleared after review.
 
 ### <a id="cli-command-variable"></a> CLI command: Variable
 
-Lists all configured variables (constants) in a similar fasion like [object list](8-cli-commands.md#cli-command-object).
+Lists all configured variables (constants) in a similar fasion like [object list](7-cli-commands.md#cli-command-object).
 
     # icinga2 variable --help
     icinga2 - The Icinga 2 network monitoring daemon (version: v2.1.1-299-gf695275)
@@ -406,7 +406,7 @@ Lists all configured variables (constants) in a similar fasion like [object list
 Icinga 2 provides configuration files for some commonly used features. These
 are installed in the `/etc/icinga2/features-available` directory and can be
 enabled and disabled using the `icinga2 feature enable` and `icinga2 feature disable`
-[CLI commands](8-cli-commands.md#cli-command-feature), respectively.
+[CLI commands](7-cli-commands.md#cli-command-feature), respectively.
 
 The `icinga2 feature enable` CLI command creates symlinks in the
 `/etc/icinga2/features-enabled` directory which is included by default
@@ -486,7 +486,7 @@ Or manually passing the `-C` argument:
 If you encouter errors during configuration validation, please make sure
 to read the [troubleshooting](12-troubleshooting.md#troubleshooting) chapter.
 
-You can also use the [CLI command](8-cli-commands.md#cli-command-object) `icinga2 object list`
+You can also use the [CLI command](7-cli-commands.md#cli-command-object) `icinga2 object list`
 after validation passes to analyze object attributes, inheritance or created
 objects by apply rules.
 Find more on troubleshooting with `object list` in [this chapter](12-troubleshooting.md#list-configuration-objects).
@@ -522,7 +522,7 @@ Example filtered by `Service` objects with the name `ping*`:
 ## <a id="config-change-reload"></a> Reload on Configuration Changes
 
 Everytime you have changed your configuration you should first tell Icinga 2
-to [validate](8-cli-commands.md#config-validation). If there are no validation errors you can
+to [validate](7-cli-commands.md#config-validation). If there are no validation errors you can
 safely reload the Icinga 2 daemon.
 
     # /etc/init.d/icinga2 reload

diff --git a/doc/7-monitoring-remote-systems.md b/doc/8-monitoring-remote-systems.md
similarity index 93%
rename from doc/7-monitoring-remote-systems.md
rename to doc/8-monitoring-remote-systems.md
index b2f3779fec2f3a16b279499b85e2071c45132a61..fa9d0b7980ca057ec73e49c10238f664157cfa6f 100644 (file)
--- a/doc/7-monitoring-remote-systems.md
+++ b/doc/8-monitoring-remote-systems.md
@@ -1,17 +1,17 @@
 # <a id="monitoring-remote-systems"></a> Monitoring Remote Systems
 
-There are multiple ways you can monitor remote clients. Be it using [agent-less](7-monitoring-remote-systems.md#agent-less-checks)
+There are multiple ways you can monitor remote clients. Be it using [agent-less](8-monitoring-remote-systems.md#agent-less-checks)
 or [agent-based](agent-based-checks-addons) using additional addons & tools.
 
 Icinga 2 uses its own unique and secure communitication protol amongst instances.
 Be it an High-Availability cluster setup, distributed load-balanced setup or just a single
-agent [monitoring a remote client](7-monitoring-remote-systems.md#icinga2-remote-client-monitoring).
+agent [monitoring a remote client](8-monitoring-remote-systems.md#icinga2-remote-client-monitoring).
 
 All communication is secured by TLS with certificates, and fully supports IPv4 and IPv6.
 
 If you are planning to use the native Icinga 2 cluster feature for distributed
 monitoring and high-availability, please continue reading in
-[this chapter](7-monitoring-remote-systems.md#distributed-monitoring-high-availability).
+[this chapter](8-monitoring-remote-systems.md#distributed-monitoring-high-availability).
 
 > **Tip**
 >
@@ -58,13 +58,13 @@ First, you should decide which role the remote client has:
 * a remote command execution client (similar to NRPE, NSClient++, etc)
 
 Later on, you will be asked again and told how to proceed with these
-different [roles](7-monitoring-remote-systems.md#icinga2-remote-monitoring-client-roles).
+different [roles](8-monitoring-remote-systems.md#icinga2-remote-monitoring-client-roles).
 
 > **Note**
 >
 > If you are planning to build an Icinga 2 distributed setup using the cluster feature, please skip
 > the following instructions and jump directly to the
-> [cluster setup instructions](7-monitoring-remote-systems.md#distributed-monitoring-high-availability).
+> [cluster setup instructions](8-monitoring-remote-systems.md#distributed-monitoring-high-availability).
 
 > **Note**
 >
@@ -73,7 +73,7 @@ different [roles](7-monitoring-remote-systems.md#icinga2-remote-monitoring-clien
 
 ## <a id="icinga2-remote-monitoring-master"></a> Master Setup for Remote Monitoring
 
-If you are planning to use the [remote Icinga 2 clients](7-monitoring-remote-systems.md#icinga2-remote-monitoring-client)
+If you are planning to use the [remote Icinga 2 clients](8-monitoring-remote-systems.md#icinga2-remote-monitoring-client)
 you'll first need to update your master setup.
 
 Your master setup requires the following
@@ -82,7 +82,7 @@ Your master setup requires the following
 * Enabled API feature, and a local Endpoint and Zone object configuration
 * Firewall ACLs for the communication port (default 5665)
 
-You can use the [CLI command](8-cli-commands.md#cli-command-node) `node wizard` for setting up a new node
+You can use the [CLI command](7-cli-commands.md#cli-command-node) `node wizard` for setting up a new node
 on the master. The command must be run as root, all Icinga 2 specific files
 will be updated to the icinga user the daemon is running as (certificate files
 for example).
@@ -148,13 +148,13 @@ The setup wizard does not automatically restart Icinga 2.
 ## <a id="icinga2-remote-monitoring-client"></a> Client Setup for Remote Monitoring
 
 Icinga 2 can be installed on Linux/Unix and Windows. While
-[Linux/Unix](7-monitoring-remote-systems.md#icinga2-remote-monitoring-client-linux) will be using the [CLI command](8-cli-commands.md#cli-command-node)
+[Linux/Unix](8-monitoring-remote-systems.md#icinga2-remote-monitoring-client-linux) will be using the [CLI command](7-cli-commands.md#cli-command-node)
 `node wizard` for a guided setup, you will need to use the
 graphical installer for Windows based client setup.
 
 Your client setup requires the following
 
-* A ready configured and installed [master node](7-monitoring-remote-systems.md#icinga2-remote-monitoring-master)
+* A ready configured and installed [master node](8-monitoring-remote-systems.md#icinga2-remote-monitoring-master)
 * SSL signed certificate for communication with the master (Use [CSR auto-signing](certifiates-csr-autosigning)).
 * Enabled API feature, and a local Endpoint and Zone object configuration
 * Firewall ACLs for the communication port (default 5665)
@@ -169,7 +169,7 @@ If your remote clients are capable of connecting to the central master, Icinga 2
 supports CSR auto-signing.
 
 First you'll need to define a secure ticket salt in the [constants.conf](4-configuring-icinga-2.md#constants-conf).
-The [setup wizard for the master setup](7-monitoring-remote-systems.md#icinga2-remote-monitoring-master) will create
+The [setup wizard for the master setup](8-monitoring-remote-systems.md#icinga2-remote-monitoring-master) will create
 one for you already.
 
     # grep TicketSalt /etc/icinga2/constants.conf
@@ -193,11 +193,11 @@ Example for a client notebook:
 
 #### <a id="certificates-manual-creation"></a> Manual SSL Certificate Generation
 
-This is described separately in the [cluster setup chapter](7-monitoring-remote-systems.md#manual-certificate-generation).
+This is described separately in the [cluster setup chapter](8-monitoring-remote-systems.md#manual-certificate-generation).
 
 > **Note**
 >
-> If you're using [CSR Auto-Signing](7-monitoring-remote-systems.md#csr-autosigning-requirements), skip this step.
+> If you're using [CSR Auto-Signing](8-monitoring-remote-systems.md#csr-autosigning-requirements), skip this step.
 
 
 #### <a id="icinga2-remote-monitoring-client-linux-setup"></a> Linux Client Setup Wizard for Remote Monitoring
@@ -205,8 +205,8 @@ This is described separately in the [cluster setup chapter](7-monitoring-remote-
 Install Icinga 2 from your distribution's package repository as described in the
 general [installation instructions](2-getting-started.md#setting-up-icinga2).
 
-Please make sure that either [CSR Auto-Signing](7-monitoring-remote-systems.md#csr-autosigning-requirements) requirements
-are fulfilled, or that you're using [manual SSL certificate generation](7-monitoring-remote-systems.md#manual-certificate-generation).
+Please make sure that either [CSR Auto-Signing](8-monitoring-remote-systems.md#csr-autosigning-requirements) requirements
+are fulfilled, or that you're using [manual SSL certificate generation](8-monitoring-remote-systems.md#manual-certificate-generation).
 
 > **Note**
 >
@@ -222,7 +222,7 @@ You'll need the following configuration details:
 * The client's local zone name. Defaults to FQDN.
 * The master endpoint name. Look into your master setup `zones.conf` file for the proper name.
 * The master endpoint connection information. Your master's IP address and port (defaults to 5665)
-* The [request ticket number](7-monitoring-remote-systems.md#csr-autosigning-requirements) generated on your master
+* The [request ticket number](8-monitoring-remote-systems.md#csr-autosigning-requirements) generated on your master
 for CSR Auto-Signing
 * Bind host/port for the Api feature (optional)
 
@@ -325,7 +325,7 @@ You'll need the following configuration details:
 * The client's local zone name. Defaults to FQDN.
 * The master endpoint name. Look into your master setup `zones.conf` file for the proper name.
 * The master endpoint connection information. Your master's IP address and port (defaults to 5665)
-* The [request ticket number](7-monitoring-remote-systems.md#csr-autosigning-requirements) generated on your master
+* The [request ticket number](8-monitoring-remote-systems.md#csr-autosigning-requirements) generated on your master
 for CSR Auto-Signing
 * Bind host/port for the Api feature (optional)
 
@@ -395,8 +395,8 @@ in [zones.conf](#zones-conf) and define a trusted master zone as `parent`.
     }
 
 More details here:
-* [configure endpoints](7-monitoring-remote-systems.md#configure-cluster-endpoints)
-* [configure zones](7-monitoring-remote-systems.md#configure-cluster-zones)
+* [configure endpoints](8-monitoring-remote-systems.md#configure-cluster-endpoints)
+* [configure zones](8-monitoring-remote-systems.md#configure-cluster-zones)
 
 
 Configuration example for host and service objects running commands on the remote endpoint `remote-client1`:
@@ -447,7 +447,7 @@ schedule client updates in your management tool (e.g. Puppet).
 > clients. There are no local configured objects available.
 >
 > If you require this, please install a full-featured
-> [local client](7-monitoring-remote-systems.md#icinga2-remote-monitoring-client-local-config).
+> [local client](8-monitoring-remote-systems.md#icinga2-remote-monitoring-client-local-config).
 
 ### <a id="icinga2-remote-monitoring-client-local-config"></a> Remote Client with Local Configuration
 
@@ -519,7 +519,7 @@ using the following CLI command:
 
 > **Note**
 >
-> Better use [blacklists and/or whitelists](7-monitoring-remote-systems.md#icinga2-remote-monitoring-master-discovery-blacklist-whitelist)
+> Better use [blacklists and/or whitelists](8-monitoring-remote-systems.md#icinga2-remote-monitoring-master-discovery-blacklist-whitelist)
 > to control which clients and hosts/services are integrated into your master configuration repository.
 
 ### <a id="icinga2-remote-monitoring-master-discovery-generate-config"></a> Generate Icinga 2 Configuration for Client Services on the Master
@@ -602,13 +602,13 @@ You can `list` and `remove` existing blacklists:
 
 Define a [Zone](5-object-types.md#objecttype-zone) with a new [Endpoint](5-object-types.md#objecttype-endpoint) similar to the cluster setup.
 
-* [configure the node name](7-monitoring-remote-systems.md#configure-nodename)
-* [configure the ApiListener object](7-monitoring-remote-systems.md#configure-apilistener-object)
-* [configure cluster endpoints](7-monitoring-remote-systems.md#configure-cluster-endpoints)
-* [configure cluster zones](7-monitoring-remote-systems.md#configure-cluster-zones)
+* [configure the node name](8-monitoring-remote-systems.md#configure-nodename)
+* [configure the ApiListener object](8-monitoring-remote-systems.md#configure-apilistener-object)
+* [configure cluster endpoints](8-monitoring-remote-systems.md#configure-cluster-endpoints)
+* [configure cluster zones](8-monitoring-remote-systems.md#configure-cluster-zones)
 
 on a per remote client basis. If you prefer to synchronize the configuration to remote
-clients, you can also use the cluster provided [configuration sync](7-monitoring-remote-systems.md#cluster-zone-config-sync)
+clients, you can also use the cluster provided [configuration sync](8-monitoring-remote-systems.md#cluster-zone-config-sync)
 in `zones.d`.
 
 
@@ -676,7 +676,7 @@ remote client.
 > The NRPE protocol is considered insecure and has multiple flaws in its
 > design. Upstream is not willing to fix these issues.
 >
-> In order to stay safe, please use the native [Icinga 2 client](7-monitoring-remote-systems.md#icinga2-remote-monitoring-master)
+> In order to stay safe, please use the native [Icinga 2 client](8-monitoring-remote-systems.md#icinga2-remote-monitoring-master)
 > instead.
 
 The NRPE daemon uses its own configuration format in nrpe.cfg while `check_nrpe`
@@ -742,7 +742,7 @@ executed by the NRPE daemon looks similar to that:
 
     /usr/local/icinga/libexec/check_disk -w 20% -c 10% -p /
 
-You can pass arguments in a similar manner to [NSClient++](7-monitoring-remote-systems.md#agent-based-checks-nsclient)
+You can pass arguments in a similar manner to [NSClient++](8-monitoring-remote-systems.md#agent-based-checks-nsclient)
 when using its NRPE supported check method.
 
 ### <a id="agent-based-checks-nsclient"></a> NSClient++
@@ -973,9 +973,9 @@ passive update with the state and text from the second and third varbind:
 Building distributed environments with high availability included is fairly easy with Icinga 2.
 The cluster feature is built-in and allows you to build many scenarios based on your requirements:
 
-* [High Availability](7-monitoring-remote-systems.md#cluster-scenarios-high-availability). All instances in the `Zone` elect one active master and run as Active/Active cluster.
-* [Distributed Zones](7-monitoring-remote-systems.md#cluster-scenarios-distributed-zones). A master zone and one or more satellites in their zones.
-* [Load Distribution](7-monitoring-remote-systems.md#cluster-scenarios-load-distribution). A configuration master and multiple checker satellites.
+* [High Availability](8-monitoring-remote-systems.md#cluster-scenarios-high-availability). All instances in the `Zone` elect one active master and run as Active/Active cluster.
+* [Distributed Zones](8-monitoring-remote-systems.md#cluster-scenarios-distributed-zones). A master zone and one or more satellites in their zones.
+* [Load Distribution](8-monitoring-remote-systems.md#cluster-scenarios-load-distribution). A configuration master and multiple checker satellites.
 
 You can combine these scenarios into a global setup fitting your requirements.
 
@@ -999,7 +999,7 @@ Before you start deploying, keep the following things in mind:
     * cluster zones can be built in a Top-Down-design where the child trusts the parent
     * communication between zones happens bi-directional which means that a DMZ-located node can still reach the master node, or vice versa
 * Update firewall rules and ACLs
-* Decide whether to use the built-in [configuration syncronization](7-monitoring-remote-systems.md#cluster-zone-config-sync) or use an external tool (Puppet, Ansible, Chef, Salt, etc) to manage the configuration deployment
+* Decide whether to use the built-in [configuration syncronization](8-monitoring-remote-systems.md#cluster-zone-config-sync) or use an external tool (Puppet, Ansible, Chef, Salt, etc) to manage the configuration deployment
 
 
 > **Tip**
@@ -1010,7 +1010,7 @@ Before you start deploying, keep the following things in mind:
 
 ### <a id="manual-certificate-generation"></a> Manual SSL Certificate Generation
 
-Icinga 2 ships [CLI commands](8-cli-commands.md#cli-command-pki) assisting with CA and node certificate creation
+Icinga 2 ships [CLI commands](7-cli-commands.md#cli-command-pki) assisting with CA and node certificate creation
 for your Icinga 2 distributed setup.
 
 > **Note**
@@ -1079,7 +1079,7 @@ The [Endpoint](5-object-types.md#objecttype-endpoint) name is further referenced
       endpoints = [ "icinga2a", "icinga2b" ]
     }
 
-Specifying the local node name using the [NodeName](7-monitoring-remote-systems.md#configure-nodename) variable requires
+Specifying the local node name using the [NodeName](8-monitoring-remote-systems.md#configure-nodename) variable requires
 the same name as used for the endpoint name and common name above. If not set, the FQDN is used.
 
     const NodeName = "icinga2a"
@@ -1090,14 +1090,14 @@ the same name as used for the endpoint name and common name above. If not set, t
 The following section describe which configuration must be updated/created
 in order to get your cluster running with basic functionality.
 
-* [configure the node name](7-monitoring-remote-systems.md#configure-nodename)
-* [configure the ApiListener object](7-monitoring-remote-systems.md#configure-apilistener-object)
-* [configure cluster endpoints](7-monitoring-remote-systems.md#configure-cluster-endpoints)
-* [configure cluster zones](7-monitoring-remote-systems.md#configure-cluster-zones)
+* [configure the node name](8-monitoring-remote-systems.md#configure-nodename)
+* [configure the ApiListener object](8-monitoring-remote-systems.md#configure-apilistener-object)
+* [configure cluster endpoints](8-monitoring-remote-systems.md#configure-cluster-endpoints)
+* [configure cluster zones](8-monitoring-remote-systems.md#configure-cluster-zones)
 
 Once you're finished with the basic setup the following section will
-describe how to use [zone configuration synchronisation](7-monitoring-remote-systems.md#cluster-zone-config-sync)
-and configure [cluster scenarios](7-monitoring-remote-systems.md#cluster-scenarios).
+describe how to use [zone configuration synchronisation](8-monitoring-remote-systems.md#cluster-zone-config-sync)
+and configure [cluster scenarios](8-monitoring-remote-systems.md#cluster-scenarios).
 
 #### <a id="configure-nodename"></a> Configure the Icinga Node Name
 
@@ -1112,7 +1112,7 @@ that value using the [NodeName](15-language-reference.md#constants) constant.
 This setting must be unique for each node, and must also match
 the name of the local [Endpoint](5-object-types.md#objecttype-endpoint) object and the
 SSL certificate common name as described in the
-[cluster naming convention](7-monitoring-remote-systems.md#cluster-naming-convention).
+[cluster naming convention](8-monitoring-remote-systems.md#cluster-naming-convention).
 
     vim /etc/icinga2/constants.conf
 
@@ -1122,7 +1122,7 @@ SSL certificate common name as described in the
     const NodeName = "icinga2a"
 
 
-Read further about additional [naming conventions](7-monitoring-remote-systems.md#cluster-naming-convention).
+Read further about additional [naming conventions](8-monitoring-remote-systems.md#cluster-naming-convention).
 
 Not specifying the node name will make Icinga 2 using the FQDN. Make sure that all
 configured endpoint names and common names are in sync.
@@ -1177,9 +1177,9 @@ If this endpoint object is reachable on a different port, you must configure the
 `Zone` objects specify the endpoints located in a zone. That way your distributed setup can be
 seen as zones connected together instead of multiple instances in that specific zone.
 
-Zones can be used for [high availability](7-monitoring-remote-systems.md#cluster-scenarios-high-availability),
-[distributed setups](7-monitoring-remote-systems.md#cluster-scenarios-distributed-zones) and
-[load distribution](7-monitoring-remote-systems.md#cluster-scenarios-load-distribution).
+Zones can be used for [high availability](8-monitoring-remote-systems.md#cluster-scenarios-high-availability),
+[distributed setups](8-monitoring-remote-systems.md#cluster-scenarios-distributed-zones) and
+[load distribution](8-monitoring-remote-systems.md#cluster-scenarios-load-distribution).
 
 Each Icinga 2 `Endpoint` must be put into its respective `Zone`. In this example, you will
 define the zone `config-ha-master` where the `icinga2a` and `icinga2b` endpoints
@@ -1214,7 +1214,7 @@ on the configuration master.
 Your child zones and endpoint members **must not** have their config copied to `zones.d`.
 The built-in configuration synchronisation takes care of that if your nodes accept
 configuration from the parent zone. You can define that in the
-[ApiListener](7-monitoring-remote-systems.md#configure-apilistener-object) object by configuring the `accept_config`
+[ApiListener](8-monitoring-remote-systems.md#configure-apilistener-object) object by configuring the `accept_config`
 attribute accordingly.
 
 You should remove the sample config included in `conf.d` by commenting the `recursive_include`
@@ -1224,11 +1224,11 @@ statement in [icinga2.conf](4-configuring-icinga-2.md#icinga2-conf):
 
 Better use a dedicated directory name like `cluster` or similar, and include that
 one if your nodes require local configuration not being synced to other nodes. That's
-useful for local [health checks](7-monitoring-remote-systems.md#cluster-health-check) for example.
+useful for local [health checks](8-monitoring-remote-systems.md#cluster-health-check) for example.
 
 > **Note**
 >
-> In a [high availability](7-monitoring-remote-systems.md#cluster-scenarios-high-availability)
+> In a [high availability](8-monitoring-remote-systems.md#cluster-scenarios-high-availability)
 > setup only one assigned node can act as configuration master. All other zone
 > member nodes **must not** have the `/etc/icinga2/zones.d` directory populated.
 
@@ -1237,7 +1237,7 @@ to their respective target zone instances.
 
 Each configured zone must exist with the same directory name. The parent zone
 syncs the configuration to the child zones, if allowed using the `accept_config`
-attribute of the [ApiListener](7-monitoring-remote-systems.md#configure-apilistener-object) object.
+attribute of the [ApiListener](8-monitoring-remote-systems.md#configure-apilistener-object) object.
 
 Config on node `icinga2a`:
 
@@ -1395,7 +1395,7 @@ additional security itself:
 * Child zones only receive event updates (check results, commands, etc) for their configured updates.
 * Zones cannot influence/interfere other zones. Each checked object is assigned to only one zone.
 * All nodes in a zone trust each other.
-* [Configuration sync](7-monitoring-remote-systems.md#zone-config-sync-permissions) is disabled by default.
+* [Configuration sync](8-monitoring-remote-systems.md#zone-config-sync-permissions) is disabled by default.
 
 #### <a id="cluster-scenarios-features"></a> Features in Cluster Zones
 
@@ -1406,11 +1406,11 @@ re-schedule a check or acknowledge a problem on the master, and it gets replicat
 actual slave checker node.
 
 DB IDO on the left, graphite on the right side - works (if you disable
-[DB IDO HA](7-monitoring-remote-systems.md#high-availability-db-ido)).
+[DB IDO HA](8-monitoring-remote-systems.md#high-availability-db-ido)).
 Icinga Web 2 on the left, checker and notifications on the right side - works too.
 Everything on the left and on the right side - make sure to deal with
-[load-balanced notifications and checks](7-monitoring-remote-systems.md#high-availability-features) in a
-[HA zone](7-monitoring-remote-systems.md#cluster-scenarios-high-availability).
+[load-balanced notifications and checks](8-monitoring-remote-systems.md#high-availability-features) in a
+[HA zone](8-monitoring-remote-systems.md#cluster-scenarios-high-availability).
 configure-cluster-zones
 #### <a id="cluster-scenarios-distributed-zones"></a> Distributed Zones
 
@@ -1425,7 +1425,7 @@ graphing, etc. in their own specified zone.
 
 Imagine the following example with a master node in Nuremberg, and two remote DMZ
 based instances in Berlin and Vienna. Additonally you'll specify
-[global templates](7-monitoring-remote-systems.md#zone-global-config-templates) available in all zones.
+[global templates](8-monitoring-remote-systems.md#zone-global-config-templates) available in all zones.
 
 The configuration tree on the master instance `nuremberg` could look like this:
 
@@ -1489,7 +1489,7 @@ check results from the satellite nodes in the zones `berlin` and `vienna`.
 > The child zones `berlin` and `vienna` will get their configuration synchronised
 > from the configuration master 'nuremberg'. The endpoints in the child
 > zones **must not** have their `zones.d` directory populated if this endpoint
-> [accepts synced configuration](7-monitoring-remote-systems.md#zone-config-sync-permissions).
+> [accepts synced configuration](8-monitoring-remote-systems.md#zone-config-sync-permissions).
 
 #### <a id="cluster-scenarios-load-distribution"></a> Load Distribution
 
@@ -1548,15 +1548,15 @@ Zones:
 > The child zones `checker` will get its configuration synchronised
 > from the configuration master 'master'. The endpoints in the child
 > zone **must not** have their `zones.d` directory populated if this endpoint
-> [accepts synced configuration](7-monitoring-remote-systems.md#zone-config-sync-permissions).
+> [accepts synced configuration](8-monitoring-remote-systems.md#zone-config-sync-permissions).
 
 #### <a id="cluster-scenarios-high-availability"></a> Cluster High Availability
 
 High availability with Icinga 2 is possible by putting multiple nodes into
-a dedicated [zone](7-monitoring-remote-systems.md#configure-cluster-zones). All nodes will elect one
+a dedicated [zone](8-monitoring-remote-systems.md#configure-cluster-zones). All nodes will elect one
 active master, and retry an election once the current active master is down.
 
-Selected features provide advanced [HA functionality](7-monitoring-remote-systems.md#high-availability-features).
+Selected features provide advanced [HA functionality](8-monitoring-remote-systems.md#high-availability-features).
 Checks and notifications are load-balanced between nodes in the high availability
 zone.
 
@@ -1568,17 +1568,17 @@ commands, etc.
       endpoints = [ "icinga2a", "icinga2b", "icinga2c" ]
     }
 
-Two or more nodes in a high availability setup require an [initial cluster sync](7-monitoring-remote-systems.md#initial-cluster-sync).
+Two or more nodes in a high availability setup require an [initial cluster sync](8-monitoring-remote-systems.md#initial-cluster-sync).
 
 > **Note**
 >
 > Keep in mind that **only one node acts as configuration master** having the
 > configuration files in the `zones.d` directory. All other nodes **must not**
 > have that directory populated. Instead they are required to
-> [accept synced configuration](7-monitoring-remote-systems.md#zone-config-sync-permissions).
-> Details in the [Configuration Sync Chapter](7-monitoring-remote-systems.md#cluster-zone-config-sync).
+> [accept synced configuration](8-monitoring-remote-systems.md#zone-config-sync-permissions).
+> Details in the [Configuration Sync Chapter](8-monitoring-remote-systems.md#cluster-zone-config-sync).
 
-#### <a id="cluster-scenarios-multiple-hierachies"></a> Multiple Hierachies
+#### <a id="cluster-scenarios-multiple-hierarchies"></a> Multiple Hierarchies
 
 Your master zone collects all check results for reporting and graphing and also
 does some sort of additional notifications.
@@ -1610,9 +1610,9 @@ amongst them.
 
 By default the following features provide advanced HA functionality:
 
-* [Checks](7-monitoring-remote-systems.md#high-availability-checks) (load balanced, automated failover)
-* [Notifications](7-monitoring-remote-systems.md#high-availability-notifications) (load balanced, automated failover)
-* [DB IDO](7-monitoring-remote-systems.md#high-availability-db-ido) (Run-Once, automated failover)
+* [Checks](8-monitoring-remote-systems.md#high-availability-checks) (load balanced, automated failover)
+* [Notifications](8-monitoring-remote-systems.md#high-availability-notifications) (load balanced, automated failover)
+* [DB IDO](8-monitoring-remote-systems.md#high-availability-db-ido) (Run-Once, automated failover)
 
 #### <a id="high-availability-checks"></a> High Availability with Checks
 
@@ -1682,11 +1682,11 @@ These steps are required for integrating a new cluster endpoint:
 
 * generate a new [SSL client certificate](#certificate-authority-certificates)
 * identify its location in the zones
-* update the `zones.conf` file on each involved node ([endpoint](7-monitoring-remote-systems.md#configure-cluster-endpoints), [zones](7-monitoring-remote-systems.md#configure-cluster-zones))
+* update the `zones.conf` file on each involved node ([endpoint](8-monitoring-remote-systems.md#configure-cluster-endpoints), [zones](8-monitoring-remote-systems.md#configure-cluster-zones))
     * a new slave zone node requires updates for the master and slave zones
-    * verify if this endpoints requires [configuration synchronisation](7-monitoring-remote-systems.md#cluster-zone-config-sync) enabled
-* if the node requires the existing zone history: [initial cluster sync](7-monitoring-remote-systems.md#initial-cluster-sync)
-* add a [cluster health check](7-monitoring-remote-systems.md#cluster-health-check)
+    * verify if this endpoints requires [configuration synchronisation](8-monitoring-remote-systems.md#cluster-zone-config-sync) enabled
+* if the node requires the existing zone history: [initial cluster sync](8-monitoring-remote-systems.md#initial-cluster-sync)
+* add a [cluster health check](8-monitoring-remote-systems.md#cluster-health-check)
 
 #### <a id="initial-cluster-sync"></a> Initial Cluster Sync
 

diff --git a/mkdocs.yml b/mkdocs.yml
index 32bc1440c1212384b1741924a2b1c6ef1e3feead..3f7aaedfe519a929f646d32f0e60d9b5440b98f2 100644 (file)
--- a/mkdocs.yml
+++ b/mkdocs.yml
@@ -8,8 +8,8 @@ pages:
 - [4-configuring-icinga-2.md, Configuring Icinga 2]
 - [5-object-types.md, Object Types]
 - [6-icinga-template-library.md, Icinga Template Library]
-- [7-monitoring-remote-systems.md, Monitoring Remote Systems]
-- [8-cli-commands.md, CLI Commands]
+- [7-cli-commands.md, CLI Commands]
+- [8-monitoring-remote-systems.md, Monitoring Remote Systems]
 - [9-addons-plugins.md, Addons and Plugins]
 - [10-alternative-frontends.md, Alternative Frontends]
 - [11-livestatus.md, Livestatus]