cPanel (the company) — Slow The Fuck Down!

As of this writing, most reputable hosting companies using cPanel software are likely on some combination of WHM 11.52, “54” or “56”.    “58” is now in Release, and “60” is in development.

Why are hosting companies behind on versions?    Because cPanel is pushing technologies into production that are not ready for production use, most obvious being EasyApache 4 ( EA4 ).

cPanel itself had never provided adequate protection for symlink attacks, nor did it provide an adequate jailed environment [at least in my opinion].   CloudLinux came along and saved the day.    Thousands upon thousands of hosting companies flocked to using CloudLinux in combination with their cPanel shared hosting to protect their servers / customers / data.   CloudLinux brought out Alt-PHP (with the PHP selector, allowing you to select any one of a number of versions of PHP) a couple of years ago.    There was no sign at the time that cPanel was going to try and do something similar.   In fact, when people would bring up the idea of multiple PHP versions in feature requests and such, it pretty much seemed to fall  upon deaf ears.

Now, way after all of the sensible admins have switched to CloudLinux with PHP Selector in their cPanel environments, cPanel is pushing hard to get EA4 (EasyApache 4) into production with its own version of multiple PHP support (MultiPHP).    This is a royal clusterfuck.

Not only is EA4 not ready for production on any server that currently hosts 100s or more domains, but cPanel is pushing hard to EOL EA3 (with “60” being the last version of WHM to support EA3).

A few thoughts:

cPanel is pushing out versions too quick, is bringing on new “features” before they are ready for a production environment, and forcing hosting companies to totally scramble and panick trying to think of ways to convert their userbase to EA4, be ride of CentOS 5 and CentOS 6 32-bit, etc.

cPanel started the whole MultiPHP thing too late.    I think that before we ever knew that cPanel was developing support for multiple PHP versions, CloudLinux already had delivered production-ready multiple PHP versions.

CloudLinux’s PHP Selector setup was a learning curve for many, including myself.   And I think that most of the admins using CloudLinux + CageFS + PHP Selector are now loving it once we’ve gotten used to it.   Now cPanel is throwing MultiPHP into the mix.

It’s obvious from the posts I see on the cPanel forums that EA4 is not ready for prime time yet.   There are some horror stories out there from admins who have converted to EA4 thus far.   And so far those reports seem to be from admins who aren’t using CloudLinux’s PHP Selector.    I can only imagine that the nightmares will become much worse for admins using CloudLinux’s PHP Selector to convert to EA4 without issues.

cPanel really needs to slow down and make absolutely positively sure that the switch to EA4 is painless for all admins, whether they are running CloudLinux + PHP Selector or not.

I think cPanel’s take is that it’s CloudLinux’s burden to figure out how in the hell to make PHP Selector work in an EA4+MultiPHP environment.   However, it is unrealistic in my mind to expect CloudLinux to work that miracle when cPanel’s EA4 isn’t refined enough for use in Production.

Now, I’m sure there are hundreds if not more new cPanel servers coming online every day, and I’m sure that WHM 58 is being deployed by default on them with EA4 and MultiPHP.   And I imagine those brand new servers will do just fine.  What I’m concerned about is all of the admins running (a) EA3 who need to convert a server with 500+ accounts to EA4 and (b) those admins who are running CloudLinux + PHP Selector who need to convert a server with 500+ accounts to EA4 AND be able to continue to use PHP Selector without issue.

Then I have to wonder what CloudLinux’s long term plans are since they and cPanel will both be devoting a lot of development time to their versions of multiple PHP support.   Is CloudLinux going to bail out of the multiple PHP version race because cPanel is now doing it?   I sure hope not.   I trust CloudLinux’s implementation — I have a tremendous amount of experience with it.   It  just works.   It’s easy to configure.   It has been done right.   It is refined.

Okay that’s the end of my rambling.

4 comments on cPanel (the company) — Slow The Fuck Down!

  1. nice article.

    cPanel broke a good working structure.

    multi php support with CloudLinux works very nicely.

    cPanel is not only the PHP compilation function, apache-php-sided whole system has changed from the beginning and did not take into account the customer has no idea. EA4 forced them to.

    also made it a condition that they provide for their own EA4 only the rpm package. PHP components that will prevent the use of these customers want.

  2. I am leary to try this upgrade. Have any of you tried to do EA4+MultiPHP on top of a CloudLinux MultiPHP yet? I kept asking them whether or not it would have any chance of working correctly (or together) without sharing the same /opt location, but of course those were conveniently ignored.

    Personally, i don’t see how it would. /opt/cpanel/ea-php* is EA4. /opt/alt/php* is CloudLinux. How the F is that supposed to work out?

  3. I have not yet tried an EA3–>EA4 migration. However, I did set up a test server with a development license of cPanel from cPanel, a trial CloudLinux license from CloudLinux. I installed CentOS 7 and then upgraded it to CL 7. I then installed cPanel. I then installed CageFS / lvemanager / PHP Selector.

    A fresh install gives you WHM 58 and EA4 already. So I didn’t have a chance to convert / migrate anything. I did run into an issue, and opened a ticket with cPanel. They then came back and told me that since I didn’t get my CloudLinux license through them, they would not help me and thus I needed to contact CloudLinux. (what a cop-out. It was cPanel’s own staff that encouraged me to set up a test environment. But then when I ran into an issue, they didn’t want to check it out). I contacted CloudLinux, and while their tech was looking into the issue, I found the issue and brought it to CL’s attention. It was a simple fix. My issue was that mod_lsapi wasn’t working. I had forgotten to go and enable it server-wide.

    So, once everything was functioning like my “live” environment, I started testing.

    I copied over a site from a “live” server to the test server, and adjusted my windows hosts file so that when I would browse to the domain on that account, I could view the domain as it exists on the test site.

    I went into WHM –> MultiPHP Manager and set the default system PHP version to PHP 7. Then, in WHM –> MultiPHP Manager I set all of the domains on the account to “inherit”. From there onward, PHP Selector was working fine.

    So far, in order to use PHP Selector:

    1. CageFS must be enabled and the user must be in the cage
    2. In WHM –> MultiPHP Manager the domain’s PHP version must be set to the the same version as the System PHP version. ( )
    3. Make sure that in CL PHP Selector you do _not_ have “native” selected.

    #2 can be accomplished either by setting (in WHM –> MultiPHP Manager) the domain’s PHP version to the specific PHP version that matches the System PHP version (such as PHP 5.6), or by setting the domain to “inherit”. In my case, I will want all of my users’ domains to use PHP Selector, and so I’ll want all domains set to “inherit” so that even if the System Default PHP is changed, my users’ will still be using PHP selector.

    NOTE: If after migration (or on a fresh install) you still have “native” as an option in CL PHP Selector AND you your cPanel account is set to “native” in CL PHP Selector, then it is going to revert back to using cPanel’s MultiPHP.

    This is a very tricky process in my mind, and I can see how at some point the system could get confused about whether a site should be using MultiPHP or PHP Selector. I just cannot imagine an EA3-EA4 conversion will be smooth on a server running CageFS / PHP Selector and hundreds of accounts. Despite cPanel’s best assurances, I just don’t buy into the fact that a ton of hosts have already done an EA3–>EA4 migration on that same exact platform.

    I don’t doubt that the EA3–>EA4 migration would go smooth on a server that is _not_ running CL, or that is _not_ running PHP Selector. But, specifically on a server that is running CL + CageFS + PHP Selector + mod_lsapi enabled serverwide, I think there are going to be a lot of failures.

    And, because PHP Selector is a CL product, I have a feeling that as soon as somebody complains (to cPanel) about a failed EA3–>EA4 migration on a server running CL + CageFS + PHP Selector (+ mod_lsapi enabled serverwide), that cPanel is just going to say “open a ticket with CloudLinux”. Of course, if you bought your CL license through cPanel, I guess they will help you. But be very aware ahead of time that if your CL license is not purchased through cPanel _and_ you are running CL + CageFS + PHP Selector (+ mod_lsapi), you shouldn’t even bother attempting to get support from cPanel if your websites are down after an EA3–>EA4 migration. Instead open a ticket with CloudLinux immediately, so as to avoid the extra wasted time waiting for cPanel to pick up the ticket and then tell you that they won’t help.

    1. Great, I have had some 100 active websites on two of my servers and I made this let’s say painful migration which made me troubleshoot “EVERY SINGLE WEBSITE” of my clients to check what may have caused this mess , and Only Cloudlinux support could help me a little to get out of this burden.

      I’m dealing with this migration for two months and I have some angry customers which prefer to migrate to a NON-Updated server.


Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.