EasyApache 4
Forum
  1. Forums
  2. CloudLinux and Control Panels
  3. CloudLinux and cPanel
  1. Karl Fleming
  2. Tuesday, 13 January 2015
  3.  Subscribe via email
Upcomming EasyApache 4 Announcement
Rate this post:
  1. 18.08.2016 12:08:32
  2. # 61
Mike Tindor Accepted Answer
Posts: 35
Joined: 08.11.2013
0
Votes
Undo
I agree with Karl.    A few things concern me.

1.   cPanel has a "hardened" kernel available now, meant to deal with the symlinks issue
2.   cPanel has EA4 + MultiPHP (to deal with the longtime outcries for support for multiple versions of PHP)

CloudLinux had all of this taken care of a couple years ago.   Sure, in order for people to benefit they had to pay for a CL license and install CL.   And I do understand that cPanel likely has many many customers who do not use CL.  So naturally cPanel had to come up with something to appease their customers who do not use CL.

But now there is a huge base of CL users, including a likely huge base running CageFS+PHP Selector.     All of us who have adopted PHP Selector are used to it.   Whether we love it or hate it, when compared to what is currently offered [and being marketed as production quality] by cPanel cannot compare to the ease of configurability of accounts with PHP Selector.     I don't want to have to move away from PHP Selector.   In the past [Igor, I believe] mentioned that at some point down the road, when CL felt that EA4+MultiPHP was refined enough, that CL may drop their PHP Selector.    I would certainly like to know if this is still something that CL is planning to do in the future.   And, if so, how far into the future can be expect continued full-blown PHP Selector support to continue?

Early on cPanel seemed to encourage/nudge its customers toward adopting CloudLinux (likely because of security).   But now, I just get this feeling that there is a disconnect between cPanel / CloudLinux as far as their future together.

I understand that EA4 is inevitable.   I just have to wonder if hosts who hosts hundreds or more accounts per server will ever be able to have confidence in the EA3/EA4 conversion, or we all simply need to plan for/expect a lot of breakage and then feel relieved and lucky if we do not experience issues.     And when (not if, but when -- we will have no choice) we do migrate to EA4, if things start breaking are we going to need to contact cPanel or are we going to need to contact CloudLinux?

Before I even attempt to do an EA4 conversion,I need to know up front whose door I will need to bang on for assistance, and I'll need to know that they are ready to support the hell out of us during that process so that our customers' sites aren't down for 15 hours.

Nothing in the documentation for EA4, either through cPanel or CloudLinux, gives me any confidence of a smooth migration.    And if I shouldn't expect a smooth migration, then one / both companies should be documenting things that could / likely will go wrong and how to fix them so that we, as admins, can act quickly to fix any issues that arise.

After all, we aren't privy to information regarding how badly a migration has went, what kinds of things needed to be done to fix it, etc.    If an EA3 to EA4 migration isn't bulletproof, then we need to have some documentation to guide us through fixing things while we await help from cPanel or CloudLinux.   After all, you never know if somebody is going to pick up your ticket in 5 minutes or 5 hours.

Listen, I love CL.   I can sleep at night with CL.    I haven't had a server crash in ages, I haven't had resources run away in ages.   Machines consistently perform at a certain load level and never really fluctuate.   It's a beautiful thing.   I have nothing but good things to say about CloudLinux.   And I absolutely realize that everytime something is changed in EA4 (or the EA3-->EA4 conversion process) by cPanel, CloudLInux is stuck having to catch up with those fixes/changes after the fact.   I can't fault CloudLinux for that.

I would, however, like to hear CloudLinux respond with their thoughts on the EA3-->EA4 conversion, common issues that arise during such a conversion, and also give us some sort of guarantee on how long PHP Selector will be supported into the future.

Mike
  1. 18.08.2016 13:08:26
  2. # 62
Igor Seletskiy Accepted Answer
Posts: 1200
Joined: 09.02.2010
0
Votes
Undo
The EA4 support should become production ready within weeks. As you know - we tend to keep things in beta for a long time -- until they are mature.
We have A LOT of people running EA4 already. It works, it works very well. We still encounter some minor things like:
* We have reported that apache configured to run on 8080 was reconfigured to run on port 80 after the upgrade. So far we cannot replicate it, not sure what caused it
* mod_lsapi treats php.ini files in subdirectories differently from suPHP, which creates issues with MultiPHP (but not with PHPSelector/EA4) - fixed, in testing

