Icinga passes umlauts in argument values wrong in german based Windows server setups

[stevie-sy]

Describe the bug

We note, that on german based Windows server, the Icinga Agent triggers checks with argument whose values contain umlauts in wrong way. It has probably never been noticed until now, because the previous - now depracted - checks like check_disk.exe, check_load.exe etc. offers only parameters for threshold. With the release of the "Icinga-PowerShell-Framework" and "Icinga-PowerShell-Plugins" aka "Icinga for Windows" exists checks, where a value can be more than a threshold value. What I mean is, that the passed value can be a (Secure)String, Object, etc.

For example the check "Invoke-IcingaCheckScheduledTask" has a parameter to check for a taskname. The type of the value is a string. And a task could have in german environments one or more umlauts in the name. Ok, here we could say write "oe" instead of "ö" etc. because it's nicer. But here other examples:

• Based on the PowerShell-Framework I wrote for us a Cmdlet to check for specific mails in diffrent mail boxes on our exchange server. And of course in mails could be umlauts and other special characters in german communications.
• Let's think this further: If you have to pass a password string which contains a umlaut, the check will never work!

To Reproduce

I did some in investigation and testing in this case. First I created a ScheduledTask called "TestTask Umlaute äöüß" which triggers a simply "Hello World"-PowerShell-Script.

After I created the service check in the director:

The director deploy this in correct way to the Agent. So it's a UTF-8-file which contains the correct spelling:

apply Service "task-windows_TEST_Umlaute" {
    import "template_generic-service_active_agent"
    check_command = "Invoke-IcingaCheckScheduledTask"
    assign where host.name == "xxxxxx"
    vars.IcingaCheckScheduledTask_Array_State = [ "Ready", "Running" ]
    vars.IcingaCheckScheduledTask_Array_TaskName = [ "TestTask Umlaute äöüß" ]
    vars.IcingaCheckScheduledTask_Int32_Verbosity = "2"
    import DirectorOverrideTemplate
}

If you click on inspect in icingaweb2 you'll see this:

'C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe' '-C' 'try { Use-Icinga -Minimal; } catch { Write-Output '\''The Icinga PowerShell Framework is either not installed on the system or not configured properly. Please check https://icinga.com/docs/windows for further details'\''; exit 3; }; Exit-IcingaExecutePlugin -Command '\''Invoke-IcingaCheckScheduledTask'\'' ' '-TaskName' ''\''TestTask Umlaute äöüß'\''' '-State' ''\''Ready'\'','\''Running'\''' '-Verbosity' '2'

