Automated deployment of Windows Agent

Icinga 2 Automation & Infrastructure
1

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.

2

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
3

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
4

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

5

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

6

You always can simple write your own simple powershellscript that does what the icingamodule is doing, but straight forward for your invironment. In the end, it just fires icinga2 commands.

You don’t need a direct connection to the master if you have a satellite. If you want to add the host with the director, you can use a Proxy on the satellite or add a redirect on your company proxy. I have not tested it, but wit ca proxy feature it should be possible to get it up and running without Agent > Master connection if the other way around is working.

For me I’am using the module, as it works very well if you configured it to fit your environment. The only real drawback at the moment is, that you can’t change the service account with it, because you can’t set the folder permissions to that user with the script. It will fail and sets the user back to the “network account” so i change the user later on, after added the permission.

7

If icinga2-powershell-module shall add the host to the director, then it needs direct access to the master. The CAProxy can only be used for certificate handling via a satellite.

8

Yes, thats why i mentioned the “web”-Proxy on the satellite or a redirect on the company proxy. This way you can avoid aditional firewallrules.

9

Hey,
we had a similar issue and wrote an agent installer using NSIS. It has plenty of problems, but we still have the source available.



It does work, there was a detailed discussion of the problems with the module (mostly security related). It might be that the issues are fine. We are due to fix a bug to keep it working with latest icingaweb2, as we will have customers who use it. Its not perfect, but its a whole nother approach.

2 Likes
10

While I agree on the statements by Roland, not all is lost and you can still use icinga2-powershell-module for automation, the thing is you need to invest time to research, test and poke around with the configuration / command line arguments to see the real benefit.
We played a game at work, two Windows administrators against a monitoring guy to see who can find the proper configuration faster that works for our environment.
We collaborated with our findings and we managed to have a working configuration with icinga2-powershell-module, one of the things that helped us was the latest updates done by Lord Hepipud to the script.
We have one master and several satellites connected across the globe, all clients communicate to the satellites to be monitored, they only communicate to the master for Director configuration. In order to achieve this, we don’t use the master’s ticket, we use the Directors Self-API instead.
All is down to the arguments you pass to the script and to know what each one of these parts do during the process, that’s the difficult part, because this needs to be clear enough to be automated by the DevOps / Admin teams, but once is done, everything is straight-forward.
The thing is that we have a working setup with Icinga Agent + Nsclient + Puppet for automation, all that works for us.
I’ll try to make a quick write up on how we did that next week after the real Puppet tryouts and share that with the community ASAP. Remember, YMMV but it will give you an idea on how can it work on your environment.

2 Likes