Windows Clients with Icinga Agent in the Director

Hello guys,

first of all, here is what I am using:

Icinga2 - 2.10.2
Icingaweb2 - 2.6.2
Icinga2 Director - 1.6.0
running on a Debian 9.6

I was wondering whether there is a documentation about setting up windows hosts in the director?
Most stuff I have found is without using the director. It is a little confusing for a beginner.
I have installed the Agent and NSClient++ on a Windows Server 2012 R2 . (using this how to: https://icinga.com/docs/icinga2/latest/doc/06-distributed-monitoring/#client-setup-on-windows)

I already see measuring results there:

After that i created a host template with Agent: yes but it seems that the checks are not running on the windows client but on the master? Because Icinga says

execvpe(/usr/lib/nagios/plugins/check_disk.exe) failed: No such file or directory

I guess i have to configure an enpoint for the windows client but how exactly has this to be done?
Do i really have to create a new endpoint for every windows host? Because i have about 150 clients i would like to monitor like that.

Any help is much appreciated. Thank you

this error most likely happens, because the path to the plugins on your windows agent is not correct.

check the constants.conf in the installation director for a PluginDir variable it should point to the folder where all your checks live

1 Like

Thanks for your reply, Kevin!
So i do not have to configure an additional endpoint for that?

This is the constants.conf on my Master:

/**

  • This file defines global constants which can be used in
  • the other configuration files.
    */

/* The directory which contains the plugins from the Monitoring Plugins project. */
const PluginDir = “/usr/lib/nagios/plugins”

On the Windows Agent Host, it looks like that:

/* The directory which contains the plugins from the Monitoring Plugins project. */
const PluginDir = PrefixDir + “/sbin”

The director is trying to execute the command on the Master but check_disk.exe is located on the Agent System.

How can I tell the director to execute the check on the Agent System?

Thanks in advance for any help!

that explains the problem you have. did you setup your windows client with the advanced options to accept commands and config? if not, the check will be run on the master, because the client refuses the check command

1 Like

For me it’s obvious that the script is executed on the wrong machine means command_endpoint is not defined. As I’m not using the director for service definitions, I’m not able to describe the necessary settings there.

1 Like

if the director is used and the agent setting is set to Yes, it will automagically create the needed endpoint configuration. After reading the howto he followed it is easy to overread the necessary config to let the endpoint accept commands and config from the master

1 Like

Thank you both so far.
This is exactly how i installed the agent, i have followed the documentation in my link above.
The only thing i did not do was to set a Zone (windows-templates)

Check Source shows the FQDN from my Icinga2 Master

Here is my Host Template:

Any idea how to get this working?

thanks again for your help!

open the tcp port on the left side so that the master can contact the agent. this could lead to your problem, not entirely sure though

1 Like

I opened the port but unfortunately, it did not work.
Checked the log meanwhile (i have edited names):

root@ICINGA2:~# tail /var/log/icinga2/icinga2.log
[2019-02-28 12:47:04 +0100] warning/ApiListener: No data received on new API connection for identity ‘XYZ-VM-043.OUR.DOMAIN’. Ensure that the remote endpoints are properly configured in a cluster setup.
Context:
(0) Handling new API client connection

[2019-02-28 12:47:06 +0100] information/ApiListener: Reconnecting to endpoint ‘XYZ-VM-043 (AGENT TEST)’ via host ‘10.40.4.193’ and port ‘5665’
[2019-02-28 12:47:06 +0100] warning/ApiListener: Unexpected certificate common name while connecting to endpoint ‘XYZ-VM-043 (AGENT TEST)’: got ‘XYZ-VM-043.OUR.DOMAIN’
Context:
(0) Handling new API client connection

[2019-02-28 12:47:07 +0100] information/ApiListener: Finished reconnecting to endpoint ‘XYZ-VM-043 (AGENT TEST)’ via host ‘10.40.4.193’ and port ‘5665’

yeah looks like the common name in the certificate does not match the name, that the endpoint has. You should be able to edit the endpoint name in the constants.conf.

1 Like

Seems that we are one step closer now.
I did not change the constants.conf but I edited the hostname in the director so that it matches the NodeName in the constants.conf on the agent system.

The log now looks like that:

root@ICINGA2:~# tail /var/log/icinga2/icinga2.log
Context:
(0) Handling new API client connection

[2019-02-28 12:57:45 +0100] information/ApiListener: Reconnecting to endpoint ‘XYZ-VM-043.OUR.DOMAIN’ via host ‘10.40.4.193’ and port ‘5665’
[2019-02-28 12:57:45 +0100] warning/ApiListener: Certificate validation failed for endpoint ‘XYZ-VM-043.OUR.DOMAIN’: code 18: self signed certificate
Context:
(0) Handling new API client connection

[2019-02-28 12:57:45 +0100] information/ApiListener: New client connection for identity ‘XYZ-VM-043.OUR.DOMAIN’ to [10.40.4.193]:5665 (certificate validation failed: code 18: self signed certificate)
[2019-02-28 12:57:45 +0100] information/ApiListener: Finished reconnecting to endpoint ‘XYZ-VM-043.OUR.DOMAIN’ via host ‘10.40.4.193’ and port ‘5665’

what certificate is meant here?

Ah, you have configured disk-windows as host command which does not make sense. At this place is usually hostalive or hostalive4 etc. configured to check whether this host is alive or not. In this case it’s correct to not have command_endpoint defined as your Icinga machine is the right check source.

1 Like

Yes, thats right - changed it to hostalive now and added a Service with the command “disk-windows”.
The service is now stuck at “unknown”, but the check source is now correct and shows the windows agent client:


The Plugin Output says, that my Agent is not connected to my master.

The logfile has not changed and still shows " Certificate validation failed for endpoint ‘XYZ-VM-043.OUR.DOMAIN’: code 18: self signed certificate"

This is the service i created:

Your agent isn’t connected to your master due to the certificate failure. I’d assume you haven’t shown your real screenshots, therefore, it’s difficult to analyse for me.

thanks, Roland.
I actually just removed all the company information from the screenshots and logs - nothing else.
Except the one screenshot I took from the documentation to show, what i have configured during the installation every screenshot is directly from my system.

I checked the icinga.log on the windows agent host now:

[2019-02-28 14:05:24 +0100] information/ApiListener: Reconnecting to endpoint ‘IT-ICINGA2.OUR.DOMAIN’ via host ‘10.40.4.122’ and port ‘5665’

[2019-02-28 14:05:24 +0100] information/ApiListener: New client connection for identity ‘IT-ICINGA2.OUR.DOMAIN’ to [10.40.4.122]:5665

[2019-02-28 14:05:24 +0100] information/ApiListener: Finished reconnecting to endpoint ‘IT-ICINGA2.OUR.DOMAIN’ via host ‘10.40.4.122’ and port ‘5665’

[2019-02-28 14:05:24 +0100] information/ApiListener: Requesting new certificate for this Icinga instance from endpoint ‘IT-ICINGA2.OUR.DOMAIN’.

[2019-02-28 14:05:24 +0100] information/ApiListener: Sending config updates for endpoint ‘IT-ICINGA2.OUR.DOMAIN’ in zone ‘master’.

[2019-02-28 14:05:24 +0100] information/ApiListener: Finished sending config file updates for endpoint ‘IT-ICINGA2.OUR.DOMAIN’ in zone ‘master’.

[2019-02-28 14:05:24 +0100] information/ApiListener: Syncing runtime objects to endpoint ‘IT-ICINGA2.OUR.DOMAIN’.

[2019-02-28 14:05:24 +0100] information/ApiListener: Finished syncing runtime objects to endpoint ‘IT-ICINGA2.OUR.DOMAIN’.

[2019-02-28 14:05:24 +0100] information/ApiListener: Finished sending runtime config updates for endpoint ‘IT-ICINGA2.OUR.DOMAIN’ in zone ‘master’.

[2019-02-28 14:05:24 +0100] information/ApiListener: Sending replay log for endpoint ‘IT-ICINGA2.OUR.DOMAIN’ in zone ‘master’.

[2019-02-28 14:05:24 +0100] information/ApiListener: Finished sending replay log for endpoint ‘IT-ICINGA2.OUR.DOMAIN’ in zone ‘master’.

[2019-02-28 14:05:24 +0100] information/ApiListener: Finished syncing endpoint ‘IT-ICINGA2.OUR.DOMAIN’ in zone ‘master’.

[2019-02-28 14:05:28 +0100] information/ApiListener: New client connection for identity ‘IT-ICINGA2.OUR.DOMAIN’ from [::ffff:10.40.4.122]:46656

[2019-02-28 14:05:28 +0100] warning/ApiListener: No data received on new API connection for identity ‘IT-ICINGA2.OUR.DOMAIN’. Ensure that the remote endpoints are properly configured in a cluster setup.

Context:

(0) Handling new API client connection

[2019-02-28 14:05:38 +0100] information/ApiListener: New client connection for identity ‘IT-ICINGA2.OUR.DOMAIN’ from [::ffff:10.40.4.122]:46658

[2019-02-28 14:05:38 +0100] warning/ApiListener: No data received on new API connection for identity ‘IT-ICINGA2.OUR.DOMAIN’. Ensure that the remote endpoints are properly configured in a cluster setup.

I think “Ensure that the remote endpoints are properly configured in a cluster setup” is the core information here - but I dont know, what that means just yet.

If you haven’t been changing your config yet, you still have this certificate issue:

Client host name, endpoint and zone have to be identical, recommend is FQDN of that machine. If I understand your config correctly, the endpoint is host name only whereas CN is FQDN.

1 Like

Thank you, Roland.
Yes i was able to fix this name issue but i still get
“Ensure that the remote endpoints are properly configured in a cluster setup.”

It must be an issue with the endpoints and zones on the director side.
Kevin said above, that the director creates the necessary endpoint automatically.
But that seems not to happen.

I am not sure where to troubleshoot next.

Hello guys,

i finally made it work.

image

The problem besides the name issues (fqdn = case sensitive) was, that my master was not completly set up for API connections.
I had to run the master-setup in order to have a CA.
So that they (agent and master) were able to handle a connection and sign the appropriate certificate.

Thank you all for your help!