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. 01.03.2016 11:03:17
  2. # 21
Baby Accepted Answer
Posts: 23
Joined: 04.10.2012
0
Votes
Undo
Will this work with CloudLinux 6.x or will it require 7.x?
  1. 01.03.2016 12:03:56
  2. # 22
Eduard Drehner Accepted Answer
Posts: 4
Joined: 20.11.2015
0
Votes
Undo
That's encouraging to hear!  :)

Scott, we are going to release EA4 support really soon, Most probably it will be done tomorrow if nothing critical happens.
  1. 01.03.2016 12:03:16
  2. # 23
Bogdan Accepted Answer
Posts: 709
Joined: 26.06.2013
0
Votes
Undo
It will work on both CL6 and CL7 .
  1. 02.03.2016 13:03:00
  2. # 24
Bogdan Accepted Answer
Posts: 709
Joined: 26.06.2013
0
Votes
Undo
We have to delay EA4 support till next week, just got an update from cpanel that brake a part of our functionality :(
  1. 08.03.2016 12:03:38
  2. # 25
Scott Mutter Accepted Answer
Posts: 56
Joined: 23.04.2014
0
Votes
Undo
Do you still anticipate support for this being released this week?
  1. 09.03.2016 15:03:05
  2. # 26
Bogdan Accepted Answer
Posts: 709
Joined: 26.06.2013
0
Votes
Undo
We are really close to release, but I am not sure if it will be done this week. Trying to handle all possible situations including \'What to do if EA4 is installed on CentOS server and someone gonna to convert it to CloudLinux\' .
  1. 11.03.2016 12:03:05
  2. # 27
  1. 14.03.2016 05:03:36
  2. # 28
repa repa Accepted Answer
Posts: 1
Joined: 14.03.2016
0
Votes
Undo
Thanks, but this os only for the testing release of cpanel.

for production not the best option. We need PHP7 and this is only possible with EA4, on CloudLinux this is only possible with testing release of CPANEL.

I think this will not change?
  1. 15.03.2016 12:03:34
  2. # 29
Scott Mutter Accepted Answer
Posts: 56
Joined: 23.04.2014
0
Votes
Undo
Yea, slightly disappointed that this is only for cPanel Edge.  Was hoping to see this for cPanel 54.  But, development has to start some where.  It will be a while before I get to get into this, because I don't run Edge releases on our servers.

I suspect that all of this will come together a bit more once EA4 becomes standard with cPanel.  Which I believe will happen sooner rather than later, now that CloudLinux at least has something for EA4.  The problem is the dual system that CloudLinux has to support (some people run EA3 others run EA4).  As everyone moves to EA4, CloudLinux can stop supporting EA3 and dedicate more resources to their development of EA4.

I'm also a bit disappointed that all of this requires the use of packages in the cloudlinux-updates-testing respository.  But again, development has to start some where.  I am curious as to why alt-php packages have to be installed from cloudlinux-updates-testing.

It would seem to me (again, I haven't tested this I'm just reading through the blog and bash script), the main thing to get from this is the introduction of ea-apache24-mod_lsapi (and alt-mod-passenger) in cloudlinux-updates-testing that is necessary for EA4 based cPanel Apache setups.  [S]With EA3, mod_lsapi was compiled during EA3 updates.  With EA4 an RPM for mod_lsapi had to be provided.  Not sure why this would require alt-php from testing and also not real sure why cPanel Edge is required, but who am I to question this?[/S]

Edit: Woops!  Meant mod_hostinglimits.  With EA3, mod_hostinglimits is compiled.  To move to EA4, mod_hostinglimits had to be provided as RPM, which is now available (ea-apache24-mod_hostinglimits) I'm guessing that is in the new cl-ea4-testing repository.  I'm guessing the difference between ea-apache24-mod_lsapi and cpanel-mod-lsapi is to distinguish between EA4 and EA3.

Bottom line, hopefully we can eventually start seeing things moved out of cloudlinux-updates-testing and into the main repositories.
  1. 22.03.2016 05:03:27
  2. # 30
Pete Accepted Answer
Posts: 11
Joined: 08.11.2013
0
Votes
Undo
Another important thing - it seems cPanel will not provide php 5.3 and php 5.2 support via Multi PHP as per:

https://features.cpanel.net/topic/allow-to-install-multiple-php-5x-versions
https://features.cpanel.net/topic/allow-to-install-php-5-3-in-easy-apache-4

So no EOL PHP versions in Multi PHP as it seems.

I am highly interested on the official Cloudlinux position about this as the initial plans were Multi PHP to completely replace alt-php in time.
Alt-PHP is doing great job with the EOL PHP versions support and with the addition of the Hardened PHP feature, so my best wish would be to stay that way and not get depricated especially when Multi PHP will be a different product altogether... I hope this will not make the EA4-Cloudlinux integration more difficult. What do you think?
  1. 22.03.2016 11:03:32
  2. # 31
Scott Mutter Accepted Answer
Posts: 56
Joined: 23.04.2014
0
Votes
Undo
In my opinion, I don't like the fact that CloudLinux provides backported EOL PHP versions.  PHP versions go end of life for a reason.  If you are using a script that won't run on PHP 5.5, 5.6, or 7.0, then it's very likely that that script is outdated.  What security holes is that script riddled with?

By providing end-of-life PHP versions, you are just catering to that group that doesn't want to upgrade their script and leaving yourself open to potential security threats.

That's my opinion anyway.

I will say that I kind of wish PHP would be a bit longer in their release cycles.  PHP 5.4 had a lifetime of about 3 years.  Perhaps a 5 to 10 year life cycle is just not feasible with a web based development language.  PHP generally does a good job of announcing PHP upcoming end-of-life, so there is that.  But I'm just more of a fan of stability and would prefer to see longer life cycles for products (same is true for scripts, like WordPress).  But I may be the minority.
  1. 22.03.2016 13:03:25
  2. # 32
Pete Accepted Answer
Posts: 11
Joined: 08.11.2013
0
Votes
Undo
Security and stability should always come first, I agree.
However, we are talking about functionality here.
There are different setups, configurations and strategies.
Just try to migrate multiple joomla 1x servers to a non EOL php version and you will see my point.
The rest of the servers can still be up to date though. I am not saying supporting the EOL php versions is the best thing to do but there are situations where there is no choice.
And yes we live in a world where php live cycles are short enough to cause us serious problems and security concerns.
  1. 22.03.2016 13:03:29
  2. # 33
Karl Fleming Accepted Answer
Posts: 19
Joined: 08.06.2014
0
Votes
Undo
In a perfect world, users would update their scripts (like Wordpress) within hours of updates being released, and businesses would keep throwing money at developing new websites that use the latest and greatest PHP releases.

This isn't a perfect world !!

Uneducated bean counters, lazy users, a crippled economy, endless patches, PHP releases that seem to outstrip ones ability to deploy them, dropping website revenues,  are just some of the motivations (or excuses if you like) that influence the decision to defer upgrades to new PHP compatible software.

Whilst never a reason for not patching ones own scripts - at least CloudLinux are back patching EOL PHP versions, and giving companies the chance to catch their breath - where the alternative may well be bankruptcy and closing down - I would say that the CloudLinux initiative in this respect is outstanding !

I should be saddened to see the loss of the legacy PHP versions for the sake of expediency, and might even feel a bit betrayed that the acclaimed cPanel / CloudLinux partnership and cooperation looks to have hit turbulent waters.

Is it just me, or does anyone else share that uneasy feeling in the pit of ones stomach that hints at uncertainty and lack of direction and focus ?

Perhaps there is a perfect and logical road-map and direction for CloudLinux, but it just hasn't been particularly well communicated to the users and supporters.

Either way, in an uncertain and far from perfect world (and being OLD and not liking change)  - I have to agree with Scott regarding stability and longer life cycles. Turning everything on its head every 10 minutes just because one CAN seems to be the overwhelming desire of the "move fast and break stuff" brigade - I am not at all sure it is in everyone's (or perhaps anyone's) best interest.
  1. 22.03.2016 14:03:42
  2. # 34
