|
|
| Author |
Message |
tymbow
Joined: 14 May 2005
Posts: 48
|
 Posted: Mon Oct 13, 2008 10:35 pm Post subject: BUG (Possible): Custom Data Input Method |
 |
|
I have a number of templates that use a custom data input method that runs a Perl script that takes a number of input fields the contents of which vary for each target host.
Long story short, two of the input fields are "username" and "password". What I'm finding is that passwords that contain either ' or $ are not working. If I run the command line for the script manually all is fine thus I'm guessing this is a PHP issue with special characters in text fields.
Is this a known bug, or is there a recommended work around (apart from using passwords without the offending characters of course)? |
|
| Back to top |
|
 |
TheWitness
Developer
Joined: 14 May 2002
Posts: 9736
Location: MI, USA
|
| Posted: Tue Oct 21, 2008 9:27 pm Post subject: |
|
|
Place single quotes around the output in your prel script. Does this help the issue? What poller are you using?
TheWitness |
|
| Back to top |
|
|
tymbow
Joined: 14 May 2005
Posts: 48
|
| Posted: Wed Oct 22, 2008 12:02 am Post subject: |
|
|
I'm using Spine on Windows.
If I check the cacti log, the command to run which includes the Perl script and username/password is actually correct. That is, if I just copy this line and run it on the command line it works perfectly and returns the correct data.
My security colleagues have now actually adjusted the "offending" passwords so the problem is mitigated for now. What I will try and do is to replicate it on our test platform and try to get more specific details on what conditions cause the error. |
|
| Back to top |
|
|
TheWitness
Developer
Joined: 14 May 2002
Posts: 9736
Location: MI, USA
|
| Posted: Wed Oct 22, 2008 4:31 am Post subject: |
|
|
Well, that works too 
TheWitness |
|
| Back to top |
|
|
tymbow
Joined: 14 May 2005
Posts: 48
|
| Posted: Wed Oct 22, 2008 7:06 am Post subject: |
|
|
Some brief tests seem to indicate that the "offending" characters, so far at least, were:
I'm not that familiar with PHP, but I'm assuming these may be reserved characters which is what makes me wonder if there is an issue when the command line script is called by Spine.
As the script runs properly on the Windows command line, Windows obviously does not have issue with them which leaves PHP or Spine. It may be that they need to be quoted when called, but I can't see how to achieve this. The quoting needs to occur when the command line is built so changing the Perl script will have no effect.
FYI, what the script does is scrapes and parses an HTML page which contains memory usage data for Blue Coat SG proxies and spits out a series of "parameter:value" fields that get used by Cacti. It is used thus:
| Code: | | perl script.pl device username password |
I'll keep toying about with it. |
|
| Back to top |
|
|
tymbow
Joined: 14 May 2005
Posts: 48
|
| Posted: Wed Nov 12, 2008 1:41 am Post subject: |
|
|
| TheWitness wrote: | | Well, that works too |
Yeah it did
However, as a follow on to this, we recently had another issue with special characters involving the "ss_host_cpu.php" and "ss_host_disk.php" scripts for some new hosts with special characters in their SNMP community strings. The scripts kept returning 0 items with no errors which was not the case. Running them from the command line revealed the problem with the characters.
Again we changed the strings to someone less "offensive" but there definitely seems to be some issues with how Cacti handles certain characters in passwords, community strings etc. God I wish our security bods would make less crazy passwords... |
|
| Back to top |
|
|
|
FAQ
Search
Memberlist
Register
Profile
Log in to check your private messages
Log in
