are a good way to start with Icinga 2.
If you're interested in a detailed explanation of each language feature used in those
-configuration files you can find more information in the [Language Reference](19-language-reference.md#language-reference)
+configuration files you can find more information in the [Language Reference](18-language-reference.md#language-reference)
chapter.
## <a id="configuration-best-practice"></a> Configuration Best Practice
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 tool](13-addons-plugins.md#configuration-tools) such as Puppet, Chef, Ansible, etc.
+* Generated by a [configuration management tool](14-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.
* to the documentation that is distributed as part of Icinga 2.
*/
-Icinga 2 supports [C/C++-style comments](19-language-reference.md#comments).
+Icinga 2 supports [C/C++-style comments](18-language-reference.md#comments).
/**
* The constants.conf defines global constants.
This `include` directive takes care of including the configuration files for all
the features which have been enabled with `icinga2 feature enable`. See
-[Enabling/Disabling Features](8-cli-commands.md#features) for more details.
+[Enabling/Disabling Features](8-cli-commands.md#enable-features) for more details.
/**
* The repository.d directory contains all configuration objects
This `include_recursive` directive is used for discovery of services on remote clients
and their generated configuration described in
-[this chapter](10-icinga2-client.md#icinga2-remote-monitoring-master-discovery).
+[this chapter](11-icinga2-client.md#icinga2-remote-monitoring-master-discovery).
/**
* [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)
+* [api-users.conf](4-configuring-icinga-2.md#api-users-conf)
+* [app.conf](4-configuring-icinga-2.md#app-conf)
#### <a id="hosts-conf"></a> hosts.conf
> **Tip**
>
-> If you don't understand all the attributes and how to use [apply rules](19-language-reference.md#apply)
+> If you don't understand all the attributes and how to use [apply rules](18-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](19-language-reference.md#apply) will show you how to monitor
+These service [apply rules](18-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.
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](19-language-reference.md#expression-operators)
+is created for each matching host. [Expression operators](18-language-reference.md#expression-operators)
may be used in `assign where` conditions.
Multiple `assign where` condition can be combined with `AND` using the `&&` operator
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](19-language-reference.md#expression-operators), for example
+and `OR` using `&&` and `||` [operators](18-language-reference.md#expression-operators), for example
`assign where host.address && (vars.os == "Linux" || vars.os == "Windows")`.
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](19-language-reference.md#group-assign) expressions similar
+This is done by using the [group assign](18-language-reference.md#group-assign) expressions similar
to previously seen [apply rules](3-monitoring-basics.md#using-apply).
object HostGroup "linux-servers" {
}
Service groups can be grouped together by similar pattern matches.
-The [match() function](19-language-reference.md#function-calls) expects a wildcard match string
+The [match() function](18-language-reference.md#function-calls) expects a wildcard match string
and the attribute string to match with.
object ServiceGroup "ping" {
#### <a id="satellite-conf"></a> satellite.conf
Includes default templates and dependencies for
-[monitoring remote clients](10-icinga2-client.md#icinga2-client)
+[monitoring remote clients](11-icinga2-client.md#icinga2-client)
using service discovery and
-[config generation](10-icinga2-client.md#icinga2-remote-monitoring-master-discovery)
-on the master. Can be ignored/removed on setups not using this features.
+[config generation](11-icinga2-client.md#icinga2-remote-monitoring-master-discovery)
+on the master. Can be ignored/removed on setups not using this feature.
Further details on the monitoring configuration can be found in the
[monitoring basics](3-monitoring-basics.md#monitoring-basics) chapter.
+
+#### <a id="api-users-conf"></a> api-users.conf
+
+Provides the default [ApiUser](6-object-types.md#objecttype-apiuser) object
+named "root" for the [API authentication](9-icinga2-api.md#icinga2-api-authentication).
+
+#### <a id="app-conf"></a> app.conf
+
+Provides the default [IcingaApplication](6-object-types.md#objecttype-icingaapplication)
+object named "app" for additional settings such as disabling notifications
+globally, etc.
projects / icinga2 / blobdiff