Bogdan Accepted Answer
Posts: 709
Joined: 26.06.2013
0
Votes
Undo
The position doesn’t change. We expect PHP Selector will be superseded by MultiPHP as no longer needed (once they reach feature parity). We expect MultiPHP to be able to use our alt-php/hardenedPHP, so it would be best of both words. This is our official position.

About EOL php versions - 4.4, 5.1, 5.2, 5.3 and 5.4 already reached their EOL. They become 'Hardened' and will be supported as long as possible by our alt-php packages. There are no end of life for them from our side, that is main purpose of hardened PHP.
  1. 22.03.2016 15:03:02
  2. # 35
Karl Fleming Accepted Answer
Posts: 19
Joined: 08.06.2014
0
Votes
Undo
The position doesn’t change. We expect PHP Selector will be superseded by MultiPHP as no longer needed (once they reach feature parity). We expect MultiPHP to be able to use our alt-php/hardenedPHP, so it would be best of both words. This is our official position.

About EOL php versions - 4.4, 5.1, 5.2, 5.3 and 5.4 already reached their EOL. They become 'Hardened' and will be supported as long as possible by our alt-php packages. There are no end of life for them from our side, that is main purpose of hardened PHP.

Thank you. Your commitment to feature parity is enormously reassuring !
  1. 24.03.2016 07:03:42
  2. # 36
