Documentation: Move configuration before advanced topics

fixes #9431

doc/10-icinga2-client.md

@@ -115,7 +115,7 @@ The setup wizard will do the following:
 * Generate a new CSR, sign it with the local CA and copying it into `/etc/icinga2/pki`
 * Generate a local zone and endpoint configuration for this master based on FQDN
 * Enabling the API feature, and setting optional `bind_host` and `bind_port`
-* Setting the `NodeName` and `TicketSalt` constants in [constants.conf](5-configuring-icinga-2.md#constants-conf)
+* Setting the `NodeName` and `TicketSalt` constants in [constants.conf](4-configuring-icinga-2.md#constants-conf)
 
 The setup wizard does not automatically restart Icinga 2.
 
@@ -166,7 +166,7 @@ Your client setup requires the following
 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](5-configuring-icinga-2.md#constants-conf).
+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](10-icinga2-client.md#icinga2-client-installation-master-setup) will create
 one for you already.
 
@@ -187,7 +187,7 @@ Example for a client:
 > **Note**
 >
 > You can omit the `--salt` parameter using the `TicketSalt` constant from
-> [constants.conf](5-configuring-icinga-2.md#constants-conf) if already defined and Icinga 2 was
+> [constants.conf](4-configuring-icinga-2.md#constants-conf) if already defined and Icinga 2 was
 > reloaded after the master setup.
 
 ### <a id="certificates-manual-creation"></a> Manual SSL Certificate Generation
@@ -293,7 +293,7 @@ The setup wizard will do the following:
 (based on FQDN)
 * Disabling the `notification` feature for this client
 * Enabling the `api` feature, and setting optional `bind_host` and `bind_port`
-* Setting the `NodeName` constant in [constants.conf](5-configuring-icinga-2.md#constants-conf)
+* Setting the `NodeName` constant in [constants.conf](4-configuring-icinga-2.md#constants-conf)
 
 The setup wizard does not automatically restart Icinga 2.
 

doc/12-distributed-monitoring-ha.md

@@ -263,7 +263,7 @@ configuration from the parent zone. You can define that in the
 attribute accordingly.
 
 You should remove the sample config included in `conf.d` by commenting the `recursive_include`
-statement in [icinga2.conf](5-configuring-icinga-2.md#icinga2-conf):
+statement in [icinga2.conf](4-configuring-icinga-2.md#icinga2-conf):
 
     //include_recursive "conf.d"
 
@@ -321,7 +321,7 @@ process.
 
 > **Note**
 >
-> `zones.d` must not be included in [icinga2.conf](5-configuring-icinga-2.md#icinga2-conf). Icinga 2 automatically
+> `zones.d` must not be included in [icinga2.conf](4-configuring-icinga-2.md#icinga2-conf). Icinga 2 automatically
 > determines the required include directory. This can be overridden using the
 > [global constant](19-language-reference.md#constants) `ZonesDir`.
 
@@ -811,7 +811,7 @@ Special scenarios might require multiple cluster nodes running on a single host.
 By default Icinga 2 and its features will place their runtime data below the prefix
 `LocalStateDir`. By default packages will set that path to `/var`.
 You can either set that variable as constant configuration
-definition in [icinga2.conf](5-configuring-icinga-2.md#icinga2-conf) or pass it as runtime variable to
+definition in [icinga2.conf](4-configuring-icinga-2.md#icinga2-conf) or pass it as runtime variable to
 the Icinga 2 daemon.
 
     # icinga2 -c /etc/icinga2/node1/icinga2.conf -DLocalStateDir=/opt/node1/var

doc/13-addons-plugins.md

@@ -13,7 +13,7 @@ Use your distribution's package manager to install the `pnp4nagios` package.
 
 If you're planning to use it configure it to use the
 [bulk mode with npcd and npcdmod](http://docs.pnp4nagios.org/pnp-0.6/modes#bulk_mode_with_npcd_and_npcdmod)
-in combination with Icinga 2's [PerfdataWriter](4-advanced-topics.md#performance-data). NPCD collects the performance
+in combination with Icinga 2's [PerfdataWriter](5-advanced-topics.md#performance-data). NPCD collects the performance
 data files which Icinga 2 generates.
 
 Enable performance data writer in icinga 2
@@ -45,7 +45,7 @@ Graphite consists of 3 software components:
 * whisper - a simple database library for storing time-series data (similar in design to RRD)
 * graphite webapp - A Django webapp that renders graphs on-demand using Cairo
 
-Use the [GraphiteWriter](4-advanced-topics.md#graphite-carbon-cache-writer) feature
+Use the [GraphiteWriter](5-advanced-topics.md#graphite-carbon-cache-writer) feature
 for sending real-time metrics from Icinga 2 to Graphite.
 
     # icinga2 feature enable graphite
@@ -55,7 +55,7 @@ There are Graphite addons available for collecting the performance data files to
 ### <a id="addons-graphing-ingraph"></a> inGraph
 
 [inGraph](https://www.netways.org/projects/ingraph/wiki) requires the ingraph-collector addon
-to be configured to point at the perfdata files. Icinga 2's [PerfdataWriter](4-advanced-topics.md#performance-data) will
+to be configured to point at the perfdata files. Icinga 2's [PerfdataWriter](5-advanced-topics.md#performance-data) will
 write to the performance data spool directory.
 
 ## <a id="addons-visualization"></a> Visualization
@@ -112,7 +112,7 @@ list of popular community sites which host check plugins:
 * [Icinga Wiki](https://wiki.icinga.org)
 
 The recommended way of setting up these plugins is to copy them to a common directory
-and create a new global constant, e.g. `CustomPluginDir` in your [constants.conf](5-configuring-icinga-2.md#constants-conf)
+and create a new global constant, e.g. `CustomPluginDir` in your [constants.conf](4-configuring-icinga-2.md#constants-conf)
 configuration file:
 
     # cp check_snmp_int.pl /opt/monitoring/plugins
@@ -229,7 +229,7 @@ This behavior changed in Icinga 2 compared to Icinga 1.x. Though there are certa
 fix this:
 
 * Create a symlink for example from the `templates.dist/check_ping.php` template to the actual check name in Icinga 2 (`templates/ping4.php`)
-* Pass the check command name inside the [format template configuration](4-advanced-topics.md#writing-performance-data-files)
+* Pass the check command name inside the [format template configuration](5-advanced-topics.md#writing-performance-data-files)
 
 The latter becomes difficult with agent based checks like NRPE or SSH where the first command argument acts as
 graph template identifier. There is the possibility to define the pnp template name as custom attribute

doc/14-alternative-frontends.md

@@ -3,7 +3,7 @@
 ## <a id="setting-up-icinga-classic-ui"></a> Setting up Icinga Classic UI 1.x
 
 Icinga 2 can write `status.dat` and `objects.cache` files in the format that
-is supported by the Icinga 1.x Classic UI. [External commands](4-advanced-topics.md#external-commands)
+is supported by the Icinga 1.x Classic UI. [External commands](5-advanced-topics.md#external-commands)
 (a.k.a. the "command pipe") are also supported. It also supports writing Icinga 1.x
 log files which are required for the reporting functionality in the Classic UI.
 
@@ -32,8 +32,8 @@ to satisfy this dependency:
 On all distributions other than Debian you may have to restart both your web
 server as well as Icinga 2 after installing the Classic UI package.
 
-Icinga Classic UI requires the [StatusDataWriter](4-advanced-topics.md#status-data), [CompatLogger](4-advanced-topics.md#compat-logging)
+Icinga Classic UI requires the [StatusDataWriter](5-advanced-topics.md#status-data), [CompatLogger](5-advanced-topics.md#compat-logging)
-and [ExternalCommandListener](4-advanced-topics.md#external-commands) features.
+and [ExternalCommandListener](5-advanced-topics.md#external-commands) features.
 Enable these features and restart Icinga 2.
 
     # icinga2 feature enable statusdata compatlog command
@@ -104,7 +104,7 @@ found in the [Icinga Web documentation](http://docs.icinga.org/latest/en/icinga-
 
     # icinga-web-clearcache
 
-Additionally you need to enable the `command` feature for sending [external commands](4-advanced-topics.md#external-commands):
+Additionally you need to enable the `command` feature for sending [external commands](5-advanced-topics.md#external-commands):
 
     # icinga2 feature enable command
 

doc/16-troubleshooting.md

@@ -102,7 +102,7 @@ included using
     include <itl>
     include <plugins>
 
-in the [icinga2.conf](5-configuring-icinga-2.md#icinga2-conf) configuration file. These files are not considered configuration files and will be overridden
+in the [icinga2.conf](4-configuring-icinga-2.md#icinga2-conf) configuration file. These files are not considered configuration files and will be overridden
 on upgrade, so please send modifications as proposed patches upstream. The default include path is set to
 `LocalStateDir + "/share/icinga2/includes"`.
 
@@ -151,7 +151,7 @@ Examples:
 ## <a id="feature-not-working"></a> Feature is not working
 
 * Make sure that the feature configuration is enabled by symlinking from `features-available/`
-to `features-enabled` and that the latter is included in [icinga2.conf](5-configuring-icinga-2.md#icinga2-conf).
+to `features-enabled` and that the latter is included in [icinga2.conf](4-configuring-icinga-2.md#icinga2-conf).
 * Are the feature attributes set correctly according to the documentation?
 * Any errors on the logs?
 
@@ -159,7 +159,7 @@ to `features-enabled` and that the latter is included in [icinga2.conf](5-config
 
 * Make sure that the line(s) are not [commented out](19-language-reference.md#comments) (starting with `//` or `#`, or
 encapsulated by `/* ... */`).
-* Is the configuration file included in [icinga2.conf](5-configuring-icinga-2.md#icinga2-conf)?
+* Is the configuration file included in [icinga2.conf](4-configuring-icinga-2.md#icinga2-conf)?
 
 ## <a id="configuration-attribute-inheritance"></a> Configuration attributes are inherited from
 

doc/18-migrating-from-icinga-1x.md

@@ -739,7 +739,7 @@ included in `icinga2.conf` by default.
 > **Note**
 >
 > Add your own custom templates in the `conf.d/` directory as well, e.g. inside
-> the [templates.conf](5-configuring-icinga-2.md#templates-conf) file.
+> the [templates.conf](4-configuring-icinga-2.md#templates-conf) file.
 
 ### <a id="differences-1x-2-main-config"></a> Main Config File
 
@@ -747,7 +747,7 @@ In Icinga 1.x there are many global configuration settings available in `icinga.
 Icinga 2 only uses a small set of [global constants](19-language-reference.md#constants) allowing
 you to specify certain different setting such as the `NodeName` in a cluster scenario.
 
-Aside from that, the [icinga2.conf](5-configuring-icinga-2.md#icinga2-conf) should take care of including
+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.
 
 ### <a id="differences-1x-2-include-files-dirs"></a> Include Files and Directories

doc/2-getting-started.md

@@ -154,7 +154,7 @@ FreeBSD                | nagios-plugins     | /usr/local/libexec/nagios
 OS X (MacPorts)        | nagios-plugins     | /opt/local/libexec
 
 Depending on which directory your plugins are installed into you may need to
-update the global `PluginDir` constant in your [Icinga 2 configuration](5-configuring-icinga-2.md#constants-conf).
+update the global `PluginDir` constant in your [Icinga 2 configuration](4-configuring-icinga-2.md#constants-conf).
 This constant is used by the check command definitions contained in the Icinga Template Library
 to determine where to find the plugin binaries.
 

doc/3-monitoring-basics.md

@@ -197,7 +197,7 @@ value of arbitrary macro expressions:
     }}
 
 Acessing object attributes at runtime inside these functions is described in the
-[advanced topics](4-advanced-topics.md#access-object-attributes-at-runtime) chapter.
+[advanced topics](5-advanced-topics.md#access-object-attributes-at-runtime) chapter.
 
 ## <a id="runtime-macros"></a> Runtime Macros
 
@@ -407,7 +407,7 @@ based on attribute identifiers for example `host_name` objects can be [applied](
 Before you start using the apply rules keep the following in mind:
 
 * Define the best match.
-    * A set of unique [custom attributes](#custom-attributes-apply) for these hosts/services?
+    * A set of unique [custom attributes](3-monitoring-basics.md#custom-attributes) for these hosts/services?
     * Or [group](3-monitoring-basics.md#groups) memberships, e.g. a host being a member of a hostgroup, applying services to it?
     * A generic pattern [match](19-language-reference.md#function-calls) on the host/service name?
     * [Multiple expressions combined](3-monitoring-basics.md#using-apply-expressions) with `&&` or `||` [operators](19-language-reference.md#expression-operators)
@@ -429,7 +429,7 @@ for not only matching for their existance or values in apply expressions, but al
 
 A more advanced example is using [apply with for loops on arrays or
 dictionaries](#using-apply-for) for example provided by
-[custom atttributes](#custom-attributes-apply) or groups.
+[custom atttributes](3-monitoring-basics.md#custom-attributes) or groups.
 
 > **Tip**
 >
@@ -492,8 +492,8 @@ The notification is ignored for services whose host name ends with `*internal`
 
 ### <a id="using-apply-services"></a> Apply Services to Hosts
 
-The sample configuration already includes a detailed example in [hosts.conf](5-configuring-icinga-2.md#hosts-conf)
+The sample configuration already includes a detailed example in [hosts.conf](4-configuring-icinga-2.md#hosts-conf)
-and [services.conf](5-configuring-icinga-2.md#services-conf) for this use case.
+and [services.conf](4-configuring-icinga-2.md#services-conf) for this use case.
 
 The example for `ssh` applies a service object to all hosts with the `address`
 attribute being defined and the custom attribute `os` set to the string `Linux` in `vars`.
@@ -508,7 +508,7 @@ attribute being defined and the custom attribute `os` set to the string `Linux`
 
 
 Other detailed scenario examples are used in their respective chapters, for example
-[apply services with custom command arguments](#using-apply-services-command-arguments).
+[apply services with custom command arguments](3-monitoring-basics.md#command-passing-parameters).
 
 ### <a id="using-apply-notifications"></a> Apply Notifications to Hosts and Services
 
@@ -535,9 +535,9 @@ Detailed examples can be found in the [dependencies](3-monitoring-basics.md#depe
 
 ### <a id="using-apply-scheduledowntimes"></a> Apply Recurring Downtimes to Hosts and Services
 
-The sample configuration includes an example in [downtimes.conf](5-configuring-icinga-2.md#downtimes-conf).
+The sample configuration includes an example in [downtimes.conf](4-configuring-icinga-2.md#downtimes-conf).
 
-Detailed examples can be found in the [recurring downtimes](4-advanced-topics.md#recurring-downtimes) chapter.
+Detailed examples can be found in the [recurring downtimes](5-advanced-topics.md#recurring-downtimes) chapter.
 
 
 ### <a id="using-apply-for"></a> Using Apply For Rules
@@ -546,8 +546,8 @@ Next to the standard way of using [apply rules](3-monitoring-basics.md#using-app
 there is the requirement of generating apply rules objects based on set (array or
 dictionary).
 
-The sample configuration already includes a detailed example in [hosts.conf](5-configuring-icinga-2.md#hosts-conf)
+The sample configuration already includes a detailed example in [hosts.conf](4-configuring-icinga-2.md#hosts-conf)
-and [services.conf](5-configuring-icinga-2.md#services-conf) for this use case.
+and [services.conf](4-configuring-icinga-2.md#services-conf) for this use case.
 
 Take the following example: A host provides the snmp oids for different service check
 types. This could look like the following example:
@@ -604,7 +604,7 @@ with many interfaces (services). The following requirements/problems apply:
 dynamically generated
 
 
-Tip: Define the snmp community as global constant in your [constants.conf](5-configuring-icinga-2.md#constants-conf) file.
+Tip: Define the snmp community as global constant in your [constants.conf](4-configuring-icinga-2.md#constants-conf) file.
 
     const IftrafficSnmpCommunity = "public"
 
@@ -722,7 +722,7 @@ if set.
 This example makes use of the [check_iftraffic](https://exchange.icinga.org/exchange/iftraffic) plugin.
 The `CheckCommand` definition can be found in the
 [contributed plugin check commands](7-icinga-template-library.md#plugins-contrib-command-iftraffic)
-- make sure to include them in your [icinga2 configuration file](5-configuring-icinga-2.md#icinga2-conf).
+- make sure to include them in your [icinga2 configuration file](4-configuring-icinga-2.md#icinga2-conf).
 
 
 > **Tip**
@@ -1014,7 +1014,7 @@ notifications between start and end time.
       vars.mobile = "+1 555 424642"
     }
 
-Define an additional [NotificationCommand](#notification) for SMS notifications.
+Define an additional [NotificationCommand](3-monitoring-basics.md#notification-commands) for SMS notifications.
 
 > **Note**
 >
@@ -1165,7 +1165,7 @@ using the `check_command` attribute.
 `plugin-check-command` to support native plugin based check methods.
 
 Unless you have done so already, download your check plugin and put it
-into the [PluginDir](5-configuring-icinga-2.md#constants-conf) directory. The following example uses the
+into the [PluginDir](4-configuring-icinga-2.md#constants-conf) directory. The following example uses the
 `check_disk` plugin contained in the Monitoring Plugins package.
 
 The plugin path and all command arguments are made a list of
@@ -1292,7 +1292,7 @@ string values for passing multiple partitions to the `check_disk` check plugin.
 
 
 More details on using arrays in custom attributes can be found in
-[this chapter](#runtime-custom-attributes).
+[this chapter](3-monitoring-basics.md#custom-attributes).
 
 
 #### <a id="command-arguments"></a> Command Arguments

doc/4-configuring-icinga-2.md

@@ -37,7 +37,7 @@ host and service basis.
 Then you should look for the object specific configuration setting `host_name` etc accordingly.
 
 Finding the best files and directory tree for your configuration is up to you. Make sure that
-the [icinga2.conf](5-configuring-icinga-2.md#icinga2-conf) configuration file includes them,
+the [icinga2.conf](4-configuring-icinga-2.md#icinga2-conf) configuration file includes them,
 and then think about:
 
 * tree-based on locations, hostgroups, specific host attributes with sub levels of directories.
@@ -53,7 +53,7 @@ You can later use them for applying assign/ignore rules, or export them into ext
 * Put hosts into hostgroups, services into servicegroups and use these attributes for your apply rules.
 * Use templates to store generic attributes for your objects and apply rules making your configuration more readable.
 Details can be found in the [using templates](3-monitoring-basics.md#object-inheritance-using-templates) chapter.
-* Apply rules may overlap. Keep a central place (for example, [services.conf](5-configuring-icinga-2.md#services-conf) or [notifications.conf](5-configuring-icinga-2.md#notifications-conf)) storing
+* Apply rules may overlap. Keep a central place (for example, [services.conf](4-configuring-icinga-2.md#services-conf) or [notifications.conf](4-configuring-icinga-2.md#notifications-conf)) storing
 the configuration instead of defining apply rules deep in your configuration tree.
 * Every plugin used as check, notification or event command requires a `Command` definition.
 Further details can be looked up in the [check commands](3-monitoring-basics.md#check-commands) chapter.
@@ -133,7 +133,7 @@ and their generated configuration described in
      */
     include_recursive "conf.d"
 
-You can put your own configuration files in the [conf.d](5-configuring-icinga-2.md#conf-d) directory. This
+You can put your own configuration files in the [conf.d](4-configuring-icinga-2.md#conf-d) directory. This
 directive makes sure that all of your own configuration files are included.
 
 ### <a id="constants-conf"></a> constants.conf
@@ -178,35 +178,35 @@ and distributed setups only.
 
 This directory contains example configuration which should help you get started
 with monitoring the local host and its services. It is included in the
-[icinga2.conf](5-configuring-icinga-2.md#icinga2-conf) configuration file by default.
+[icinga2.conf](4-configuring-icinga-2.md#icinga2-conf) configuration file by default.
 
 It can be used as reference example for your own configuration strategy.
 Just keep in mind to include the main directories in the
-[icinga2.conf](5-configuring-icinga-2.md#icinga2-conf) file.
+[icinga2.conf](4-configuring-icinga-2.md#icinga2-conf) file.
 
 You are certainly not bound to it. Remove it, if you prefer your own
 way of deploying Icinga 2 configuration.
 
 Further details on configuration best practice and how to build your
-own strategy is described in [this chapter](5-configuring-icinga-2.md#configuration-best-practice).
+own strategy is described in [this chapter](4-configuring-icinga-2.md#configuration-best-practice).
 
 Available configuration files which are installed by default:
 
-* [hosts.conf](5-configuring-icinga-2.md#hosts-conf)
+* [hosts.conf](4-configuring-icinga-2.md#hosts-conf)
-* [services.conf](5-configuring-icinga-2.md#services-conf)
+* [services.conf](4-configuring-icinga-2.md#services-conf)
-* [users.conf](5-configuring-icinga-2.md#users-conf)
+* [users.conf](4-configuring-icinga-2.md#users-conf)
-* [notifications.conf](5-configuring-icinga-2.md#notifications-conf)
+* [notifications.conf](4-configuring-icinga-2.md#notifications-conf)
-* [commands.conf](5-configuring-icinga-2.md#commands-conf)
+* [commands.conf](4-configuring-icinga-2.md#commands-conf)
-* [groups.conf](5-configuring-icinga-2.md#groups-conf)
+* [groups.conf](4-configuring-icinga-2.md#groups-conf)
-* [templates.conf](5-configuring-icinga-2.md#templates-conf)
+* [templates.conf](4-configuring-icinga-2.md#templates-conf)
-* [downtimes.conf](5-configuring-icinga-2.md#downtimes-conf)
+* [downtimes.conf](4-configuring-icinga-2.md#downtimes-conf)
-* [timeperiods.conf](5-configuring-icinga-2.md#timeperiods-conf)
+* [timeperiods.conf](4-configuring-icinga-2.md#timeperiods-conf)
-* [satellite.conf](5-configuring-icinga-2.md#satellite-conf)
+* [satellite.conf](4-configuring-icinga-2.md#satellite-conf)
 
 #### <a id="hosts-conf"></a> hosts.conf
 
 The `hosts.conf` file contains an example host based on your
-`NodeName` setting in [constants.conf](5-configuring-icinga-2.md#constants-conf). You
+`NodeName` setting in [constants.conf](4-configuring-icinga-2.md#constants-conf). You
 can use global constants for your object names instead of string
 values.
 
@@ -219,20 +219,20 @@ for check and notification commands. Most of the [Plugin Check Commands](7-icing
 in the Icinga Template Library require an `address` attribute.
 
 The custom attribute `os` is evaluated by the `linux-servers` group in
-[groups.conf](5-configuring-icinga-2.md#groups-conf) making the local host a member.
+[groups.conf](4-configuring-icinga-2.md#groups-conf) making the local host a member.
 
 The example host will show you how to
 
 * define http vhost attributes for the `http` service apply rule defined
-in [services.conf](5-configuring-icinga-2.md#services-conf).
+in [services.conf](4-configuring-icinga-2.md#services-conf).
 * define disks (all, specific `/`) and their attributes for the `disk`
-service apply rule defined in [services.conf](5-configuring-icinga-2.md#services-conf).
+service apply rule defined in [services.conf](4-configuring-icinga-2.md#services-conf).
 * define notification types (`mail`) and set the groups attribute. This
 will be used by notification apply rules in [notifications.conf](notifications-conf).
 
 If you've installed [Icinga Web 2](2-getting-started.md#setting-up-icingaweb2) you can
 uncomment the http vhost attributes and reload Icinga 2. The apply
-rules in [services.conf](5-configuring-icinga-2.md#services-conf) will automatically
+rules in [services.conf](4-configuring-icinga-2.md#services-conf) will automatically
 generate a new service checking the `/icingaweb2` URI using the `http`
 check.
 
@@ -289,7 +289,7 @@ check.
     }
 
 This is only the host object definition. Now we'll need to make sure that this
-host and your additional hosts are getting [services](5-configuring-icinga-2.md#services-conf) applied.
+host and your additional hosts are getting [services](4-configuring-icinga-2.md#services-conf) applied.
 
 > **Tip**
 >
@@ -343,7 +343,7 @@ attributes.
 
 The custom attribe `backup_downtime` is defined to a specific timerange string.
 This variable value will be used for applying a `ScheduledDowntime` object to
-these services in [downtimes.conf](5-configuring-icinga-2.md#downtimes-conf).
+these services in [downtimes.conf](4-configuring-icinga-2.md#downtimes-conf).
 
 In this example the `assign where` condition is a boolean expression which is
 evaluated for all objects of type `Host` and a new service with name "load"
@@ -374,10 +374,10 @@ rules. While one `apply` rule for `ssh` will only create a service for matching
 hosts, you can go one step further: Generate apply rules based on array items
 or dictionary key-value pairs.
 
-The idea is simple: Your host in [hosts.conf](5-configuring-icinga-2.md#hosts-conf) defines the
+The idea is simple: Your host in [hosts.conf](4-configuring-icinga-2.md#hosts-conf) defines the
 `disks` dictionary as custom attribute in `vars`.
 
-Remember the example from [hosts.conf](5-configuring-icinga-2.md#hosts-conf):
+Remember the example from [hosts.conf](4-configuring-icinga-2.md#hosts-conf):
 
     ...
 
@@ -429,7 +429,7 @@ A similar example is used for the `http` services. That way you can make your
 host the information provider for all apply rules. Define them once, and only
 manage your hosts.
 
-Look into [notifications.conf](5-configuring-icinga-2.md#notifications-conf) how this technique is used
+Look into [notifications.conf](4-configuring-icinga-2.md#notifications-conf) how this technique is used
 for applying notifications to hosts and services using their type and user
 attributes.
 
@@ -442,8 +442,8 @@ Further details on the monitoring configuration can be found in the
 #### <a id="users-conf"></a> users.conf
 
 Defines the `icingaadmin` User and the `icingaadmins` UserGroup. The latter is used in
-[hosts.conf](5-configuring-icinga-2.md#hosts-conf) for defining a custom host attribute later used in
+[hosts.conf](4-configuring-icinga-2.md#hosts-conf) for defining a custom host attribute later used in
-[notifications.conf](5-configuring-icinga-2.md#notifications-conf) for notification apply rules.
+[notifications.conf](4-configuring-icinga-2.md#notifications-conf) for notification apply rules.
 
     object User "icingaadmin" {
       import "generic-user"
@@ -470,13 +470,13 @@ nested dictionary attribute `notification.mail` is set.
 
 Please note that the `to` keyword is important in [notification apply rules](3-monitoring-basics.md#using-apply-notifications)
 defining whether these notifications are applies to hosts or services.
-The `import` keyword imports the specific mail templates defined in [templates.conf](5-configuring-icinga-2.md#templates-conf).
+The `import` keyword imports the specific mail templates defined in [templates.conf](4-configuring-icinga-2.md#templates-conf).
 
 The `interval` attribute is not explicitly set - it [defaults to 30 minutes](6-object-types.md#objecttype-notification).
 
 By setting the `user_groups` to the value provided by the
-respective [host.vars.notification.mail](5-configuring-icinga-2.md#hosts-conf) attribute we'll
+respective [host.vars.notification.mail](4-configuring-icinga-2.md#hosts-conf) attribute we'll
-implicitely use the `icingaadmins` UserGroup defined in [users.conf](5-configuring-icinga-2.md#users-conf).
+implicitely use the `icingaadmins` UserGroup defined in [users.conf](4-configuring-icinga-2.md#users-conf).
 
     apply Notification "mail-icingaadmin" to Host {
       import "mail-host-notification"
@@ -502,7 +502,7 @@ filters can be read in [this chapter](3-monitoring-basics.md#notifications).
 ### <a id="commands-conf"></a> commands.conf
 
 This is the place where your own command configuration can be defined. By default
-only the notification commands used by the notification templates defined in [templates.conf](5-configuring-icinga-2.md#templates-conf).
+only the notification commands used by the notification templates defined in [templates.conf](4-configuring-icinga-2.md#templates-conf).
 
 You can freely customize these notification commands, and adapt them for your needs.
 Read more on that topic [here](3-monitoring-basics.md#notification-commands).
@@ -601,7 +601,7 @@ More details on `Notification` object attributes can be found [here](6-object-ty
 
 #### <a id="downtimes-conf"></a> downtimes.conf
 
-The `load` service apply rule defined in [services.conf](5-configuring-icinga-2.md#services-conf) defines
+The `load` service apply rule defined in [services.conf](4-configuring-icinga-2.md#services-conf) defines
 the `backup_downtime` custom attribute.
 
 The [ScheduledDowntime](6-object-types.md#objecttype-scheduleddowntime) apply rule uses this attribute

doc/5-advanced-topics.md

@@ -53,7 +53,7 @@ is removed (may happen before or after the actual end time!).
 
 ### <a id="scheduling-downtime"></a> Scheduling a downtime
 
-This can either happen through a web interface or by sending an [external command](4-advanced-topics.md#external-commands)
+This can either happen through a web interface or by sending an [external command](5-advanced-topics.md#external-commands)
 to the external command pipe provided by the `ExternalCommandListener` configuration.
 
 Fixed downtimes require a start and end time (a duration will be ignored).
@@ -462,7 +462,7 @@ You can customize the metric prefix name by using the `host_name_template` and
 
 The example below uses [runtime macros](3-monitoring-basics.md#runtime-macros) and a
 [global constant](19-language-reference.md#constants) named `GraphiteEnv`. The constant name
-is freely definable and should be put in the [constants.conf](5-configuring-icinga-2.md#constants-conf) file.
+is freely definable and should be put in the [constants.conf](4-configuring-icinga-2.md#constants-conf) file.
 
     const GraphiteEnv = "icinga.env1"
 

doc/6-object-types.md

@@ -11,7 +11,7 @@ description are explained as well.
 ApiListener objects are used for distributed monitoring setups
 specifying the certificate files used for ssl authorization.
 
-The `NodeName` constant must be defined in [constants.conf](5-configuring-icinga-2.md#constants-conf).
+The `NodeName` constant must be defined in [constants.conf](4-configuring-icinga-2.md#constants-conf).
 
 Example:
 
@@ -319,31 +319,6 @@ Configuration Attributes:
   log_duration    |**Optional.** Duration for keeping replay logs on connection loss. Defaults to `1d`.
 
 
-## <a id="objecttype-zone"></a> Zone
-
-Zone objects are used to specify which Icinga 2 instances are located in a zone.
-
-Example:
-
-    object Zone "config-ha-master" {
-      endpoints = [ "icinga2a", "icinga2b" ]
-
-    }
-
-    object Zone "check-satellite" {
-      endpoints = [ "icinga2c" ]
-      parent = "config-ha-master"
-    }
-
-Configuration Attributes:
-
-  Name            |Description
-  ----------------|----------------
-  endpoints       |**Optional.** Dictionary with endpoints located in this zone.
-  parent          |**Optional.** The name of the parent zone.
-  global          |**Optional.** Whether configuration files for this zone should be synced to all endpoints. Defaults to false.
-
-
 ## <a id="objecttype-eventcommand"></a> EventCommand
 
 An event command definition.
@@ -999,7 +974,7 @@ ScheduledDowntime objects can be used to set up recurring downtimes for hosts/se
 > to just create a `ScheduledDowntime` template and use the `apply` keyword to assign the
 > scheduled downtime to a number of hosts or services. Use the `to` keyword to set the specific target
 > type for `Host` or `Service`.
-> Check the [recurring downtimes](4-advanced-topics.md#recurring-downtimes) example for details.
+> Check the [recurring downtimes](5-advanced-topics.md#recurring-downtimes) example for details.
 
 Example:
 

doc/7-icinga-template-library.md

@@ -1053,12 +1053,12 @@ users\_win\_crit | **Optional**. The critical threshold.
 Icinga 2 can use the `nscp client` command to run arbitrary NSClient++ checks.
 
 You can enable these check commands by adding the following the include directive in your
-[icinga2.conf](5-configuring-icinga-2.md#icinga2-conf) configuration file:
+[icinga2.conf](4-configuring-icinga-2.md#icinga2-conf) configuration file:
 
     include <nscp>
 
 You can also optionally specify an alternative installation directory for NSClient++ by adding
-the NscpPath constant in your [constants.conf](5-configuring-icinga-2.md#constants-conf) configuration
+the NscpPath constant in your [constants.conf](4-configuring-icinga-2.md#constants-conf) configuration
 file:
 
     const NscpPath = "C:\\Program Files (x86)\\NSClient++"
@@ -1146,7 +1146,7 @@ The SNMP manubulon plugin check commands assume that the global constant named `
 is set to the path where the Manubublon SNMP plugins are installed.
 
 You can enable these plugin check commands by adding the following the include directive in your
-[icinga2.conf](5-configuring-icinga-2.md#icinga2-conf) configuration file:
+[icinga2.conf](4-configuring-icinga-2.md#icinga2-conf) configuration file:
 
     include <manubulon>
 

doc/9-monitoring-remote-systems.md

@@ -36,7 +36,7 @@ Start your search at
 * [Icinga Wiki](https://wiki.icinga.org)
 
 An example is provided in the sample configuration in the getting started
-section shipped with Icinga 2 ([hosts.conf](5-configuring-icinga-2.md#hosts-conf), [services.conf](5-configuring-icinga-2.md#services-conf)).
+section provided by Icinga 2 ([hosts.conf](4-configuring-icinga-2.md#hosts-conf), [services.conf](4-configuring-icinga-2.md#services-conf)).
 
 
 ## <a id="agent-based-checks"></a> Agent-based Checks

mkdocs.yml

@@ -5,8 +5,8 @@ pages:
 - [1-about.md, About Icinga 2]
 - [2-getting-started.md, Getting Started]
 - [3-monitoring-basics.md, Monitoring Basics]
-- [4-advanced-topics.md, Advanced Topics]
+- [4-configuring-icinga-2.md, Configuring Icinga 2]
-- [5-configuring-icinga-2.md, Configuring Icinga 2]
+- [5-advanced-topics.md, Advanced Topics]
 - [6-object-types.md, Object Types]
 - [7-icinga-template-library.md, Icinga Template Library]
 - [8-cli-commands.md, CLI Commands]