Add an argument allowing the definition of global-zones for the configuration.

More can be read here: Icinga Director #997

Creating and validating the Icinga 2 configuration fails on Windows 2008 R2 because of the -Raw parameter at the following line:

if (Test-Path $this.getIcingaConfigFile()) {
      $icingaCurrentConfig = Get-Content $this.getIcingaConfigFile() -Raw;
}

The code to flush the API directory in case defined with argument -FlushApiDirectory should be called before any config generation and validation to prevent false positives.

It could happen that the config is not valid because of missing templates.

By using the function 'setProperty' before calling 'getProperty' it will happen that parameter values beeing initialised on the first run on 'getProperty' are overwritten.

Hello,
It is quite common that the MSI packages (or any other ressources) cannot be downloaded due to some security policies. So, that would be nice to have in this module the possibility to specify a directory where the MSI packages are stored.
I have modified the script for my usage, by disabling the download, changing the installer package. It works, but that would be great to have an option for such a feature.
BR,
Yannick

We forgot to provide some information (e.g. -InstallAgentVersion ) so the module was not able to install the agent. The script exited with code 0 nonetheless.

Right now the service state check returns with a success state, once the service reached state 'Running' but is not aware of a service beeing crashed meanwhile.

Possible solution: Add a small delay and check the state again to ensure it's running properly

Right now the module is not able to run properly on Windows 2016 Nano Servers.

Downloads with Invoke-WebRequest are not supported and require to become replaced with either local directories or network device locations.

Add more variations for fetching the hostname, applying the first valid rule.

Hi,

It would be rather useful if the module could check if the master / ca host really is the one we are talking to. I think the best way to minimize the risk of a man in the middle attack would be to provide the module not only with the hostname of the master but with the fingerprint of it's certificate.

Cheers,
Thomas

Some software management tools could use the module more easily when you could provide them with the full path to the .msi package. e.g. C:\install\icinga.msi. This would make giving the version number obsolete.

In case the icinga2.conf is corrupt the module should exit with an error instead of continuing with further actions.

Right now the module is not able to run properly on Windows Core Server.

e.g. you have to install the .nupkg instead of the MSI file.

Add support to fetch the IP Address of a host and make it's content available over placeholder variable &ipaddress$

Proposal:
[Net.DNS]::GetHostEntry("MachineName")

If the IE is not allowed to download files, the script fails with a message that it can not install the agent. Also providing a local URL will not fix this. Support for other protocols like FTP/SFTP could be a solution for such environments.

Right now each Windows Systems requires plenty of parameters in order to execute the script correctly.
A better solution would be to - in case possible - access the Icinga Director and retreive all required Informations like configuration, Ticket and Icinga 2 version. This will enable the possibilty to partly automate the entire process on plenty of Windows systems.

For the authentication I recommend a token, allowing access to a host objects configuration inside the Director. Access is only possible by the hostname which is send directly by the script to the Director.

Hi,

I just tried to add a Host for testing purposes to my Icinga Director via this script. I'm not sure if I am doing it wrong or if this is a bug.

I added the psd1 and psm1 files as a module to the machine (-> is this mandatory? can it be run without this?)

then, I created a new host template and created a new api token.
Then I configured the selfservice API as follows:

then, I run the following script on my machine:

