diff --git a/modules/monitoring/doc/commandtransports.md b/modules/monitoring/doc/commandtransports.md index 238643f5c..ba9a3be54 100644 --- a/modules/monitoring/doc/commandtransports.md +++ b/modules/monitoring/doc/commandtransports.md @@ -1,24 +1,56 @@ -# The commandtransports.ini configuration file +# External Command Transport Configuration -## Abstract +## Introduction -The commandtransports.ini defines how Icinga Web 2 accesses the command pipe of -your Icinga instance in order to submit external commands. Depending on the -config path (default: /etc/icingaweb2) of your Icinga Web 2 installation you can -find it under ./modules/monitoring/commandtransports.ini. +The `commandtransports.ini` defines how Icinga Web 2 transports commands to your Icinga instance in order to submit +external commands. By default, this file is located at `/etc/icingaweb2/modules/monitoring/commandtransports.ini`. -## Syntax +You can define multiple command transports in the `commandtransports.ini`. Every transport starts with a section header +containing its name, followed by the config directives for this transport in the standard INI-format. -You can define multiple command transports in the commandtransports.ini. Every -transport starts with a section header containing its name, followed by the -config directives for this transport in the standard INI-format. +Icinga Web 2 will try one transport after another to send a command until the command is successfully sent. +If [configured](#commandtransports-multiple-instances), Icinga Web 2 will take different instances into account. +The order in which Icinga Web 2 processes the configured transports is defined by the order of sections in +`commandtransports.ini`. -Icinga Web 2 will try one transport after another to send a command, depending -on the respective Icinga instance, until the command is successfully sent. The -order in which Icinga Web 2 processes the configured transports is defined by -the order of sections in the commandtransports.ini. +## Use the Icinga 2 API -## Using a local command pipe +If you're running Icinga 2 it's best to use the Icinga 2 API for transmitting external commands. + +First, you have to enable the `api` feature on the Icinga 2 host where you want to send the commands to: + +``` +icinga2 feature enable api +``` + +Next, you have to create an ApiUser object for authenticating against the Icinga 2 API. This configuration also applies +to the host where you want to send the commands to. We recommend to create/edit the file +`/etc/icinga2/conf.d/api-users.conf`: + +``` +object ApiUser "web2" { + password = "bea11beb7b810ea9ce6ea" // Change this! + permissions = [ "actions/*", "objects/modify/hosts", "objects/modify/services", "objects/modify/icingaapplications" ] +} +``` + +The permissions `actions/*`, `objects/modify/hosts`, `objects/modify/services`, `objects/modify/icingaapplications` are +mandatory in order to submit all external commands from within Icinga Web 2. + +**Restart Icinga 2** for the changes to take effect. + +After that, you have to set up Icinga Web 2's `commandtransport.ini` to use the Icinga 2 API: + +``` +[icinga2] +transport = "api" +host = "127.0.0.1" // Icinga 2 host +port = "5665" +username = "web2" +password = "bea11beb7b810ea9ce6ea" // Change that! +``` + +## Use a Local Command Pipe A local Icinga instance requires the following directives: @@ -31,7 +63,7 @@ path = /var/run/icinga2/cmd/icinga2.cmd When sending commands to the Icinga instance, Icinga Web 2 opens the file found on the local filesystem underneath 'path' and writes the external command to it. -## Using SSH for accessing a remote command pipe +## Use SSH For a Remote Command Pipe A command pipe on a remote host's filesystem can be accessed by configuring a SSH based command transport and requires the following directives: @@ -74,11 +106,10 @@ user = icinga private_key = /etc/icingaweb2/ssh/icinga ``` -## Configuring transports for different Icinga instances +## Configure Transports for Different Icinga Instances -If there are multiple but different Icinga instances writing to your IDO you can -define which transport belongs to which Icinga instance by providing the -directive 'instance'. This directive should contain the name of the Icinga +If there are multiple but different Icinga instances writing to your IDO, you can define which transport belongs to +which Icinga instance by providing the directive `instance`. This directive should contain the name of the Icinga instance you want to assign to the transport: ``` @@ -91,6 +122,5 @@ instance = icinga1 instance = icinga2 ``` -Associating a transport to a specific Icinga instance causes this transport to -be used to send commands to the linked instance only. Transports without a -linked Icinga instance are utilized to send commands to all instances. +Associating a transport to a specific Icinga instance causes this transport to be used to send commands to the linked +instance only. Transports without a linked Icinga instance are used to send commands to all instances.