So far so good, but if you run the check, the output in icingaweb2 is this (I know there is a permission problem (https://github.com/Icinga/icinga-powershell-plugins/issues/207) , but we know how to fix it 😉 . So shouldn't play another role here ):

If I test this in the Icinga PowerShell-Console and if the task is found you'll get this output (ok, the output is not nice, here could be also a problem - I have to test this more to create another issue for the framework if needed):

But interesting in this case is, that in the debug log it looks like that icinga triggers theck in correct way:

[2021-08-05 18:43:34 +0200] notice/Process: Running command 'C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -C "try { Use-Icinga -Minimal; } catch { Write-Output 'The Icinga PowerShell Framework is either not installed on the system or not configured properly. Please check https://icinga.com/docs/windows for further details'; exit 3; }; Exit-IcingaExecutePlugin -Command 'Invoke-IcingaCheckScheduledTask' " -TaskName "'TestTask Umlaute äöüß'" -State 'Ready','Running' -Verbosity 2': PID 6360

If I compare this two result I come to the conclusions that Icinga triggers the check with the wrong encoding of string values. To be sure I did some more testing and I went a little bit deeper:

First I checked the codepages from Windows and PowerShell. And here is the first diffrence: The command chcp in the command prompt delivers the codepage 850 The command [System.Text.Encoding]::Default in PowerShell delivers codepage 1252

With this knowledge I tried diffrent things to trigger checks:

• I wrote a Bat-File for the hole check. Before running the check, change the codepage to 65001 (UTF-8) => works, because no argument/values are passed!

@echo off
chcp 65001 > nul
C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -C try { Use-Icinga; } catch { Write-Output 'The Icinga PowerShell Framework is either not installed on the system or not configured properly. Please check https://icinga.com/docs/windows for further details'; exit 3; }; Exit-IcingaExecutePlugin -Command Invoke-IcingaCheckScheduledTask -TaskName 'TestTask Umlaute äöüß' -State 'Ready','Running'-Verbosity 2
exit %errorlevel%

• Based on the first Bat-Script I created a Wrapper-Script => fails, because of passing value in wrong encoding. Changing the codepage before running doesn't help!

@echo off
chcp 65001 > nul
C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe %*
exit %errorlevel%`

• Windows Server 2019 offers a option in the region settings, to set UTF-8 as standard: With this is everything is fine. On the one hand, Microsoft has declared this option as beta and on the other hand, one cannot really judge whether there are any side effects with the software that is running on the server. Furthermore this (beta) option doesn't exist on Windows 2012R2 and Windows 2016. So not really an option in my opinion.

• I tested also to adjust the Cmdlet use-icinga from the PowerShell-Framework with following line: $PSDefaultParameterValues['*:Encoding'] = 'utf8' But this doesn't help as well.

Of course there is no problem on Linux. Here is the standard encoding already UTF-8!

If you need futher information, please let us know.

Expected behavior

Make sure, that that Icinga triggers a check with parameters and their values in correct way/encoding. Maybe set the encoding to utf-8 before trigger the check if possible.

Your Environment

Include as many relevant details about the environment you experienced the problem in

• Version used (icinga2 --version): 2.12.4
• Operating System and version: W2012R2, W2016, W2019

[moreamazingnick]

https://github.com/Icinga/icinga2/blob/bad805996973a8d48617cd5ca599c31bfc7b6454/lib/icinga/pluginutility.cpp#L27 add an utf8 to ISO-8859-1 converter

[Al2Klimov]

@LordHepipud Any way to fix this in the PS plugins like #7346?

[LordHepipud]

I'm honestly not sure. I tried to play around in with this on my test environment, and for me the call itself is broken:

[2022-02-16 12:57:31 +0100] notice/JsonRpcConnection: Received 'event::ExecuteCommand' message from identity 'sales-net-icinga2a'.
[2022-02-16 12:57:31 +0100] notice/Process: Running command 'C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -NoProfile -NoLogo -ExecutionPolicy ByPass -C "try { Use-Icinga -Minimal; } catch { Write-Output 'The Icinga PowerShell Framework is either not installed on the system or not configured properly. Please check https://icinga.com/docs/windows for further details'; Write-Output 'Error:' $($_.Exception.Message)Components:`r`n$( Get-Module -ListAvailable 'icinga-powershell-*' )`r`n'Module-Path:'`r`n$($Env:PSModulePath); exit 3; }; Exit-IcingaExecutePlugin -Command 'Invoke-IcingaCheckDirectory' " -Path C:\über\den\Wolken -FileNames @() -Verbosity 3': PID 3224

[LordHepipud]

Nvm - figured it out. But still, no idea on how to resolve this issue properly

[LordHepipud]

Can you please test this PR from the Icinga PowerShell Framework?

https://github.com/Icinga/icinga-powershell-framework/pull/482

This should resolve the problem without requring to modify anything locally on the Windows machine.

In case you are using Icinga Repositories, you can install this PR as update with this command:

[string]$Project = 'icinga-powershell-framework';
[string]$Branch  = 'fix/utf8_encoding_errors';

Add-IcingaRepository `
    -Name "$Project/$Branch" `
    -RemotePath "https://packages.icinga.com/IcingaForWindows/snapshot/$Project/$Branch/ifw.repo.json";

Install-IcingaComponent -Name $Project.Replace('icinga-powershell-', '') -Version $Branch -Snapshot -Force;

[stevie-sy]

@LordHepipud thanks for the fix in the framework. I'll try to do it the next days. But it can take a while. Because we resintall our test environment at the moment incl. testing the new version 1.8.0 you released some days before. Anyway, I'll report back

[stevie-sy]

I started testing the PR now. What I can say now, that it works, but somehow it doesn't. Let me explain/show what I mean:

• I created again two tasks with umlauts and created a service and applied it to test servers with W2012R2, W2016, W2019 und W2022.
• the director reder them correctly. With the inspect function we can control it:
• run the check manually in the cmd. Everything is fine as well:
• the same running the check manually in the ISE
• But if Icinga is triggers the check, something weird happens. This is the output in icingaweb2: In this is from the debug log from the agent:

What we can see here, that icinga triggers the check correctly as the director renders the service. But the question here what is icinga doing the produce an exit code 3?

[LordHepipud]

The plugin cannot find the servcices, as the umlauts are not correct. Once you updated your local version with the Framework PR, did you rebuild the cache?

Write-IcingaFrameworkCodeCache

Otherwise you might still run the older version. I'm not sure if this is the problem, but on my test machine, this worked properly (in general you shouldn't require to manually rebuild the cache if you did it with the method I provided - need to have a look on that)

[stevie-sy]

Since some troubles during testing in the past, I'll run always

Import-Module icinga-powershell-framework -force -Verbose
Import-Module icinga-powershell-plugins -force -Verbose
Get-ChildItem -Path 'C:\Program Files\WindowsPowerShell\Modules\icinga-powershell-framework' -Recurse | Unblock-File;
Get-ChildItem -Path 'C:\Program Files\WindowsPowerShell\Modules\icinga-powershell-plugins' -Recurse | Unblock-File;
Write-IcingaFrameworkCodeCache
Restart-Service icinga2 -Force -Verbose
Use-Icinga

just to be save :-) Especially if we try a lot on a test system and switch between versions. You'll know :'-) The versioning of the modules cannot spoil things for us either. I stopped that on the test servers with 1.8.0

So strange behaviour, so for the moment I've no idea. But I will do some more tests, what it could be. As I wrote above, manually running the checks works fine with the new changes.

[LordHepipud]

Just to make one thing sure: Could you please check, if this file does exist?

https://github.com/Icinga/icinga-powershell-framework/pull/482/commits/493dcbde2022c747d544d4cfb240a490ffdb3989#diff-80ad8ab9e78f0f4c7b27fab97f2de303829a240f3bfc259571985d05f60d61cd

[stevie-sy]

yes

[LordHepipud]

This is a weird scenario then, because it should just work fine now without problems. Do you use the Icinga for Windows service with the REST-Api? If so, have you restarted the Icinga for Windows service (if present)?

[stevie-sy]

No we don't use it yet. We just wait for the big performance boost change you presented as future plan at the OSMC last year :-)

[stevie-sy]

Did some addional tests:

• set in the region options (see in my inital post) the BETA-option to UTF8 -> everything fine
• run icinga2 in the foreground in the cmd and set manually the codepage (chcp 65001) before -> not work
• run icinga2 in the foreground in the powershell and set the codepag ($PSDefaultParameterValues['*:Encoding'] = 'utf8') -> not work

So for me this looks like, that this problem has nothing to do with the great PS-Framework from @LordHepipud. It has more to do with icinga and Windows itself. So I found this docs, maybe this is something for you https://docs.microsoft.com/en-us/windows/apps/design/globalizing/use-utf8-code-page So the quesion now is: is icinga using the default code page from windows? or does icinga2 forces utf-8 while starting?

If I should check/test more, please let me know

[Al2Klimov]

does icinga2 forces utf-8 while starting?

Yes, since #7346.

[stevie-sy]

Ok thanks for the information. So now it's a little bit strange and interesting why this doesn't work like it should.

[LordHepipud]

Icinga for Windows v1.10.0 will fix this issue: https://github.com/Icinga/icinga-powershell-framework/pull/482

[tbauriedel]

ref/NC/761567

[Al2Klimov]

There's even a non-.0 version of IfW with that fix, v1.10.1.

Please re-open if it didn't fix it.