CentOS 7 and suPHP

[jeking]

I've moved to a new server and a new hosting company. The server I came from was CentOS 6 using DSO and the php handler. Site ran fine for months.

On the new server, I'm getting a blank page when logging in as a customer. Problem is, no error logs exist. The host and cPanel say file and folder permissions are correct, 755 for folders and 644 for files. I have checked the logs folder and it is 755.

They are stumped as to why Zen Cart is not writing error logs. The exact copy of this cart did on the old server. Is there any known issues with CentOS 7? Any other thoughts on the cause??

The site was created using the cpanel to cpanel transfer. PHP version is 5.6, same as old server. mySQL is 5.6 now, 5.5 on old server.

[DrByte]

No, not a CentOS-specific issue. ZC is never directly tested on CentOS during development. But there's nothing specific to CentOS that is likely to be uniquely problematic.
That said, the actual configuration of each server could be vastly different. So that's where to investigate.

As a diagnostic step I'd try running zc_install (tell it to use a different database temporarily, so you don't wipe out current data), and see what it flags up as "issues" with the new server, and whether it can properly write the contents of the configure.php files.

Then test logging into that temporary copy of the site.

Once testing is done, simply edit the database-name in the configure.php files to point back to the real data.


Also check whether the installed apache modules of the old server are on the new one, and compare apache conf and php.ini between servers (and, ya, cPanel makes that comparison insanely complicated).

[jeking]

I ran the Zen Cart install on another domain on this same server. Installation pointed out no problems and completed successfully. This install log and install exception (made a typo in db name during first attempt) files were both created in he logs folder.

I created an error in Zen Cart. The error is logged to the error_log file in the roof folder (per the php.ini file) but nothing in the logs folder.

I still have to compare apache modules and php.ini

[jeking]

A quick off-topic, what OS is Zen Cart tested on?

[DrByte]

A quick off-topic, what OS is Zen Cart tested on?

Automated testing is on Ubuntu LTS: https://travis-ci.org/zencart/zencart
Developers are using various combinations of Ubuntu, OSX, and ..... I completely forgot that cPanel servers are mostly CentOS by default, so a handful of CentOS are actually being used (but in those cases, operated by 3rd parties, and we have zero control over configuration or any devops activities, hence forgetting what OS is in use).

[carlwhat]

ok... feel free to ignore me, but call me old-school.... an error that one can replicate is an error that one can solve....

now, feel free to correct me if i am wrong, but we are talking some low level stuff here... we have a blank page with no error log....

from what i can tell, the error log is created in:

includes/classes/class.base.php

and specifically in the notify function.

if i was troubleshooting this problem, i would start adding some die statements within that function and see if you are getting to the point when replicating the error, ie logging in as a customer. i like to use:

die(__FILE__ . ':' . __LINE__);

so that i know exactly where i have gotten.

you can add one right after the notify function or right before the line:

error_log( strftime("%Y-%m-%d %H:%M:%S") . ' [main_page=' . $main_page . '] ' . $eventID . $output . "\n", 3, $file);

which in theory creates the log file.

if you are successfully getting to the line, you can then change your die to:

die($output);

so you can see the actual problem, and then tell the hosting company something is wrong as ZC as done its part and no error log gets created. if you do not get to that line you can try seeing if you are getting to the notify function by adding a die statement at the beginning of the function.

errors that you can not reproduce at will are the toughest ones..... ones that you can reproduce, i find, can almost always be solved, or at least understood...

good luck. let us know how it goes....

[barco57]

As someone who spends all his time in a hosting environment I wouldn't expect centos 7 to be the issue, it would likely be the last place I looked after I had exhausted everything else...

If the server your on lets you do the following I would put it at the top of the page that is suppose to be loading and see if I can get it to display the error on screen.

ini_set('display_errors', '1');

Also mod_sec could be the culprit, a 500 error could actually be taking place and not displaying, though normally mod_sec would trigger a second rule to avoid data leakage and kick you back to the root of the domain and display the home page.

[jeking]

The new host has spent hours on this and cPanel support has as well. We've got to the point that errors are begin written, but they are going into the server error_logs file and not the 'logs' folder within each Zen Cart. While you could argue that this works, I feel there is still something wrong and it's silly to proceed. Plus that fact that finding the errors is now more difficult for site owners.

@barco57 mod_sec is enabled.

I also believe the issue is not CentOS 7 but I also don't know what the actual problem is.

File permissions should not be the issue. The logs folder is correct as is all other files/folders as we used these steps:
http://boomshadow.net/tech/fixes/fixperms-script/

I've done all I can. The new host has done all they can or are willing. To be fair, they have put in a lot of time and engaged cpanel so I have to respect the effort. But, it's still not working.

I don't see an option but to go back to my previous host (I was 40% of they way through moving accounts, so now have to move them back). I will have this new server for another 2 weeks. If someone is willing and interested in taking a look to help, I'll give access and compensate for your time. PM me.

[jeking]

@barco57 mod_sec is enabled.

Correction, NOT enabled. Which is the true on our old server as well.

[lat9]

FWIW, I ran into the same issue over the summer when I transferred a couple of sites ... writable folders weren't being written to (i.e. /logs, /cache, /admin/includes/backup, etc.).

I'd created the sites' file-system via FTP. The old location was running a PHP 5.4 variant and the new location is running a variant of PHP 5.6.

The "fix" for my situation was running that "fixperms" script; once that was done all was working properly.