$icinga = Icinga2AgentModule `
              -DirectorUrl       'http://<my_icinga_host>/icingaweb2/director/' `
              -DirectorAuthToken '<my_api_token>' `
              -RunInstaller

the output of the script is this:

Notice: Started script run...
Notice: Reading host api token <my_api_token> from C:\ProgramData\icinga2\etc\icinga2\icingadirector.token
Notice: Setting internal Agent Name to SRVTEST
Notice: Trying to fetch Host IP-Address for hostname: SRVTEST.test.local
Notice: Transforming Agent Name to srvtest
Notice: Host API-Key validation successfull.
Exception calling "fetchArgumentsFromIcingaDirector" with "1" argument(s): "Exception calling "Substring" with "2" argument(s): "startIndex cannot be larger than length of string.
Parameter name: startIndex""

On my Icinga machine, the host does get added but that's it. Nothing gets installed, but I'd like to solve this error anyways.
Also: the hostname in icinga gets added correctly (only hostname, no fqdn), the displayname gets added as fqdn though.. any chance to change this?

Thanks in advance for the help. Please let me know if you need any more configs or info.

It's great that you have listed the default values for the basic arguments, but could you please add information about options being mandatory?

I know, the "new way" with Director 1.4 will make this obsolete but I think not every user will use this and some will still stick to the current configuration.

Hi,

you fixed the error with the NULL-Array. This works now for me.

Now I got a new error:

Exception calling "applyPossibleConfigChanges" with "0" argument(s): "Exception calling "hasConfigChanged" with "0" argument(s): "Exception calling "getHashFromString" with "1" argument(s): "The variable '$result' cannot be retrieved because it has not been set."""

The error appears only with Powershell Version 2 (4 & 5 works). Maybe another bug?

A parameter agent_add_firewall_rule would be nice, allowing one to open port 5665 in case parent(s) should connect to the agent

Some users use the Powershell Module via configuration- / software management and can't read the output of the Module. Could you add an optional logfile that keeps all the output when using the module for installation / configuration?

Signing certificates for Icinga 2 is failing because the executable is not found.
The installation path detection is not working properly on 32bit Windows Systems in function 'isAgentInstalled'

When testing REST Api using the following command.

curl -H 'Accept: application/json' -u 'directoruser:directorpwd' https://server1.test.com/icingaweb2/director/host?name=wkstest1.test.com --insecure
Getting the following error.

{ "error": "Failed to load icinga_host \"wkstest1.test.com\"" }

Any ideas what can be causing this and a possible fix?
Thanks.

The Icinga Director URL should be explicit instead of implicit.

https://icinga2-master.example.com/icingaweb2/director/

Fix a possible deadlock on 'startProcess' function by moving

$stdout = $process.StandardOutput.ReadToEnd();
$stderr = $process.StandardError.ReadToEnd();

before

$process.WaitForExit();

Otherwise the script will freeze on some cases, caused by an deadlock.

Instead of using

$text = 'The value is ' + $value + '.'

we should use

$text = [string]::Format('The value is {0}.', $value);

Right now the config rollback in case of an error is printing out possible success messages, is however not rolling back the configuration.

The code part is not active. Need to investigate why and fix this asap.

Hey,

maybe you could help me out with the method of the IcingaServiceUser. I want to change the Log On User to the LocalSystem-User.

$icinga = Icinga2AgentModule -IcingaServiceUser 'HOSTNAME\LocalSystem'

I have tried some different versions but I always get this error output, and the Log On User does not change:

Notice: Updating Icinga 2 service user to HOSTNAME\LocalSystem
Error: DESCRIPTION: Modifies a service entry in the registry and Service Database.USAGE: sc config [service name] ...OPTIONS:NOTE: The
option name includes the equal sign. A space is required between the equal sign and the value. type= <own|share|interact|kernel|filesys|rec|adapt> start= <boot|system|aut
o|demand|disabled|delayed-auto> error= <normal|severe|critical|ignore> binPath= group= tag= <yes|no> depend= <Dependencies(separated by / (for
ward slash))> obj= <AccountName|ObjectName> DisplayName= password=

Hi,

i found an issue with the the attached powershell script to read the local hostname from the powershell.
There is a difference for the results of the command
(Get-WmiObject win32_computersystem).DNSHostName
depending on the installed powershell version.
Example hostname "dummy":
V4.0: dummy
V1.0: DUMMY

We created our monitored devices within Icinga2 completly in lower case.
This causes the script to generate faulty certificates and install a broken Icinga2 Client.
To clean this up, i have to uninstall the client and manualy clean (delete the Icinga2 folder) the "ProgramData" folder - Icinga stores the broken certificates there and uses them for all of the following setup attempts!
Maybe a little bit of cleanup after an error or before each run of the installation script would be nice to have.

For now i resolved this issue, by adding the "toLower()" method to the DNSHostName.

# Ensure we get the hostname or FQDN
# from the PowerShell to make things more
# easier
#
$installer | Add-Member -membertype ScriptMethod -name 'fetchHostnameOrFQDN' -value {
    if ($this.config('get_agent_fqdn') -And (Get-WmiObject win32_computersystem).Domain) {
        [string]$hostname = (Get-WmiObject win32_computersystem).DNSHostName + '.' + (Get-WmiObject win32_computersystem).Domain;
        $this.setProperty('local_hostname', $hostname);
        $this.info('Setting internal Agent Name to ' + $this.getProperty('local_hostname'));
    } elseif ($this.config('get_agent_name')) {
        [string]$hostname = (Get-WmiObject win32_computersystem).DNSHostName;
        $this.setProperty('local_hostname', $hostname);
        $this.info('Setting internal Agent Name to ' + $this.getProperty('local_hostname'));
    }

    if (-Not $this.getProperty('local_hostname')) {
        $this.warn('You have not specified an Agent Name or turned on to auto fetch this information.');
    }
}

The function Get-FileHash required to get the installers file hash to verify against a provided array of hashes is not supported by PowerShell Version 2.

I want to run:

Icinga2AgentModule().installWithDirector(
  'https://icinga.example.com/icingaweb2/director/',
  '5e6444f2200dd72163dc28d68cdc16c4a8632310'
);

...instead of:

$icinga = Icinga2AgentModule `
    -DirectorUrl       'https://icinga.example.com/icingaweb2/director/' `
    -DirectorAuthToken '5e6444f2200dd72163dc28d68cdc16c4a8632310'

$icinga.installMonitoringComponents()

The function responsible to flush the API directory from all content is only removing files. Directories are left intact.

This should be fixed to prevent possible conflicts with zone directories.

Expected Behavior

Use the default paths and configuration files as proposed by the Windows package for Icinga 2.

Current Behavior

Putting everything into the icinga2.conf makes debugging a Windows client harder, as it does not follow the official documentation. I've seen it today in a support case, it costs plenty of time to find out where things are stored.

It also breaks supported CLI commands such as icinga2 feature enable debuglog.

Possible Solution

Please enable users to use the proposed standard paths of the Icinga 2 Windows package:

• Only include directives inside icinga2.conf (leave it as is, or just remove "conf.d" inclusion - see Icinga/icinga2#5426 and Icinga/icinga2#3246)
• Populate zone and endpoint details into zones.conf. Keep in mind that Icinga 2 v2.7.0 automatically provides director-global and global-templates by default inside the zones.conf file (see Icinga/icinga2#5106 for details)
• Enable the default features on an agent (main-log should be sufficient, optional: checker for config sync, not command_endpoint)
• Include features-enabled in icinga2.conf and allow to use the documented CLI command icinga2 feature <list|enable|disable>
• Update features-available/api.conf with specified settings, i.e. accept_config and accept_commands
• Update constants.conf when needed, i.e. setting the NodeName constant

The received certificates are correctly stored in SysconfDir + "/icinga2/pki/" + NodeName ... already. It would be nice to see anything else also put into the default paths as documented everywhere.

Specifically this would need rewrites in generateIcingaConfiguration and remove the config blob.

If it is about config validation and a possible rollback (this seemed to be the main argument months ago):

• Deploy the configuration into a temporary directory, like %ProgramData%\ICINGA2\tmp
• Run a config validation with changed paths: `icinga2.exe daemon -C -DSysconfDir= %ProgramData%\ICINGA2\tmp
• If successful, change the copy target to "production"

