Automated deployment of Windows Agent

We’ve been using icinga2-powershell-module and plan to get rid of it. Some reasons:

  • BUGs are not fixed quick enough
  • Code is hard to debug
  • Connections from every client to the master are required, which requires sometimes additional firewall rules

Before I start writing my own installation procedure can anybody recommend an alternative? Ansible, Chef, Saltstack etc. is not an option, unfortunately.

I think about a powershell script that installs/updates the MSI paket and do the configuration staff at the client side.

Hello and thank you for your feedback.

Personally I’m not aware of a solution for installing the Agent and doing the configuration on Windows besides the already mentioned tools and modules.
That was the reason for creating the module in first place.

For the mentioned topics I would like to add the following comments:

  • BUGs are not fixed quick enough
    Yes it’s true that there are some bugs open at the moment. There are always several possibilities to handle this: Someone is providing a fix for them, someone is paying for these issues or these issues are fixed whenever there is time. Some of these issues are not something that can be done without plenty of testing, ensuring not to break anything which brings me to

  • Code is hard to debug
    Fully agree on that. The code grew over time and the module became a monster. I’m fully aware of this and hopefully this will change. There are already ideas around the corner, but they have to carefully be tested and discussed on how we proceed

  • Connections from every client to the master are required, which requires sometimes additional firewall rules
    This only applies if the configuration is done over the Icinga Directors Self-Service API. The module itself is fully capable for manual configuration with all arguments. For the certificate, even that one is handled by the module by using the Icinga CA-Proxy which is described here: https://github.com/Icinga/icinga2-powershell-module/blob/master/doc/13-Icinga2-CA-Proxy.md

In general, yes I agree that the current state of the module - open bugs and code itself alike - is not perfect. Planned is that some things will change in the near future, but giving an estimation is not possible sadly by now.

2 Likes

Imho Powershell is the best bet on Windows, unfortunately I lack the knowledge to help you here. But I do know that community members build plugins like that as well. IIRC @log1c did that if I am not mistaken.

Batch files would work too, but error handling is a bit insane there imho.

Typically you need to decide some things before installing a client/agent:

  • Certificate handling: Have a ticket at hand, or use the on-demand csr signing. The latter requires you to sign the certificate requests on the master then. The clients will receive a signed certificate on the next reconnect (happens automatically, since self-signed certificates are always untrusted resulting in disconnect).
  • Parent zone and endpoint details
  • Connection direction: Should the agent connect to the parent endpoints? If yes, populate the parent endpoint object with the host attribute. If no, leave it out and configure the parent endpoint, with the agent endpoint and host attributes.

Knowing about this, you can start building the script.

  • The msi can be installed silently as shown in the docs.
  • Optional: Also install NSClient++ bundled in there
  • Run node setup and extract all the required parameters.

Above you have chosen the connection mode.

If the agent shouldn’t actively connect to the parent endpoint, leave away the parent_host parameter. The thing kept in mind here is that you need the public ca.crt from your Icinga CA on this node, so you’ll have to have a copy. This is the connection-less setup available since 2.10.

If the agent may connect to the parent, and you’re good to go with on-demand signing, set the parent_host to the FQDN/IP of that endpoint. Using the CA proxy feature since 2.8, a satellite in the middle can forward the signing requests to the master endpoint.

Specific parent zone names can be set as well, by default this will be master. If there’s more than one endpoint in the parent zone, repeat the --endpoint parameter. This parameter also holds the details about connection, --endpoint icinga2-satellite1.localdomain,192.168.33.5,5665 for example.

Using the parent host connection method, there’s one little thing in order to approve the trust - you’ll need to fetch the parent’s public certificate and validate that. This is what the graphical Windows setup wizard asks you “do you trust it?”, the CLI command save-cert downloads that for you, which you need to pass to node setup always.

All the mentioned CLI commands work on Windows in the same way, just ensure that icinga2.exe is either inside PATH or you use the full binary path, typically C:\Program Files\icinga2\sbin\icinga2.exe.

That being said, start simple: first finish the installation, then test the signing and setup process manually before implementing it into a script.

The CLI commands within icinga2 are built in a way that you typically don’t need to modify the configuration on disk afterwards. You can also set --accept-commands and --accept-config btw.

This also apply for enabling features, your script should ensure that mainlog is enabled, but checker is disabled` on a command endpoint.

The final thought here: A custom script means your own maintenance required, likely you want to share it on GitHub or in here, and discuss with others. Or you’ll combine your efforts and send PRs for the icinga2-powershell-module. The most important part is learn Powershell at first glance anyways :slight_smile:

Cheers,
Michael

1 Like

Tbh I still use the NSClient for monitoring Windows systems :blush:

I have yet to set up a system where the Icinga Agent is used for Windows systems.
Atm I don’t see a real benefit from installing the Agent, at least if it comes to the setup procedure. There is, for my limited knowledge, no real difference between the Agent and the NSClient.:man_shrugging:

Other than that I use many self-written PowerShell scripts to monitor things, but I have no script for installing stuff.

we only use a small batch script to install the nsclient with “one click” (or through SCCM)

@echo off

:set_variables
SET scriptpath=%~dp0

if %processor_architecture% == AMD64 (
    SET msifile=NSCP-0.5.2.33-x64.msi
) else (
    SET msifile=NSCP-0.5.2.33-Win32.msi
)

SET nscppath=C:\Program Files\NSClient++\

:check_Permissions
    echo Administrative permissions required. Detecting permissions...

    net session >nul 2>&1
    if %errorLevel% == 0 (
        echo Success: Administrative permissions confirmed.
	goto main
    ) else (
        echo Failure: Current permissions inadequate.
    )

    echo Press any Key to continue...
    pause >nul
    
    exit /B 1

:main

:install_nscp_main
msiexec /i "%scriptpath%nscp\%msifile%" ADDDEFAULT=ALL REMOVE=DotNetPluginSupport,NSCPlugins,Shortcuts,WEBPlugins /l*vx "%scriptpath%Install.log" /qb /norestart

:copy_nscp_config and boot.ini
COPY "%scriptpath%boot.ini" "%nscppath%boot.ini"

:copy_custom_plugins
COPY "%scriptpath%\custom\*" "%nscppath%\scripts\"

:restart_nscp_service
"%nscppath%nscp.exe" service --stop
"%nscppath%nscp.exe" service --start

Sorry I can’t be of more help here :slight_smile:
Best regards

Thanks, no worries. I did not exactly remember who was working with Powershell in the past months :slight_smile: