EasyApache 4

[karl]

Any news on any of this ?

With cPanel version 60 about to be released to current, and support for EA3 depreciated and due for removal in 62, and cPanel targeted major release cycle down to 3 months ....... we seem to be rapidly running out of time !!

Please let us know what is going on. We have enough to worry about with just supporting our customers, Brexit, EU legislation and just keeping ones head above water without having to expend so much time and effort searching for clues as to what the next upgrade disaster to befall us might be.

As I have said before - this is our lives and livelihoods you guys are playing with - some of us don work for multinationals and cant afford the time or $$ to go play at one of your conventions where one MIGHT stumble across some answers.

Maybe the plan all along is to force out and get rid of all the small independent hosting companies and just take care of the big players - it certainly seems to be working from the number of hosting companies I am seeing collapse each week due to the inability of the tech staff to keep up with what cPanel and apparently Cloudlinux are doing (although since Cloudlinux isn telling us anything its hard to know)

I am beginning to regret ever switching from Plesk to cPanel/Cloudlinux now ..... and Plesk was dreadful at the time ! (Probably still is)

Wish I could extend my warmest regards, but I am too unhappy and concerned to do so with any sincerity.

[dave518]

Ive got to say... even though I have immense respect for the staff at CloudLinux and I think they provide excellent support in almost all cases, the issues surrounding the switch fr om EA3 to EA4 have been beyond stressful and my results from upgrading one server from EA3 to EA4 were so bad (broken scripts, badly formatted php.ini files, customers with sites down, parameters that don make sense, UI that doesn allow for re-compiling with all the same / proper modules the way we could in EA3, etc...) that I ended up switching back to EA3 just to survive and not lose customers. One of the craziest things that happened was that, even though my servers were already set to PHP "5.6 Native" with EA3 and everything was working fine, as soon as I followed the steps to switch to EA4 with "5.6 Native" it broke all WordPress sites and most other PHP scripts, and I had to manually switch all user accounts from PHP "5.6 Native" to just PHP "5.6" non-native in the PHP Selector to even get things working somewhat correctly.

One extremely frustrating factor in all of this is that in support ticket discussions with CloudLinux and cPanel it looks like one side just blames the other.

When I reported some issues to CloudLinux, a couple of the responses I got included the statements:

"Easyapache4 - a new product of cPanel. Therefore, some of the options look different."
"easyapache4 it is cPanel product, so settings for native php.ini are beyond our control."
"If you want to know about it - please contact cpanel."

And yet what cPanel says is:

"As you
e on CloudLinux, they are doing their own distributions of EA4. Check this out for more info: https://cloudlinux.com/blog/entry/be...for-cloudlinux "

Which begs the questions - why is CloudLinux making it seem as if this EA4 is a cPanel product, while cPanel is making it seem as if this new EA4 is a CloudLinux product? And if the WHM EA3 is what I started with and what worked fine, while the instructions to switch to EA4 are from CloudLinux and that is wh ere problems occur, then whose EA4 are we talking about? Is it CloudLinux EA4 or cPanel EA4?

When I brought this issue up in a support ticket and asked candidly - "What happened between cPanel and CloudLinux to make things suddenly dysfunctional?" - that question was quietly ignored.

Up until all of this, my experience with CloudLinux has been great. Like I said, the support staff at CloudLinux have been great (prompt, courteous, helpful) and CL is clearly an excellent product, but this whole situation with the switch to EA4 creating some major issues, and the ping-ponging back & forth between CloudLinux and cPanel to try to get solutions as they point the finger at each other has become a source of great stress for me. Im in the midst of some very important changes to my small hosting service, changes that are already creating some unrest with my customers, and so I can bear to endure another day-long episode of service / site interruptions that will upset my customers. If I lose any more I will be facing very hard times, and I have over 20 years of my life invested in my small shared hosting service. It is my entire livelihood.

If anyone has come up with a straight-forward smooth approach to switch from WHMs EA3 to CLs EA4 that doesn create a huge disruption and necessitate a mass scramble to try fixing all the bugs, fixing all the php.ini settings that get derailed in the process, I hope that you will please share it here.