Within last two weeks, we solved about ten other small issues like that. Some of them (most of them?) are not even related to CL, but to EA4 itself, and would be there on CentOS as well. It is just that we are very particular about naming things 'production'.
Yet, we are pretty much at the end of the beta cycle. The rate of new errors dropped dramatically, while the number of people upgrading is speeding up with every day.
  1. 18.08.2016 13:08:59
  2. # 63
Mike Tindor Accepted Answer
Posts: 35
Joined: 08.11.2013
0
Votes
Undo
Thanks for the update on EA4, Igor.    Personally, I figured it would be quite a while for EA4 to be out of beta.  I've been using optimumcache for a long time now, and it's still in beta even though it's been working wonderfully for me in production.

Can you elaborate on my question about long-term support of  PHP Selector?   At this point in time, are you able to say how long CL will continue to provide PHP Selector?    In the past you had suggested that, in the future if you felt MultiPHP worked as well as / provided equivalent features as PHP Selector, then CL might consider dropping development of PHP Selector.

So I'm just wondering if we can expect to have PHP Selector available to us for years, or if we will be stuck in a year having to migrate people from PHP Selector to MultiPHP.

Mike
  1. 18.08.2016 13:08:14
  2. # 64
Igor Seletskiy Accepted Answer
Posts: 1200
Joined: 09.02.2010
0
Votes
Undo
We will continue to provide PHP Selector until:
- MultiPHP has the same functionality (that might never happen)
AND
- we have easy/transparent migration from PHPSelector to MultiPHP

We are not going to abandon it in any way or form.

At this stage we made PHP Selector to work with MultiPHP (like you can select one way or the other, etc...)
  1. 18.08.2016 13:08:21
  2. # 65
Mike Tindor Accepted Answer
Posts: 35
Joined: 08.11.2013
0
Votes
Undo
You guys are rock stars!

Tnx

Mike
  1. 18.08.2016 14:08:23
  2. # 66
Karl Fleming Accepted Answer
Posts: 19
Joined: 08.06.2014
0
Votes
Undo
They ARE rock stars and their ideas and code are fantastic.

I just wish they would remember to let us mere mortals know what was going on from time to time, instead of us having to make provocative posts to elicit some scraps of information. :D I think they need some extra Public Relations staff to cope with us Grumpy Old Men !

Having said that, I shall now crawl back under my rock for a few weeks - my very best wishes to all the CL team
Kindest regards
Karl Fleming
  1. 18.08.2016 14:08:37
  2. # 67
Mike Tindor Accepted Answer
Posts: 35
Joined: 08.11.2013
0
Votes
Undo
Karl,

You're probably right about public relations.   I'm glad that Igor responded though, and I have confidence that they won't leave us hanging.    Now I need to go find somebody else to complain to :)

Mike
  1. 07.09.2016 14:09:40
  2. # 68
Karl Fleming Accepted Answer
Posts: 19
Joined: 08.06.2014
0
Votes
Undo
So there I was, contemplating CloudLinux and Existentialism, and I have to wonder if there isn\'t an easier way of going about an RPM based web server.

Why not just ignore \"EasyApache 3/4/dream-on\" and produce an RPM based, optimized, CloudLinux httpd (Apache, nginx - whatever works best) that can be installed as an alternative to EA and fully supports (enhances?) CageFS, LVE and PHP Selector, and is updated by Yum once a day as necessary as part of upcp ?

Am I missing something here ? It seems such a simple solution, but maybe I haven\'t grasped the intricacies of the EA httpd integration into cPanel.
  1. 04.10.2016 15:10:01
  2. # 69
Karl Fleming Accepted Answer
Posts: 19
Joined: 08.06.2014
0
Votes
Undo
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\'t 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\'t 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.
  1. 05.10.2016 04:10:00
  2. # 70
Dave Accepted Answer
Posts: 9
Joined: 09.12.2014
0
Votes
Undo
I\'ve 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\'t make sense, UI that doesn\'t 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\'re on CloudLinux, they are doing their own distributions of EA4. Check this out for more info: https://cloudlinux.com/blog/entry/beta-easyapache-4-released-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. I\'m 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\'t 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 WHM\'s EA3 to CL\'s EA4 that doesn\'t 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.

