Error_log full of error from SupportSuite

[netaddict]

I’ve noticed my error_log file in plesk each day becoming rather large. On further investigation it’s full of error related to Kayako SupportSuite. I’m running version SupportSuite 3.30.02 Stable.

[Fri Sep 05 05:45:02 2008] [error] [client x.x.x.x] PHP Notice: Undefined index: isdemo in /home/httpd/vhosts/domain.com/httpdocs/helpdesk/swift.php on line 202
[Fri Sep 05 05:45:02 2008] [error] [client x.x.x.x] PHP Notice: Undefined index: type in /home/httpd/vhosts/domain.com/httpdocs/helpdesk/swift.php on line 226
[Fri Sep 05 05:45:03 2008] [error] [client x.x.x.x] PHP Notice: Undefined index: querydb in /home/httpd/vhosts/domain.com/httpdocs/helpdesk/includes/functions.php on line 474
[Fri Sep 05 05:45:03 2008] [error] [client x.x.x.x] PHP Notice: Undefined index: scheme in /home/httpd/vhosts/domain.com/httpdocs/helpdesk/swift.php on line 584
[Fri Sep 05 05:45:03 2008] [error] [client x.x.x.x] PHP Notice: Undefined index: host in /home/httpd/vhosts/domain.com/httpdocs/helpdesk/swift.php on line 584
[Fri Sep 05 05:45:03 2008] [error] [client x.x.x.x] PHP Notice: Undefined index: eventaction in /home/httpd/vhosts/domain.com/httpdocs/helpdesk/modules/parser/parser.php on line 65
[Fri Sep 05 05:45:03 2008] [error] [client x.x.x.x] PHP Notice: Constant ACTION_MERGE already defined in /home/httpd/vhosts/domain.com/httpdocs/helpdesk/modules/tickets/tickets.php on line 58
[Fri Sep 05 05:45:04 2008] [error] [client x.x.x.x] PHP Notice: Undefined index: deletelockfile in /home/httpd/vhosts/domain.com/httpdocs/helpdesk/modules/parser/cron_parser.php on line 92
[Fri Sep 05 05:45:07 2008] [error] [client x.x.x.x] PHP Warning: file_exists() [<a href='function.file-exists'>function.file-exists</a>]: open_basedir restriction in effect. File(./files/parser.lockfile) is not within the allowed path(s): (/home/httpd/vhosts/domain.com/httpdocs:/tmp) in /home/httpd/vhosts/domain.com/httpdocs/helpdesk/modules/parser/cron_parser.php on line 32

Is anyone able to help me out with what is causing all the above errors? There’s over 700kb of them in ever 24 hour period.

Thanks,
Dylan

[John Haugeland]

This is very probably the php 5.1.* open_basedir bug. Please update to a version of PHP newer than 5.1.6 .

There are several other threads where this is already explained.

[netaddict]

Running PHP Version 5.2.5 on this server.

[netaddict]

I've been told by Kayako support with this problem to set The Error_Reporting to: E_ALL & ~E_NOTICE

Isn't having to do something like that really a bug with Kayako?

[Matthew]

I have this error, as well:

[Mon Sep 15 17:10:09 2008] [error] [client x.x.x.x] PHP Warning: file_exists() [<a href='function.file-exists'>function.file-exists</a>]: open_basedir restriction in effect. File(./files/parser.lockfile) is not within the allowed path(s): (/var/www/vhosts/mydomain/subdomains/help/httpdocs:/usr/share/pear:/bin:/usr/bin:/sbin:/usr/sbin:/tmp) in /var/www/vhosts/mydomain/subdomains/help/httpdocs/modules/parser/cron_parser.php on line 32

If I set open_basedir none, it goes away, of course. But that won't do...

I'm using PHP 5.2.6 on a CentOS 4 with Plesk 8.4 and SS 3.20.02. Does anyone know what this is about? ./files is clearly within the allowed paths...

I've looked in other threads but can't seem to find an answer to this.

[netaddict]

Originally Posted by Matthew

I have this error, as well:

[Mon Sep 15 17:10:09 2008] [error] [client x.x.x.x] PHP Warning: file_exists() [<a href='function.file-exists'>function.file-exists</a>]: open_basedir restriction in effect. File(./files/parser.lockfile) is not within the allowed path(s): (/var/www/vhosts/mydomain/subdomains/help/httpdocs:/usr/share/pear:/bin:/usr/bin:/sbin:/usr/sbin:/tmp) in /var/www/vhosts/mydomain/subdomains/help/httpdocs/modules/parser/cron_parser.php on line 32

If I set open_basedir none, it goes away, of course. But that won't do...

I'm using PHP 5.2.6 on a CentOS 4 with Plesk 8.4 and SS 3.20.02. Does anyone know what this is about? ./files is clearly within the allowed paths...

I've looked in other threads but can't seem to find an answer to this.

Log a support ticket and they will be able to help you (eventually).

