EasyApache 4

[bogdan.sh]

We have to delay EA4 support till next week, just got an update from cpanel that brake a part of our functionality

[scott]

Do you still anticipate support for this being released this week?

[bogdan.sh]

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 .

[bogdan.sh]

This happened: https://www.cloudlinux.com/cloudlinu...for-cloudlinux

[repa]

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?

[scott]

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 dont 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.

Im 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 havent tested this Im 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) Im guessing that is in the new cl-ea4-testing repository. Im 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.

[xvidvideo]

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?

[scott]

In my opinion, I dont 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 wont run on PHP 5.5, 5.6, or 7.0, then its 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 doesnt want to upgrade their script and leaving yourself open to potential security threats.

Thats 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 Im 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.

[xvidvideo]

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.

[karl]

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 isnt 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 hasnt 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 everyones (or perhaps anyones) best interest.

[bogdan.sh]

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.

[karl]

> 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 !

[cinusik]

> 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. Im sure there are many people not using EA at all like me. Im using LSWS and with PHP Selector its 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

[system33r]

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

[dave518]

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 Im feeling very unsure about how this is all going to play out and how it will affect me / my users. For example, Im 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 cPanels MultiPHP?

Im not quite as savvy with the nuances of custom PHP environments on a per user basis as Id 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 give up their old custom made scripts and don 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 Im starting to get to know CL now Im already feeling like Ill 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?