Marcin Kedzia Accepted Answer
Posts: 7
Joined: 18.04.2012
0
Votes
Undo
The position doesn’t change. We expect PHP Selector will be superseded by MultiPHP as no longer needed (once they reach feature parity). We expect MultiPHP to be able to use our alt-php/hardenedPHP, so it would be best of both words. This is our official position. 
About EOL php versions - 4.4, 5.1, 5.2, 5.3 and 5.4 already reached their EOL. They become 'Hardened' and will be supported as long as possible by our alt-php packages. There are no end of life for them from our side, that is main purpose of hardened PHP.


You should not abandon development on PHP Selector. I'm sure there are many people not using EA at all like me. I'm using LSWS and with PHP Selector it's just awesome setup. Lot of flexibility regarding PHP modules configuration (I do not see informations anywhere that MultiPHP will have this functionality) and easy PHP per directory implementation.
It makes me really sad reading that you are planning to abandon this functionality :(
  1. 24.03.2016 07:03:53
  2. # 37
Eduard Drehner Accepted Answer
Posts: 4
Joined: 20.11.2015
0
Votes
Undo
I agree with you Mr. Kedzia. In my case one of the main reasons for even buying CloudLinux  was due to that particular feature; PHP Selector.

Faithfully,
-k0nsl
  1. 24.03.2016 08:03:36
  2. # 38
Dave Accepted Answer
Posts: 9
Joined: 09.12.2014
0
Votes
Undo
After almost 2 decades of using RHEL, a few months ago (in December) I decided to get new servers and switch to CloudLinux. One of the main reasons I made that decision was because of the PHP Selector feature.

At this point I\'m feeling very unsure about how this is all going to play out and how it will affect me / my users. For example, I\'m running CL 6.7 / cPanel / EA3 now and I have PHP 5.5 set as default, but have several users who have custom scripts that require older versions of PHP and custom php.ini, so I saw CL as the safest way to continue to accommodate these users, and so what happens with their config? Is there going to be some type of seamless way to cross them over from PHP Selector to cPanel\'s MultiPHP?

I\'m not quite as savvy with the nuances of custom PHP environments on a per user basis as I\'d like to be and my hope that my recent migration to CloudLinux would be the answer to my frustration with the constant change & tweaking involved in customer retention, especially those who won\'t give up their old custom made scripts and don\'t have a way to expediently make them work past 5.3 or 5.4 in some cases.

Switching to CloudLinux to accommodate those users with the PHP Selector was a key factor in my recent decision to migrate, and now just as I\'m starting to get to know CL now I\'m already feeling like I\'ll be scrambling to spend more time trying to figure out change again.

Am I worried over nothing? Or is this going to be a big transition from the OS that I just started purchasing in the last 4 months?
  1. 24.03.2016 10:03:22
  2. # 39
Scott Mutter Accepted Answer
Posts: 56
Joined: 23.04.2014
0
Votes
Undo
I think all of this (at least as far as CloudLinux + cPanel integration) will eventually move to EasyApache4.  Now whether CloudLinux chooses to maintain their own PHP branches or utilize cPanel's PHP branches that remains to be seen.  EasyApache3 will eventually die and EasyApache4 will be the new standard, and in my opinion the sooner this happens the better (although admittedly I'm not in a position to migrate all of our servers over to this at this time).