I\'ve pretty much chewed all my fingernails off down to the skin at this point :(
  1. 05.10.2016 04:10:47
  2. # 71
Baby Accepted Answer
Posts: 23
Joined: 04.10.2012
0
Votes
Undo
@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!
  1. 05.10.2016 05:10:43
  2. # 72
Dave Accepted Answer
Posts: 9
Joined: 09.12.2014
0
Votes
Undo
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 CPU's, 64GB RAM, Dual 1TB SSD's) it's 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 can't be the only small host who would have financial difficulties with it.

Additionally, in my case, there's an extra consideration - I'm right in the process of assigning / announcing my own /24 subnet, which means I'm 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 isn't exactly a small feat since the main shared IP's are basically bound to the hardware. And since a good portion of my customers are e-commerce sites with dedicated IP addresses, that's a lot of IP changing and propagation to schedule in addition to the downtime involved in completely swapping out the data center's IPs for my own IPs. (I've 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, they'd rather lose me than lose the guy hosting spam servers, so I'm basically forced to get my own IPS and go through this nightmare).

I realize that bit isn't your problem or CL's problem, but in the end it's 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 I'd 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!
  1. 05.10.2016 06:10:28
  2. # 73
Baby Accepted Answer
Posts: 23
Joined: 04.10.2012
0
Votes
Undo
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.
  1. 05.10.2016 08:10:46
  2. # 74
Karl Fleming Accepted Answer
Posts: 19
Joined: 08.06.2014
0
Votes
Undo
OK Hang on just a min :D

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\'t 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\'t 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.
  1. 05.10.2016 08:10:20
  2. # 75
Baby Accepted Answer
Posts: 23
Joined: 04.10.2012
0
Votes
Undo
Dave\'s issue seems to be caused either in full or in part by the fact that cPanel\'s Native PHP package is being used by default. While that isn\'t 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 CloudLinux\'s PHP packages.

@Karl: With this in mind, do you happen to have cPanel\'s 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?
  1. 05.10.2016 08:10:46
  2. # 76
Mike Tindor Accepted Answer
Posts: 35
Joined: 08.11.2013
0
Votes
Undo
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 weren't behaving as I had hoped, I contacted cPanel.   They were all about helping until they discovered that my CloudLinux license wasn't purchased through them.  As soon as they realized that, they simply said "you'll have to contact CloudLinux for support".   Granted, in the end it did end up being a CL issue (mod_lsapi wasn't 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 don't 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 I'm 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 concern's on cPanel's 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 haven't yet had CloudLinux point the finger at cPanel, but if they do I wont like it -- but I'll 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, I'm 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.   It'll save you a lot of hassle and disappointment of having a company tell you that they can't help you even though they made the product that broke everything.

Mike
  1. 05.10.2016 09:10:57
  2. # 77
Karl Fleming Accepted Answer
Posts: 19
Joined: 08.06.2014
0
Votes
Undo
Hi Mike,

I hear and respect what you are saying..... but guess what ? I DON\'T CARE

It doesn\'t 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 ?
  1. 05.10.2016 09:10:55
  2. # 78
Igor Seletskiy Accepted Answer
Posts: 1200
Joined: 09.02.2010
0
Votes
Undo
I am sorry - but at this point, I just don't 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 don't 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 don't 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.
  1. 05.10.2016 14:10:30
  2. # 79
Karl Fleming Accepted Answer
Posts: 19
Joined: 08.06.2014
0
Votes
Undo
So I'm 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 CloudLinux's uses the setuid bit. Detect both cases properly.  Unfortunately, the fix doesn't 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. :D
  1. 06.10.2016 12:10:25
  2. # 80
Igor Seletskiy Accepted Answer
Posts: 1200
Joined: 09.02.2010
0
Votes
Undo
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?


There are no replies made for this post yet.
Be one of the first to reply to this post!
Guest
Submit Your Response
Upload files or images for this discussion by clicking on the upload button below. Supports gif,jpg,png,zip,rar,pdf
• Insert • Remove Upload Files (Maximum File Size: 2 MB)
Captcha
To protect the site from bots and unauthorized scripts, we require that you enter the captcha codes below before posting your question.