Ive pretty much chewed all my fingernails off down to the skin at this point

[cloudlinux.com]

@Karl and @Dave, thank you for sharing your stories.

We have not touched EA4 just yet, but here’s what we would do if we were in your shoes:

First of all, we haven’t used PHP 5.6 Native pretty much since we started using CloudLinux years ago. We have Native deactivated, and only activate the PHP packages that come with CloudLinux.

We haven’t seen CloudLinux’s (a.k.a. non-native) PHP packages causing any unexpected issues with WordPress and other sites.

So that’s the first thing you’d want to try — switching away from Native (whilst still on EA3) one site at a time to work out any kinks, and then ultimately deactivating it altogether on the server.

Doing so means the CloudLinux team would then actually be able to advise you on any issues that you might encounter whilst working out the kinks, since you would be using CloudLinux’s PHP packages, and not cPanel’s Native PHP.

Once the kinks are worked out and you’re successfully using CloudLinux’s PHP packages on EA3 for all of your clients, you could then try migrating to EA4.

But again, to prevent any potential issues from affecting all clients on the server, we wouldn’t recommend performing such a conversion on the same server!

Instead, we would perform WHM transfers of accounts from a EA3 CloudLinux server to an EA4 CloudLinux server, one at a time, monitoring and working out any kinks, and then once everything looks fine, perform mass WHM transfers to finish up the rest.

I hope this makes sense. Let us know how it goes!

[dave518]

Thank you for the reply Baby,

You had me right up until this part:

>> But again, to prevent any potential issues fr om affecting all clients on the server, we wouldn’t recommend performing such a conversion on the same server!
>>
>> Instead, we would perform WHM transfers of accounts from a EA3 CloudLinux server to an EA4 CloudLinux server, one at a time, monitoring and working out any kinks, and then once everything looks fine, perform mass WHM transfers to finish up the rest.

In a perfect world we could all afford to purchase spare servers to have just sitting around waiting to test a migration to, but in my world it would be a big impractical expense, considering that the type of hosting I provide / type of clientele I cater to requires that I run beefy servers (Dual E5-2620v3 CPUs, 64GB RAM, Dual 1TB SSDs) its just not financially feasible to open a "spare" server to pay extra for during yet another migration process after just recently spending months migrating away from RHEL servers to CL 6.7 servers.

And while that scenario might not be a problem for everyone, I cant be the only small host who would have financial difficulties with it.

Additionally, in my case, theres an extra consideration - Im right in the process of assigning / announcing my own /24 subnet, which means Im disassociating all current IP addresses on my servers and ARPing / assigning the new ones. As you probably know, re-assigning the main IP addresses to servers isnt exactly a small feat since the main shared IPs are basically bound to the hardware. And since a good portion of my customers are e-commerce sites with dedicated IP addresses, thats a lot of IP changing and propagation to schedule in addition to the downtime involved in completely swapping out the data centers IPs for my own IPs. (Ive had the misfortune of receiving a bunch of bad IPs in "bad neighborhoods" from the data center wh ere I lease my servers, and the client who owns the "bad behaving" servers in the same current /24 subnet as mine is a big money customer to the data center, theyd rather lose me than lose the guy hosting spam servers, so Im basically forced to get my own IPS and go through this nightmare).

I realize that bit isnt your problem or CLs problem, but in the end its just cost-prohibitive to lease extra new servers while we struggle to pay for the ones we have. It would be different if data centers would provide an extra server for free for a month, in which case Id do exactly what you recommend.

But how about a feasible solution for struggling small hosts?

Thank you for your response and intent to help, I truly appreciate it!

[cloudlinux.com]

I suppose what I’d do in that case would be to sign up for a small SSD VPS for 1 month, have it set up to run EA4 CloudLinux, then transfer a couple of your typical accounts onto it from the EA3 server and see if anything breaks (both running CloudLinux PHP packages with Native PHP deactivated).

If something breaks, I would contact CloudLinux support so they could help iron out any remaining issues.

