PHP files are downloading after EA4 conversion

[dazeck]

Hi

I am very nervous about migrating to EA4 from EA3 on my CloudLinux server so I decided to commission a new VPS on DigitalOcean as it's cheap enough to try for a few days. I have put a trial version of Cpanel on and a trial version of CloudLinux on. EA4 was installed out of the box, and I'm not sure how I've done this but I placed a PHPINFO file into the an account folder and when I access the URL it downloads the PHP file.

I did try installing the lsapi handler and it was kind of working but I couldn't get the user php.ini files to work so I tried to switch back to suphp and that's where everything went tits up. I've followed the instructions to remove the lsapi handler. I've even provisioned a new profile (several different ones in fact) and nothing works. CGI handler gives a 500 error and suphp downloads the file.

At the moment I have no confidence in migrating my live server to Easyapache 4, especially reading the issues people are having.

I'll probably delete the temporary VPS I set up and wait a while.

 

[Infopro]

Please feel free to open a ticket to cPanel Technical Support before killing it. I'm sure they'd be interested in looking at your installation to see what went wrong.

 

[dazeck]

I'll do that, anything to help the product.

 

[cPanelNick]

I'll do that, anything to help the product.

Hi dazeck,

Would you kindly post the ticket # once its submitted so we can make sure it gets priority.

Thanks

 

[dazeck]

Sure, Ticket Number 7632185. Already had someone look at it and cgi is working but suphp still downloads the php file. That's my major worry because nobody wants that to happen on their production server.

 

[mtindor]

Sure, Ticket Number 7632185. Already had someone look at it and cgi is working but suphp still downloads the php file. That's my major worry because nobody wants that to happen on their production server.

Indeed, that's a really bad thing to have happen -- especially if you can't manage to fix it quickly. Just from past experience with php files being downloaded when browsed, it seems to pretty much always be an issue with AddHandler stuff in apache. Whether it's a global issue in the Apache config or an issue whereby you have .htaccess files in your accounts that have an AddHandler specifying the now incorrect PHP handler is the question. Somebody posted something very similar to this on these forums somewhere in the past week or two --- trouble with php files being downloaded when browsed instead of of being processed by PHP. And in their case I believe they reported that the AddHandlers had changed and that any custom AddHandler that somebody had in their .htaccess file ended up needing to be modified.

Post #29 of Request to keep EasyApache 3 is where somebody reported something similar.

Are you using custom AddHandler lines in your customer's .htaccess files?

Mike

 

[dazeck]

There are no custom addhandlers at all, it was a fresh install of centos, cpanel and cloudlinux I then tried to install lsapi and then roll back to suphp once I'd worked out there was a problem with user php.ini files. There were no "customer" accounts on the new server I just created a pseudo account and created a brand new php file with just phpinfo in it. I was trying to get close to my production server as I could before then hoping to copy over an account. I didn't get that far.

 

[mtindor]

There are no custom addhandlers at all, it was a fresh install of centos, cpanel and cloudlinux I then tried to install lsapi and then roll back to suphp once I'd worked out there was a problem with user php.ini files. There were no "customer" accounts on the new server I just created a pseudo account and created a brand new php file with just phpinfo in it. I was trying to get close to my production server as I could before then hoping to copy over an account. I didn't get that far.

Ok. Then it's good that you opened a ticket with cPanel because it'll definitely need their attention.

Mike

 

[dazeck]

There looked to be a missing file required form suPHP to work:
[01:08:10 vps2 [email protected] ~]cPs# rpm -V ea-apache24-mod_suphp
missing c /etc/apache2/conf.modules.d/90-suphp.conf

 

[mtindor]

There looked to be a missing file required form suPHP to work:
[01:08:10 vps2 [email protected] ~]cPs# rpm -V ea-apache24-mod_suphp
missing c /etc/apache2/conf.modules.d/90-suphp.conf

What was the fix for this? I've got a test server up and running and have the same issue.

Mike

 

[dazeck]

What was the fix for this? I've got a test server up and running and have the same issue.

Mike

Hi Mike.

Literally, that's what was in the support ticket, I have no idea what they actually did.

 

[mtindor]

Thanks. I got it working. Of course I can't figure out what fixed it. EA4 reconfigure maybe. No idea.

On another note, I too use mod_lsapi -- and the whole idea that mod_lsapi had to be uninstalled so that the ea4- version of it could be installed threw me off. I was scratching my head for hours trying to figure out why mod_lsapi didn't appear to be working even though when I tailed /usr/local/apache/logs/error_log mod_lsapi was mentioned upon startup. Ended up being that I still had to run:

/usr/bin/switch_mod_lsapi --setup
/usr/bin/switch_mod_lsapi --enable-global
/scripts/restartsrv_apache

Then I could see in phpinfo that Server API shows Litespeed like it should.

Mike

 

[cPanelMichael]

Sure, Ticket Number 7632185. Already had someone look at it and cgi is working but suphp still downloads the php file. That's my major worry because nobody wants that to happen on their production server.

Hello,

To update, the issue with suPHP (where access requests resulted in a download of the file) was due to a missing file associated with the ea-apache24-mod_suphp RPM.

# rpm -V ea-apache24-mod_suphp
missing   c /etc/apache2/conf.modules.d/90-suphp.conf

The resolution was to reinstall that RPM with the following command:

yum reinstall ea-apache24-mod_suphp

It looks like the issue is isolated to CloudLinux users who enabled mod_lsap. CloudLinux has published an update with the following change that might help prevent this from happening again:

removed php-x.x.x-ea4-ini.patch which breaks mod_lsapi in some cases (PHPRC related issues).

Feel free to open a separate thread if you notice any additional issues.

Thank you.

 

[dazeck]

@cPanelMichael thanks for the update, much appreciated. Having CloudLinux and cPanel I never know where to log my issues, but cPanel staff never let me down.