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. 05.08.2016 14:08:21
  2. # 41
Webdomain Accepted Answer
Posts: 6
Joined: 07.04.2015
0
Votes
Undo
Thank you.

I opened a ticket ( #HWU-271-99583).
  1. 08.08.2016 13:08:52
  2. # 42
bettinz Accepted Answer
Posts: 12
Joined: 19.01.2013
0
Votes
Undo
Hello, is that normal that php version are not updated (7.0.8 for example).
Thanks :)
  1. 09.08.2016 00:08:10
  2. # 43
Dave Strydom Accepted Answer
Posts: 5
Joined: 16.04.2016
0
Votes
Undo
With EA4 being stable with cpanel 11.58, is the Cloudlinux integration with EA4 stable yet?
  1. 09.08.2016 06:08:50
  2. # 44
bettinz Accepted Answer
Posts: 12
Joined: 19.01.2013
0
Votes
Undo
I\'m sorry, I don\'t undestand. I\'m using easyapache 4, so I think I need to use easy-apache repository from cloundlinux:

http://repo.cloudlinux.com/cloudlinux/EA4/6/updates/x86_64/

But here I see only 7.0.8

Thanks
  1. 09.08.2016 09:08:22
  2. # 45
Garry Accepted Answer
Posts: 10
Joined: 18.04.2015
0
Votes
Undo
Hi,

As Dave said.
With EA4 being fully released now, is CloudLinux classed as stable with EA4?

Thanks
  1. 17.08.2016 16:08:48
  2. # 46
Karl Fleming Accepted Answer
Posts: 19
Joined: 08.06.2014
0
Votes
Undo
OK Lets go over what we know and where we appear to be at;


  1. EA3 that fully supports CL PHP Selector will expire September 2017 after which there will be no new updates from cPanel sources.
  2. The last cPanel version to support EA3 will be v60 anticipated for September 2016.
  3. Users running EA3 and CL PHP Selector will be blocked from upgrading to cPanel v62 which will release probably in December 2016 / January 2017.
  4. The current EA4/MultiPHP that cPanel supplies in 58.0.20 is rubbish compared to the CL EA3/PHP Selector and looks like it has little chance of ever getting anywhere close to feature parity by the time that EA3 goes EOL.
  5. We have had no news from CL about their spin of EA4 and if it will ever leave the beta development stage, or about anything else to do with this topic (that I started well over a year ago) !!
  6. The disconnect between cPanel staff and their endorsement of CL seems to be widening by the day.



Come on guys, this is our livelihood you are playing with here – at least have the ethics and courtesy to let us know what is happening – even if that is 'not much'
  1. 18.08.2016 12:08:32
  2. # 47
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. # 48
Igor Seletskiy Accepted Answer
Posts: 1201
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. # 49
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. # 50
Igor Seletskiy Accepted Answer
Posts: 1201
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. # 51
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. # 52
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. # 53
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. # 54
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. # 55
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. # 56
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. # 57
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. # 58
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. # 59
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. # 60
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.


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.