Update documentation

doc/1-about.md

@@ -46,7 +46,7 @@ More details in the [Icinga FAQ](https://www.icinga.org/icinga/faq/).
 
 * [Register](https://exchange.icinga.org/authentication/register) an Icinga account.
 * Create a new issue at the [Icinga 2 Development Tracker](https://dev.icinga.org/projects/i2).
-* When reporting a bug, please include the details described in the [Troubleshooting](8-troubleshooting.md#troubleshooting-information-required) chapter (version, configs, logs, etc).
+* When reporting a bug, please include the details described in the [Troubleshooting](10-troubleshooting.md#troubleshooting-information-required) chapter (version, configs, logs, etc).
 
 ## <a id="whats-new"></a> What's new
 

doc/10-troubleshooting.md

@@ -8,7 +8,7 @@
 * Provide complete configuration snippets explaining your problem in detail
 * Provide complete logs targetting your problem
 * If the check command failed - what's the output of your manual plugin tests?
-* In case of [debugging](8-troubleshooting.md#debug) Icinga 2, the full back traces and outputs
+* In case of [debugging](10-troubleshooting.md#debug) Icinga 2, the full back traces and outputs
 
 ## <a id="troubleshooting-enable-debug-output"></a> Enable Debug Output
 
@@ -32,7 +32,7 @@ You can find the debug log file in `/var/log/icinga2/debug.log`.
 The `icinga2 object list` CLI command can be used to list all configuration objects and their
 attributes. The tool also shows where each of the attributes was modified.
 
-That way you can also identify which objects have been created from your [apply rules](10-language-reference.md#apply).
+That way you can also identify which objects have been created from your [apply rules](13-language-reference.md#apply).
 
     # icinga2 object list
 
@@ -91,13 +91,13 @@ You can also filter by name and type:
 
 ## <a id="check-command-definitions"></a> Where are the check command definitions?
 
-Icinga 2 ships additional [plugin check command definitions](13-icinga-template-library.md#plugin-check-commands) which are
+Icinga 2 ships additional [plugin check command definitions](16-icinga-template-library.md#plugin-check-commands) which are
 included using
 
     include <itl>
     include <plugins>
 
-in the [icinga2.conf](2-getting-started.md#icinga2-conf) configuration file. These configurations will be overridden
+in the [icinga2.conf](4-configuring-icinga-2.md#icinga2-conf) configuration file. These configurations will be overridden
 on upgrade, so please send modifications as proposed patches upstream. The default include path is set to
 `LocalStateDir + "/share/icinga2/includes"`.
 
@@ -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](5-cli-commands.md#features) feature is enabled.
+* Make sure the [checker](6-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](5-cli-commands.md#features) feature is enabled.
+* Make sure the [notification](6-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.
@@ -146,25 +146,25 @@ 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](2-getting-started.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?
 
 ## <a id="configuration-ignored"></a> Configuration is ignored
 
-* Make sure that the line(s) are not [commented out](10-language-reference.md#comments) (starting with `//` or `#`, or
+* Make sure that the line(s) are not [commented out](13-language-reference.md#comments) (starting with `//` or `#`, or
 encapsulated by `/* ... */`).
-* Is the configuration file included in [icinga2.conf](2-getting-started.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
 
-Icinga 2 allows you to import templates using the [import](10-language-reference.md#template-imports) keyword. If these templates
+Icinga 2 allows you to import templates using the [import](13-language-reference.md#template-imports) keyword. If these templates
 contain additional attributes, your objects will automatically inherit them. You can override
 or modify these attributes in the current object.
 
 ## <a id="troubleshooting-cluster"></a> Cluster Troubleshooting
 
-You should configure the [cluster health checks](4-monitoring-remote-systems.md#cluster-health-check) if you haven't
+You should configure the [cluster health checks](5-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](4-monitoring-remote-systems.md#zone-config-sync-permissions), or not
+* The `icinga2.log` log file will indicate whether this ApiListener [accepts config](5-monitoring-remote-systems.md#zone-config-sync-permissions), or not
 
 
 ## <a id="debug"></a> Debug Icinga 2
@@ -294,7 +294,7 @@ Icinga 2 Pretty Printers:
 Now you'll need to modify/setup your `~/.gdbinit` configuration file.
 You can download the one from Icinga 2 and modify all paths.
 
-Example on Fedora 20 x64:
+Example on Fedora:
 
     $ wget https://raw.githubusercontent.com/Icinga/icinga2/master/tools/debug/gdb/gdbinit -O ~/.gdbinit
     $ vim ~/.gdbinit

doc/11-upgrading-icinga-2.md

@@ -0,0 +1,57 @@
+# Upgrading Icinga 2
+
+Upgrading Icinga 2 is usually quite straightforward. Ordinarily the only manual steps involved
+are scheme updates for the IDO database.
+
+## <a id="upgrading-mysql-db"></a> Upgrading the MySQL database
+
+If you're upgrading an existing Icinga 2 instance you should check the
+`/usr/share/icinga2-ido-mysql/schema/upgrade` directory for an incremental schema upgrade file.
+
+> **Note**
+>
+> If there isn't an upgrade file for your current version available there's nothing to do.
+
+Apply all database schema upgrade files incrementially.
+
+    # mysql -u root -p icinga < /usr/share/icinga2-ido-mysql/schema/upgrade/<version>.sql
+
+The Icinga 2 DB IDO module will check for the required database schema version on startup
+and generate an error message if not satisfied.
+
+
+**Example:** You are upgrading Icinga 2 from version `2.0.2` to `2.2.0`. Look into
+the *upgrade* directory:
+
+    $ ls /usr/share/icinga2-ido-mysql/schema/upgrade/
+    2.0.2.sql  2.1.0.sql 2.2.0.sql
+
+There are two new upgrade files called `2.1.0.sql` and `2.2.0.sql`
+which must be applied incrementially to your IDO database.
+
+## <a id="upgrading-postgresql-db"></a> Upgrading the PostgreSQL database
+
+If you're updating an existing Icinga 2 instance you should check the
+`/usr/share/icinga2-ido-pgsql/schema/upgrade` directory for an incremental schema upgrade file.
+
+> **Note**
+>
+> If there isn't an upgrade file for your current version available there's nothing to do.
+
+Apply all database schema upgrade files incrementially.
+
+    # export PGPASSWORD=icinga
+    # psql -U icinga -d icinga < /usr/share/icinga2-ido-pgsql/schema/upgrade/<version>.sql
+
+The Icinga 2 DB IDO module will check for the required database schema version on startup
+and generate an error message if not satisfied.
+
+**Example:** You are upgrading Icinga 2 from version `2.0.2` to `2.1.0`. Look into
+the *upgrade* directory:
+
+    $ ls /usr/share/icinga2-ido-pgsql/schema/upgrade/
+    2.0.2.sql  2.1.0.sql 2.2.0.sql
+
+There are two new upgrade files called `2.1.0.sql` and `2.2.0.sql`
+which must be applied incrementially to your IDO database.
+

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

@@ -27,7 +27,7 @@ If you encounter a bug, please open an issue at https://dev.icinga.org.
 For a long-term migration of your configuration you should consider re-creating
 your configuration based on the proposed Icinga 2 configuration paradigm.
 
-Please read the [next chapter](9-migrating-from-icinga-1x.md#differences-1x-2) to find out more about the differences
+Please read the [next chapter](12-migrating-from-icinga-1x.md#differences-1x-2) to find out more about the differences
 between 1.x and 2.
 
 ### <a id="manual-config-migration-hints"></a> Manual Config Migration Hints
@@ -39,7 +39,7 @@ Icinga 1.x configuration.
 The examples are taken from Icinga 1.x test and production environments and converted
 straight into a possible Icinga 2 format. If you found a different strategy, send a patch!
 
-If you require in-depth explanations, please check the [next chapter](9-migrating-from-icinga-1x.md#differences-1x-2).
+If you require in-depth explanations, please check the [next chapter](12-migrating-from-icinga-1x.md#differences-1x-2).
 
 #### <a id="manual-config-migration-hints-Intervals"></a> Manual Config Migration Hints for Intervals
 
@@ -127,7 +127,7 @@ a member and includes all members of the `hg1` hostgroup.
       hostgroup_members               hg1
     }
 
-This can be migrated to Icinga 2 and [using group assign](10-language-reference.md#group-assign). The additional nested hostgroup
+This can be migrated to Icinga 2 and [using group assign](13-language-reference.md#group-assign). The additional nested hostgroup
 `hg1` is included into `hg2` with the `groups` attribute.
 
 
@@ -217,8 +217,8 @@ directory - one major problem solved.
 For the check command it is required to
 
 * Escape all double quotes with an additional `\`.
-* Replace all [runtime macros](9-migrating-from-icinga-1x.md#manual-config-migration-hints-runtime-macros), e.g. `$HOSTADDRESS$` with `$address$`.
+* Replace all [runtime macros](12-migrating-from-icinga-1x.md#manual-config-migration-hints-runtime-macros), e.g. `$HOSTADDRESS$` with `$address$`.
-* Replace [custom variable macros](9-migrating-from-icinga-1x.md#manual-config-migration-hints-runtime-custom-attributes) if any.
+* Replace [custom variable macros](12-migrating-from-icinga-1x.md#manual-config-migration-hints-runtime-custom-attributes) if any.
 * Keep `$ARGn$` macros.
 
 The final check command looks like this in Icinga2:
@@ -257,7 +257,7 @@ That way the old command arguments fashion can be applied for Icinga 2, although
 
 #### <a id="manual-config-migration-hints-runtime-macros"></a> Manual Config Migration Hints for Runtime Macros
 
-Runtime macros have been renamed. A detailed comparison table can be found [here](9-migrating-from-icinga-1x.md#differences-1x-2-runtime-macros).
+Runtime macros have been renamed. A detailed comparison table can be found [here](12-migrating-from-icinga-1x.md#differences-1x-2-runtime-macros).
 
 For example, accessing the service check output looks like the following in Icinga 1.x:
 
@@ -318,7 +318,7 @@ while the service check command resolves its value to the service attribute attr
 #### <a id="manual-config-migration-hints-contacts-users"></a> Manual Config Migration Hints for Contacts (Users)
 
 Contacts in Icinga 1.x act as users in Icinga 2, but do not have any notification commands specified.
-This migration part is explained in the [next chapter](9-migrating-from-icinga-1x.md#manual-config-migration-hints-notifications).
+This migration part is explained in the [next chapter](12-migrating-from-icinga-1x.md#manual-config-migration-hints-notifications).
 
     define contact{
       contact_name                    testconfig-user
@@ -328,7 +328,7 @@ This migration part is explained in the [next chapter](9-migrating-from-icinga-1
       email                           icinga@localhost
     }
 
-The `service_notification_options` can be [mapped](9-migrating-from-icinga-1x.md#manual-config-migration-hints-notification-filters)
+The `service_notification_options` can be [mapped](12-migrating-from-icinga-1x.md#manual-config-migration-hints-notification-filters)
 into generic `state` and `type` filters, if additional notification filtering is required. `alias` gets
 renamed to `display_name`.
 
@@ -380,7 +380,7 @@ Assign it to the host or service and set the newly generated notification comman
 
 
 Convert the `notification_options` attribute from Icinga 1.x to Icinga 2 `states` and `types`. Details
-[here](9-migrating-from-icinga-1x.md#manual-config-migration-hints-notification-filters). Add the notification period.
+[here](12-migrating-from-icinga-1x.md#manual-config-migration-hints-notification-filters). Add the notification period.
 
       states = [ OK, Warning, Critical ]
       types = [ Recovery, Problem, Custom ]
@@ -617,7 +617,7 @@ enabled.
       assign where "hg_svcdep2" in host.groups
     }
 
-Host dependencies are explained in the [next chapter](9-migrating-from-icinga-1x.md#manual-config-migration-hints-host-parents).
+Host dependencies are explained in the [next chapter](12-migrating-from-icinga-1x.md#manual-config-migration-hints-host-parents).
 
 
 
@@ -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](4-monitoring-remote-systems.md#cluster-scenarios-load-distribution) setup with Icinga 2.
+building a [load distribution](5-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](4-monitoring-remote-systems.md#cluster-scenarios-high-availability) setup.
+consider the [High Availability](5-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.
@@ -773,11 +773,11 @@ included in `icinga2.conf` by default.
 ### <a id="differences-1x-2-main-config"></a> Main Config File
 
 In Icinga 1.x there are many global configuration settings available in `icinga.cfg`.
-Icinga 2 only uses a small set of [global constants](10-language-reference.md#constants) allowing
+Icinga 2 only uses a small set of [global constants](13-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](2-getting-started.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](5-cli-commands.md#features) and the object configuration.
+global constants, enabled [features](6-cli-commands.md#features) and the object configuration.
 
 ### <a id="differences-1x-2-include-files-dirs"></a> Include Files and Directories
 
@@ -826,7 +826,7 @@ set in the `constants.conf` configuration file:
 
     const PluginDir = "/usr/lib/nagios/plugins"
 
-[Global macros](10-language-reference.md#constants) can only be defined once. Trying to modify a
+[Global macros](13-language-reference.md#constants) can only be defined once. Trying to modify a
 global constant will result in an error.
 
 ### <a id="differences-1x-2-configuration-comments"></a> Configuration Comments
@@ -1251,7 +1251,7 @@ timeout. This was essentially bad when there only was a couple of check plugins
 requiring some command timeouts to be extended.
 
 Icinga 2 allows you to specify the command timeout directly on the command. So
-if your VMVware check plugin takes 15 minutes, [increase the timeout](12-object-types.md#objecttype-checkcommand)
+if your VMVware check plugin takes 15 minutes, [increase the timeout](15-object-types.md#objecttype-checkcommand)
 accordingly.
 
 
@@ -1386,7 +1386,7 @@ child attributes may be omitted.
 For detailed examples on how to use the dependencies please check the [dependencies](3-monitoring-basics.md#dependencies)
 chapter.
 
-Dependencies can be applied to hosts or services using the [apply rules](10-language-reference.md#apply).
+Dependencies can be applied to hosts or services using the [apply rules](13-language-reference.md#apply).
 
 The `StatusDataWriter`, `IdoMysqlConnection` and `LivestatusListener` types
 support the Icinga 1.x schema with dependencies and parent attributes for
@@ -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](4-monitoring-remote-systems.md#cluster-zone-config-sync))
+(this is ESSENTIAL for the [cluster config synchronisation](5-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](4-monitoring-remote-systems.md#distributed-monitoring-high-availability),
+Icinga 2 implements a new built-in [distributed monitoring architecture](5-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.

doc/13-language-reference.md

@@ -188,7 +188,7 @@ Functions can be called using the `()` operator:
       check_interval = len(MyGroups) * 1m
     }
 
-A list of available functions is available in the [Library Reference](11-library-reference.md#library-reference) chapter.
+A list of available functions is available in the [Library Reference](14-library-reference.md#library-reference) chapter.
 
 ## <a id="dictionary-operators"></a> Assignments
 
@@ -383,7 +383,7 @@ another group of objects.
 
 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 "ping"
-is created for each matching host. [Expression operators](10-language-reference.md#expression-operators)
+is created for each matching host. [Expression operators](13-language-reference.md#expression-operators)
 may be used in `assign where` conditions.
 
 The `to` keyword and the target type may be omitted if there is only one target
@@ -420,7 +420,7 @@ and `ignore where` conditions.
 In this example the `assign where` condition is a boolean expression which is evaluated
 for all objects of the type `Host`. Each matching host is added as member to the host group
 with the name "linux-servers". Membership exclusion can be controlled using the `ignore where`
-condition. [Expression operators](10-language-reference.md#expression-operators) may be used in `assign where` and
+condition. [Expression operators](13-language-reference.md#expression-operators) may be used in `assign where` and
 `ignore where` conditions.
 
 Source Type       | Variables
@@ -449,7 +449,7 @@ Empty dictionary     | {}                | false
 Non-empty dictionary | { key = "value" } | true
 
 For a list of supported expression operators for `assign where` and `ignore where`
-statements, see [expression operators](10-language-reference.md#expression-operators).
+statements, see [expression operators](13-language-reference.md#expression-operators).
 
 ## <a id="comments"></a> Comments
 
@@ -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](5-cli-commands.md#config-include-path).
+[command-line options](6-cli-commands.md#config-include-path).
 
 Wildcards are not permitted when using angle brackets.
 

doc/14-library-reference.md

@@ -16,6 +16,7 @@ bool(value)                     | Converts the value to a bool.
 random()                        | Returns a random value between 0 and RAND_MAX (as defined in stdlib.h).
 log(value)                      | Writes a message to the log. Non-string values are converted to a JSON string.
 log(severity, facility, value)  | Writes a message to the log. `severity` can be one of `LogDebug`, `LogNotice`, `LogInformation`, `LogWarning`, and `LogCritical`. Non-string values are converted to a JSON string.
+typeof(value)                   | Returns the type object for a value.
 exit(integer)                   | Terminates the application.
 
 ## <a id="math-object"></a> Math object
@@ -356,7 +357,7 @@ Signature:
 
     function add(value);
 
-TODO
+Adds a new value after the last element in the array.
 
 ### <a id="array-clear"></a> Array#clear
 
@@ -364,13 +365,14 @@ Signature:
 
     function clear();
 
-TODO
+Removes all elements from the array.
 
 ### <a id="array-clone"></a> Array#clone
 
     function clone();
 
-TODO
+Returns a copy of the array. Note that for elements which are reference values (e.g. objects such
+as arrays and dictionaries) only the references are copied.
 
 ### <a id="array-contains"></a> Array#contains
 
@@ -378,7 +380,7 @@ Signature:
 
     function contains(value);
 
-TODO
+Returns true if the array contains the specified value, false otherwise.
 
 ### <a id="array-len"></a> Array#len
 
@@ -386,7 +388,7 @@ Signature:
 
     function len();
 
-TODO
+Returns the number of elements contained in the array.
 
 ### <a id="array-remove"></a> Array#remove
 
@@ -394,7 +396,7 @@ Signature:
 
     function remove(index);
 
-TODO
+Removes the element at the specified zero-based index.
 
 ### <a id="array-set"></a> Array#set
 
@@ -402,7 +404,8 @@ Signature:
 
     function set(index, value);
 
-TODO
+Sets the element at the zero-based index to the specified value. The `index` must refer to an element
+which already exists in the array.
 
 ### <a id="array-sort"></a> Array#sort
 
@@ -422,7 +425,8 @@ Signature:
 
     function clone();
 
-TODO
+Returns a copy of the dictionary. Note that for elements which are reference values (e.g. objects such
+as arrays and dictionaries) only the references are copied.
 
 ### <a id="dictionary-contains"></a> Dictionary#contains
 
@@ -430,7 +434,7 @@ Signature:
 
     function contains(key);
 
-TODO
+Returns true if a dictionary item with the specified `key` exists, false otherwise.
 
 ### <a id="dictionary-len"></a> Dictionary#len
 
@@ -438,7 +442,7 @@ Signature:
 
     function len();
 
-TODO
+Returns the number of items contained in the dictionary.
 
 ### <a id="dictionary-remove"></a> Dictionary#remove
 
@@ -446,7 +450,8 @@ Signature:
 
     function remove(key);
 
-TODO
+Removes the item with the specified `key`. Trying to remove an item which does not exist
+is a no-op.
 
 ### <a id="dictionary-set"></a> Dictionary#set
 
@@ -454,7 +459,7 @@ Signature:
 
     function set(key, value);
 
-TODO
+Creates or updates an item with the specified `key` and `value`.
 
 ## <a id="scriptfunction-type"></a> Function type
 

doc/15-object-types.md

@@ -59,7 +59,7 @@ A group of hosts.
 
 > **Best Practice**
 >
-> Assign host group members using the [group assign](10-language-reference.md#group-assign) rules.
+> Assign host group members using the [group assign](13-language-reference.md#group-assign) rules.
 
 Example:
 
@@ -145,7 +145,7 @@ A group of services.
 
 > **Best Practice**
 >
-> Assign service group members using the [group assign](10-language-reference.md#group-assign) rules.
+> Assign service group members using the [group assign](13-language-reference.md#group-assign) rules.
 
 Example:
 
@@ -224,7 +224,7 @@ A user group.
 
 > **Best Practice**
 >
-> Assign user group members using the [group assign](10-language-reference.md#group-assign) rules.
+> Assign user group members using the [group assign](13-language-reference.md#group-assign) rules.
 
 Example:
 
@@ -398,7 +398,7 @@ Attributes:
   zone		  |**Optional.** The zone this object is a member of.
   arguments       |**Optional.** A dictionary of command arguments.
 
-Command arguments can be used the same way as for [CheckCommand objects](12-object-types.md#objecttype-checkcommand-arguments).
+Command arguments can be used the same way as for [CheckCommand objects](15-object-types.md#objecttype-checkcommand-arguments).
 
 
 ## <a id="objecttype-eventcommand"></a> EventCommand
@@ -425,7 +425,7 @@ Attributes:
   timeout         |**Optional.** The command timeout in seconds. Defaults to 60 seconds.
   arguments       |**Optional.** A dictionary of command arguments.
 
-Command arguments can be used the same way as for [CheckCommand objects](12-object-types.md#objecttype-checkcommand-arguments).
+Command arguments can be used the same way as for [CheckCommand objects](15-object-types.md#objecttype-checkcommand-arguments).
 
 
 ## <a id="objecttype-notification"></a> Notification
@@ -737,7 +737,7 @@ Attributes:
 
 Metric prefix names can be modified using [runtime macros](3-monitoring-basics.md#runtime-macros).
 
-Example with your custom [global constant](10-language-reference.md#constants) `GraphiteEnv`:
+Example with your custom [global constant](13-language-reference.md#constants) `GraphiteEnv`:
 
     const GraphiteEnv = "icinga.env1"
 
@@ -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](4-monitoring-remote-systems.md#high-availability-db-ido). Defaults to "true".
+  enable_ha       |**Optional.** Enable the high availability functionality. Only valid in a [cluster setup](5-monitoring-remote-systems.md#high-availability-db-ido). Defaults to "true".
-  failover_timeout | **Optional.** Set the failover timeout in a [HA cluster](4-monitoring-remote-systems.md#high-availability-db-ido). Must not be lower than 60s. Defaults to "60s".
+  failover_timeout | **Optional.** Set the failover timeout in a [HA cluster](5-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](4-monitoring-remote-systems.md#high-availability-db-ido). Defaults to "true".
+  enable_ha       |**Optional.** Enable the high availability functionality. Only valid in a [cluster setup](5-monitoring-remote-systems.md#high-availability-db-ido). Defaults to "true".
-  failover_timeout | **Optional.** Set the failover timeout in a [HA cluster](4-monitoring-remote-systems.md#high-availability-db-ido). Must not be lower than 60s. Defaults to "60s".
+  failover_timeout | **Optional.** Set the failover timeout in a [HA cluster](5-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.
 
@@ -1154,7 +1154,7 @@ Attributes:
 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](2-getting-started.md#constants-conf).
+The `NodeName` constant must be defined in [constants.conf](4-configuring-icinga-2.md#constants-conf).
 
 Example:
 

doc/16-icinga-template-library.md

@@ -1,7 +1,5 @@
 # <a id="icinga-template-library"></a> Icinga Template Library
 
-## <a id="itl-overview"></a> Overview
-
 The Icinga Template Library (ITL) implements standard templates and object
 definitions for commonly used services.
 
@@ -62,8 +60,6 @@ cluster_zone | **Optional.** The zone name. Defaults to "$host.name$".
 
 # <a id="plugin-check-commands"></a> Plugin Check Commands
 
-## <a id="plugin-check-command-overview"></a> Overview
-
 The Plugin Check Commands provides example configuration for plugin check commands
 provided by the Monitoring Plugins project.
 
@@ -613,8 +609,6 @@ The `running_kernel` check command does not support any vars.
 
 # <a id="snmp-manubulon-plugin-check-commands"></a> SNMP Manubulon Plugin Check Commands
 
-## <a id="snmp-manubulon-plugin-check-commands-overview"></a> Overview
-
 The `SNMP Manubulon Plugin Check Commands` provide example configuration for plugin check
 commands provided by the [SNMP Manubulon project](http://nagios.manubulon.com/index_snmp.html).
 
@@ -622,7 +616,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
-configuration [icinga2.conf](2-getting-started.md#icinga2-conf) file:
+configuration [icinga2.conf](4-configuring-icinga-2.md#icinga2-conf) file:
 
     include <manubulon>
 

doc/3-monitoring-basics.md

@@ -43,7 +43,7 @@ check command.
 The `address` attribute is used by check commands to determine which network
 address is associated with the host object.
 
-Details on troubleshooting check problems can be found [here](8-troubleshooting.md#troubleshooting).
+Details on troubleshooting check problems can be found [here](10-troubleshooting.md#troubleshooting).
 
 ### <a id="host-states"></a> Host States
 
@@ -97,7 +97,7 @@ there is no check available, the `dummy` check command.
 Service checks could also use a `dummy` check, but the common strategy is to
 [integrate an existing plugin](3-monitoring-basics.md#command-plugin-integration) as
 [check command](3-monitoring-basics.md#check-commands) and [reference](3-monitoring-basics.md#command-passing-parameters)
-that in your [Service](12-object-types.md#objecttype-service) object definition.
+that in your [Service](15-object-types.md#objecttype-service) object definition.
 
 ## <a id="configuration-best-practice"></a> Configuration Best Practice
 
@@ -109,7 +109,7 @@ requirements first and then decide for a possible strategy.
 There are many ways of creating Icinga 2 configuration objects:
 
 * Manually with your preferred editor, for example vi(m), nano, notepad, etc.
-* Generated by a [configuration management too](2-getting-started.md#configuration-tools) such as Puppet, Chef, Ansible, etc.
+* Generated by a [configuration management too](7-addons-plugins.md#configuration-tools) such as Puppet, Chef, Ansible, etc.
 * A configuration addon for Icinga 2
 * A custom exporter script from your CMDB or inventory tool
 * your own.
@@ -128,7 +128,7 @@ instead of defining objects on a per 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](2-getting-started.md#icinga2-conf) configuration file includes them, and then think about:
+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.
 * flat `hosts.conf`, `services.conf`, etc files for rule based configuration.
@@ -143,7 +143,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](2-getting-started.md#services-conf) or [notifications.conf](2-getting-started.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.
@@ -213,18 +213,18 @@ Example for importing objects:
 
 ### <a id="using-apply"></a> Apply objects based on rules
 
-Instead of assigning each object ([Service](12-object-types.md#objecttype-service),
+Instead of assigning each object ([Service](15-object-types.md#objecttype-service),
-[Notification](12-object-types.md#objecttype-notification), [Dependency](12-object-types.md#objecttype-dependency),
+[Notification](15-object-types.md#objecttype-notification), [Dependency](15-object-types.md#objecttype-dependency),
-[ScheduledDowntime](12-object-types.md#objecttype-scheduleddowntime))
+[ScheduledDowntime](15-object-types.md#objecttype-scheduleddowntime))
-based on attribute identifiers for example `host_name` objects can be [applied](10-language-reference.md#apply).
+based on attribute identifiers for example `host_name` objects can be [applied](13-language-reference.md#apply).
 
 Before you start using the apply rules keep the following in mind:
 
 * Define the best match.
     * A set of unique [custom attributes](3-monitoring-basics.md#custom-attributes-apply) 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](10-language-reference.md#function-calls) on the host/service name?
+    * A generic pattern [match](13-language-reference.md#function-calls) on the host/service name?
-    * [Multiple expressions combined](3-monitoring-basics.md#using-apply-expressions) with `&&` or `||` [operators](10-language-reference.md#expression-operators)
+    * [Multiple expressions combined](3-monitoring-basics.md#using-apply-expressions) with `&&` or `||` [operators](13-language-reference.md#expression-operators)
 * All expressions must return a boolean value (an empty string is equal to `false` e.g.)
 
 > **Note**
@@ -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](5-cli-commands.md#cli-command-object)
+> of the generated objects. Use the `object list` [CLI command](6-cli-commands.md#cli-command-object)
-> after successful [configuration validation](5-cli-commands.md#config-validation).
+> after successful [configuration validation](6-cli-commands.md#config-validation).
 
 
 #### <a id="using-apply-expressions"></a> Apply Rules Expressions
@@ -288,7 +288,7 @@ two condition passes: Either the `customer` host custom attribute is set to `cus
 `OR` the host custom attribute `always_notify` is set to `true`.
 
 The notification is ignored for services whose host name ends with `*internal`
-`OR` the `priority` custom attribute is [less than](10-language-reference.md#expression-operators) `2`.
+`OR` the `priority` custom attribute is [less than](13-language-reference.md#expression-operators) `2`.
 
     template Notification "cust-xy-notification" {
       users = [ "noc-xy", "mgmt-xy" ]
@@ -307,8 +307,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 ships a detailed example in [hosts.conf](2-getting-started.md#hosts-conf)
+The sample configuration already ships a detailed example in [hosts.conf](4-configuring-icinga-2.md#hosts-conf)
-and [services.conf](2-getting-started.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`.
@@ -350,7 +350,7 @@ 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 confituration ships an example in [downtimes.conf](2-getting-started.md#downtimes-conf).
+The sample confituration ships an example in [downtimes.conf](4-configuring-icinga-2.md#downtimes-conf).
 
 Detailed examples can be found in the [recurring downtimes](3-monitoring-basics.md#recurring-downtimes) chapter.
 
@@ -362,8 +362,8 @@ apply rules objects based on set (array or dictionary). That way you'll save qui
 of a lot of duplicated apply rules by combining them into one generic generating
 the object name with or without a prefix.
 
-The sample configuration already ships a detailed example in [hosts.conf](2-getting-started.md#hosts-conf)
+The sample configuration already ships a detailed example in [hosts.conf](4-configuring-icinga-2.md#hosts-conf)
-and [services.conf](2-getting-started.md#services-conf) for this use case.
+and [services.conf](4-configuring-icinga-2.md#services-conf) for this use case.
 
 Imagine a different example: You are monitoring your switch (hosts) with many
 interfaces (services). The following requirements/problems apply:
@@ -432,13 +432,13 @@ You can also specifiy the check command that way.
     }
 
 Note that numbers must be explicitely casted to string when adding to strings.
-This can be achieved by wrapping them into the [string()](10-language-reference.md#function-calls) function.
+This can be achieved by wrapping them into the [string()](13-language-reference.md#function-calls) function.
 
 > **Tip**
 >
 > Building configuration in that dynamic way requires detailed information
-> of the generated objects. Use the `object list` [CLI command](5-cli-commands.md#cli-command-object)
+> of the generated objects. Use the `object list` [CLI command](6-cli-commands.md#cli-command-object)
-> after successful [configuration validation](5-cli-commands.md#config-validation).
+> after successful [configuration validation](6-cli-commands.md#config-validation).
 
 
 #### <a id="using-apply-object attributes"></a> Use Object Attributes in Apply Rules
@@ -545,7 +545,7 @@ the user groups are associated as attributes in `Notification` objects.
 
 If there is a certain number of hosts, services, or users matching a pattern
 it's reasonable to assign the group object to these members.
-Details on the `assign where` syntax can be found [here](10-language-reference.md#apply)
+Details on the `assign where` syntax can be found [here](13-language-reference.md#apply)
 
     object HostGroup "prod-mssql" {
       display_name = "Production MSSQL Servers"
@@ -590,11 +590,11 @@ The user `icingaadmin` in the example below will get notified only on `WARNING`
 If you don't set the `states` and `types` configuration attributes for the `User`
 object, notifications for all states and types will be sent.
 
-Details on troubleshooting notification problems can be found [here](8-troubleshooting.md#troubleshooting).
+Details on troubleshooting notification problems can be found [here](10-troubleshooting.md#troubleshooting).
 
 > **Note**
 >
-> Make sure that the [notification](5-cli-commands.md#features) feature is enabled on your master instance
+> Make sure that the [notification](6-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
@@ -886,25 +886,25 @@ Please check [Runtime Custom Attributes as Environment Variables](3-monitoring-b
 
 ### <a id="check-commands"></a> Check Commands
 
-[CheckCommand](12-object-types.md#objecttype-checkcommand) objects define the command line how
+[CheckCommand](15-object-types.md#objecttype-checkcommand) objects define the command line how
 a check is called.
 
-[CheckCommand](12-object-types.md#objecttype-checkcommand) objects are referenced by
+[CheckCommand](15-object-types.md#objecttype-checkcommand) objects are referenced by
-[Host](12-object-types.md#objecttype-host) and [Service](12-object-types.md#objecttype-service) objects
+[Host](15-object-types.md#objecttype-host) and [Service](15-object-types.md#objecttype-service) objects
 using the `check_command` attribute.
 
 > **Note**
 >
-> Make sure that the [checker](5-cli-commands.md#features) feature is enabled in order to
+> Make sure that the [checker](6-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
 
-[CheckCommand](12-object-types.md#objecttype-checkcommand) objects require the [ITL template](13-icinga-template-library.md#itl-plugin-check-command)
+[CheckCommand](15-object-types.md#objecttype-checkcommand) objects require the [ITL template](16-icinga-template-library.md#itl-plugin-check-command)
 `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](2-getting-started.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 shipped with the Monitoring Plugins package.
 
 The plugin path and all command arguments are made a list of
@@ -932,7 +932,7 @@ partition defined (`-p`) it will check all local partitions.
 > Don't execute plugins as `root` and always use the absolute path to the plugin! Trust us.
 
 Next step is to understand how command parameters are being passed from
-a host or service object, and add a [CheckCommand](12-object-types.md#objecttype-checkcommand)
+a host or service object, and add a [CheckCommand](15-object-types.md#objecttype-checkcommand)
 definition based on these required parameters and/or default values.
 
 #### <a id="command-passing-parameters"></a> Passing Check Command Parameters from Host or Service
@@ -976,7 +976,7 @@ can also be inherited from a parent template using additive inheritance (`+=`).
 > **Note**
 >
 > A proper example for the `check_disk` plugin is already shipped with Icinga 2
-> ready to use with the [plugin check commands](13-icinga-template-library.md#plugin-check-command-disk).
+> ready to use with the [plugin check commands](16-icinga-template-library.md#plugin-check-command-disk).
 
 The host `localhost` with the applied service `basic-partitions` checks a basic set of disk partitions
 with modified custom attributes (warning thresholds at `10%`, critical thresholds at `5%`
@@ -1072,7 +1072,7 @@ That way you can use the `check_http` command definition for both, with and
 without SSL enabled checks saving you duplicated command definitions.
 
 Details on all available options can be found in the
-[CheckCommand object definition](12-object-types.md#objecttype-checkcommand).
+[CheckCommand object definition](15-object-types.md#objecttype-checkcommand).
 
 ### <a id="using-apply-services-command-arguments"></a> Apply Services with Custom Command Arguments
 
@@ -1100,7 +1100,7 @@ the `my-host2` host requires a different port on 2222. Both hosts are in the hos
     }
 
 All hosts in the `my-linux-servers` hostgroup should get the `my-ssh` service applied based on an
-[apply rule](10-language-reference.md#apply). The optional `ssh_port` command argument should be inherited from the host
+[apply rule](13-language-reference.md#apply). The optional `ssh_port` command argument should be inherited from the host
 the service is applied to. If not set, the check command `my-ssh` will omit the argument.
 The `host` argument is special: `skip_key` tells Icinga 2 to ignore the key, and directly put the
 value onto the command line. The `order` attribute specifies that this argument is the first one
@@ -1145,18 +1145,18 @@ The `my-host2` will inherit the `custom_ssh_port` variable to the service and ex
 
 ### <a id="notification-commands"></a> Notification Commands
 
-[NotificationCommand](12-object-types.md#objecttype-notificationcommand) objects define how notifications are delivered to external
+[NotificationCommand](15-object-types.md#objecttype-notificationcommand) objects define how notifications are delivered to external
 interfaces (E-Mail, XMPP, IRC, Twitter, etc).
 
-[NotificationCommand](12-object-types.md#objecttype-notificationcommand) objects are referenced by
+[NotificationCommand](15-object-types.md#objecttype-notificationcommand) objects are referenced by
-[Notification](12-object-types.md#objecttype-notification) objects using the `command` attribute.
+[Notification](15-object-types.md#objecttype-notification) objects using the `command` attribute.
 
-`NotificationCommand` objects require the [ITL template](13-icinga-template-library.md#itl-plugin-notification-command)
+`NotificationCommand` objects require the [ITL template](16-icinga-template-library.md#itl-plugin-notification-command)
 `plugin-notification-command` to support native plugin-based notifications.
 
 > **Note**
 >
-> Make sure that the [notification](5-cli-commands.md#features) feature is enabled on your master instance
+> Make sure that the [notification](6-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
@@ -1231,8 +1231,8 @@ check execution if one of these conditions match:
 * The host/service state changes into a [hard state](3-monitoring-basics.md#hard-soft-states)
 * The host/service state recovers from a [soft or hard state](3-monitoring-basics.md#hard-soft-states) to [OK](3-monitoring-basics.md#service-states)/[Up](3-monitoring-basics.md#host-states)
 
-[EventCommand](12-object-types.md#objecttype-eventcommand) objects are referenced by
+[EventCommand](15-object-types.md#objecttype-eventcommand) objects are referenced by
-[Host](12-object-types.md#objecttype-host) and [Service](12-object-types.md#objecttype-service) objects
+[Host](15-object-types.md#objecttype-host) and [Service](15-object-types.md#objecttype-service) objects
 using the `event_command` attribute.
 
 Therefore the `EventCommand` object should define a command line
@@ -1269,7 +1269,7 @@ Example on Debian:
     icinga  ALL=(ALL) NOPASSWD: /etc/init.d/apache2 restart
 
 
-Define a generic [EventCommand](12-object-types.md#objecttype-eventcommand) object `event_by_ssh`
+Define a generic [EventCommand](15-object-types.md#objecttype-eventcommand) object `event_by_ssh`
 which can be used for all event commands triggered using ssh:
 
     /* pass event commands through ssh */
@@ -1370,7 +1370,7 @@ Remote Host Terminal:
 
 ## <a id="dependencies"></a> Dependencies
 
-Icinga 2 uses host and service [Dependency](12-object-types.md#objecttype-dependency) objects
+Icinga 2 uses host and service [Dependency](15-object-types.md#objecttype-dependency) objects
 for determing their network reachability.
 
 A service can depend on a host, and vice versa. A service has an implicit
@@ -1405,7 +1405,7 @@ Rephrased: If the parent service object changes into the `Warning` state, this
 dependency will fail and render all child objects (hosts or services) unreachable.
 
 You can determine the child's reachability by querying the `is_reachable` attribute
-in for example [DB IDO](14-appendix.md#schema-db-ido-extensions).
+in for example [DB IDO](17-appendix.md#schema-db-ido-extensions).
 
 ### <a id="dependencies-implicit-host-service"></a> Implicit Dependencies for Services on Host
 
@@ -1657,7 +1657,7 @@ downtime on NOT-OK state change.
 
 ### <a id="recurring-downtimes"></a> Recurring Downtimes
 
-[ScheduledDowntime objects](12-object-types.md#objecttype-scheduleddowntime) can be used to set up
+[ScheduledDowntime objects](15-object-types.md#objecttype-scheduleddowntime) can be used to set up
 recurring downtimes for services.
 
 Example:
@@ -1728,9 +1728,9 @@ for applying objects for dynamic config generation.
 
 There are several ways of using custom attributes with [apply rules](3-monitoring-basics.md#using-apply):
 
-* As simple attribute literal ([number](10-language-reference.md#numeric-literals), [string](10-language-reference.md#string-literals),
+* As simple attribute literal ([number](13-language-reference.md#numeric-literals), [string](13-language-reference.md#string-literals),
-[boolean](10-language-reference.md#boolean-literals)) for expression conditions (`assign where`, `ignore where`)
+[boolean](13-language-reference.md#boolean-literals)) for expression conditions (`assign where`, `ignore where`)
-* As [array](10-language-reference.md#array) or [dictionary](10-language-reference.md#dictionary) attribute with nested values
+* As [array](13-language-reference.md#array) or [dictionary](13-language-reference.md#dictionary) attribute with nested values
 (e.g. dictionaries in dictionaries) in [apply for](3-monitoring-basics.md#using-apply-for) rules.
 
 Features like [DB IDO](3-monitoring-basics.md#db-ido), Livestatus(#setting-up-livestatus) or StatusData(#status-data)
@@ -1751,7 +1751,7 @@ which use custom runtime attributes to format their output.
 > **Tip**
 >
 > Custom attributes are identified by the `vars` dictionary attribute as short name.
-> Accessing the different attribute keys is possible using the [index accessor](10-language-reference.md#indexer) `.`.
+> Accessing the different attribute keys is possible using the [index accessor](13-language-reference.md#indexer) `.`.
 
 Custom attributes in command definitions or performance data templates are evaluated at
 runtime when executing a command. These custom attributes cannot be used somewhere else
@@ -1764,13 +1764,13 @@ Arrays can be used to pass multiple arguments with or without repeating the key
 This helps passing multiple parameters to check plugins requiring them. Prominent
 plugin examples are:
 
-* [check_disk -p](13-icinga-template-library.md#plugin-check-command-disk)
+* [check_disk -p](16-icinga-template-library.md#plugin-check-command-disk)
-* [check_nrpe -a](13-icinga-template-library.md#plugin-check-command-nrpe)
+* [check_nrpe -a](16-icinga-template-library.md#plugin-check-command-nrpe)
-* [check_nscp -l](13-icinga-template-library.md#plugin-check-command-nscp)
+* [check_nscp -l](16-icinga-template-library.md#plugin-check-command-nscp)
-* [check_dns -a](13-icinga-template-library.md#plugin-check-command-dns)
+* [check_dns -a](16-icinga-template-library.md#plugin-check-command-dns)
 
 More details on how to use `repeat_key` and other command argument options can be
-found in [this section](12-object-types.md#objecttype-checkcommand-arguments).
+found in [this section](15-object-types.md#objecttype-checkcommand-arguments).
 
 > **Note**
 >
@@ -2204,7 +2204,7 @@ a forced service check:
 
 ### <a id="external-command-list"></a> External Command List
 
-A list of currently supported external commands can be found [here](14-appendix.md#external-commands-list-detail).
+A list of currently supported external commands can be found [here](17-appendix.md#external-commands-list-detail).
 
 Detailed information on the commands and their required parameters can be found
 on the [Icinga 1.x documentation](http://docs.icinga.org/latest/en/extcommands2.html).
@@ -2291,8 +2291,8 @@ You can customize the metric prefix name by using the `host_name_template` and
 `service_name_template` configuration attributes.
 
 The example below uses [runtime macros](3-monitoring-basics.md#runtime-macros) and a
-[global constant](10-language-reference.md#constants) named `GraphiteEnv`. The constant name
+[global constant](13-language-reference.md#constants) named `GraphiteEnv`. The constant name
-is freely definable and should be put in the [constants.conf](2-getting-started.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"
 
@@ -2385,7 +2385,7 @@ in Icinga 2 provided with the `CompatLogger` object.
 These logs are not only used for informational representation in
 external web interfaces parsing the logs, but also to generate
 SLA reports and trends in Icinga 1.x Classic UI. Furthermore the
-[Livestatus](7-livestatus.md#setting-up-livestatus) feature uses these logs for answering queries to
+[Livestatus](9-livestatus.md#setting-up-livestatus) feature uses these logs for answering queries to
 historical tables.
 
 The `CompatLogger` object can be enabled with
@@ -2434,10 +2434,10 @@ by a number of projects including Icinga Web 1.x and 2.
 
 Details on the installation can be found in the [Configuring DB IDO](2-getting-started.md#configuring-db-ido)
 chapter. Details on the configuration can be found in the
-[IdoMysqlConnection](12-object-types.md#objecttype-idomysqlconnection) and
+[IdoMysqlConnection](15-object-types.md#objecttype-idomysqlconnection) and
-[IdoPgsqlConnection](12-object-types.md#objecttype-idopgsqlconnection)
+[IdoPgsqlConnection](15-object-types.md#objecttype-idopgsqlconnection)
 object configuration documentation.
-The DB IDO feature supports [High Availability](4-monitoring-remote-systems.md#high-availability-db-ido) in
+The DB IDO feature supports [High Availability](5-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
@@ -2448,7 +2448,7 @@ the query returns an empty result.
 
 > **Tip**
 >
-> Use [check plugins](6-addons-plugins.md#plugins) to monitor the backend.
+> Use [check plugins](7-addons-plugins.md#plugins) to monitor the backend.
 
 Replace the `default` string with your instance name, if different.
 
@@ -2479,7 +2479,7 @@ Example for PostgreSQL:
     (1 Zeile)
 
 
-A detailed list on the available table attributes can be found in the [DB IDO Schema documentation](14-appendix.md#schema-db-ido).
+A detailed list on the available table attributes can be found in the [DB IDO Schema documentation](17-appendix.md#schema-db-ido).
 
 
 ## <a id="check-result-files"></a> Check Result Files

doc/4-configuring-icinga-2.md

@@ -0,0 +1,595 @@
+# <a id="configuring-icinga2-first-steps"></a> Configuring Icinga 2: First Steps
+
+## <a id="icinga2-conf"></a> icinga2.conf
+
+An example configuration file is installed for you in `/etc/icinga2/icinga2.conf`.
+
+Here's a brief description of the example configuration:
+
+    /**
+     * Icinga 2 configuration file
+     * - this is where you define settings for the Icinga application including
+     * which hosts/services to check.
+     *
+     * For an overview of all available configuration options please refer
+     * to the documentation that is distributed as part of Icinga 2.
+     */
+
+Icinga 2 supports [C/C++-style comments](13-language-reference.md#comments).
+
+    /**
+     * The constants.conf defines global constants.
+     */
+    include "constants.conf"
+
+The `include` directive can be used to include other files.
+
+    /**
+     * The zones.conf defines zones for a cluster setup.
+     * Not required for single instance setups.
+     */
+     include "zones.conf"
+
+    /**
+     * The Icinga Template Library (ITL) provides a number of useful templates
+     * and command definitions.
+     * Common monitoring plugin command definitions are included separately.
+     */
+    include <itl>
+    include <plugins>
+
+    /**
+     * The features-available directory contains a number of configuration
+     * files for features which can be enabled and disabled using the
+     * icinga2 feature enable / icinga2 feature disable CLI commands.
+     * These commands work by creating and removing symbolic links in
+     * the features-enabled directory.
+     */
+    include "features-enabled/*.conf"
+
+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](6-cli-commands.md#features) for more details.
+
+    /**
+     * The repository.d directory contains all configuration objects
+     * managed by the 'icinga2 repository' CLI commands.
+     */
+    include_recursive "repository.d"
+
+This `include_recursive` directive is used for discovery of services on remote clients
+and their generated configuration described in
+[this chapter](5-monitoring-remote-systems.md#icinga2-remote-monitoring-master-discovery-generate-config).
+
+
+    /**
+     * Although in theory you could define all your objects in this file
+     * the preferred way is to create separate directories and files in the conf.d
+     * directory. Each of these files must have the file extension ".conf".
+     */
+    include_recursive "conf.d"
+
+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.
+
+> **Tip**
+>
+> The example configuration is shipped in this directory too. You can either
+> remove it entirely, or adapt the existing configuration structure with your
+> own object configuration.
+
+## <a id="constants-conf"></a> constants.conf
+
+The `constants.conf` configuration file can be used to define global constants.
+
+By default, you need to make sure to set these constants:
+
+* The `PluginDir` constant must be pointed to your [check plugins](2-getting-started.md#setting-up-check-plugins) path.
+This constant is required by the shipped
+[plugin check command configuration](16-icinga-template-library.md#plugin-check-commands).
+* The `NodeName` constant defines your local node name. Should be set to FQDN which is the default
+if not set. This constant is required for local host configuration, monitoring remote clients and
+cluster setup.
+
+Example:
+
+    /* The directory which contains the plugins from the Monitoring Plugins project. */
+    const PluginDir = "/usr/lib64/nagios/plugins"
+
+
+    /* The directory which contains the Manubulon plugins.
+     * Check the documentation, chapter "SNMP Manubulon Plugin Check Commands", for details.
+     */
+    const ManubulonPluginDir = "/usr/lib64/nagios/plugins"
+
+    /* Our local instance name. By default this is the server's hostname as returned by `hostname --fqdn`.
+     * This should be the common name from the API certificate.
+     */
+    //const NodeName = "localhost"
+
+    /* Our local zone name. */
+    const ZoneName = NodeName
+
+    /* Secret key for remote node tickets */
+    const TicketSalt = ""
+
+The `ZoneName` and `TicketSalt` constants are required for remote client
+and distributed setups only.
+
+## <a id="conf-d"></a> The conf.d Directory
+
+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](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](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](3-monitoring-basics.md#configuration-best-practice).
+
+Available configuration files shipped by default:
+
+* [hosts.conf](4-configuring-icinga-2.md#hosts-conf)
+* [services.conf](4-configuring-icinga-2.md#services-conf)
+* [users.conf](4-configuring-icinga-2.md#users-conf)
+* [notifications.conf](4-configuring-icinga-2.md#notifications-conf)
+* [commands.conf](4-configuring-icinga-2.md#commands-conf)
+* [groups.conf](4-configuring-icinga-2.md#groups-conf)
+* [templates.conf](4-configuring-icinga-2.md#templates-conf)
+* [downtimes.conf](4-configuring-icinga-2.md#downtimes-conf)
+* [timeperiods.conf](4-configuring-icinga-2.md#timeperiods-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](4-configuring-icinga-2.md#constants-conf). You
+can use global constants for your object names instead of string
+values.
+
+The `import` keyword is used to import the `generic-host` template which
+takes care of setting up the host check command to `hostalive`. If you
+require a different check command, you can override it in the object definition.
+
+The `vars` attribute can be used to define custom attributes which are available
+for check and notification commands. Most of the [Plugin Check Commands](16-icinga-template-library.md#plugin-check-commands)
+in the Icinga Template Library require an `address` attribute.
+
+The custom attribute `os` is evaluated by the `linux-servers` group in
+[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](4-configuring-icinga-2.md#services-conf).
+* define disks (all, specific `/`) and their attributes for the `disk`
+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 relaod Icinga 2. The apply
+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.
+
+    /*
+     * Host definitions with object attributes
+     * used for apply rules for Service, Notification,
+     * Dependency and ScheduledDowntime objects.
+     *
+     * Tip: Use `icinga2 object list --type Host` to
+     * list all host objects after running
+     * configuration validation (`icinga2 daemon -C`).
+     */
+
+    /*
+     * This is an example host based on your
+     * local host's FQDN. Specify the NodeName
+     * constant in `constants.conf` or use your
+     * own description, e.g. "db-host-1".
+     */
+
+    object Host NodeName {
+      /* Import the default host template defined in `templates.conf`. */
+      import "generic-host"
+
+      /* Specify the address attributes for checks e.g. `ssh` or `http`. */
+      address = "127.0.0.1"
+      address6 = "::1"
+
+      /* Set custom attribute `os` for hostgroup assignment in `groups.conf`. */
+      vars.os = "Linux"
+
+      /* Define http vhost attributes for service apply rules in `services.conf`. */
+      vars.http_vhosts["http"] = {
+        http_uri = "/"
+      }
+      /* Uncomment if you've sucessfully installed Icinga Web 2. */
+      //vars.http_vhosts["Icinga Web 2"] = {
+      //  http_uri = "/icingaweb2"
+      //}
+
+      /* Define disks and attributes for service apply rules in `services.conf`. */
+      vars.disks["disk"] = {
+        /* No parameters. */
+      }
+      vars.disks["disk /"] = {
+        disk_partitions = "/"
+      }
+
+      /* Define notification mail attributes for notification apply rules in `notifications.conf`. */
+      vars.notification["mail"] = {
+        /* The UserGroup `icingaadmins` is defined in `users.conf`. */
+        groups = [ "icingaadmins" ]
+      }
+    }
+
+This is only the host object definition. Now we'll need to make sure that this
+host and your additional hosts are getting [services](4-configuring-icinga-2.md#services-conf) applied.
+
+> **Tip**
+>
+> If you don't understand all the attributes and how to use [apply rules](13-language-reference.md#apply)
+> don't worry - the [monitoring basics](3-monitoring-basics.md#monitoring-basics) chapter will explain
+> that in detail.
+
+### <a id="services-conf"></a> services.conf
+
+These service [apply rules](13-language-reference.md#apply) will show you how to monitor
+the local host, but also allow you to re-use or modify them for
+your own requirements.
+
+You should define all your service apply rules in `services.conf`
+or any other central location keeping them organized.
+
+By default, the local host will be monitored by the following services
+
+Service(s)                                  | Applied on host(s)
+--------------------------------------------|------------------------
+`load`, `procs`, `swap`, `users`, `icinga`  | The `NodeName` host only
+`ping4`, `ping6`                            | All hosts with `address` resp. `address6` attribute
+`ssh`                                       | All hosts with `address` and `vars.os` set to `Linux`
+`http`, optional: `Icinga Web 2`            | All hosts with custom attribute `http_vhosts` defined as dictionary
+`disk`, `disk /`                            | All hosts with custom attribute `disks` defined as dictionary
+
+The Debian packages also ship an additional `apt` service check applied to the local host.
+
+The command object `icinga` for the embedded health check is provided by the
+[Icinga Template Library (ITL)](16-icinga-template-library.md#icinga-template-library) while `http_ip`, `ssh`, `load`, `processes`,
+`users` and `disk` are all provided by the [Plugin Check Commands](16-icinga-template-library.md#plugin-check-commands)
+which we enabled earlier by including the `itl` and `plugins` configuration file.
+
+
+Example `load` service apply rule:
+
+    apply Service "load" {
+      import "generic-service"
+
+      check_command = "load"
+
+      /* Used by the ScheduledDowntime apply rule in `downtimes.conf`. */
+      vars.backup_downtime = "02:00-03:00"
+
+      assign where host.name == NodeName
+    }
+
+The `apply` keyword can be used to create new objects which are associated with
+another group of objects. You can `import` existing templates, define (custom)
+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](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"
+is created for each matching host. [Expression operators](13-language-reference.md#expression-operators)
+may be used in `assign where` conditions.
+
+Multiple `assign where` condition can be combined with `AND` using the `&&` operator
+as shown in the `ssh` example:
+
+    apply Service "ssh" {
+      import "generic-service"
+
+      check_command = "ssh"
+
+      assign where host.address && host.vars.os == "Linux"
+    }
+
+In this example, the service `ssh` is applied to all hosts having the `address`
+attribute defined `AND` having the custom attribute `os` set to the string
+`Linux`.
+You can modify this condition to match multiple expressions by combinding `AND`
+and `OR` using `&&` and `||` [operators](13-language-reference.md#expression-operators), for example
+`assign where host.address && (vars.os == "Linux" || vars.os == "Windows")`.
+
+
+A more advanced example is shown by the `http` and `disk` service apply
+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](4-configuring-icinga-2.md#hosts-conf) defines the
+`disks` dictionary as custom attribute in `vars`.
+
+Remember the example from [hosts.conf](4-configuring-icinga-2.md#hosts-conf):
+
+    ...
+
+      /* Define disks and attributes for service apply rules in `services.conf`. */
+      vars.disks["disk"] = {
+        /* No parameters. */
+      }
+      vars.disks["disk /"] = {
+        disk_partition = "/"
+      }
+    ...
+
+
+This dictionary contains multiple service names we want to monitor. `disk`
+should just check all available disks, while `disk /` will pass an additional
+parameter `disk_partition` to the check command.
+
+You'll recognize that the naming is important - that's the very same name
+as it is passed from a service to a check command argument. Read about services
+and passing check commands in [this chapter](3-monitoring-basics.md#command-passing-parameters).
+
+Using `apply Service for` omits the service name, it will take the key stored in
+the `disk` variable in `key => config` as new service object name.
+
+The `for` keyword expects a loop definition, for example `key => value in dictionary`
+as known from Perl and other scripting languages.
+
+Once defined like this, the `apply` rule defined below will do the following:
+
+* only match hosts with `host.vars.disks` defined through the `assign where` condition
+* loop through all entries in the `host.vars.disks` dictionary. That's `disk` and `disk /` as keys.
+* call `apply` on each, and set the service object name from the provided key
+* inside apply, the `generic-service` template is imported
+* defining the [disk](16-icinga-template-library.md#plugin-check-command-disk) check command requiring command arguments like `disk_partition`
+* adding the `config` dictionary items to `vars`. Simply said, there's now `vars.disk_partition` defined for the
+generated service
+
+Configuration example:
+
+    apply Service for (disk => config in host.vars.disks) {
+      import "generic-service"
+
+      check_command = "disk"
+
+      vars += config
+
+      assign where host.vars.disks
+    }
+
+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](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.
+
+Don't forget to install the [check plugins](2-getting-started.md#setting-up-check-plugins) required by
+the hosts and services and their check commands.
+
+Further details on the monitoring configuration can be found in the
+[monitoring basics](3-monitoring-basics.md#monitoring-basics) chapter.
+
+### <a id="users-conf"></a> users.conf
+
+Defines the `icingaadmin` User and the `icingaadmins` UserGroup. The latter is used in
+[hosts.conf](4-configuring-icinga-2.md#hosts-conf) for defining a custom host attribute later used in
+[notifications.conf](4-configuring-icinga-2.md#notifications-conf) for notification apply rules.
+
+    object User "icingaadmin" {
+      import "generic-user"
+
+      display_name = "Icinga 2 Admin"
+      groups = [ "icingaadmins" ]
+
+      email = "icinga@localhost"
+    }
+
+    object UserGroup "icingaadmins" {
+      display_name = "Icinga 2 Admin Group"
+    }
+
+
+### <a id="notifications-conf"></a> notifications.conf
+
+Notifications for check alerts are an integral part or your
+Icinga 2 monitoring stack.
+
+The shipped example defines two notification apply rules for hosts and services.
+Both `apply` rules match on the same condition: They are only applied if the
+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](4-configuring-icinga-2.md#templates-conf).
+
+The `interval` attribute is not explicitly set - it [defaults to 30 minutes](15-object-types.md#objecttype-notification).
+
+By setting the `user_groups` to the value provided by the
+respective [host.vars.notification.mail](4-configuring-icinga-2.md#hosts-conf) attribute we'll
+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"
+
+      user_groups = host.vars.notification.mail.groups
+
+      assign where host.vars.notification.mail
+    }
+
+    apply Notification "mail-icingaadmin" to Service {
+      import "mail-service-notification"
+
+      user_groups = host.vars.notification.mail.groups
+
+      assign where host.vars.notification.mail
+    }
+
+More details on defining notifications and their additional attributes such as
+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](4-configuring-icinga-2.md#templates-conf).
+
+> **Tip**
+>
+> Icinga 2 ships the most common command definitions already in the
+> [Plugin Check Commands](16-icinga-template-library.md#plugin-check-commands) definitions. More details on
+> that topic in the [troubleshooting section](10-troubleshooting.md#check-command-definitions).
+
+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).
+
+### <a id="groups-conf"></a> groups.conf
+
+The example host defined in [hosts.conf](hosts-conf) already has the
+custom attribute `os` set to `Linux` and is therefore automatically
+a member of the host group `linux-servers`.
+
+This is done by using the [group assign](13-language-reference.md#group-assign) expressions similar
+to previously seen [apply rules](3-monitoring-basics.md#using-apply).
+
+    object HostGroup "linux-servers" {
+      display_name = "Linux Servers"
+
+      assign where host.vars.os == "Linux"
+    }
+
+    object HostGroup "windows-servers" {
+      display_name = "Windows Servers"
+
+      assign where host.vars.os == "Windows"
+    }
+
+Service groups can be grouped together by similar pattern matches.
+The [match() function](13-language-reference.md#function-calls) expects a wildcard match string
+and the attribute string to match with.
+
+    object ServiceGroup "ping" {
+      display_name = "Ping Checks"
+
+      assign where match("ping*", service.name)
+    }
+
+    object ServiceGroup "http" {
+      display_name = "HTTP Checks"
+
+      assign where match("http*", service.check_command)
+    }
+
+    object ServiceGroup "disk" {
+      display_name = "Disk Checks"
+
+      assign where match("disk*", service.check_command)
+    }
+
+
+### <a id="templates-conf"></a> templates.conf
+
+All shipped example configuration objects use generic global templates by
+default. Be it setting a default `check_command` attribute in the `generic-host`
+templates for your hosts defined in [hosts.conf](4-configuring-icinga-2.md#hosts-conf), or defining
+the default `states` and `types` filters for notification apply rules defined in
+[notifications.conf](4-configuring-icinga-2.md#notifications-conf).
+
+
+    template Host "generic-host" {
+      max_check_attempts = 5
+      check_interval = 1m
+      retry_interval = 30s
+
+      check_command = "hostalive"
+    }
+
+    template Service "generic-service" {
+      max_check_attempts = 3
+      check_interval = 1m
+      retry_interval = 30s
+    }
+
+The `hostalive` check command is shipped with Icinga 2 in the
+[Plugin Check Commands](16-icinga-template-library.md#plugin-check-commands).
+
+
+    template Notification "mail-host-notification" {
+      command = "mail-host-notification"
+
+      states = [ Up, Down ]
+      types = [ Problem, Acknowledgement, Recovery, Custom,
+                FlappingStart, FlappingEnd,
+                DowntimeStart, DowntimeEnd, DowntimeRemoved ]
+
+      period = "24x7"
+    }
+
+    template Notification "mail-service-notification" {
+      command = "mail-service-notification"
+
+      states = [ OK, Warning, Critical, Unknown ]
+      types = [ Problem, Acknowledgement, Recovery, Custom,
+                FlappingStart, FlappingEnd,
+                DowntimeStart, DowntimeEnd, DowntimeRemoved ]
+
+      period = "24x7"
+    }
+
+More details on `Notification` object attributes can be found [here](15-object-types.md#objecttype-notification).
+
+
+### <a id="downtimes-conf"></a> downtimes.conf
+
+The `load` service apply rule defined in [services.conf](4-configuring-icinga-2.md#services-conf) defines
+the `backup_downtime` custom attribute.
+
+The [ScheduledDowntime](15-object-types.md#objecttype-scheduleddowntime) apply rule uses this attribute
+to define the default value for the time ranges required for recurring downtime slots.
+
+    apply ScheduledDowntime "backup-downtime" to Service {
+      author = "icingaadmin"
+      comment = "Scheduled downtime for backup"
+
+      ranges = {
+        monday = service.vars.backup_downtime
+        tuesday = service.vars.backup_downtime
+        wednesday = service.vars.backup_downtime
+        thursday = service.vars.backup_downtime
+        friday = service.vars.backup_downtime
+        saturday = service.vars.backup_downtime
+        sunday = service.vars.backup_downtime
+      }
+
+      assign where service.vars.backup_downtime != ""
+    }
+
+
+### <a id="timeperiods-conf"></a> timeperiods.conf
+
+This file ships the default timeperiod definitions for `24x7`, `9to5`
+and `never`. Timeperiod objects are referenced by `*period`
+objects such as hosts, services or notifications.
+
+
+### <a id="satellite-conf"></a> satellite.conf
+
+Ships default templates and dependencies for [monitoring remote clients](5-monitoring-remote-systems.md#icinga2-remote-client-monitoring)
+using service discovery and [config generation](5-monitoring-remote-systems.md#icinga2-remote-monitoring-master-discovery-generate-config)
+on the master. Can be ignored/removed on setups not using this features.
+
+
+Further details on the monitoring configuration can be found in the
+[monitoring basics](3-monitoring-basics.md#monitoring-basics) chapter.

doc/5-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](4-monitoring-remote-systems.md#agent-less-checks)
+There are multiple ways you can monitor remote clients. Be it using [agent-less](5-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](4-monitoring-remote-systems.md#icinga2-remote-client-monitoring).
+agent [monitoring a remote client](5-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](4-monitoring-remote-systems.md#distributed-monitoring-high-availability).
+[this chapter](5-monitoring-remote-systems.md#distributed-monitoring-high-availability).
 
 > **Tip**
 >
@@ -24,19 +24,19 @@ monitoring and high-availability, please continue reading in
 If the remote service is available using a network protocol and port,
 and a [check plugin](2-getting-started.md#setting-up-check-plugins) is available, you don't
 necessarily need a local client installed. Rather choose a plugin and
-configure all parameters and thresholds. The [Icinga 2 Template Library](13-icinga-template-library.md#icinga-template-library)
+configure all parameters and thresholds. The [Icinga 2 Template Library](16-icinga-template-library.md#icinga-template-library)
 already ships various examples like
 
-* [ping4](13-icinga-template-library.md#plugin-check-command-ping4), [ping6](13-icinga-template-library.md#plugin-check-command-ping6),
+* [ping4](16-icinga-template-library.md#plugin-check-command-ping4), [ping6](16-icinga-template-library.md#plugin-check-command-ping6),
-[fping4](13-icinga-template-library.md#plugin-check-command-fping4), [fping6](13-icinga-template-library.md#plugin-check-command-fping6), [hostalive](13-icinga-template-library.md#plugin-check-command-hostalive)
+[fping4](16-icinga-template-library.md#plugin-check-command-fping4), [fping6](16-icinga-template-library.md#plugin-check-command-fping6), [hostalive](16-icinga-template-library.md#plugin-check-command-hostalive)
-* [tcp](13-icinga-template-library.md#plugin-check-command-tcp), [udp](13-icinga-template-library.md#plugin-check-command-udp), [ssl](13-icinga-template-library.md#plugin-check-command-ssl)
+* [tcp](16-icinga-template-library.md#plugin-check-command-tcp), [udp](16-icinga-template-library.md#plugin-check-command-udp), [ssl](16-icinga-template-library.md#plugin-check-command-ssl)
-* [http](13-icinga-template-library.md#plugin-check-command-http), [ftp](13-icinga-template-library.md#plugin-check-command-ftp)
+* [http](16-icinga-template-library.md#plugin-check-command-http), [ftp](16-icinga-template-library.md#plugin-check-command-ftp)
-* [smtp](13-icinga-template-library.md#plugin-check-command-smtp), [ssmtp](13-icinga-template-library.md#plugin-check-command-ssmtp),
+* [smtp](16-icinga-template-library.md#plugin-check-command-smtp), [ssmtp](16-icinga-template-library.md#plugin-check-command-ssmtp),
-[imap](13-icinga-template-library.md#plugin-check-command-imap), [simap](13-icinga-template-library.md#plugin-check-command-simap),
+[imap](16-icinga-template-library.md#plugin-check-command-imap), [simap](16-icinga-template-library.md#plugin-check-command-simap),
-[pop](13-icinga-template-library.md#plugin-check-command-pop), [spop](13-icinga-template-library.md#plugin-check-command-spop)
+[pop](16-icinga-template-library.md#plugin-check-command-pop), [spop](16-icinga-template-library.md#plugin-check-command-spop)
-* [ntp_time](13-icinga-template-library.md#plugin-check-command-ntp-time)
+* [ntp_time](16-icinga-template-library.md#plugin-check-command-ntp-time)
-* [ssh](13-icinga-template-library.md#plugin-check-command-ssh)
+* [ssh](16-icinga-template-library.md#plugin-check-command-ssh)
-* [dns](13-icinga-template-library.md#plugin-check-command-dns), [dig](13-icinga-template-library.md#plugin-check-command-dig), [dhcp](13-icinga-template-library.md#plugin-check-command-dhcp)
+* [dns](16-icinga-template-library.md#plugin-check-command-dns), [dig](16-icinga-template-library.md#plugin-check-command-dig), [dhcp](16-icinga-template-library.md#plugin-check-command-dhcp)
 
 There are numerous check plugins contributed by community members available
 on the internet. If you found one for your requirements, [integrate them into Icinga 2](3-monitoring-basics.md#command-plugin-integration).
@@ -47,7 +47,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](2-getting-started.md#hosts-conf), [services.conf](2-getting-started.md#services-conf)).
+section shipped with Icinga 2 ([hosts.conf](4-configuring-icinga-2.md#hosts-conf), [services.conf](4-configuring-icinga-2.md#services-conf)).
 
 ## <a id="icinga2-remote-client-monitoring"></a> Monitoring Icinga 2 Remote Clients
 
@@ -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](4-monitoring-remote-systems.md#icinga2-remote-monitoring-client-roles).
+different [roles](5-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](4-monitoring-remote-systems.md#distributed-monitoring-high-availability).
+> [cluster setup instructions](5-monitoring-remote-systems.md#distributed-monitoring-high-availability).
 
 > **Note**
 >
@@ -73,7 +73,7 @@ different [roles](4-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](4-monitoring-remote-systems.md#icinga2-remote-monitoring-client)
+If you are planning to use the [remote Icinga 2 clients](5-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](5-cli-commands.md#cli-command-node) `node wizard` for setting up a new node
+You can use the [CLI command](6-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).
@@ -133,7 +133,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](2-getting-started.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.
 
@@ -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](4-monitoring-remote-systems.md#icinga2-remote-monitoring-client-linux) will be using the [CLI command](5-cli-commands.md#cli-command-node)
+[Linux/Unix](5-monitoring-remote-systems.md#icinga2-remote-monitoring-client-linux) will be using the [CLI command](6-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](4-monitoring-remote-systems.md#icinga2-remote-monitoring-master)
+* A ready configured and installed [master node](5-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)
@@ -168,8 +168,8 @@ 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](2-getting-started.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](4-monitoring-remote-systems.md#icinga2-remote-monitoring-master) will create
+The [setup wizard for the master setup](5-monitoring-remote-systems.md#icinga2-remote-monitoring-master) will create
 one for you already.
 
     # grep TicketSalt /etc/icinga2/constants.conf
@@ -188,16 +188,16 @@ Example for a client notebook:
 > **Note**
 >
 > You can omit the `--salt` parameter using the `TicketSalt` constant from
-> [constants.conf](2-getting-started.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
 
-This is described separately in the [cluster setup chapter](4-monitoring-remote-systems.md#manual-certificate-generation).
+This is described separately in the [cluster setup chapter](5-monitoring-remote-systems.md#manual-certificate-generation).
 
 > **Note**
 >
-> If you're using [CSR Auto-Signing](4-monitoring-remote-systems.md#csr-autosigning-requirements), skip this step.
+> If you're using [CSR Auto-Signing](5-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](4-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](4-monitoring-remote-systems.md#csr-autosigning-requirements) requirements
+Please make sure that either [CSR Auto-Signing](5-monitoring-remote-systems.md#csr-autosigning-requirements) requirements
-are fulfilled, or that you're using [manual SSL certificate generation](4-monitoring-remote-systems.md#manual-certificate-generation).
+are fulfilled, or that you're using [manual SSL certificate generation](5-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](4-monitoring-remote-systems.md#csr-autosigning-requirements) generated on your master
+* The [request ticket number](5-monitoring-remote-systems.md#csr-autosigning-requirements) generated on your master
 for CSR Auto-Signing
 * Bind host/port for the Api feature (optional)
 
@@ -299,7 +299,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](2-getting-started.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.
 
@@ -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](4-monitoring-remote-systems.md#csr-autosigning-requirements) generated on your master
+* The [request ticket number](5-monitoring-remote-systems.md#csr-autosigning-requirements) generated on your master
 for CSR Auto-Signing
 * Bind host/port for the Api feature (optional)
 
@@ -348,8 +348,8 @@ This scenario allows you to configure the checkable objects (hosts, services) on
 your Icinga 2 master or satellite, and only send commands remotely.
 
 Requirements:
-* Exact same [CheckCommand](12-object-types.md#objecttype-checkcommand) (and
+* Exact same [CheckCommand](15-object-types.md#objecttype-checkcommand) (and
-[EventCommand](12-object-types.md#objecttype-eventcommand)) configuration objects
+[EventCommand](15-object-types.md#objecttype-eventcommand)) configuration objects
 on the master and the remote client(s).
 * Installed plugin scripts on the remote client (`PluginDir` constant can be locally modified)
 * `Zone` and `Endpoint` configuration for the client on the master
@@ -357,9 +357,9 @@ on the master and the remote client(s).
 endpoint
 
 `CheckCommand` objects are already shipped with the Icinga 2 ITL
-as [plugin check commands](13-icinga-template-library.md#plugin-check-commands). If you are
+as [plugin check commands](16-icinga-template-library.md#plugin-check-commands). If you are
 using your own configuration definitions for example in
-[commands.conf](2-getting-started.md#commands-conf) make sure to copy/sync it
+[commands.conf](4-configuring-icinga-2.md#commands-conf) make sure to copy/sync it
 on your remote client.
 
 #### <a id="icinga2-remote-monitoring-client-command-execution-client"></a> Client Configuration Remote Client for Command Execution
@@ -395,8 +395,8 @@ in [zones.conf](#zones-conf) and define a trusted master zone as `parent`.
     }
 
 More details here:
-* [configure endpoints](4-monitoring-remote-systems.md#configure-cluster-endpoints)
+* [configure endpoints](5-monitoring-remote-systems.md#configure-cluster-endpoints)
-* [configure zones](4-monitoring-remote-systems.md#configure-cluster-zones)
+* [configure zones](5-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](4-monitoring-remote-systems.md#icinga2-remote-monitoring-client-local-config).
+> [local client](5-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](4-monitoring-remote-systems.md#icinga2-remote-monitoring-master-discovery-blacklist-whitelist)
+> Better use [blacklists and/or whitelists](5-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
@@ -600,15 +600,15 @@ You can `list` and `remove` existing blacklists:
 
 ### <a id="icinga2-remote-monitoring-master-manual-add-endpoint-zone"></a> Manually add Client Endpoint and Zone Objects on the Master
 
-Define a [Zone](12-object-types.md#objecttype-zone) with a new [Endpoint](12-object-types.md#objecttype-endpoint) similar to the cluster setup.
+Define a [Zone](15-object-types.md#objecttype-zone) with a new [Endpoint](15-object-types.md#objecttype-endpoint) similar to the cluster setup.
 
-* [configure the node name](4-monitoring-remote-systems.md#configure-nodename)
+* [configure the node name](5-monitoring-remote-systems.md#configure-nodename)
-* [configure the ApiListener object](4-monitoring-remote-systems.md#configure-apilistener-object)
+* [configure the ApiListener object](5-monitoring-remote-systems.md#configure-apilistener-object)
-* [configure cluster endpoints](4-monitoring-remote-systems.md#configure-cluster-endpoints)
+* [configure cluster endpoints](5-monitoring-remote-systems.md#configure-cluster-endpoints)
-* [configure cluster zones](4-monitoring-remote-systems.md#configure-cluster-zones)
+* [configure cluster zones](5-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](4-monitoring-remote-systems.md#cluster-zone-config-sync)
+clients, you can also use the cluster provided [configuration sync](5-monitoring-remote-systems.md#cluster-zone-config-sync)
 in `zones.d`.
 
 
@@ -622,10 +622,10 @@ become handy.
 
 The SNMP daemon runs on the remote system and answers SNMP queries by plugin
 binaries. The [Monitoring Plugins package](2-getting-started.md#setting-up-check-plugins) ships
-the `check_snmp` plugin binary, but there are plenty of [existing plugins](6-addons-plugins.md#plugins)
+the `check_snmp` plugin binary, but there are plenty of [existing plugins](7-addons-plugins.md#plugins)
 for specific use cases already around, for example monitoring Cisco routers.
 
-The following example uses the [SNMP ITL](13-icinga-template-library.md#plugin-check-command-snmp) `CheckCommand` and just
+The following example uses the [SNMP ITL](16-icinga-template-library.md#plugin-check-command-snmp) `CheckCommand` and just
 overrides the `snmp_oid` custom attribute. A service is created for all hosts which
 have the `snmp-community` custom attribute.
 
@@ -638,7 +638,7 @@ have the `snmp-community` custom attribute.
       assign where host.vars.snmp_community != ""
     }
 
-Additional SNMP plugins are available using the [Manubulon SNMP Plugins](13-icinga-template-library.md#snmp-manubulon-plugin-check-commands).
+Additional SNMP plugins are available using the [Manubulon SNMP Plugins](16-icinga-template-library.md#snmp-manubulon-plugin-check-commands).
 
 ### <a id="agent-based-checks-ssh"></a> SSH
 
@@ -676,14 +676,14 @@ 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](4-monitoring-remote-systems.md#icinga2-remote-monitoring-master)
+> In order to stay safe, please use the native [Icinga 2 client](5-monitoring-remote-systems.md#icinga2-remote-monitoring-master)
 > instead.
 
 The NRPE daemon uses its own configuration format in nrpe.cfg while `check_nrpe`
 can be embedded into the Icinga 2 `CheckCommand` configuration syntax.
 
 You can use the `check_nrpe` plugin from the NRPE project to query the NRPE daemon.
-Icinga 2 provides the [nrpe check command](13-icinga-template-library.md#plugin-check-command-nrpe) for this:
+Icinga 2 provides the [nrpe check command](16-icinga-template-library.md#plugin-check-command-nrpe) for this:
 
 Example:
 
@@ -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++](4-monitoring-remote-systems.md#agent-based-checks-nsclient)
+You can pass arguments in a similar manner to [NSClient++](5-monitoring-remote-systems.md#agent-based-checks-nsclient)
 when using its NRPE supported check method.
 
 ### <a id="agent-based-checks-nsclient"></a> NSClient++
@@ -753,7 +753,7 @@ but using `NSClient++` will allow you to run local scripts similar to check plug
 the required output and performance counters.
 
 You can use the `check_nt` plugin from the Monitoring Plugins project to query NSClient++.
-Icinga 2 provides the [nscp check command](13-icinga-template-library.md#plugin-check-command-nscp) for this:
+Icinga 2 provides the [nscp check command](16-icinga-template-library.md#plugin-check-command-nscp) for this:
 
 Example:
 
@@ -789,7 +789,7 @@ SNMP Traps can be received and filtered by using [SNMPTT](http://snmptt.sourcefo
 and specific trap handlers passing the check results to Icinga 2.
 
 Following the SNMPTT [Format](http://snmptt.sourceforge.net/docs/snmptt.shtml#SNMPTT.CONF-FORMAT)
-documentation and the Icinga external command syntax found [here](14-appendix.md#external-commands-list-detail)
+documentation and the Icinga external command syntax found [here](17-appendix.md#external-commands-list-detail)
 we can create generic services that can accommodate any number of hosts for a given scenario.
 
 #### <a id="simple-traps"></a> Simple SNMP Traps
@@ -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](4-monitoring-remote-systems.md#cluster-scenarios-high-availability). All instances in the `Zone` elect one active master and run as Active/Active cluster.
+* [High Availability](5-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](4-monitoring-remote-systems.md#cluster-scenarios-distributed-zones). A master zone and one or more satellites in their zones.
+* [Distributed Zones](5-monitoring-remote-systems.md#cluster-scenarios-distributed-zones). A master zone and one or more satellites in their zones.
-* [Load Distribution](4-monitoring-remote-systems.md#cluster-scenarios-load-distribution). A configuration master and multiple checker satellites.
+* [Load Distribution](5-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,18 +999,18 @@ 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](4-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](5-monitoring-remote-systems.md#cluster-zone-config-sync) or use an external tool (Puppet, Ansible, Chef, Salt, etc) to manage the configuration deployment
 
 
 > **Tip**
 >
 > If you're looking for troubleshooting cluster problems, check the general
-> [troubleshooting](8-troubleshooting.md#troubleshooting-cluster) section.
+> [troubleshooting](10-troubleshooting.md#troubleshooting-cluster) section.
 
 
 ### <a id="manual-certificate-generation"></a> Manual SSL Certificate Generation
 
-Icinga 2 ships [CLI commands](5-cli-commands.md#cli-command-pki) assisting with CA and node certificate creation
+Icinga 2 ships [CLI commands](6-cli-commands.md#cli-command-pki) assisting with CA and node certificate creation
 for your Icinga 2 distributed setup.
 
 > **Note**
@@ -1053,8 +1053,8 @@ the host's FQDN):
 
 #### <a id="cluster-naming-convention"></a> Cluster Naming Convention
 
-The SSL certificate common name (CN) will be used by the [ApiListener](12-object-types.md#objecttype-apilistener)
+The SSL certificate common name (CN) will be used by the [ApiListener](15-object-types.md#objecttype-apilistener)
-object to determine the local authority. This name must match the local [Endpoint](12-object-types.md#objecttype-endpoint)
+object to determine the local authority. This name must match the local [Endpoint](15-object-types.md#objecttype-endpoint)
 object name.
 
 Example:
@@ -1068,8 +1068,8 @@ Example:
       host = "icinga2a.icinga.org"
     }
 
-The [Endpoint](12-object-types.md#objecttype-endpoint) name is further referenced as `endpoints` attribute on the
+The [Endpoint](15-object-types.md#objecttype-endpoint) name is further referenced as `endpoints` attribute on the
-[Zone](12-object-types.md#objecttype-zone) object.
+[Zone](15-object-types.md#objecttype-zone) object.
 
     object Endpoint "icinga2b" {
       host = "icinga2b.icinga.org"
@@ -1079,7 +1079,7 @@ The [Endpoint](12-object-types.md#objecttype-endpoint) name is further reference
       endpoints = [ "icinga2a", "icinga2b" ]
     }
 
-Specifying the local node name using the [NodeName](4-monitoring-remote-systems.md#configure-nodename) variable requires
+Specifying the local node name using the [NodeName](5-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,19 +1090,19 @@ 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](4-monitoring-remote-systems.md#configure-nodename)
+* [configure the node name](5-monitoring-remote-systems.md#configure-nodename)
-* [configure the ApiListener object](4-monitoring-remote-systems.md#configure-apilistener-object)
+* [configure the ApiListener object](5-monitoring-remote-systems.md#configure-apilistener-object)
-* [configure cluster endpoints](4-monitoring-remote-systems.md#configure-cluster-endpoints)
+* [configure cluster endpoints](5-monitoring-remote-systems.md#configure-cluster-endpoints)
-* [configure cluster zones](4-monitoring-remote-systems.md#configure-cluster-zones)
+* [configure cluster zones](5-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](4-monitoring-remote-systems.md#cluster-zone-config-sync)
+describe how to use [zone configuration synchronisation](5-monitoring-remote-systems.md#cluster-zone-config-sync)
-and configure [cluster scenarios](4-monitoring-remote-systems.md#cluster-scenarios).
+and configure [cluster scenarios](5-monitoring-remote-systems.md#cluster-scenarios).
 
 #### <a id="configure-nodename"></a> Configure the Icinga Node Name
 
 Instead of using the default FQDN as node name you can optionally set
-that value using the [NodeName](10-language-reference.md#constants) constant.
+that value using the [NodeName](13-language-reference.md#constants) constant.
 
 > ** Note **
 >
@@ -1110,9 +1110,9 @@ that value using the [NodeName](10-language-reference.md#constants) constant.
 > in `/etc/icinga2/constants.conf`.
 
 This setting must be unique for each node, and must also match
-the name of the local [Endpoint](12-object-types.md#objecttype-endpoint) object and the
+the name of the local [Endpoint](15-object-types.md#objecttype-endpoint) object and the
 SSL certificate common name as described in the
-[cluster naming convention](4-monitoring-remote-systems.md#cluster-naming-convention).
+[cluster naming convention](5-monitoring-remote-systems.md#cluster-naming-convention).
 
     vim /etc/icinga2/constants.conf
 
@@ -1122,14 +1122,14 @@ SSL certificate common name as described in the
     const NodeName = "icinga2a"
 
 
-Read further about additional [naming conventions](4-monitoring-remote-systems.md#cluster-naming-convention).
+Read further about additional [naming conventions](5-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.
 
 #### <a id="configure-apilistener-object"></a> Configure the ApiListener Object
 
-The [ApiListener](12-object-types.md#objecttype-apilistener) object needs to be configured on
+The [ApiListener](15-object-types.md#objecttype-apilistener) object needs to be configured on
 every node in the cluster with the following settings:
 
 A sample config looks like:
@@ -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](4-monitoring-remote-systems.md#cluster-scenarios-high-availability),
+Zones can be used for [high availability](5-monitoring-remote-systems.md#cluster-scenarios-high-availability),
-[distributed setups](4-monitoring-remote-systems.md#cluster-scenarios-distributed-zones) and
+[distributed setups](5-monitoring-remote-systems.md#cluster-scenarios-distributed-zones) and
-[load distribution](4-monitoring-remote-systems.md#cluster-scenarios-load-distribution).
+[load distribution](5-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,21 +1214,21 @@ 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](4-monitoring-remote-systems.md#configure-apilistener-object) object by configuring the `accept_config`
+[ApiListener](5-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`
-statement in [icinga2.conf](2-getting-started.md#icinga2-conf):
+statement in [icinga2.conf](4-configuring-icinga-2.md#icinga2-conf):
 
     //include_recursive "conf.d"
 
 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](4-monitoring-remote-systems.md#cluster-health-check) for example.
+useful for local [health checks](5-monitoring-remote-systems.md#cluster-health-check) for example.
 
 > **Note**
 >
-> In a [high availability](4-monitoring-remote-systems.md#cluster-scenarios-high-availability)
+> In a [high availability](5-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](4-monitoring-remote-systems.md#configure-apilistener-object) object.
+attribute of the [ApiListener](5-monitoring-remote-systems.md#configure-apilistener-object) object.
 
 Config on node `icinga2a`:
 
@@ -1276,9 +1276,9 @@ process.
 
 > **Note**
 >
-> `zones.d` must not be included in [icinga2.conf](2-getting-started.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](10-language-reference.md#constants) `ZonesDir`.
+> [global constant](13-language-reference.md#constants) `ZonesDir`.
 
 #### <a id="zone-global-config-templates"></a> Global Configuration Zone for Templates
 
@@ -1325,7 +1325,7 @@ If you don't require any global configuration, skip this setting.
 
 #### <a id="zone-config-sync-permissions"></a> Zone Configuration Synchronisation Permissions
 
-Each [ApiListener](12-object-types.md#objecttype-apilistener) object must have the `accept_config` attribute
+Each [ApiListener](15-object-types.md#objecttype-apilistener) object must have the `accept_config` attribute
 set to `true` to receive configuration from the parent `Zone` members. Default value is `false`.
 
     object ApiListener "api" {
@@ -1340,13 +1340,13 @@ master instances anymore.
 
 > ** Tip **
 >
-> Look into the [troubleshooting guides](8-troubleshooting.md#troubleshooting-cluster-config-sync) for debugging
+> Look into the [troubleshooting guides](10-troubleshooting.md#troubleshooting-cluster-config-sync) for debugging
 > problems with the configuration synchronisation.
 
 
 ### <a id="cluster-health-check"></a> Cluster Health Check
 
-The Icinga 2 [ITL](13-icinga-template-library.md#icinga-template-library) ships an internal check command checking all configured
+The Icinga 2 [ITL](16-icinga-template-library.md#icinga-template-library) ships an internal check command checking all configured
 `EndPoints` in the cluster setup. The check result will become critical if
 one or more configured nodes are not connected.
 
@@ -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](4-monitoring-remote-systems.md#zone-config-sync-permissions) is disabled by default.
+* [Configuration sync](5-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](4-monitoring-remote-systems.md#high-availability-db-ido)).
+[DB IDO HA](5-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](4-monitoring-remote-systems.md#high-availability-features) in a
+[load-balanced notifications and checks](5-monitoring-remote-systems.md#high-availability-features) in a
-[HA zone](4-monitoring-remote-systems.md#cluster-scenarios-high-availability).
+[HA zone](5-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](4-monitoring-remote-systems.md#zone-global-config-templates) available in all zones.
+[global templates](5-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](4-monitoring-remote-systems.md#zone-config-sync-permissions).
+> [accepts synced configuration](5-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](4-monitoring-remote-systems.md#zone-config-sync-permissions).
+> [accepts synced configuration](5-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](4-monitoring-remote-systems.md#configure-cluster-zones). All nodes will elect one
+a dedicated [zone](5-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](4-monitoring-remote-systems.md#high-availability-features).
+Selected features provide advanced [HA functionality](5-monitoring-remote-systems.md#high-availability-features).
 Checks and notifications are load-balanced between nodes in the high availability
 zone.
 
@@ -1568,15 +1568,15 @@ commands, etc.
       endpoints = [ "icinga2a", "icinga2b", "icinga2c" ]
     }
 
-Two or more nodes in a high availability setup require an [initial cluster sync](4-monitoring-remote-systems.md#initial-cluster-sync).
+Two or more nodes in a high availability setup require an [initial cluster sync](5-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](4-monitoring-remote-systems.md#zone-config-sync-permissions).
+> [accept synced configuration](5-monitoring-remote-systems.md#zone-config-sync-permissions).
-> Details in the [Configuration Sync Chapter](4-monitoring-remote-systems.md#cluster-zone-config-sync).
+> Details in the [Configuration Sync Chapter](5-monitoring-remote-systems.md#cluster-zone-config-sync).
 
 #### <a id="cluster-scenarios-multiple-hierachies"></a> Multiple Hierachies
 
@@ -1610,9 +1610,9 @@ amongst them.
 
 By default the following features provide advanced HA functionality:
 
-* [Checks](4-monitoring-remote-systems.md#high-availability-checks) (load balanced, automated failover)
+* [Checks](5-monitoring-remote-systems.md#high-availability-checks) (load balanced, automated failover)
-* [Notifications](4-monitoring-remote-systems.md#high-availability-notifications) (load balanced, automated failover)
+* [Notifications](5-monitoring-remote-systems.md#high-availability-notifications) (load balanced, automated failover)
-* [DB IDO](4-monitoring-remote-systems.md#high-availability-db-ido) (Run-Once, automated failover)
+* [DB IDO](5-monitoring-remote-systems.md#high-availability-db-ido) (Run-Once, automated failover)
 
 #### <a id="high-availability-checks"></a> High Availability with Checks
 
@@ -1633,7 +1633,7 @@ Notifications are load balanced amongst all nodes in a zone. By default this fun
 is enabled.
 If your nodes should notify independent from any other nodes (this will cause
 duplicated notifications if not properly handled!), you can set `enable_ha = false`
-in the [NotificationComponent](12-object-types.md#objecttype-notificationcomponent) feature.
+in the [NotificationComponent](15-object-types.md#objecttype-notificationcomponent) feature.
 
 #### <a id="high-availability-db-ido"></a> High Availability with DB IDO
 
@@ -1651,8 +1651,8 @@ nodes disable the active IDO database connection at runtime.
 > **Note**
 >
 > The DB IDO HA feature can be disabled by setting the `enable_ha` attribute to `false`
-> for the [IdoMysqlConnection](12-object-types.md#objecttype-idomysqlconnection) or
+> for the [IdoMysqlConnection](15-object-types.md#objecttype-idomysqlconnection) or
-> [IdoPgsqlConnection](12-object-types.md#objecttype-idopgsqlconnection) object on all nodes in the
+> [IdoPgsqlConnection](15-object-types.md#objecttype-idopgsqlconnection) object on all nodes in the
 > same zone.
 >
 > All endpoints will enable the DB IDO feature then, connect to the configured
@@ -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](4-monitoring-remote-systems.md#configure-cluster-endpoints), [zones](4-monitoring-remote-systems.md#configure-cluster-zones))
+* update the `zones.conf` file on each involved node ([endpoint](5-monitoring-remote-systems.md#configure-cluster-endpoints), [zones](5-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](4-monitoring-remote-systems.md#cluster-zone-config-sync) enabled
+    * verify if this endpoints requires [configuration synchronisation](5-monitoring-remote-systems.md#cluster-zone-config-sync) enabled
-* if the node requires the existing zone history: [initial cluster sync](4-monitoring-remote-systems.md#initial-cluster-sync)
+* if the node requires the existing zone history: [initial cluster sync](5-monitoring-remote-systems.md#initial-cluster-sync)
-* add a [cluster health check](4-monitoring-remote-systems.md#cluster-health-check)
+* add a [cluster health check](5-monitoring-remote-systems.md#cluster-health-check)
 
 #### <a id="initial-cluster-sync"></a> Initial Cluster Sync
 
@@ -1705,7 +1705,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](2-getting-started.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/6-cli-commands.md

@@ -105,12 +105,12 @@ Debian/Ubuntu:
 
 #### Libraries
 
-Instead of loading libraries using the [`library` config directive](10-language-reference.md#library)
+Instead of loading libraries using the [`library` config directive](13-language-reference.md#library)
 you can also use the `--library` command-line option.
 
 #### Constants
 
-[Global constants](10-language-reference.md#constants) can be set using the `--define` command-line option.
+[Global constants](13-language-reference.md#constants) can be set using the `--define` command-line option.
 
 #### <a id="config-include-path"></a> Config Include Path
 
@@ -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](5-cli-commands.md#config-validation).
+Furthermore it provides the [configuration validation](6-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](5-cli-commands.md#config-validation) chapter.
+is returned. More details in the [configuration validation](6-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 ](4-monitoring-remote-systems.md#icinga2-remote-client-monitoring) or
+nodes in a [remote monitoring ](5-monitoring-remote-systems.md#icinga2-remote-client-monitoring) or
-[distributed cluster](4-monitoring-remote-systems.md#distributed-monitoring-high-availability) scenario.
+[distributed cluster](5-monitoring-remote-systems.md#distributed-monitoring-high-availability) scenario.
 
 
     # icinga2 node --help
@@ -240,9 +240,9 @@ nodes in a [remote monitoring ](4-monitoring-remote-systems.md#icinga2-remote-cl
 
 The `object` CLI command can be used to list all configuration objects and their
 attributes. The command also shows where each of the attributes was modified.
-That way you can also identify which objects have been created from your [apply rules](10-language-reference.md#apply).
+That way you can also identify which objects have been created from your [apply rules](13-language-reference.md#apply).
 
-More information can be found in the [troubleshooting](8-troubleshooting.md#list-configuration-objects) section.
+More information can be found in the [troubleshooting](10-troubleshooting.md#list-configuration-objects) section.
 
     # icinga2 object --help
     icinga2 - The Icinga 2 network monitoring daemon (version: v2.1.1-299-gf695275)
@@ -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](5-cli-commands.md#cli-command-pki) CLI commands too.
+This functionality is used by the [node setup/wizard](6-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](5-cli-commands.md#cli-command-object).
+Lists all configured variables (constants) in a similar fasion like [object list](6-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](5-cli-commands.md#cli-command-feature), respectively.
+[CLI commands](6-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
@@ -484,12 +484,12 @@ Or manually passing the `-C` argument:
 > `# icinga2 daemon -C`
 
 If you encouter errors during configuration validation, please make sure
-to read the [troubleshooting](8-troubleshooting.md#troubleshooting) chapter.
+to read the [troubleshooting](10-troubleshooting.md#troubleshooting) chapter.
 
-You can also use the [CLI command](5-cli-commands.md#cli-command-object) `icinga2 object list`
+You can also use the [CLI command](6-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](8-troubleshooting.md#list-configuration-objects).
+Find more on troubleshooting with `object list` in [this chapter](10-troubleshooting.md#list-configuration-objects).
 
 Example filtered by `Service` objects with the name `ping*`:
 
@@ -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](5-cli-commands.md#config-validation). If there are no validation errors you can
+to [validate](6-cli-commands.md#config-validation). If there are no validation errors you can
 safely reload the Icinga 2 daemon.
 
     # /etc/init.d/icinga2 reload
@@ -533,5 +533,5 @@ safely reload the Icinga 2 daemon.
 > which will validate the configuration in a separate process and not stop
 > the other events like check execution, notifications, etc.
 >
-> Details can be found [here](9-migrating-from-icinga-1x.md#differences-1x-2-real-reload).
+> Details can be found [here](12-migrating-from-icinga-1x.md#differences-1x-2-real-reload).
 

doc/7-addons-plugins.md

@@ -39,7 +39,7 @@ based on your monitoring configuration and status data using [NagVis](http://www
 As well as the Icinga supported web interfaces (Classic UI 1.x, Web 1.x, Web 2) there are a
 number of community provided web interfaces too:
 
-* [Thruk](http://www.thruk.org) based on the [Livestatus](7-livestatus.md#setting-up-livestatus) feature
+* [Thruk](http://www.thruk.org) based on the [Livestatus](9-livestatus.md#setting-up-livestatus) feature
 
 
 ## <a id="plugins"></a> Plugins
@@ -54,7 +54,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](2-getting-started.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/plugins
@@ -81,9 +81,9 @@ documentation and/or plugin provided README for installation instructions.
 Sometimes plugins contain hard-coded paths to other components. Instead of changing
 the plugin it might be easier to create logical links which is (more) update-safe.
 
-Each plugin requires a [CheckCommand](12-object-types.md#objecttype-checkcommand) object in your
+Each plugin requires a [CheckCommand](15-object-types.md#objecttype-checkcommand) object in your
-configuration which can be used in the [Service](12-object-types.md#objecttype-service) or
+configuration which can be used in the [Service](15-object-types.md#objecttype-service) or
-[Host](12-object-types.md#objecttype-host) object definition.
+[Host](15-object-types.md#objecttype-host) object definition.
 
 There are the following conventions to follow when adding a new command object definition:
 
@@ -93,7 +93,7 @@ in `[ ... ]` then for shell escaping.
 * Define a unique `prefix` for the command's specific command arguments. That way you can safely
 set them on host/service level and you'll always know which command they control.
 * Use command argument default values, e.g. for thresholds
-* Use [advanced conditions](12-object-types.md#objecttype-checkcommand) like `set_if` definitions.
+* Use [advanced conditions](15-object-types.md#objecttype-checkcommand) like `set_if` definitions.
 
 Example for a custom `my-snmp-int` check command:
 
@@ -124,7 +124,7 @@ Example for a custom `my-snmp-int` check command:
     }
 
 You can find an existing `CheckCommand` definition for the `check_snmp_int.pl` plugin
-shipped with the optional [Manubulon Plugin Check Command](13-icinga-template-library.md#snmp-manubulon-plugin-check-commands)
+shipped with the optional [Manubulon Plugin Check Command](16-icinga-template-library.md#snmp-manubulon-plugin-check-commands)
 definitions already.
 
 
@@ -144,3 +144,66 @@ The `Monitoring Plugin API` is defined in the [Monitoring Plugins Development Gu
 
 There are no output length restrictions using Icinga 2. This is different to the
 [Icinga 1.x plugin api definition](http://docs.icinga.org/latest/en/pluginapi.html#outputlengthrestrictions).
+
+## <a id="configuration-tools"></a> Configuration Tools
+
+If you require your favourite configuration tool to export Icinga 2 configuration, please get in
+touch with their developers. The Icinga project does not provide a configuration web interface
+or similar.
+
+> **Tip**
+>
+> Get to know the new configuration format and the advanced [apply](3-monitoring-basics.md#using-apply) rules and
+> use [syntax highlighting](7-addons-plugins.md#configuration-syntax-highlighting) in vim/nano.
+
+If you're looking for puppet manifests, chef cookbooks, ansible recipes, etc - we're happy
+to integrate them upstream, so please get in touch at [https://support.icinga.org](https://support.icinga.org).
+
+These tools are in development and require feedback and tests:
+
+* [Ansible Roles](https://github.com/Icinga/icinga2-ansible)
+* [Puppet Module](https://github.com/Icinga/puppet-icinga2)
+
+## <a id="configuration-syntax-highlighting"></a> Configuration Syntax Highlighting
+
+Icinga 2 ships configuration examples for syntax highlighting using the `vim` and `nano` editors.
+The RHEL, SUSE and Debian package `icinga2-common` install these files into
+`/usr/share/*/icinga2-common/syntax`. Sources provide these files in `tools/syntax`.
+
+### <a id="configuration-syntax-highlighting-vim"></a> Configuration Syntax Highlighting using Vim
+
+Create a new local vim configuration storage, if not already existing.
+Edit `vim/ftdetect/icinga2.vim` if your paths to the Icinga 2 configuration
+differ.
+
+    $ PREFIX=~/.vim
+    $ mkdir -p $PREFIX/{syntax,ftdetect}
+    $ cp vim/syntax/icinga2.vim $PREFIX/syntax/
+    $ cp vim/ftdetect/icinga2.vim $PREFIX/ftdetect/
+
+Test it:
+
+    $ vim /etc/icinga2/conf.d/templates.conf
+
+### <a id="configuration-syntax-highlighting-nano"></a> Configuration Syntax Highlighting using Nano
+
+Copy the `/etc/nanorc` sample file to your home directory. Create the `/etc/nano` directory
+and copy the provided `icinga2.nanorc` into it.
+
+    $ cp /etc/nanorc ~/.nanorc
+
+    # mkdir -p /etc/nano
+    # cp icinga2.nanorc /etc/nano/
+
+Then include the icinga2.nanorc file in your ~/.nanorc by adding the following line:
+
+    $ vim ~/.nanorc
+
+    ## Icinga 2
+    include "/etc/nano/icinga2.nanorc"
+
+Test it:
+
+    $ nano /etc/icinga2/conf.d/templates.conf
+
+

doc/8-alternative-frontends.md

@@ -0,0 +1,176 @@
+# <a id="alternative-frontends"></a> Alternative Frontends
+
+## <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](3-monitoring-basics.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.
+
+### <a id="installing-icinga-classic-ui"></a> Installing Icinga Classic UI 1.x
+
+The Icinga package repository has both Debian and RPM packages. You can install
+the Classic UI using the following packages:
+
+  Distribution  | Packages
+  --------------|---------------------
+  Debian        | icinga2-classicui
+  RHEL/SUSE     | icinga2-classicui-config icinga-gui
+
+The Debian packages require additional packages which are provided by the
+[Debian Monitoring Project](http://www.debmon.org) (`debmon`) repository.
+
+`libjs-jquery-ui` requires at least version `1.10.*` which is not available
+in Debian 7 (Wheezy) and Ubuntu 12.04 LTS (Precise). Add the following repositories
+to satisfy this dependency:
+
+  Distribution  		| Package Repositories
+  ------------------------------|------------------------------
+  Debian Wheezy 		| [wheezy-backports](http://backports.debian.org/Instructions/) or [debmon](http://www.debmon.org)
+  Ubuntu 12.04 LTS (Precise)    | [Icinga PPA](https://launchpad.net/~formorer/+archive/icinga)
+
+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](3-monitoring-basics.md#status-data), [CompatLogger](3-monitoring-basics.md#compat-logging)
+and [ExternalCommandListener](3-monitoring-basics.md#external-commands) features.
+Enable these features and restart Icinga 2.
+
+    # icinga2 feature enable statusdata compatlog command
+
+In order for commands to work you will need to [setup the external command pipe](2-getting-started.md#setting-up-external-command-pipe).
+
+### <a id="setting-up-icinga-classic-ui-summary"></a> Setting Up Icinga Classic UI 1.x Summary
+
+Verify that your Icinga 1.x Classic UI works by browsing to your Classic
+UI installation URL:
+
+  Distribution  | URL                                                                      | Default Login
+  --------------|--------------------------------------------------------------------------|--------------------------
+  Debian        | [http://localhost/icinga2-classicui](http://localhost/icinga2-classicui) | asked during installation
+  all others    | [http://localhost/icinga](http://localhost/icinga)                       | icingaadmin/icingaadmin
+
+For further information on configuration, troubleshooting and interface documentation
+please check the official [Icinga 1.x user interface documentation](http://docs.icinga.org/latest/en/ch06.html).
+
+## <a id="setting-up-icinga-web"></a> Setting up Icinga Web 1.x
+
+Icinga 2 can write to the same schema supplied by `Icinga IDOUtils 1.x` which
+is an explicit requirement to run `Icinga Web` next to the external command pipe.
+Therefore you need to setup the [DB IDO feature](2-getting-started.md#configuring-db-ido) remarked in the previous sections.
+
+### <a id="installing-icinga-web"></a> Installing Icinga Web 1.x
+
+The Icinga package repository has both Debian and RPM packages. You can install
+Icinga Web using the following packages (RPMs ship an additional configuration package):
+
+  Distribution  | Packages
+  --------------|-------------------------------------------------------
+  RHEL/SUSE     | icinga-web icinga-web-{mysql,pgsql}
+  Debian        | icinga-web icinga-web-config-icinga2-ido-{mysql,pgsql}
+
+### <a id="icinga-web-rpm-notes"></a> Icinga Web 1.x on RPM based systems
+
+Additionally you need to setup the `icinga_web` database and import the database schema.
+Details can be found in the package `README` files, for example [README.RHEL](https://github.com/Icinga/icinga-web/blob/master/doc/README.RHEL)
+
+The Icinga Web RPM packages install the schema files into
+`/usr/share/doc/icinga-web-*/schema` (`*` means package version).
+The Icinga Web dist tarball ships the schema files in `etc/schema`.
+
+On SuSE-based distributions the schema files are installed in
+`/usr/share/doc/packages/icinga-web/schema`.
+
+Example for RHEL and MySQL:
+
+    # mysql -u root -p
+
+    mysql> CREATE DATABASE icinga_web;
+           GRANT SELECT, INSERT, UPDATE, DELETE, DROP, CREATE VIEW, INDEX, EXECUTE ON icinga_web.* TO 'icinga_web'@'localhost' IDENTIFIED BY 'icinga_web';
+           quit
+
+    # mysql -u root -p icinga_web <  /usr/share/doc/icinga-web-<version>/schema/mysql.sql
+
+Icinga Web requires the IDO feature as database backend using MySQL or PostgreSQL.
+Enable that feature, e.g. for MySQL.
+
+    # icinga2 feature enable ido-mysql
+
+If you've changed your default credentials you may either create a read-only user
+or use the credentials defined in the IDO feature for Icinga Web backend configuration.
+Edit `databases.xml` accordingly and clear the cache afterwards. Further details can be
+found in the [Icinga Web documentation](http://docs.icinga.org/latest/en/icinga-web-config.html).
+
+    # vim /etc/icinga-web/conf.d/databases.xml
+
+    # icinga-web-clearcache
+
+Additionally you need to enable the `command` feature for sending [external commands](3-monitoring-basics.md#external-commands):
+
+    # icinga2 feature enable command
+
+In order for commands to work you will need to [setup the external command pipe](2-getting-started.md#setting-up-external-command-pipe).
+
+Then edit the Icinga Web configuration for sending commands in `/etc/icinga-web/conf.d/access.xml`
+(RHEL) or `/etc/icinga-web/access.xml` (SUSE) setting the command pipe path
+to the default used in Icinga 2. Make sure to clear the cache afterwards.
+
+    # vim /etc/icinga-web/conf.d/access.xml
+
+                <write>
+                    <files>
+                        <resource name="icinga_pipe">/var/run/icinga2/cmd/icinga2.cmd</resource>
+                    </files>
+                </write>
+
+    # icinga-web-clearcache
+
+> **Note**
+>
+> The path to the Icinga Web `clearcache` script may differ. Please check the
+> [Icinga Web documentation](https://docs.icinga.org) for details.
+
+### <a id="icinga-web-debian-notes"></a> Icinga Web on Debian systems
+
+Since Icinga Web `1.11.1-2` the IDO auto-configuration has been moved into
+additional packages on Debian and Ubuntu.
+
+The package `icinga-web` no longer configures the IDO connection. You must now
+use one of the config packages:
+
+ - `icinga-web-config-icinga2-ido-mysql`
+ - `icinga-web-config-icinga2-ido-pgsql`
+
+These packages take care of setting up the [DB IDO](2-getting-started.md#configuring-db-ido) configuration,
+enabling the external command pipe for Icinga Web and depend on
+the corresponding packages of Icinga 2.
+
+Please read the `README.Debian` files for details and advanced configuration:
+
+ - `/usr/share/doc/icinga-web/README.Debian`
+ - `/usr/share/doc/icinga-web-config-icinga2-ido-mysql/README.Debian`
+ - `/usr/share/doc/icinga-web-config-icinga2-ido-pgsql/README.Debian`
+
+When changing Icinga Web configuration files make sure to clear the config cache:
+
+    # /usr/lib/icinga-web/bin/clearcache.sh
+
+> **Note**
+>
+> If you are using an older version of Icinga Web, install it like this and adapt
+> the configuration manually as shown in [the RPM notes](8-alternative-frontends.md#icinga-web-rpm-notes):
+>
+> `apt-get install --no-install-recommends icinga-web`
+
+### <a id="setting-up-icinga-web-summary"></a> Setting Up Icinga Web 1.x Summary
+
+Verify that your Icinga 1.x Web works by browsing to your Web installation URL:
+
+  Distribution  | URL                                                         | Default Login
+  --------------|-------------------------------------------------------------|--------------------------
+  Debian        | [http://localhost/icinga-web](http://localhost/icinga-web)  | asked during installation
+  all others    | [http://localhost/icinga-web](http://localhost/icinga-web)  | root/password
+
+For further information on configuration, troubleshooting and interface documentation
+please check the official [Icinga 1.x user interface documentation](http://docs.icinga.org/latest/en/ch06.html).
+

doc/9-livestatus.md

@@ -8,7 +8,7 @@ status information. It can also be used to send commands.
 >
 > Only install the Livestatus feature if your web interface or addon requires
 > you to do so (for example, [Icinga Web 2](2-getting-started.md#setting-up-icingaweb2)).
-> [Icinga Classic UI](2-getting-started.md#setting-up-icinga-classic-ui) and [Icinga Web](2-getting-started.md#setting-up-icinga-web)
+> [Icinga Classic UI](8-alternative-frontends.md#setting-up-icinga-classic-ui) and [Icinga Web](8-alternative-frontends.md#setting-up-icinga-web)
 > do not use Livestatus as backend.
 
 The Livestatus component that is distributed as part of Icinga 2 is a
@@ -16,7 +16,7 @@ re-implementation of the Livestatus protocol which is compatible with MK
 Livestatus.
 
 Details on the available tables and attributes with Icinga 2 can be found
-in the [Livestatus Schema](14-appendix.md#schema-livestatus) section.
+in the [Livestatus Schema](17-appendix.md#schema-livestatus) section.
 
 You can enable Livestatus using icinga2 feature enable:
 
@@ -28,7 +28,7 @@ Debian/Ubuntu, RHEL/CentOS 6 and SUSE:
 
     # service icinga2 restart
 
-RHEL/CentOS 7 and Fedora 20:
+RHEL/CentOS 7 and Fedora:
 
     # systemctl restart icinga2
 
@@ -59,7 +59,7 @@ Other to the Icinga 1.x Addon, Icinga 2 supports two socket types
 * Unix socket (default)
 * TCP socket
 
-Details on the configuration can be found in the [LivestatusListener](12-object-types.md#objecttype-livestatuslistener)
+Details on the configuration can be found in the [LivestatusListener](15-object-types.md#objecttype-livestatuslistener)
 object configuration.
 
 ### <a id="livestatus-get-queries"></a> Livestatus GET Queries
@@ -92,7 +92,7 @@ Example using the tcp socket listening on port `6558`:
 
 ### <a id="livestatus-command-queries"></a> Livestatus COMMAND Queries
 
-A list of available external commands and their parameters can be found [here](14-appendix.md#external-commands-list-detail)
+A list of available external commands and their parameters can be found [here](17-appendix.md#external-commands-list-detail)
 
     $ echo -e 'COMMAND <externalcommandstring>' | netcat 127.0.0.1 6558
 
@@ -185,10 +185,10 @@ Default separators.
   downtimes     | services  | status attributes
   timeperiods   | &nbsp;    | name and is inside flag
   endpoints     | &nbsp;    | config and status attributes
-  log           | services, hosts, contacts, commands | parses [compatlog](12-object-types.md#objecttype-compatlogger) and shows log attributes
+  log           | services, hosts, contacts, commands | parses [compatlog](15-object-types.md#objecttype-compatlogger) and shows log attributes
-  statehist     | hosts, services | parses [compatlog](12-object-types.md#objecttype-compatlogger) and aggregates state change attributes
+  statehist     | hosts, services | parses [compatlog](15-object-types.md#objecttype-compatlogger) and aggregates state change attributes
 
 The `commands` table is populated with `CheckCommand`, `EventCommand` and `NotificationCommand` objects.
 
-A detailed list on the available table attributes can be found in the [Livestatus Schema documentation](14-appendix.md#schema-livestatus).
+A detailed list on the available table attributes can be found in the [Livestatus Schema documentation](17-appendix.md#schema-livestatus).
 

mkdocs.yml

@@ -5,17 +5,18 @@ pages:
 - [1-about.md, About Icinga 2]
 - [2-getting-started.md, Getting Started]
 - [3-monitoring-basics.md, Monitoring Basics]
-- [4-monitoring-remote-systems.md, Monitoring Remote Systems]
+- [4-configuring-icinga-2.md, Configuring Icinga 2]
-- [5-cli-commands.md, CLI Commands]
+- [5-monitoring-remote-systems.md, Monitoring Remote Systems]
-- [6-addons-plugins.md, Addons and Plugins]
+- [6-cli-commands.md, CLI Commands]
-- [7-livestatus.md, Livestatus]
+- [7-addons-plugins.md, Addons and Plugins]
-- [8-troubleshooting.md, Troubleshooting]
+- [8-livestatus.md, Livestatus]
-- [9-migrating-from-icinga-1x.md, Migrating from Icinga 1.x]
+- [9-troubleshooting.md, Troubleshooting]
-- [10-language-reference.md, Language Reference]
+- [10-migrating-from-icinga-1x.md, Migrating from Icinga 1.x]
-- [11-library-reference.md, Library Reference]
+- [11-language-reference.md, Language Reference]
-- [12-object-types.md, Object Types]
+- [12-library-reference.md, Library Reference]
-- [13-icinga-template-library.md, Icinga Template Library]
+- [13-object-types.md, Object Types]
-- [14-appendix.md, Appendix]
+- [14-icinga-template-library.md, Icinga Template Library]
+- [15-appendix.md, Appendix]
 theme: readthedocs
 markdown_extensions: [smarty]
 extra_javascript: [scroll.js]