Apparently it’s a problem with the parser file and they updated it for me.

Don't necessarily expect a prompt resolution, took over a week back and forth with support and I still don't exactly know the entire fix's and why.

[craigbrass]

You should post your ticket ID. Jamie (whos job includes investigating this sort of thing) may be able to find out why it took so long and make sure it doesn't happen in the future.

[Matthew]

I took a stab at cron_parser.php, applying a little intui-logic...

Find line 21:

define ("PARSER_LOCKFILE", "./files/parser.lockfile");

Replace ./files/parser.lockfile with the full path of the file, as so:

define ("PARSER_LOCKFILE", "/var/www/vhosts/yourdomain.com/httpdocs/files/parser.lockfile");

I guessed that open_basedir is not happy with this particular relative path when called by the file_exists function. So I just replaced it with an absolute path.

It's been 25+ minutes, and the error seems to have disappeared.

[John Haugeland]

Originally Posted by netaddict

I've been told by Kayako support with this problem to set The Error_Reporting to: E_ALL & ~E_NOTICE

Isn't having to do something like that really a bug with Kayako?

No. That isn't a fix; that's a way for them to get the information they need to know what's wrong. It's a diagnostic step.

Imagine if you had a car that had a switch that turned off all the horrible clunking sounds. When you took the car to the mechanic, he'd have to turn off that switch to get a sense of what was going on.

Because error messages from poorly developed software occasionally lead to ways to find security holes, it is common for hosts to suppress error messages as a last-gasp security wallpaint maneuver. This is responsible, given that many people run applications with questionable security records (I won't name names, but a lot of you know which applications I mean.)

However, when our staff wants to go in and find out what's gone wrong, temporarily removing error suppression becomes important to the diagnostic process.

I hope that clears things up. I'll ask the support staff to be a little clearer about why they're requesting that, in the future.

[Jamie Edwards]

Hi Matthew,

Originally Posted by Matthew

I took a stab at cron_parser.php, applying a little intui-logic...

Find line 21:

Replace ./files/parser.lockfile with the full path of the file, as so:

I guessed that open_basedir is not happy with this particular relative path when called by the file_exists function. So I just replaced it with an absolute path.

It's been 25+ minutes, and the error seems to have disappeared.

Could you open up cron_parser.php again, and find:

PHP Code:

/**
* Function to clear lock file
*/
function clearParserLockFile()
{ 


Just after this, put:

PHP Code:

echo getcwd().'\n'; 


So that it looks like:

PHP Code:

/**
* Function to clear lock file
*/
function clearParserLockFile()
{
    echo getcwd().'\n';
    if (file_exists(PARSER_LOCKFILE))
    { 


Then, execute the cron page and see what the results of that echo statement are. Can you paste them here?

[Matthew]

Hi Jamie,

I inserted the code and ran /cron/index.php, but nothing came out.

Am I executing the right file?

[netaddict]

Originally Posted by John Haugeland

No. That isn't a fix; that's a way for them to get the information they need to know what's wrong. It's a diagnostic step.

Imagine if you had a car that had a switch that turned off all the horrible clunking sounds. When you took the car to the mechanic, he'd have to turn off that switch to get a sense of what was going on.

Because error messages from poorly developed software occasionally lead to ways to find security holes, it is common for hosts to suppress error messages as a last-gasp security wallpaint maneuver. This is responsible, given that many people run applications with questionable security records (I won't name names, but a lot of you know which applications I mean.)

However, when our staff wants to go in and find out what's gone wrong, temporarily removing error suppression becomes important to the diagnostic process.

I hope that clears things up. I'll ask the support staff to be a little clearer about why they're requesting that, in the future.

So based on your reply then shouldn't the value now be set back to what it was prior to support requesting me to change it?

Support have not asked me to do that and now the errors have gone they consider it closed. I can guess the moment its set back to what it was the errors will reoccur?

[Matthew]

Originally Posted by netaddict

So based on your reply then shouldn't the value now be set back to what it was prior to support requesting me to change it?

Just curious if the fix that support gave you is the one that I came up with?

[John Haugeland]

Originally Posted by netaddict

So based on your reply then shouldn't the value now be set back to what it was prior to support requesting me to change it?

Yes.

Originally Posted by netaddict

Support have not asked me to do that and now the errors have gone they consider it closed. I can guess the moment its set back to what it was the errors will reoccur?

If nothing else was done, unfortunately, yes.

If that's what's happened in this ticket, then our support staff is in error. Jamie's looking into the matter. I very much hope that isn't what happened. That said, mistakes do get made; we're all human. We're looking into the matter. If that is what happened, with your permission, diagnosis will renew, and the actual problem will be tracked down.

From here on in, for the sake of keeping records regarding the technical problem in one place, I would prefer that we go back to handling this in the ticket. I'll leave it as your choice, though.

[netaddict]

Thanks for your comments John.

I'll update the ticket and see how that all goes. I'll post back if relavent how it goes, hopefully successful.