[dev.icinga.com #12835] Posting config stage fails on FreeBSD

[icinga-migration]

This issue has been migrated from Redmine: https://dev.icinga.com/issues/12835

Created by andrem on 2016-09-30 13:14:54 +00:00

Assignee: andrem
Status: Feedback (closed on 2016-10-13 13:09:55 +00:00)
Target Version: (none)
Last Update: 2016-12-07 20:21:25 +00:00 (in Redmine)

Icinga Version: 2.5.4

---

Hi All,

when i deploy a config from Director to my Icinga2, I get this :

/usr/local/www/icingaweb2/modules/director/library/Director/Core/RestApiClient.php:194:string '{error creation failed."}' (length=49)

The Versions are : Icinga2 (v.r2.5.4-1) und Icingaweb2 (v.2.3.4) Director 1.1.0 (Git from 30.09.2016) mySQL 56 php56 Nginx FreeBSD 10.3

Icinga2 debug.log show this :

[2016-09-30 15:11:50 +0200] information/ApiListener: New client connection from [::ffff:172.16.1.54]:17538 (no client certificate)
[2016-09-30 15:11:50 +0200] notice/ApiListener: New HTTP client
[2016-09-30 15:11:50 +0200] debug/HttpRequest: line: GET /v1/config/packages HTTP/1.1, tokens: 3
[2016-09-30 15:11:50 +0200] notice/WorkQueue: Spawning WorkQueue threads for 'HttpServerConnection'
[2016-09-30 15:11:50 +0200] information/HttpServerConnection: Request: GET /v1/config/packages (from [::ffff:172.16.1.54]:17538, user: root)
[2016-09-30 15:11:50 +0200] debug/HttpServerConnection: Http client disconnected
[2016-09-30 15:11:50 +0200] notice/WorkQueue: Stopped WorkQueue threads for 'HttpServerConnection'
[2016-09-30 15:11:51 +0200] debug/IdoMysqlConnection: Query: COMMIT
[2016-09-30 15:11:51 +0200] debug/IdoMysqlConnection: Query: BEGIN
[2016-09-30 15:11:52 +0200] debug/IdoMysqlConnection: Query: COMMIT
[2016-09-30 15:11:52 +0200] debug/IdoMysqlConnection: Query: BEGIN
[2016-09-30 15:11:53 +0200] debug/IdoMysqlConnection: Query: COMMIT
[2016-09-30 15:11:53 +0200] debug/IdoMysqlConnection: Query: BEGIN
[2016-09-30 15:11:54 +0200] debug/IdoMysqlConnection: Query: COMMIT
[2016-09-30 15:11:54 +0200] debug/IdoMysqlConnection: Query: BEGIN
[2016-09-30 15:11:54 +0200] information/ApiListener: New client connection from [::ffff:172.16.1.54]:10582 (no client certificate)
[2016-09-30 15:11:54 +0200] notice/ApiListener: New HTTP client
[2016-09-30 15:11:54 +0200] debug/HttpRequest: line: GET /v1/config/packages HTTP/1.1, tokens: 3
[2016-09-30 15:11:54 +0200] notice/WorkQueue: Spawning WorkQueue threads for 'HttpServerConnection'
[2016-09-30 15:11:54 +0200] information/HttpServerConnection: Request: GET /v1/config/packages (from [::ffff:172.16.1.54]:10582, user: root)
[2016-09-30 15:11:54 +0200] debug/HttpRequest: line: DELETE /v1/config/stages/director/icinga2-tb.XXX.de-1475240554-51 HTTP/1.1, tokens: 3
[2016-09-30 15:11:54 +0200] information/HttpServerConnection: Request: DELETE /v1/config/stages/director/icinga2-tb.XXX.de-1475240554-51 (from [::ffff:172.16.1.54]:10582, user: root)
[2016-09-30 15:11:54 +0200] debug/HttpRequest: line: GET /v1/config/packages HTTP/1.1, tokens: 3
[2016-09-30 15:11:54 +0200] information/HttpServerConnection: Request: GET /v1/config/packages (from [::ffff:172.16.1.54]:10582, user: root)
[2016-09-30 15:11:54 +0200] debug/HttpRequest: line: POST /v1/config/stages/director HTTP/1.1, tokens: 3
[2016-09-30 15:11:54 +0200] information/HttpServerConnection: Request: POST /v1/config/stages/director (from [::ffff:172.16.1.54]:10582, user: root)
[2016-09-30 15:11:54 +0200] information/ConfigPackageUtility: Updating configuration file: /var/lib/icinga2/api/packages/director/icinga2-tb.XXX.de-1475241114-52/zones.d/director-global/001-director-basics.conf
[2016-09-30 15:11:54 +0200] information/ConfigPackageUtility: Updating configuration file: /var/lib/icinga2/api/packages/director/icinga2-tb.XXX.de-1475241114-52/zones.d/director-global/commands.conf
[2016-09-30 15:11:54 +0200] information/ConfigPackageUtility: Updating configuration file: /var/lib/icinga2/api/packages/director/icinga2-tb.XXX.de-1475241114-52/zones.d/director-global/host_templates.conf
[2016-09-30 15:11:54 +0200] debug/HttpServerConnection: Http client disconnected
[2016-09-30 15:11:54 +0200] notice/WorkQueue: Stopped WorkQueue threads for 'HttpServerConnection'

Logfiles from php-fpm und nginx Show no Errors.

Best Regards.

https://monitoring-portal.org/index.php?thread/37556-icinga2-director-und-freebsd/&s=b8c3e7cf8c686b98975218ae43a1559b34f9ecef

Attachments

• curl.PNG andrem - 2016-10-18 14:59:01 +00:00

[icinga-migration]

Updated by tgelf on 2016-10-11 14:51:17 +00:00

• Tracker changed from Bug to Support

This is not a Director issue. Please check permissions for /var/lib/icinga2/api/packages as suggested in the linked forum.

[icinga-migration]

Updated by tgelf on 2016-10-13 13:09:55 +00:00

• Status changed from New to Closed

Closing this as not really Director-related. Please let me know in case you continue having such after having checked your directory permissions. In case they are wrong, this should probably be fixed in the Icinga 2 FreeBSD packages.

[icinga-migration]

Updated by LarsEngels on 2016-10-17 09:22:58 +00:00

@tgelf: I am facing the same issue. All files and directories are owned by "icinga" which also runs the icinga2 daemon.

[icinga-migration]

Updated by tgelf on 2016-10-18 01:59:56 +00:00

• Status changed from Closed to Feedback
• Assigned to set to LarsEngels

@LarsEngels: thank you! Still, I do not see much Director can do here. It fires an API request via HTTPS to port 5665 and does in no way directly work with those files. Could you please try to manually create a config package with curl or similar? Like shown here:

http://docs.icinga.org/icinga2/latest/doc/module/icinga2/chapter/icinga2-api#icinga2-api-config-management-create-package

In case it doesn't work we have an easy way to reproduce this and move the issue to the core queue. If it doesn't it must be something weird, then I'd next try to figure out whether something changes when either Director or the Core does not run on FreeBSD while the other component still does.

Thanks for your help!
Thomas

[icinga-migration]

Updated by LarsEngels on 2016-10-18 08:17:42 +00:00

Creating the config package works:

curl -k -s -u root:password -H 'Accept: application/json' -X POST https://localhost:5665/v1/config/packages/example-cmdb 
{"results":[{"code":200.0,"status":"Created package."}]}% 

However uploading a configuration does not work:

lars@milhouse  /usr/local/etc/icinga2  curl -vvv -k -s -u root:$password -H 'Accept: application/json' -X POST \
-d '{ "files": { "conf.d/test.conf": "object Host \"cmdb-host\" { chec_command = \"dummy\" }" } }' \
'https://localhost:5665/v1/config/stages/example-cmdb' | python -m json.tool
*   Trying ::1...
* TCP_NODELAY set
* Connected to localhost (::1) port 5665 (#0)
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: /usr/local/share/certs/ca-root-nss.crt
  CApath: none
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
} [5 bytes data]
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
} [512 bytes data]
* TLSv1.2 (IN), TLS handshake, Server hello (2):
{ [86 bytes data]
* TLSv1.2 (IN), TLS handshake, Certificate (11):
{ [2514 bytes data]
* TLSv1.2 (IN), TLS handshake, Request CERT (13):
{ [66 bytes data]
* TLSv1.2 (IN), TLS handshake, Server finished (14):
{ [4 bytes data]
* TLSv1.2 (OUT), TLS handshake, Certificate (11):
} [7 bytes data]
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
} [518 bytes data]
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
} [1 bytes data]
* TLSv1.2 (OUT), TLS handshake, Finished (20):
} [16 bytes data]
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
{ [1 bytes data]
* TLSv1.2 (IN), TLS handshake, Finished (20):
{ [16 bytes data]
* SSL connection using TLSv1.2 / AES256-GCM-SHA384
* ALPN, server did not agree to a protocol
* Server certificate:
*  subject: CN=milhouse.bsd-geek.de
*  start date: Oct 16 16:42:16 2016 GMT
*  expire date: Oct 13 16:42:16 2031 GMT
*  issuer: CN=Icinga CA
*  SSL certificate verify result: self signed certificate in certificate chain (19), continuing anyway.
* Server auth using Basic with user 'root'
} [5 bytes data]
> POST /v1/config/stages/example-cmdb HTTP/1.1
> Host: localhost:5665
> Authorization: Basic cm9vdDoxOTFmZmY5ZDJmY2M4MTY3
> User-Agent: curl/7.50.3
> Accept: application/json
> Content-Length: 93
> Content-Type: application/x-www-form-urlencoded
> 
} [93 bytes data]
* upload completely sent off: 93 out of 93 bytes
{ [5 bytes data]
< HTTP/1.1 500 Internal Server Error
< Content-Type: application/json
< Transfer-Encoding: chunked
< Server: Icinga/r2.5.4-1
< 
{ [60 bytes data]
* Curl_http_done: called premature == 0
* Connection #0 to host localhost left intact
{
    "error": 500.0,
    "status": "Stage creation failed."
}

[icinga-migration]

Updated by LarsEngels on 2016-10-18 08:20:16 +00:00

Strangely the configuration file was created:

 ✘ lars@milhouse  /var/lib/icinga2/api  doas -s -u icinga
milhouse% id -a
uid=183(icinga) gid=183(icinga) groups=183(icinga)
milhouse% ls /var/lib/icinga2/api/packages/example-cmdb/milhouse.bsd-geek.de-1476778554-5/conf.d/test.conf
/var/lib/icinga2/api/packages/example-cmdb/milhouse.bsd-geek.de-1476778554-5/conf.d/test.conf
milhouse% cat /var/lib/icinga2/api/packages/example-cmdb/milhouse.bsd-geek.de-1476778554-5/conf.d/test.conf
object Host "cmdb-host" { chec_command = "dummy" }%                                                                                                                                          milhouse% ls -l /var/lib/icinga2/api/packages/example-cmdb/milhouse.bsd-geek.de-1476778554-5/conf.d/test.conf
-rw-r--r--  1 icinga  icinga  50 Oct 18 10:15 /var/lib/icinga2/api/packages/example-cmdb/milhouse.bsd-geek.de-1476778554-5/conf.d/test.conf

[icinga-migration]

Updated by LarsEngels on 2016-10-18 08:24:17 +00:00

I guess it's okay that new directories in /var/lib/icinga2/api/packages get created with mode 0700 and owner icinga?
Changing this to 755 doesn't change a thing, so I guess it is not a problem.

[icinga-migration]

Updated by LarsEngels on 2016-10-18 09:38:51 +00:00

debug.log for the "failing" creation:

[2016-10-18 11:37:41 +0200] information/ApiListener: New client connection from [::1]:17898 (no client certificate)
[2016-10-18 11:37:41 +0200] notice/ApiListener: New HTTP client
[2016-10-18 11:37:41 +0200] debug/HttpRequest: line: POST /v1/config/stages/example-cmdb HTTP/1.1, tokens: 3
[2016-10-18 11:37:41 +0200] notice/WorkQueue: Spawning WorkQueue threads for 'HttpServerConnection'
[2016-10-18 11:37:41 +0200] information/HttpServerConnection: Request: POST /v1/config/stages/example-cmdb (from [::1]:17898, user: root)
[2016-10-18 11:37:41 +0200] information/ConfigPackageUtility: Updating configuration file: /var/lib/icinga2/api/packages/example-cmdb/milhouse.bsd-geek.de-1476783461-1/conf.d/test.conf
[2016-10-18 11:37:42 +0200] debug/HttpServerConnection: Http client disconnected
[2016-10-18 11:37:42 +0200] notice/WorkQueue: Stopped WorkQueue threads for 'HttpServerConnection'

[icinga-migration]

Updated by andrem on 2016-10-18 14:14:39 +00:00

Hi All,

icingaweb2 has Zend-Framwork2 as depency.

I have now edit my Makefile to this :

RUN_DEPENDS= ${LOCALBASE}/share/ZendFramework/bin/classmap_generator.php:www/zend-framework1

and deinstall / reinstalled icingaweb2

now it works for me.

Is it possible, that zendframework2 is not compatibple yet?

Here the Log :

Deployment Zeit 2016-10-18 16:03:13
Senden an icinga2-tb.XXXX.de
Konfiguration 4 Dateien, 0 Objekte, 2 Vorlagen, 992,00 B
Dauer Erstellt in 0,01s, ausgebracht in 1,23s
Phasenname icinga2-tb.XXXX.de-1476799395-9
Start
Gelungen
Startup log

information/cli: Icinga application loader (version: r2.5.4-1)
information/cli: Loading configuration file(s).
information/ConfigItem: Committing config item(s).
information/ApiListener: My API identity: icinga2-tb.XXXX.de
warning/ApplyRule: Apply rule 'satellite-host' (in /usr/local/etc/icinga2/conf.d/satellite.conf: 29:1-29:41) for type 'Dependency' does not match anywhere!
information/ConfigItem: Instantiated 2 FileLoggers.
information/ConfigItem: Instantiated 1 Endpoint.
information/ConfigItem: Instantiated 1 Zone.
information/ConfigItem: Instantiated 1 ApiListener.
information/ConfigItem: Instantiated 1 ApiUser.
information/ConfigItem: Instantiated 1 ScheduledDowntime.
information/ConfigItem: Instantiated 11 Services.
information/ConfigItem: Instantiated 12 Notifications.
information/ConfigItem: Instantiated 197 CheckCommands.
information/ConfigItem: Instantiated 3 ServiceGroups.
information/ConfigItem: Instantiated 3 TimePeriods.
information/ConfigItem: Instantiated 1 User.
information/ConfigItem: Instantiated 1 UserGroup.
information/ConfigItem: Instantiated 1 Host.
information/ConfigItem: Instantiated 2 HostGroups.
information/ConfigItem: Instantiated 1 IcingaApplication.
information/ConfigItem: Instantiated 2 NotificationCommands.
information/ConfigItem: Instantiated 1 CheckerComponent.
information/ConfigItem: Instantiated 1 IdoMysqlConnection.
information/ConfigItem: Instantiated 1 NotificationComponent.
information/ScriptGlobal: Dumping variables to file '/var/cache/icinga2/icinga2.vars'
information/cli: Finished validating the configuration file(s).

Best Regards

[icinga-migration]

Updated by LarsEngels on 2016-10-18 14:43:40 +00:00

@andrem: That's a good catch! I will update the FreeBSD ASAP.

[icinga-migration]

Updated by LarsEngels on 2016-10-18 14:45:50 +00:00

One thing: Why is this a problem with Icinga Web 2 when using curl also exposes the problem? /me scratches his head....

[icinga-migration]

Updated by andrem on 2016-10-18 14:59:10 +00:00

• File added curl.PNG

@LarsEngels

i have rebuild Curl with this Switches :

[icinga-migration]

Updated by LarsEngels on 2016-10-18 15:42:35 +00:00

Negative. Having replaced Zend-Framework 2 with version 1, I still get the same error like before.

[icinga-migration]

Updated by andrem on 2016-10-18 15:47:07 +00:00

LarsEngels wrote:

Negative. Having replaced Zend-Framework 2 with version 1, I still get the same error like before.

nginx php-fpm icinga2 restarted?

[icinga-migration]

Updated by LarsEngels on 2016-10-18 15:53:18 +00:00

Apache, yes.

[icinga-migration]

Updated by tgelf on 2016-10-18 17:42:25 +00:00

• Tracker changed from Support to Bug
• Project changed from Director to Icinga 2
• Subject changed from Director und FreeBSD to Posting config stage FreeBSD
• Category set to API
• Icinga Version set to 2

LarsEngels wrote:

Creating the config package works:

[...]

However uploading a configuration does not work:

[...]

Thanks for this, I'll move the issue to the Icinga 2 core project. The CURL example perfectly shows that this is not related to Web or Director, thanks for your efforts! Regarding the Zend Framework: Icinga Web 2 uses and ships ZF1. Some packages ship with dependencies, others contain library/vendor/Zend. ZF2 is a completely different beast, we'll never switch to that one.

Cheers,
Thomas

[icinga-migration]

Updated by tgelf on 2016-10-18 17:45:18 +00:00

• Subject changed from Posting config stage FreeBSD to Posting config stage fails on FreeBSD

[icinga-migration]

Updated by LarsEngels on 2016-10-20 10:21:30 +00:00

• Assigned to changed from LarsEngels to mfriedrich

As I'm out of guesses, @dnsmichi could you please look into this?

[icinga-migration]

Updated by mfriedrich on 2016-12-07 20:21:25 +00:00

• Assigned to changed from mfriedrich to andrem

Anyone who's interested in reproducing this and not having a FreeBSD box - I've added one for Virtualbox using an official Vagrant box image. Required some fiddling though, as the image doesn't provide a base mac address and so on. Still, it is working. Minimal docs included.

https://github.com/Icinga/icinga-vagrant/tree/master/icinga2x-freebsd

Tried to reproduce the mentioned issue, I am not able to do so.

root@icinga2-freebsd:~ # curl -k -s -u root:icinga -H 'Accept: application/json' -X POST -d '{ "files": { "conf.d/test.conf": "object Host \"cmdb-host\" { chec_command = \"dummy\" }" } }' 'https://localhost:5665/v1/config/stages/example-cmdb' | python -m json.tool
{
    "results": [
        {
            "code": 200.0,
            "package": "example-cmdb",
            "stage": "icinga2-freebsd-1481141308-4",
            "status": "Created stage."
        }
    ]
}

(that one is obviously not activated as the config validation will fail)

root@icinga2-freebsd:~ # curl -k -s -u root:icinga -X GET 'https://localhost:5665/v1/config/files/example-cmdb/icinga2-freebsd-1481141308-4/startup.log'
information/cli: Icinga application loader (version: r2.5.4-1)
information/cli: Loading configuration file(s).
information/ConfigItem: Committing config item(s).
information/ApiListener: My API identity: icinga2-freebsd
critical/config: Error: Attribute 'chec_command' does not exist.
Location: in /var/lib/icinga2/api/packages/example-cmdb/icinga2-freebsd-1481141308-4/conf.d/test.conf: 1:26-1:47
/var/lib/icinga2/api/packages/example-cmdb/icinga2-freebsd-1481141308-4/conf.d/test.conf(1): object Host "cmdb-host" { chec_command = "dummy" }
                                                                                                                      ^^^^^^^^^^^^^^^^^^^^^^

critical/config: 1 error

I'm not a FreeBSD user so anyone capable of knowing possible permission issues or other security measurements - feel free to comment. If not I'll close this for not being reproducible with a standard FreeBSD install.

[dnsmichi]

@larsengels please have a look into the Vagrant boxes. You're the FreeBSD pro and might see the difference in minutes.

[nkfilis]

I started the Vagrant box, ran

curl -k -s -u root:icinga -H 'Accept: application/json' -X POST -d '{ "files": { "conf.d/test.conf": "object Host "cmdb-host" { chec_command = "dummy" }" } }' 'https://localhost:5665/v1/config/stages/example-cmdb' | python -m json.tool
and get
{ "error": 500.0, "status": "Stage creation failed." }

[dnsmichi]

Strange. Can you modify the request body and add

"verboseErrors": true

to get a more verbose error message?

[nkfilis]

here you go:
{
"diagnostic information": "Error: Could not determine executable path.\n\n\n\t(0) 0x80222715c <_ZN6icinga6SocketD2Ev+0xe69c> at /usr/local/lib/icinga2/libbase.so.2.6.1\n\t(1) 0x8021ab24a <_ZN6icinga11Application10GetExePathERKNS_6StringE+0x78a> at /usr/local/lib/icinga2/libbase.so.2.6.1\n\t(2) 0x801b7f3fc <ZN6icinga20ConfigPackageUtility21AsyncTryActivateStageERKNS_6StringES3+0xac> at /usr/local/lib/icinga2/libremote.so.2.6.1\n\t(3) 0x801b83872 <_ZN6icinga19ConfigStagesHandler10HandlePostERKN5boost13intrusive_ptrINS_7ApiUserEEERNS_11HttpRequestERNS_12HttpResponseERKNS2_INS_10DictionaryEEE+0x3c2> at /usr/local/lib/icinga2/libremote.so.2.6.1\n\t(4) 0x801b82131 <_ZN6icinga19ConfigStagesHandler13HandleRequestERKN5boost13intrusive_ptrINS_7ApiUserEEERNS_11HttpRequestERNS_12HttpResponseERKNS2_INS_10DictionaryEEE+0x141> at /usr/local/lib/icinga2/libremote.so.2.6.1\n\t(5) 0x801b98245 <_ZN6icinga11HttpHandler14ProcessRequestERKN5boost13intrusive_ptrINS_7ApiUserEEERNS_11HttpRequestERNS_12HttpResponseE+0x775> at /usr/local/lib/icinga2/libremote.so.2.6.1\n\t(6) 0x801b9615c <_ZN6icinga20HttpServerConnection19ProcessMessageAsyncERNS_11HttpRequestE+0xbec> at /usr/local/lib/icinga2/libremote.so.2.6.1\n\t(7) 0x802217d31 <_ZN6icinga9WorkQueue16WorkerThreadProcEv+0x531> at /usr/local/lib/icinga2/libbase.so.2.6.1\n\t(8) 0x80084be94 <_ZN5boost6thread21start_thread_noexceptEv+0x184> at /usr/local/lib/libboost_thread.so.1.63.0\n\t(9) 0x8047d8b95 <pthread_create+0x915> at /lib/libthr.so.3\n\n\n",
"error": 500.0,
"status": "Stage creation failed."
}

[gunnarbeutner]

That's rather unusual. Can you please show us the output of the following two commands:

cat /proc/<PID>/environ; echo
cat /proc/<PID>/cmdline; echo

The error message you're getting implies that Icinga is unable to figure out the path for the "icinga2" executable - which should never happen. :)

[nkfilis]

Not finding things isn't very uncommon on FreeBSD, since many Linux-y assumptions regarding paths and PATH environments often fail.

cat /proc/<PID>/cmdline ; echo
returns
/usr/local/lib/icinga2/sbin/icinga2daemon-d-e/var/log/icinga2/error.log-c/usr/local/etc/icinga2/icinga2.conf

unfortunately, there is no /proc//environ, there isn't even procfs if you don't enable it ;)

[gunnarbeutner]

Oh, I only just realized you were using FreeBSD (should've read the subject!). What I'd be interested in is the value of the PATH environment variable. Maybe there's another way to figure that out for a currently-running process. :)

[nkfilis]

yes, that's procstat -e:
PID COMM ENVIRONMENT 1117 icinga2 PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin PWD=/ HOME=/ RC_PID=1064

so I guess, /usr/local/sbin is missing here, since the icinga2 binary lives there, and tadaah:

{ "results": [ { "code": 200.0, "package": "example-cmdb", "stage": "icinga2-freebsd-1487665472-0", "status": "Created stage." } ] }

[gunnarbeutner]

This should now be fixed in the master branch. Thanks for reporting this problem. :)

[dnsmichi]

Seems @larsengels pushed a workaround to the FreeBSD package.

bsd-hacker/freebsd-ports@7312bf0

[vercotux]

I had the same issue when trying to configure Director. Turns out the API user needed an extra permission called "console" which I did not see mentioned anywhere in the documentation (might have missed it), but the problem was the import just failed, made a mess in the DB to the point where I had to drop the schema and re-do the process, whilst just showing me this error:

API request failed: Unhandled exception (RestApiResponse.php:108)

[FruechteBini]

@vercotux i am getting the same error message currently. Did you have to remove your database completely? In the activity log I can see all the commands imported & everything imported, but deploying gives me the error (RestApiResponse.php:108).

API works via curl in command line strangely enough. Tried to add the "console" permission to my api user, did not work unfortunately, here is how it looks currently:

if the permissions are set to:
["actions/*", "objects/modify/hosts", "objects/modify/services", "objects/modify/icingaapplication", "console"]
I get the error message:
"API request failed: Unhandled exception (RestApiResponse.php:108)"
when trying to deploy.

If I set the permissions to :
["*", "console"]
the error changes to :
API request failed: Could not create package 'director'. (RestApiResponse.php:108)

Would appreciate a hint, thanks!

[vercotux]

@FruechteBini

Did you have to remove your database completely?

Indeed.

In the activity log I can see all the commands imported & everything imported, but deploying gives me the error (RestApiResponse.php:108).

I had the same issue. The reason was that everything was actually not imported. It looked like the import was successful, but about half of the stuff was missing in the DB.

Try with the following permissions: [ "status/query", "actions/*", "objects/modify/*", "objects/query/*", "console", "config/query", "config/modify" ].

Also make sure your config file & directory permissions are correct.

Hope it helps.

[FruechteBini]

Hey @vercotux ! Thanks for the fast answer. I was on holiday, got to try your suggestion yesterday. However, it is still not working unfortunately.

I set up a new database "director" to use it in icinga2. This is how i imported the resource:

I then configured the director module:

This is my api-users.conf:

Kickstart looks like this:

--> endpoint name is same as icinga host
--> the config seems to be valid

this is the error i get:

I would be very thankful if anyone has more tips. No idea where to start atm

Thanks & cheers

[dnsmichi]

Please move this discussion to https://community.icinga.com

This issue was closed in 2016, no need to bump it again and again. Thanks.