This would likely need just one config deployment function, which has a target as parameter (test or prod) and checks against their validation. Then you can do a rollback more easily (i.e. don't copy anything in case of a failure).

If you need cli and config rendering examples, you can look into the icinga2 node wizard or icinga2 node setup CLI code.

https://github.com/Icinga/icinga2/blob/master/lib/cli/nodesetupcommand.cpp
https://github.com/Icinga/icinga2/blob/master/lib/cli/nodewizardcommand.cpp

Since we've seen that today:

if (!globals.contains("NscpPath")) {
  NscpPath = dirname(msi_get_component_path("{5C45463A-4AE9-4325-96DB-6E239C034F93}"))
}

is not needed, that is already done inside include <nscp> and will never be evaluated.

Hi,

at the moment I test the newest version of the powershell module. At lot of changes...

I call it like this:

$icinga = Icinga2AgentModule `
    -FetchAgentFQDN       $TRUE `
    -DirectorUrl          'https://icinga-master/icingaweb2/director/' `
    -DirectorUser         'ticketuser' `
    -DirectorPassword     'password' `
    -ParentZone      'master' `
    -ParentEndpoints 'icinga-master' -EndpointsConfig 'icinga-master;5665'`
    -CAServer        'icinga-master'

exit $icinga.installMonitoringComponents();

And I get this error:

Exception calling "getIcingaDirectorVersion" with "0" argument(s): "Exception calling "createHTTPRequest" with "6" argument(s): "Cannot convert null to type "System.Net.HttpSta
tusCode" due to enumeration values that are not valid. Specify one of the following enumeration values and try again. The possible enumeration values are "Continue, SwitchingPr
otocols, OK, Created, Accepted, NonAuthoritativeInformation, NoContent, ResetContent, PartialContent, MultipleChoices, Ambiguous, MovedPermanently, Moved, Found, Redirect, SeeO
ther, RedirectMethod, NotModified, UseProxy, Unused, TemporaryRedirect, RedirectKeepVerb, BadRequest, Unauthorized, PaymentRequired, Forbidden, NotFound, MethodNotAllowed, NotA
cceptable, ProxyAuthenticationRequired, RequestTimeout, Conflict, Gone, LengthRequired, PreconditionFailed, RequestEntityTooLarge, RequestUriTooLong, UnsupportedMediaType, Requ
estedRangeNotSatisfiable, ExpectationFailed, UpgradeRequired, InternalServerError, NotImplemented, BadGateway, ServiceUnavailable, GatewayTimeout, HttpVersionNotSupported".""

Do you have any idea why this happens?
PsVersion 4 on a Windows 7

...same for uninstall. Eventually keep the former methods as alias names
for compatibility reasons.

Right now the module is capable of installing, upgrading and downgrading the Agent.

There is however no way to remove the Agent right now which might be required in some cases. Up to that there should be an option with an additional paramter to entirely remove the remaining Icinga Directories (should also be an option while installing the Agent for a full clean install)

Hi,

when using the Director Self-Service API (-DirectorUrl 'http://xxx') it is not possible to apply a custom location for the installer package (-DownloadUrl 'http://yyy') at the same time. Regardless of which value is being set as URL always the default value 'https://packages.icinga.com/windows/' is being used as location.

The installer script is automaticly detecting which Agent it should install based on the operating system architecture.

In case a 32bit Agent is already installed on the system and is upgraded / downgraded by the script, it will install the 64bit Agent by default which is intended.

The problem right now is that the script will keep the last installation directory and installs the Agent there, which is in general correct in case a custom path was defined. In case of the default path however, the script would install the Icinga 2 Agent into 'Program Files (x86)' directory instead of the x64 one.

Todo:

• Force x64 'Program Files' directory in case previous install location was 'Program Files (x86)'
• Migrate content from 'Program Files (x86)\ICINGA2' to 'Program Files\ICINGA2'
• Add notification output on PowerShell for this

In this way the setup will always be clean and the user is notified about changes, including the possibility to keep custom data

After looking into the readme, it seems not possible to install/setup Icinga2 agent on a remote system.

For Example, I want to install this module and some scripts on 1 central (Windows) server and then start installation/setup for multiple Windows clients. Currently, we need to install/deploy the module on every system and then run it.

I'd suggest to add the following ones:

&hostname&
&hostname.lowerCase&
&hostname.upperCase&

&fqdn&
&fqdn.lowerCase&
&fqdn.upperCase&

&ipaddress&

Please add a "LICENSE" file with the correct license in it.

Even when using -FullUninstallation the previously installed NSClient++ is not uninstalled during the uninstallation.

Could you add a switch that allows for uninstalling the NSClient?

Hi LordHepipud,

I have a problem with icinga2 agent rollout on Windows Server. After using your powershell script with admin rights...

PS C:\Windows\Temp> powershell.exe -executionpolicy unrestricted -file ".\Icinga2Agent-WINDOWSSERVER.ps1"

...the following exception comes up:

Exception calling "fetchHostnameOrFQDN" with "0" argument(s): "Exception calling "setProperty" with "2" argument(s): "Exception calling "init" with "0" argument(s): "Exception calling "generateEndpointNodes" with "0" argument(s): "Exception calling "getEndpointConfigurationByArrayIndex" with "1" argument(s): "Cannot index into a null array."""""

I used your newest powershell script (Apr 10, 2017).

My settings inside the powershell script are (for better visualization I removed the ending quotes `):
$icinga = Icinga2AgentModule
-ParentZone 'icinga2-master-zone'
-ParentEndpoints 'icinga2a-master.localdomain', 'icinga2b-master.localdomain'
-CAServer 'icinga2a-master.localdomain'
-DownloadUrl 'https://icinga2a-master.localdomain/icinga2-agent/'
-InstallAgentVersion '2.6.3'
-FetchAgentFQDN $TRUE
-DirectorUrl 'https://icinga2a-master.localdomain'
-DirectorUser 'apiuser'
-DirectorPassword 'test12345'
-AllowUpdates $TRUE
$icinga.installIcinga2Agent()

The API-User on the Icinga2-Server has all rights.

/etc/icinga2/conf.d/api-users.conf
object ApiUser "apiuser" {
password = "test12345"
permissions = [ "*" ]
}

Is this exception a result of a bug? If you need more information I would be glad to assist you.

Best regards and thank you for your amazing sripts
Andrej

Doing this, the scripts can be created this way:

$DirectorHostObject = @{
    'object_name' = '&hostname_placeholder&'
    'object_type' = 'object'
    'imports'     = ('import1','import2')
}

$icinga = Icinga2AgentModule -DirectorHostObject $DirectorHostObject

And internally, you could use ConvertTo-Json -Compress to get the actual JSON string to be sent to Director.

Re-Write code base for handling API-Keys and Host-Creation to ensure the script will run even when the template key is no longer present or valid.

The PowerShell Module is currently checking for status 'Started' for a service to ensure it's operating instead of 'Running'.

Right now the icinga2.conf is missing the required parameters to establish connections to configured endpoints.

Right now by using the script, connections are established from the parent Icinga 2 instance towards the Agent.

A customer of mine wants to install the agent to another Windows drive than C: . Please add a way to set the path where the agent is installed.