The issue with backported PHP versions is another issue entirely.  But this discussion on backported PHP versions also underscores the difficulties in managing and maintaining them.  That's really why this can't go on forever.  Eventually whoever is backporting older PHP versions is going to stop doing it.  Might be tomorrow, it might be 10 years from now.  But when the PHP developers release PHP 8, PHP 9, PHP 10 and so on, and CloudLinux or cPanel is still having to backport fixes for PHP 4, PHP 5, PHP 7 and so and so on, it's going to become too much of a headache for them to keep this up.

Ironically, we're talking about a shift in the development process for EasyApache3 to EasyApache4.  cPanel is not going to maintain EasyApache3 forever.  They are not going to spend time and effort making sure Apache and PHP for EA3 remains up to date like in EA4.  Eventually a cPanel release is going to happen that drops support for EasyApache 3 altogether.  When that happens and if people refuse to upgrade to EA4, then they'll have to work with and end-of-life version of cPanel and never ever upgrade.  This is software life-cycle.  It just has to happen.  Why doesn't cPanel support version 11.48 any more?  Or cPanel 11.46?  They don't have the personnel to maintain those versions forever.

For users that are running custom scripts that only work with PHP 4 or < PHP 5.5, then they should be able to made changes to those scripts to make them up to date.  If you are developing in PHP, then you have to stay in contact with PHP's development and their upcoming changes.  If you're not doing that, then you don't need to be developing in PHP.  If someone else wrote the custom scripts for you, then that's why you need to keep those developers on a retainer, so they can update it as PHP changes come about.

If you are not comfortable working with PHP and wish to develop a script that has a longer life-cycle then you probably need to use some other programming language, like Perl, which tends to have a longer life-cycle.

I really wish PHP's life-cycle was longer and more in-line with Perl.  But PHP is still a relatively young language, so it's in a state of constant development.  The life-cycles of PHP versions really isn't a secret.  But if you wish for PHP's life-cycles to be longer, then you need to discuss this with the PHP developers.  Don't like PHP constantly changing the way functions work or become deprecated?  Let them know.  Don't like having to upgrade Joomla! because Joomla! 2.5 is end-of-life?  Let Joomla! know that you want a longer life-cycle.

But also understand that if you want extended software life-cycles, you are going to sacrifice new features.  Me personally, I'd rather have longer life-cycles and more stable and mature code than to have new features all the time.  People tend to want new features and longer life-cycles and that's just really not possible.
  1. 24.03.2016 16:03:27
  2. # 40
Bogdan Accepted Answer
Posts: 709
Joined: 26.06.2013
0
Votes
Undo
Dave, we are not declining older PHP versions. Personally I am sure our PHP-Selector will work for a next few years. Only after cPanels \'multiple PHP\' will works flawlessly with our hardened PHP we could stop implementing PHP-Selector itself. But you will get same working PHP old versions as \'hardened PHP\' , functionality will nto change.

More about HardenedPHP at https://www.cloudlinux.com/hardenedphp to show we are taking it seriously and officially.


Our EA4 support is on early beta stage, everything will be improved after some time.


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.