EA4 adding wrong stuff to htaccess files

[4u123]

So I converted a server from EA3 to EA4 today, allowing EA4 to build Apache and PHP based on the EA3 config. Although despite the fact that only native PHP version 5.6 was installed, EA4 decided to install 54 55 and 56

We are using Cloudlinux PHP Selector which I'm very pleased with. There are only a handful of users that have their PHP version set to the servers native version.

But for some reason EA4 doesn't seem to take into account the fact that we are using alt-php and it decides to write crap into our users htaccess files anyway. Here is an example...

# php -- BEGIN cPanel-generated handler, do not edit
# Set the “ea-php54” package as the default “PHP” programming language.
<IfModule mime_module>
AddType application/x-httpd-ea-php54___lsphp .php .php5 .phtml
</IfModule>
# php -- END cPanel-generated handler, do not edit

I don't know why this happened, since this user was not even using the native version - but alarmingly this entry remained even after I re-provisioned PHP, removing ea-php54 from the server entirely. So this broke the clients site.

I don't know why cpanel insists on writing stuff to the clients htaccess files anyway. Cloudlinux seem to have found a much better way of dealing with versions without having to do that.

Just thought I'd vent my frustration at having yet another bad experience with EA4. I don't know how many of my clients have been affected by this but I'm sure there will be plenty more letting me know over the next couple of days.

 

[cPanelMichael]

Hello,

The following document is helpful for understanding how PHP Selector and MultiPHP integrate:

PHP Selector and MultiPHP

Can you verify if CageFS was enabled for the affected account, and if you are using mod_lsapi on this system?

Thank you.

 

[4u123]

Yes I've read that document which is why it is so alarming that the EA4 behaviour doesn't match it. The default version was 5.6 before - and the EA4 conversion shouldn't have installed 5.4, let alone set it to the default and start adding code to htaccess file. I've already had another two customers complain. How can I make sure those handlers are removed?

Yes of course CageFS was enabled. CageFS controls the PHP selector.

Yes I'm using lsapi. After the EA4 build I ran...

yum install ea-apache24-mod_lsapi
/usr/bin/switch_mod_lsapi --setup
/usr/bin/switch_mod_lsapi --enable-global

Also.. If I look in Multi PHP Manager at the versions. ALL accounts say "ea-php56 inherited". So why were those ea-php54 handlers added? And more importantly, why were they not removed?

How can I get them removed ASAP?

 

[cPanelMichael]

Hello,

I can attempt to reproduce this behavior on a test system. Can you verify the commands you used to convert to EasyApache 4? For instance, did you follow the CloudLinux instructions documented here?

Thank you.

 

[4u123]

I clicked on EasyApache4 in WHM and clicked the link to follow install instructions. I then ran /scripts/migrate_ea3_to_ea4 --run

I just noticed when I look down the list in multi php manager, there are a handful that are showing as set to ea-php54 despite that version not being installed on the server. I've updated all to use php56 as per the Cloudlinux documentation - however instead of letting CL-selector take over - the multi php manager has now written this to all users htaccess files...

# php -- BEGIN cPanel-generated handler, do not edit
# Set the “ea-php56” package as the default “PHP” programming language.
<IfModule mime_module>
AddType application/x-httpd-ea-php56___lsphp .php .php5 .phtml
</IfModule>
# php -- END cPanel-generated handler, do not edit

I don't want this at all. How can I stop this happening?

The document says...

When PHP version chosen for domain in MultiPHP Manager matches System default PHP version, then PHP Selector is used to select actual PHP version. If PHP version chosen for domain in MultiPHP Manager differs from System default PHP version, then PHP version from MultiPHP Manager is used.

So I have chosen the default version 5.6 for all users ( and 99% of them are using PHP selector) so what SHOULD happen is that multi php manager should not write the handlers and php selector should take over. Did I misunderstand that?

How can I make sure that all those using PHP selector in cpanel get to use the correct version and NOT the multi php manager version? I really need to get this resolved as soon as possble.

 

[cPanelMichael]

I clicked on EasyApache4 in WHM and clicked the link to follow install instructions. I then ran /scripts/migrate_ea3_to_ea4 --run

CloudLinux provides their own EasyApache 4 repo and thus the conversion instructions are different. The correct command for converting a CloudLinux server from EasyApache 3 to EasyApache 4 is:

cd ~; wget https://repo.cloudlinux.com/cloudlinux/sources/cloudlinux_ea3_to_ea4; sh cloudlinux_ea3_to_ea4 --convert

Can you run this command to ensure the system is setup correctly? Also, keep in mind that you are using mod_lsapi, so ensure to follow the instructions documented on the URL below:

CloudLinux Documentation

# php -- BEGIN cPanel-generated handler, do not edit
# Set the “ea-php56” package as the default “PHP” programming language.
<IfModule mime_module>
AddType application/x-httpd-ea-php56___lsphp .php .php5 .phtml
</IfModule>
# php -- END cPanel-generated handler, do not edit

Notice the entry shows "lsphp". CloudLinux recently updated ea-apache24_mod_lsapi to integrate with MultiPHP Manager, and the following case in cPanel version 66 implements support for the LSAPI handler:

Fixed case CPANEL-14021: Add CloudLinux Apache LSAPI handler for MultiPHP.

Can you verify if error messages on your website exist due to those .htaccess entries if the system uses cPanel version 66 and
mod_lsapi 1.1-17 or newer?

Thank you.

 

[4u123]

CloudLinux provides their own EasyApache 4 repo and thus the conversion instructions are different. The correct command for converting a CloudLinux server from EasyApache 3 to EasyApache 4 is:

cd ~; wget https://repo.cloudlinux.com/cloudlinux/sources/cloudlinux_ea3_to_ea4; sh cloudlinux_ea3_to_ea4 --convert

Ok, that's a terrible miscommunication by cpanel. EA4 is a cpanel product, so there's no reason for anyone to assume they would need to run a different script in order to switch from EA3 to EA4. It's a pretty bad oversight for you to point me specifically in the direction of your documentation - which includes no mention of the above.

Can you run this command to ensure the system is setup correctly? Also, keep in mind that you are using mod_lsapi, so ensure to follow the instructions documented on the URL below:

CloudLinux Documentation

I'll give it a go.

Notice the entry shows "lsphp". CloudLinux recently updated ea-apache24_mod_lsapi to integrate with MultiPHP Manager, and the following case in cPanel version 66 implements support for the LSAPI handler:

Fixed case CPANEL-14021: Add CloudLinux Apache LSAPI handler for MultiPHP.

Can you verify if error messages on your website exist due to those .htaccess entries if the system uses cPanel version 66 and
mod_lsapi 1.1-17 or newer?

Yes, the problem with the htaccess entries is not related to lsapi. The problem is two fold... Firstly, that the wrong PHP version was included in the handler -which obviously produces an error when the handler doesn't exist and secondly that the handlers are added at all when Cloudlinux should be taking care of that.

The cause of all of this is the failure of cpanel to communicate correctly how to update to EA4 when using Cloudlinux.

Why doesn't your script exit with an error stating that it shouldn't be run on Cloudlinux?

 

[cPanelMichael]

Hello,

Upon testing, it does look like the EasyApache 4 conversion script is now updated (as of cPanel 58) to properly detect CloudLinux systems and ensure the CloudLinux repositories are utilized. Could you open a support ticket using the link in my signature so we can take a closer look at your system and see why the .htaccess entries are resulting in your websites failing to load (and determine if those entries are not properly added or removed)?

Thank you.