Back to Icinga without director

I have currently installed an Icinga2 with Director and have defined a few hosts and services. Now I want to go back to .conf files and disable the director. Unfortunately I have no idea how? It is not important to me that the defined hosts and services are kept. Do I have to reinstall Icinga2 or is there another solution?


there are a couple of ways to achieve that, re-installing is not one of them :wink:

Delete the director config package via REST API

The Director communicates with Icinga only by using the REST API transport, and in specific, it creates configuration packages.

List config packages

First off, list all available configuration packages e.g. via a curl call.

curl -k -s -u root:icinga 'https://localhost:5665/v1/config/packages?pretty=1'

The Director uses the director config package by default.

Delete the director config package

Send a DELETE request to the URL endpoint containing the package name director.

curl -k -s -u root:icinga -X DELETE -H 'Accept: application/json' 'https://localhost:5665/v1/config/packages/director'

This triggers a reload of Icinga automatically.

[2019-02-01 20:22:32 +0100] information/HttpServerConnection: Request: DELETE /v1/config/packages/director (from []:54178), user: root)
[2019-02-01 20:22:32 +0100] information/HttpServerConnection: HTTP client disconnected (from []:54178)
[2019-02-01 20:22:33 +0100] information/Application: Got reload command: Starting new instance.
[2019-02-01 20:22:34 +0100] information/Application: Reload requested, letting new process take over.

Keep a backup of the config, delete the package

In case you want to keep the configuration files deployed from the Director for later reference, you can do the following.

Fetch the active stage inside the director config package.

curl -k -s -u root:icinga 'https://localhost:5665/v1/config/packages?pretty=1

Extract the value of active-stage, now referred as ACTIVESTAGE.

Fetch a list of config files contained in the current active stage in the director package.

curl -k -s -u root:icinga 'https://localhost:5665/v1/config/stages?pretty=1&stage=<ACTIVESTAGE>&package=director'

The path is stored in the name attribute.

Iterate over all result paths and fetch their content. Example with FILEPATH.

curl -k -s -u root:icinga 'https://localhost:5665/v1/config/files/director/<ACTIVESTAGE>/>FILEPATH>

The returned content type is text, not JSON and contains Icinga 2 configuration. Store it somewhere safe.

Delete the complete config package.

curl -k -s -u root:icinga -X DELETE -H 'Accept: application/json' 'https://localhost:5665/v1/config/packages/director'


1 Like

I got an error <h1>Bad Request</h1><p><pre>Invalid URL Query</pre></p>

I recognized it myself :wink:
Now my question, the director is deleted, but no host from the conf.d/ is displayed to me. I have already restarted

Fixed that, copy paste error.

Verify what’s included in your icinga2.conf file, that’s the config file used to tell the daemon where to look at.

Got it, include_recursive "conf.d" was missing. Now I think I have to check my API Settings:

Feb 02 11:07:45 ICINGA-DEFRA-01-0005 icinga2[1692]: /etc/icinga2/conf.d/api-users.conf(2):  * The ApiUser objects are used for authentication against the API.
Feb 02 11:07:45 ICINGA-DEFRA-01-0005 icinga2[1692]: /etc/icinga2/conf.d/api-users.conf(3):  */
Feb 02 11:07:45 ICINGA-DEFRA-01-0005 icinga2[1692]: /etc/icinga2/conf.d/api-users.conf(4): object ApiUser "root" {
Feb 02 11:07:45 ICINGA-DEFRA-01-0005 icinga2[1692]:                                        ^^^^^^^^^^^^^^^^^^^^^
Feb 02 11:07:45 ICINGA-DEFRA-01-0005 icinga2[1692]: /etc/icinga2/conf.d/api-users.conf(5):   password = "SECRET"
Feb 02 11:07:45 ICINGA-DEFRA-01-0005 icinga2[1692]: /etc/icinga2/conf.d/api-users.conf(6):   // client_cn = ""
Feb 02 11:07:45 ICINGA-DEFRA-01-0005 systemd[1]: icinga2.service: Main process exited, code=exited, status=1/FAILURE
Feb 02 11:07:45 ICINGA-DEFRA-01-0005 systemd[1]: Failed to start Icinga host/service/network monitoring system.
Feb 02 11:07:45 ICINGA-DEFRA-01-0005 systemd[1]: icinga2.service: Unit entered failed state.
Feb 02 11:07:45 ICINGA-DEFRA-01-0005 systemd[1]: icinga2.service: Failed with result 'exit-code'.

Without the api-user it is working fine. I have once to read what this user is for…

The ApiUser is used for accessing Icinga 2 via API, which is for example used for Icinga Web 2. You can check your config with icinga2 daemon -C

1 Like


just a guess here, but it is possible that the root ApiUser object is loaded twice by the config compiler.

You re-enabled the include_recursive "conf.d", which is disabled by the node wizard (icinga2 node wizard). The node wizard adds a new include statement in the icinga2.conf file to include the api-uses.conf file separately. If you now re-enabled the recursive include statement for the conf.d directory but not disabled the include statement for the api-users.conf file, the file is included twice.

To fix this just disable the inclusion for the api-users.conf file by editing the file icinga2.conf:

// include "conf.d/api-users.conf"

As said just a guess, but if you run icinga2 daemon -C to validate the config and you get the following error:

critical/config: Error: Object 'root' of type 'ApiUser' re-defined: in /etc/icinga2/conf.d/api-users.conf: 4:1-4:21; previous definition: in /etc/icinga2/conf.d/api-users.conf: 4:1-4:21

it is highly likely the mentioned double inclusion. If not please share the output of icinga2 daemon -C so we can figure out the problem. :slight_smile:

Best regards

1 Like


great, that’s it : // include "conf.d/api-users.conf" now it’s working. Thank you.

1 Like