> **Tip**
>
-> Don't panic - there are CLI commands available, including setup wizards for easy installation
+> Don't panic -- there are CLI commands available, including setup wizards for easy installation
> with SSL certificates.
-> If you prefer to use your own CA (for example Puppet) you can do that as well.
+> If you prefer to use your own CA (for example Puppet), you can do that as well.
## <a id="icinga2-client-scenarios"></a> Client Scenarios
### <a id="icinga2-client-installation-master-setup"></a> Setup the Master for Remote Clients
-If you are planning to use the [remote Icinga 2 clients](11-icinga2-client.md#icinga2-client)
+If you are planning to use the [remote Icinga 2 clients](11-icinga2-client.md#icinga2-client),
you'll first need to update your master setup.
Your master setup requires the following
> and must remain on the master providing the CSR Auto-Signing functionality for security reasons.
The client setup wizard will ask you to generate a valid ticket number using its CN.
-If you already know your remote client's Common Names (CNs) - usually the FQDN - you
+If you already know your remote client's Common Names (CNs) -- usually the FQDN --, you
can generate all ticket numbers on-demand.
This is also reasonable if you are not capable of installing the remote client, but
![Icinga 2 Windows Setup](images/icinga2-client/icinga2_windows_setup_wizard_04.png)
-If you have chosen to install/update the NSClient++ package the Icinga 2 setup wizard will ask
+If you have chosen to install/update the NSClient++ package, the Icinga 2 setup wizard will ask
you to do so.
![Icinga 2 Windows Setup](images/icinga2-client/icinga2_windows_setup_wizard_05.png)
![Icinga 2 Windows Setup](images/icinga2-client/icinga2_windows_running_service.png)
The Icinga 2 configuration is located inside the `C:\ProgramData\icinga2` directory.
-If you click `Examine Config` in the setup wizard running it will open a new explorer window.
+If you click `Examine Config` in the setup wizard, it will open a new explorer window.
![Icinga 2 Windows Setup](images/icinga2-client/icinga2_windows_setup_wizard_examine_config.png)
#### <a id="icinga2-client-installation-client-setup-windows-silent"></a> Silent Windows Client Setup
-If you want to install the client silently / unattended use the `/qn` modifier. The
-installation should not trigger a restart but if you want to be completly sure, you can use the `/norestart` modifier.
+If you want to install the client silently/unattended, use the `/qn` modifier. The
+installation should not trigger a restart but if you want to be completly sure you can use the `/norestart` modifier.
C:> msiexec /i C:\Icinga2-v2.4.5-x86.msi /qn /norestart
and the possibility to add Icinga 2 features on demand.
There is no difference in the configuration syntax on clients to any other Icinga 2 installation.
-You can also use additional features like notifications directly on the remote client, if you are
+You can also use additional features like notifications directly on the remote client if you are
required to. Basically everything a single Icinga 2 instance provides by default.
The following convention applies to remote clients:
# systemctl reload icinga2
-The `update-config` CLI command will fail, if there are uncommitted changes for the
+The `update-config` CLI command will fail if there are uncommitted changes for the
configuration repository or if your master is part of a HA setup (see https://dev.icinga.org/issues/8292 for details).
Please review these changes manually, or clear the commit and try again. This is a
safety hook to prevent unwanted manual changes to be committed by a updating the
Check Commands, but you should also modify the local configuration inside `commands.conf`
for example.
-If you're wondering why you need to keep the same command configuration on the master and
+If you're wondering, why you need to keep the same command configuration on the master and
remote client: Icinga 2 calculates all required runtime macros used as command arguments on
the master and sends that information to the client.
In case you want to limit command arguments or handles values in a different manner, you
### Config Validation
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
+contain errors. If any errors are found, the exit status is 1, otherwise 0
is returned. More details in the [configuration validation](8-cli-commands.md#config-validation) chapter.
## <a id="config-change-reload"></a> Reload on Configuration Changes
Everytime you have changed your configuration you should first tell Icinga 2
-to [validate](8-cli-commands.md#config-validation). If there are no validation errors you can
+to [validate](8-cli-commands.md#config-validation). If there are no validation errors, you can
safely reload the Icinga 2 daemon.
# /etc/init.d/icinga2 reload
# service icinga2 restart
-If you prefer to set up the API manually you will have to perform the following steps:
+If you prefer to set up the API manually, you will have to perform the following steps:
* Set up X.509 certificates for Icinga 2
* Enable the `api` feature (`icinga2 feature enable api`)
https://localhost:5665/v1/objects/hosts
-If you're only interested in a single object you can limit the output to that object by specifying its name:
+If you're only interested in a single object, you can limit the output to that object by specifying its name:
https://localhost:5665/v1/objects/hosts?host=localhost
https://localhost:5665/v1/objects/hosts?hosts=first-host&hosts=second-host
-Again - like in the previous example - the name of the URL parameter is the lower-case version of the type. However, because we're specifying multiple objects here the **plural form** of the type is used.
+Again -- like in the previous example -- the name of the URL parameter is the lower-case version of the type. However, because we're specifying multiple objects here the **plural form** of the type is used.
When specifying names for objects which have composite names like for example services the
full name has to be used:
Parameter | Type | Description
-------------|-----------|--------------
- next\_check | timestamp | **Optional.** The next check will be run at this time. If omitted the current time is used.
- force\_check | boolean | **Optional.** Defaults to `false`. If enabled the checks are executed regardless of time period restrictions and checks being disabled per object or on a global basis.
+ next\_check | timestamp | **Optional.** The next check will be run at this time. If omitted, the current time is used.
+ force\_check | boolean | **Optional.** Defaults to `false`. If enabled, the checks are executed regardless of time period restrictions and checks being disabled per object or on a global basis.
In addition to these parameters a [filter](9-icinga2-api.md#icinga2-api-filters) must be provided. The valid types for this action are `Host` and `Service`.
----------|-----------|--------------
author | string | **Required.** Name of the author, may be empty.
comment | string | **Required.** Comment text, may be empty.
- expiry | timestamp | **Optional.** If set the acknowledgement will vanish after this timestamp.
+ expiry | timestamp | **Optional.** If set, the acknowledgement will vanish after this timestamp.
sticky | boolean | **Optional.** If `true`, the default, the acknowledgement will remain until the service or host fully recovers.
- notify | boolean | **Optional.** If `true` a notification will be sent out to contacts to indicate this problem has been acknowledged. The default is false.
+ notify | boolean | **Optional.** If `true`, a notification will be sent out to contacts to indicate this problem has been acknowledged. The default is false.
In addition to these parameters a [filter](9-icinga2-api.md#icinga2-api-filters) must be provided. The valid types for this action are `Host` and `Service`.
start\_time | timestamp | **Required.** Timestamp marking the beginning of the downtime.
end\_time | timestamp | **Required.** Timestamp marking the end of the downtime.
duration | integer | **Required.** Duration of the downtime in seconds if `fixed` is set to false.
- fixed | boolean | **Optional.** Defaults to `true`. If true the downtime is `fixed` otherwise `flexible`. See [downtimes](5-advanced-topics.md#downtimes) for more information.
+ fixed | boolean | **Optional.** Defaults to `true`. If true, the downtime is `fixed` otherwise `flexible`. See [downtimes](5-advanced-topics.md#downtimes) for more information.
trigger\_name | string | **Optional.** Sets the trigger for a triggered downtime. See [downtimes](5-advanced-topics.md#downtimes) for more information on triggered downtimes.
In addition to these parameters a [filter](9-icinga2-api.md#icinga2-api-filters) must be provided. The valid types for this action are `Host` and `Service`.
generates a unique name for the `stage` attribute you'll need for later requests.
Icinga 2 automatically restarts the daemon in order to activate the new config stage.
-If the validation for the new config stage failed the old stage and its configuration objects
+If the validation for the new config stage failed, the old stage and its configuration objects
will remain active.
> **Note**
The [API permission](9-icinga2-api.md#icinga2-api-permissions) `console` is required for executing
expressions.
-If you specify a session identifier the same script context can be reused for multiple requests. This allows you to, for example, set a local variable in a request and use that local variable in another request. Sessions automatically expire after a set period of inactivity (currently 30 minutes).
+If you specify a session identifier, the same script context can be reused for multiple requests. This allows you to, for example, set a local variable in a request and use that local variable in another request. Sessions automatically expire after a set period of inactivity (currently 30 minutes).
Example for fetching the command line from the local host's last check result: