All of my machines are [currently] CentOS6 boxes converted to CloudLinux, running cPanel (WHM 64). Because of cPanel’s new policy on LTS releases, WHM 64 will not go into LTS. That means that as soon as WHM 66 is in Stable, if one wanted to stay on WHM 64 they would receive no future security updates. If I want to update to WHM 66 as it comes into Release [and I do], my servers have to be running EasyApache 4, since EasyApache 3 is not supported in WHM 66.
Given that, and the fact that the EasyApache 3 support has been deprecated and is scheduled to be removed altogether at the beginning of 2018, I figured I better get moving on doing some EA3–>EA4 migrations.
( EA3 Deprecation update – https://blog.cpanel.com/its-been-a-long-road-but-it-will-be-time-to-say-goodbye-soon/ )
My boxes run CloudLinux / CageFS / Alt-PHP / PHP Selector. “Native” PHP is not used and is disabled. I rely completely on CL’s Alt-PHP and PHP Selector. My EA3 PHP Handler is suphp. But of course I have mod_lsapi enabled serverwide.
So I downloaded/executed the EA3–>EA4 migration script from CloudLinux. On this first box I did (dedicated customer, 16 users) it took 10 minutes all told.
cd ~; wget https://repo.cloudlinux.com/cloudlinux/sources/cloudlinux_ea3_to_ea4
sh cloudlinux_ea3_to_ea4 –convert –mod_lsapi –altphp
When I was done I had to do a few things.
- Enable mod_lsapi globally
For whatever reason, even though ea-mod_lsapi was installed, it didn’t automatically enable globally in EA4 even though it was globally enabled in EA3. So I had to do this:
/usr/bin/switch_mod_lsapi –enable-global (and then restarted Apache)
This took care of the mod_lsapi issue. All sites were running mod_lsapi like they should.
- Then I had to copy over my old vhost includes.
In EA3, your vhost includes are in /usr/local/apache/conf/userdata/std/2 and /usr/local/apache/conf/userdata/ssl/2. In EA4, your vhost includes are in /etc/apache/conf.d/userdata/std/2_4 and /etc/apache/conf.d/userdata/ssl/2_4. So I had to copy my old includes (which were available in /usr/local/apache.ea3/conf/userdata/std|ssl/2 directories after I migrated to EA4) to the new location.
I then ran:
/scripts/ensure_vhost_includes –all-users
/scripts/rebuildhttpdconf
/scripts/restartsrv_apache
That took care of my vhost includes
Everything is working fine. No problems that I’m aware of, and no complaints by customers.
- Remember that the whole structure for Apache has changed.
old: /usr/local/apache
new: /etc/apache2
- Remember to ensure your modsecurity rulesets are loaded and working afterwards.
Summary:
If your configuration differs much from this, you will have to dot a lot more I’s and cross a lot more T’s. If you are using “Native” PHP, remember that /usr/local/lib/php.ini (native global php.ini file in EA3) is now duplicated to /opt/cpanel/ea*/root/etc/php.ini, where ea* is each version of MultiPHP that is installed during the migration.
Also remember that during the migration of the old global php.ini to the new location, the migration process comments out any references to ioncube loaders, zend, etc. You will need to manually massage your global php.ini files for each (MultiPHP) version of PHP you have installed, in /opt/cpanel/ea*/root/etc/.
I chose to completely disable the MultiPHP Manager and MultiPHP ini editor (which you disable in WHM –> Feature Editor), as my customers [and I] only wish to use CloudLinux Alt-PHP and PHP Selector. You don’t want to keep these enabled if you aren’t using EA4s versions of PHP because it will simply confuse your customer.
If you are reading this, keep in mind that your experience will almost certainly be different if your system is not configured exactly like mine are. So do not use this post as an instruction manual for migrating from EA3 to EA4. This post is mainly here for my own personal documentation. If it helps somebody out, awesome. If not, it’s no skin off of my ass.