If nothing breaks, or after the issues are resolved, I would transfer the sites back, cross my fingers and proceed with an on-server switch from EA3 to EA4 once cPanel reaches version 60 on the stable tier.

[karl]

OK Hang on just a min

We are PAYING for software that is fundamental to our business. We should not have to then pay more to run test environments - in fact - we should not have to test at all !!

Since I don try and be clever and run anything that is not included by default in cPanel and Cloudlinux, my perspective to both cPanel and Cloudlinux is "you break it - you fix it for me free of charge"

I don expect to be treated like a development guinea-pig nor have to bugfix software I pay for (I could be using a well known software from Redmond if I wanted to do that :| )

Come on guys - just give us something that works and we can get on with our lives and trying to stay afloat.

[cloudlinux.com]

Daves issue seems to be caused either in full or in part by the fact that cPanels Native PHP package is being used by default. While that isn supposed to be causing any issues to begin with, it does make it harder (if not impossible) for CloudLinux to troubleshoot or fix until he switches over to CloudLinuxs PHP packages.

@Karl: With this in mind, do you happen to have cPanels Native PHP activated by default as well? If not, what kind of issues did you run into when you tried to switch from EA3 to EA4?

[mtindor]

In planning your EA3/EA4 upgrade, be sure to have a full understanding of who is responsible for handling support for (a) your cPanel license and (b) your CloudlLinux license.

I had obtained a developmental cPanel license and a 30-day trial license of CL and then built a VM just to do the testing. When things werent behaving as I had hoped, I contacted cPanel. They were all about helping until they discovered that my CloudLinux license wasnt purchased through them. As soon as they realized that, they simply said "youll have to contact CloudLinux for support". Granted, in the end it did end up being a CL issue (mod_lsapi wasnt enabling -- the server-wide mod_lsapi would not enable itself because whatever was supposed to uncomment the appropriate line in lsapi.conf did not).

I have cPanel licenses and CL licenses through cPanel direct. Nowadays I also have of servers whose licenses are issued through the datacenter I use. I dont have any faith that cPanel will support me during any EA3/EA4 migration -- I believe they will tell me to contact my datacenter if I have an issue with either cPanel or CloudLinux during an EA3/EA4 migration. I might be wrong. But Im throwing this out there so you all make sure you have the proper support lined up and ready for you to contact should the need arise.

You all should make sure to air your concerns on cPanels forums, not just CloudLinux forums. Why? EA4 is indeed a cPanel creation. cPanel is the one requiring the conversion from EA3/EA4. Cloudlinux is left having to make adjustments [as often as cPanel makes adjustments to their product] in order to keep up with those changes.

I havent yet had CloudLinux point the finger at cPanel, but if they do I wont like it -- but Ill understand. In the end, everything we [and CL] are going through related to EA4 are because of a product pushed upon us all by cPanel, that product being EA4.

In the end, once everybody is using EA4 a couple of years from now, Im sure everything will be grand again. But for those of us having to deal with one or more EA3/EA4 conversions, we are just going to have to make sure we have the proper support lined up. Make sure you know who is ultimately on the hook to support both your cPanel license and your CloudLinux license on a particular server. Itll save you a lot of hassle and disappointment of having a company tell you that they cant help you even though they made the product that broke everything.

Mike

[karl]

Hi Mike,

I hear and respect what you are saying..... but guess what ? I DONT CARE

It doesn matter who I pay cPanel/Cloudlinux THROUGH - they ultimately get paid !

If the game is to pass blame/support/liability off to some 3rd party whenever, however, and as soon as, possible, there is something very wrong with the ethics and morality of those involved.

And if the staff here at Cloudlinux are comfortable with that ethic and moral code ....... do I have to elaborate ?

[iseletsk]

I am sorry - but at this point, I just dont understand the complaint
1. We have a lot of people upgraded from EA3 to EA4 by now; the process is smooth, and for the past few weeks, there are no tickets.
2. Regarding PHP.ini --> the only issue I know about is when cPanel support incorrectly pointed to the customer that this is how it works on CL, it must be their bug - it works differently on CentOS". After our joint investigation --> we found out that it works exactly same way on CentOS. I still dont know if they consider such behavior a bug or a feature, but I guess it is very rare. Either way -- it is the behavior of EA4 in general, not related tp CloudLinux.

