Nagios Support Forum

G ' Day Nagios XI Customer Support,

I have come up against a wall and cannot seem to figure out how to go over, under or around it.

Synopsis: Build a Powershell script that accepts three arguments registry path, name of key and expected value

i.e.
./check_registry_value.ps1 [registry path] [registry key] [expected value]

./check_registry_value.ps1 HKLM:\HARDWARE\DESCRIPTION\System\BIOS BIOSReleaseDate "11/01/2015"

OK: Value of 11/01/2015 is as expected value. Works... Taste great! Less filing!

So now I transfer the functionality into the NCPA framework.
Testing first from the NCPA web server API tab.
To pass arguments into the plugins API you can specify all three arguments in one available field or you can specify three fields each containing their own argument...good so far.
To pass special characters like "\" backslash into the url it is required to use %5C for argument one...good so far
Which results in the following text for argument 1: HKLM%3A%5CHARDWARE%5CDESCRIPTION%5CSystem%5CBIOS
Next add the second argument which is simply straight text which is no issue...again good so far
Which results in the following text for argument 2: BIOSReleaseDate
Lastly I need to pass the expected date as defined in the registry field for the last argument...this is where things went bad!
Resulting in argument 3 being passed as: 11%2F01%2F2016 <-- I have tried every way I can think of to get this to work.
I have attempted to pass all kinds on urlencode combinations to include escape characters and for the life of me I cannot seem to get the argument to include forward slashes. I understand that the url that is being passed to the NCPA web server uses forward slashes as it delimiter for passing arguments but why it will not accept %2F as part of the argument and ignore it as part of the url can only mean its not being considered in the code. Of course if the last argument contains spaces %20 or back slash %5C it processes the URL fine and functions as expected...only the forward slash %2F appears to not usable.

i.e.
https://dg0123-ibm-6029:3181/api/plugin ... F01%2F2016

{ "returncode": 2, "stdout": "CRITICAL: Value of 11/01/2016 does not equal the expected value of 11." }

If anyone has experienced this and was able to resolve I would be greatly appreciative as I have spent much time in trying to solve to no avail.
Perhaps there is configuration within the ncpa.cfg to control the ability to allow slashes in the url???

Thanks for your help,
Danny

The more I look at this...I believe just a simple change to the code when passing non-escaped quotes when passing the arguments might solve the issue...

In an another example:
i.e.
https://dg0123-ibm-6029:3181/api/plugin ... 20840%20G3

Passing space characters in the last arguments results in the failure as well...

{ "returncode": 2, "stdout": "CRITICAL: Value of HP EliteBook 840 G3 does not equal the expected value of HP." }

The actual value of the expected value HP EliteBook 840 G3 appears to be chomp off after the first space is encountered...this is obviously a bug unless there is some super secret escape sequence which is not included in the documentation...so I think looking at the code which parses the url is the culprit...something on the line of "use space as terminator for the end of the url"...just don't know.

Please let...again this should be easily replicated and confirmed.

Thanks,
Danny

Our developers will look into this, but for the time being, why don't you just wrap your date in double quotes? It *should* work.

Here's how I tested this:

my "test.ps1" script Running the script locally: In the web UI (API) - one argument: In the web UI (API) - three arguments: From the CLI - using single quotes to wrap the args (the date is wrapped in double quotes): From the CLI - using double quotes to wrap the args ("extra" double quotes are escaped with backword slashes):

Yes I understand and yes I can pass quotes either literal " or %22 but the fact remains that the parser is not returning the original variable and can be seen in your example where you pass "11/01/2015" but the parser returns those quotes along with escape characters \"11/01/2015\".

I can fix my code to drop the quotes with something like $expectedValue = $expectedValue -replace "`"","" which solves my issue...but having to code something differently just because its passing through the NCPA parser as opposed to a command shell seems hokey.

Yes by performing the replace function in the script I have satisfied the comparison operation but again I think the parser should simply drop the quotes as their true intention should be to group separated characters or allow special characters to be processed as expected...maybe I am being over critical but it seems obvious that the quotes are not really part of the data and are merely control operators to help process the data as expected.

i.e.
https://dg0123-ibm-6029:3181/api/plugin ... Name/%22HP EliteBook 840 G3%22

{ "returncode": 0, "stdout": "OK: Value of HP EliteBook 840 G3 is as expected value." }

Anyway let me know what the developers think...I would be interested.

Thanks again,
Danny

Support,

As a final note, when utilizing quotes to specify the 1st argument.

i.e.
https://dg0123-ibm-6029:3181/api/plugin ... Name/%22HP EliteBook 840 G3%22

Notice that the parser returns the variable completely different.

{ "returncode": 3, "stdout": "UNKNOWN: \"HKLM:/HARDWARE/DESCRIPTION/System/BIOS\" path not found in registry." }

The quotes are added to the variable including their escape character but even more interesting the back slashes are magically changed to forward slashes...of course that definitely breaks the code/script and increases a ton of complexity into any scripts you might want to create for plugins. Having the original variables changed by the parser other than the leading and trailing characters really concerns me seeing now I have to really consider the possible data being sent when quoted...

Just FYI...

Thanks,
Danny

This is a known issue with the NCPA API when running plugins - in newer versions of NCPA we will be moving away from arguments in the path to arguments passed via the actual arguments (although we will maintain backwards compatibility for the entire 2.x branch) that are in the GET request, which will allow for a lot of flexibility and remove the need to do the encoding for spaces and slashes.

That sounds good.
I appreciate the update.

Thanks,
Danny