Problems with special characters in Script Server arguments

[Miraculor]

I have a script to extract SNMP data using Script Server. I used to have problems with SNMP v2 Community string with special characters or in SNMP v3 Password or Passphrase.
I was able to fix the issue in the XML file by adding single quotes.

<arg_prepend>|host_hostname||host_snmp_version|:|host_snmp_port|:|host_snmp_timeout|:|host_max_oids|:'|host_snmp_community|':|host_snmp_username|:'|host_snmp_password|':|host_snmp_auth_protocol|:|host_snmp_priv_passphrase|:|host_snmp_priv_protocol|:|host_snmp_context| |host_id|</arg_prepend>

I upgraded to Cacti 0.8.8b and the script in not working anymore.

In the log I can see that the quotes are now escaped

ss_script.php ss_script 192.168.1.1 2:161:500:10:\''password-&)*!$\':::::: 21 get cbQosCMPostPolicyByte64 34.14664689

If I remove the quotes the special characters in the community/password are causing more issues.

Changing the community/passwords is not possible. Should I open a bug?

[Miraculor]

Update
The Script Server part is working. when I run it using script_server.php.

It look like the issue is limited to the Host Data Querie.

Is it possible the even if the Data Input Method is set to "Get Script Server Date (indexed)" the Host Associated Data Queries are not executed by script_server.php ?

This is the Data Query Debug Information for the host

Code: Select all

+ Running data query [13].
+ Found type = '6' [Script Query - Script Server].
+ Found data query XML file at '/var/www/html/resource/script_queries/qos.xml'
+ XML file parsed ok.
+ Executing script for num of indexes '"/usr/bin/php" -q /var/www/html/scripts/ss_qos.php 192.168.1.1 2:161:500:10:password:::::: 17 num_indexes'
+ Executing script for list of indexes '"/usr/bin/php" -q /var/www/html/scripts/ss_qos.php 192.168.1.1 2:161:500:10:password:::::: 17 index' Index Count: 0
+ Executing script query '"/usr/bin/php" -q /var/www/html/scripts/ss_qos.php 192.168.1.1 2:161:500:10:password:::::: 17 query index'
+ Executing script query '"/usr/bin/php" -q /var/www/html/scripts/ss_qos.php 192.168.1.1 2:161:500:10:password:::::: 17 query oid'
+ Executing script query '"/usr/bin/php" -q /var/www/html/scripts/ss_qos.php 192.168.1.1 2:161:500:10:password:::::: 17 query ifName'
+ Executing script query '"/usr/bin/php" -q /var/www/html/scripts/ss_qos.php 192.168.1.1 2:161:500:10:password:::::: 17 query ifDescr'
+ Executing script query '"/usr/bin/php" -q /var/www/html/scripts/ss_qos.php 192.168.1.1 2:161:500:10:password:::::: 17 query PolicyDirection'
+ Executing script query '"/usr/bin/php" -q /var/www/html/scripts/ss_qos.php 192.168.1.1 2:161:500:10:password:::::: 17 query classname'

I tested the num_index with script_server.php

Code: Select all

/var/www/html/scripts/ss_qos.php ss_qos 192.168.1.1 2:161:500:10:password:::::: 17 num_indexes

The returned value was good (20).

When I try via the CLI

Code: Select all

php /var/www/html/scripts/ss_qos.php ss_qos 192.168.1.1 2:161:500:10:password:::::: 17 num_indexes

or

Code: Select all

php /var/www/html/scripts/ss_qos.php 192.168.1.1 2:161:500:10:password:::::: 17 num_indexes

I am getting error message "-bash: :: unrecognized history modifier"

When I add quotes to the community string I am getting a valid response (20)

Code: Select all

php /var/www/html/scripts/ss_qos.php ss_qos 192.168.1.1 2:161:500:10:'password':::::: 17 num_indexes

[OID]

I’m facing a similar issue with special characters in SNMPv3 credentials.

As workaround I put parameters in single quotes within the XML:

Code: Select all

<arg_prepend>|host_hostname| |host_snmp_version| |host_snmp_port| |host_snmp_timeout| |host_max_oids| '|host_snmp_community|' '|host_snmp_username|' '|host_snmp_password|' '|host_snmp_auth_proto|' '|host_snmp_priv_passphrase|' '|host_snmp_priv_protocol|'</arg_prepend>

And later remove the single quotes within my PHP script:

function rmquotes($para) {
if ((substr($para,0,1)=="'") && (substr($para, -1)=="'")) {
return substr($para,1,-1);
}
else {
return $para;
}
}

That’s neither elegant nor robust but works for most special characters. A space in one of the parameters will confuse the script server anyway.

I found these old closed bug regarding the handling of non-standard characters.