Monitoring another Nagios system using the Wizard issue

[vijilants]

Ok, that is a normal redirection, lets see what you get with this

Code: Select all

curl -vvv "http://192.168.4.3/nagiosxi/api/v1/system/statusdetail"

See below:

Code: Select all

[[email protected]]#  curl -vvv "http://192.168.4.3/nagiosxi/api/v1/system/statusdetail"
* About to connect() to 192.168.4.3 port 80 (#0)
*   Trying 192.168.4.3... connected
* Connected to 192.168.4.3 (192.168.4.3) port 80 (#0)
> GET /nagiosxi/api/v1/system/statusdetail HTTP/1.1
> User-Agent: curl/7.19.7 (i386-redhat-linux-gnu) libcurl/7.19.7 NSS/3.15.3 zlib/1.2.3 libidn/1.18 libssh2/1.4.2
> Host: 192.168.4.3
> Accept: */*
> 
< HTTP/1.1 200 OK
< Date: Wed, 05 Sep 2018 07:10:58 GMT
< Server: Apache/2.4.6 (CentOS) OpenSSL/1.0.2k-fips PHP/5.4.16
< X-Powered-By: PHP/5.4.16
< Access-Control-Allow-Orgin: *
< Access-Control-Allow-Methods: *
< Content-Length: 32
< Content-Type: application/json
< 
{"error":"No API Key provided"}
* Connection #0 to host 192.168.4.3 left intact
* Closing connection #0
[[email protected]]#

[scottwilkerson]

ok, one more again

Code: Select all

curl -vvv "http://192.168.4.3/nagiosxi/api/v1/system/statusdetail?apikey=r96rbk8p"

[vijilants]

System was upgraded to 5.5.3 today. The command runs but it ends as per below:

Code: Select all

[[email protected]]# curl -vvv "http://192.168.4.3/nagiosxi/api/v1/system/statusdetail?apikey=r96rbk8p"
* About to connect() to 192.168.4.3 port 80 (#0)
*   Trying 192.168.4.3... connected
* Connected to 192.168.4.3 (192.168.4.3) port 80 (#0)
> GET /nagiosxi/api/v1/system/statusdetail?apikey=r96rbk8p HTTP/1.1
> User-Agent: curl/7.19.7 (i386-redhat-linux-gnu) libcurl/7.19.7 NSS/3.15.3 zlib/1.2.3 libidn/1.18 libssh2/1.4.2
> Host: 192.168.4.3
> Accept: */*
> 

[scottwilkerson]

Do you see any errors in the error log on the 192.168.4.3 server when you run this?

Code: Select all

tail -f /var/log/httpd/error_log

[vijilants]

Ive just tried it and no errors whatsoever in the error.log

It is very weird because if I try that command on the server itself (192.168.4.3) it works fine.

[lmiltchev]

Have you tried generating a new API key for this user to see if this is going to fix the problem? This is a very weird issue. We haven't been able to recreate it in-house. Perhaps we will need to schedule a remote session to further troubleshoot it.

[vijilants]

Have you tried generating a new API key for this user to see if this is going to fix the problem? This is a very weird issue. We haven't been able to recreate it in-house. Perhaps we will need to schedule a remote session to further troubleshoot it.

Agreed. I think a remote session would be best.

[lmiltchev]

@vijilants, I sent you a PM.

[lmiltchev]

The issue has been moved to our ticketing system, so I am locking this topic.