Windows Agent - Remote Icinga Instance 'ABC' is not connected to 'XYZ'

Icinga 2
1

I want to monitor my Windows servers agent based and therefore created a new host template, set the “Icinga2 Agent”, “Establish connection” and “Accepts config” settings to “yes” and generated an Self Service API Key in the Agent tab of the template.
Then I setup the icinga2-powershell-module (https://github.com/Icinga/icinga2-powershell-module) and executed

Icinga2AgentModule `
    -DirectorUrl       'https://<server>/icingaweb2/director/' `
    -DirectorAuthToken '<myToken>' `
    -RunInstaller

in Powershell. The machines showed up in director and I deployed the newly created host.
Then I created a service named disk-windows, set Run On Agent to Yes and added it to the host.

But the service states “unknown” and below “Remote Icinga Instance ‘ABC’ is not connected to ‘XYZ’”.

Did I miss something? I tried it with Agent Version 2.10.3 & 2.10.4, but no luck in both cases.
Can you give me some advice how to troubleshoot this?

I tried connecting to the API in browser by calling https://agentclient:5665/ and got a certificate not known page of cause. When I accepted the cert I got to a login, but did not know the credentials. Eatherway, this tells me that the api is up and listening. So I’m really lost here.

Unfortunately until now I have like no understanding in zones and so on. :grimacing: Maybe

Im running Icinga r2.10.4-1 on Ubuntu 18.04 with director.

Looking forward to any advice. :slight_smile: Thanx.
Sebbo

Edit:
Oh, and I also disabled the firewall, btw.

Edit2:
icinga2.log states

   (0) Handling new API client connection

[2019-04-14 23:37:42 +0200] information/ApiListener: Finished reconnecting to endpoint 'SERVER01.DOMAIN.INTERN' via host '10.10.10.9' and port '5665'
[2019-04-14 23:37:44 +0200] information/ApiListener: New client connection for identity 'SERVER01.domain.intern' from [10.10.10.9]:55421 (certificate validation failed: code 18: self signed certificate)
[2019-04-14 23:37:44 +0200] information/JsonRpcConnection: Received certificate request for CN 'SERVER01.domain.intern' not signed by our CA.
[2019-04-14 23:37:44 +0200] information/JsonRpcConnection: Certificate request for CN 'SERVER01.domain.intern' is pending. Waiting for approval.
[2019-04-14 23:37:52 +0200] information/ApiListener: Reconnecting to endpoint 'SERVER01.DOMAIN.INTERN' via host '10.10.10.9' and port '5665'
[2019-04-14 23:37:52 +0200] warning/ApiListener: Unexpected certificate common name while connecting to endpoint 'SERVER01.DOMAIN.INTERN': got 'SERVER01.domain.intern'

Edit3:
After signing the csr manually via icinga2 ca sign … I still get the following in icinga2.log

[2019-04-15 00:06:20 +0200] information/ApiListener: Reconnecting to endpoint 'SVCMGMT01.ideri.intern' via host '10.10.10.9' and port '5665'
[2019-04-15 00:06:20 +0200] critical/TcpSocket: Invalid socket: Connection refused
[2019-04-15 00:06:20 +0200] critical/ApiListener: Cannot connect to host '10.10.10.9' on port '5665'
[2019-04-15 00:06:20 +0200] information/ApiListener: Finished reconnecting to endpoint 'SVCMGMT01.ideri.intern' via host '10.10.10.9' and port '5665'

I guess I’m absolutely out of luck today…

2

Wow… got it finally working by manually reconfigure the agent and defining the icingaServer.domain.local instead of IP address as host in the instance…

Still… it was much more effort to get this working than described in all the tutorials and videos I watched.
Someone else experienced this behavior?

3

Hi,

the main “problem” here is that the Powershell script differs to what we describe in the distributed monitoring chapter for Icinga 2. It is yet another way to configure and automate things, and not yet fully integrated into the stack (except inside the Director). There’s plans to change that.

Cheers,
Michael

4

Hi Sebastian,

it seems i have encountered the exact same issue. Could you please tell me what exactly you did to resolve this? Where did you set the domain instead of the IP address? Your help would be very much appreciated.

5

I ended up not using the Powershell script and installing the client manually.

Also I had to sign the certs manually.

6

This is related to Windows and retrieving the FQDN. As I learned in a ticket, the PS module allows toggle this. The windows setup wizard just puts in what GetHostName() returns.

In order to fix this for future setups, ensure that the Endpoint object name configured on your master is the same as the agent’s certificate CN exposes (which is generated on the agent during setup).

Cheers,
Michael

8

Highly likely the ticket you have created, uses the lowercase FQDN whereas Windows identifies itself with the upper case notation.

Cheers,
Michael