Now, I know that you might not like EA4, think that it is buggy, bad, etc... but there is no difference in bugginess of EA4 right now between CentOS & CloudLinux. None. Our build system, upgrade scripts, migration scripts, etc. all had been well tested by us and by our customer base by now. A lot of people used the process, and all latest complaints were issues with EA4 itself.

Regarding the answers from the support team -- if you dont like them -- PLEASE, PLEASE, PLEASE, always rate them low. VERY LOW. Any ticket that is ranked low automatically gets escalated to the head of support, gets reviewed; support team tries to correct the issue, and once every two weeks I discuss with support any ticket with less than four stars. Each and every ticket that receives 1 to 3 stars gets reviewed by me personally. We often make adjustments to support answers and how we deal with such situations when we get such tickets.

[karl]

So Im told I worry too much. Its probably true. I worry about my Boss and his company. I worry about my ability to run his servers, and most of all, I worry about our customers and the trust they put in us to keep their websites up and running.

Then there are the small worries, like EA4 which I have only been worrying about since I started this thread back in January 2015.

So after reading Mikes excellent advice, and Igors incredulity, I decided to hold my nose and pull the chain.

Non of my sites used the cPanel default PHP – all were on alt-php and I even had the cPanel native PHP disabled.

I followed the instructions at the Cloudlinux Migrating to EasyApache 4 page and ......well.......(it should come as no surprise to Igor).....it worked beautifully !

There was some inevitable tidying up of some domains to do, principally in changing htaccess defined AddType Application lines to reflect the new php paths but that was quickly sorted.

The cron jobs all seem to work (I shall know more after 24 hours) and the inevitable Suspicious Process alerts from CSF needed the new php-cgi executable paths adding to the csf.pignore file.

An irritation was observed from the security advisor reporting suEXEC is disabled. The cPanel forums mention Case CPANEL-7731: The cPanel EA 4 suexec binary uses capabilities, but CloudLinuxs uses the setuid bit. Detect both cases properly. Unfortunately, the fix doesnt seem to be scheduled until v 60 which is only just about to hit current – so we may have to wait and worry a bit more about that (what a relief I found something to continue worrying about).

So a huge thank you to Mike, Igor and everyone that contributed to this thread and worked on the EA3 to EA4 migration process. You guys are all rock stars and you still forget that us mere mortals need to be hugged and reassured and cosseted sometimes.

[iseletsk]

Karl,

Thank you for the feedback.
Regarding this issue with .htaccess files, could you give a bit more info.
What were the old PHP paths, and what are the new ones?

[karl]

Hi Igor,

We found a number of websites that used embedded php in html and had added

AddHandler application/x-httpd-php5 .html .htm

into their htaccess files

After the conversion to EA4, most of these sites just attempted a file download in a browser, or at best, were missing the php controlled items like menus

We changed the code in the htaccess files to

AddHandler application/x-httpd-ea-php56 .html .htm

which seemed to fix everything, but maybe there is a better way (we were most concerned at getting sites back on line with minimum down-time)

[iseletsk]

Thank you. I guess old handler is gone. Not sure what is better - preserve old handler -> but what to point it to, or deal with manual changes.

[karl]

From the time I spent in the development of a well known php program, anything that is left over in an attempt to fix a legacy compatibility, gets forgotten and comes back to bite you at some later stage.

Personally, and I do understand that I dont have to deal with possibly thousands of broken sites, unless one can have a clear road-map of temporary fixs that will be positively removed in a pre-defined future release - I would rather that nothing of the old is preserved and one has a clean fresh platform.

I hate change - it makes me worry and ruins my appetite, but nevertheless, we need to progress forward (so we are told) and embrace new things !!

I do wonder if much of what we are seeing is change for changes sake, followed by clever marketing to convince us that we now cant live without a new "whatever" that we didnt even know existed, or that we desperately needed it. Life used to be much simpler before the internet