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
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
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