EasyApache4 Announcement
Over the past several months, we have been working on the next generation of EasyApache. In EasyApache 4, we will make quite a few major changes to the way cPanel & WHM utilizes Apache HTTPd & PHP. This will initially be an opt-in update so that users can choose when to move to the new ecosystem, but at some point, this will be a required change. The major changes that we plan to introduce are:
[LIST]
Improved Operating System Integration and migrating to OS standard paths for services
EasyApache will use the system package manager
Full binary distribution of Apache HTTPd and PHP via RPM & yum
Use of Modern Apache releases (2.4)
Automatic updates of Apache HTTPd & PHP
Ability to set different PHP versions on a per-vhost basis
As you can tell, there are many changes compared to what EA3 has delivered over the years. The purpose of this article is to solicit feedback about what is being planned for EasyApache 4 delivery. We absolutely want to know what our customers think of this plan! Please use this thread for posting comments.
Improved Operating System Distribution Integration
In order to align cPanel & WHM better with the operating system that the server runs, we will move the various Apache assets to match the file system paths that CentOS and RHEL provide. This will allow better customizations to Apache and make the deployment of new Apache modules a rapid process. Symlinks will be left behind in /usr/local/apache to help old scripts work with the new paths.
With these changes, porting most Apache modules that already have an RPM built for CentOS/RHEL should be relatively easy: tweak the spec file, ensure proper dependencies are provided, and recompile the RPM. Alternatively, it means that the existing resources for building RPMs for Apache modules will remain relevant and follow the process used by RHEL Administrators.
EasyApache Interface to move to Package Manager
With the initial release of EasyApache 4, we will move the EasyApache interface to the Package Manager, which will provide an interface for yum. cPanel will create yum repositories that hold the EasyApache4 RPMs, which includes Apache, PHP, and friends. Using yum will also allow your own customized repositories.
To shorten processing time and provide better quality control over the packages, EasyApache will begin utilizing RPMs. This will meet one of our project goals of cPanel & WHM becoming a better member of the Operating System"s ecosystem.
.vB
The purpose of this UI is to provide a general-purpose interface into the packages and repositories available on a system.
Multi-PHP Domain Support
The release of EasyApache 4 will include Multi-PHP support at the VirtualHost level. We will utilize Red Hat"s Software Collections to allow the installation of multiple PHP versions simultaneously. WHM and cPanel Interfaces will allow users and administrators to select system level and per-domain default PHP versions. This will be achieved by using AddHandler entries in .htaccess files.
.vB
Modern Apache only (2.4)
EasyApache 4 will only provide RPMs for Apache 2.4. This allows us to provide better support for Apache and simplifies the process of rolling out customizations.
Automatic Updates
We plan to automatically update Apache & PHP by default. This will be an opt-out process so that hosts can easily put updates of Apache & PHP under their control.
Feedback
We absolutely want to hear what you think of our plans for EasyApache4! Please comment below.
-
It is absolutely critical a proven and heavily tested working migration EA3 (Apache 2.2)-->EA4 (Apache 2.4) tool (or a migration description) to be provided since the following scenario is absolutely possible: A working EA3 Apache 2.2 environment will immediately stop working after EA4 Apache 2.4 migration. The majority of the providers are not yet fully migrated to Apache 2.4 for various of reasons. The only available alternative would be to stay with EA3 Apache 2.2 but not updating it since it will become depricated sooner or later. Theoretically, it should be easier if first the following migration can be made automatic: EA3 (Apache 2.2) --> EA3 (Apache 2.4) After that: EA3(Apache 2.4) ---> EA4 (Apache 2.4) A very important thing here is the PHP handler - Cpanel should officially choose the most stable and recommended php handler for the new setup --> EA4. Why is important? Because of the different ways the PHP handlers works - including but not limited to: .htaccess directives, custom php.ini files, directory and file permissions etc. What we have at the moment: suPHP ---> slow, almost depricated and not updated, not working with opcache accelerators, DSO --> not suitable for security reasons (not working with Cloudlinux as well), mod_ruid2 --> far from stable, most annoying issue is with the mod_security (yes, not fixed yet, I have tested it myself a week ago) fcgid --> most suitable option - compatible with Cloudlinux. 0 -
] Theoretically, it should be easier if first the following migration can be made automatic: EA3 (Apache 2.2) --> EA3 (Apache 2.4)
EasyApache 3 will already convert from Apache 2.2 to Apache 2.4. If you encounter problems with the conversion, we'd love to know about them, so we can fix them. Please file those in a new thread, so we can keep this one focused on EasyApache 4. Thank you.0 -
]Oh, I'm sure large companies use cPanel. It just seems to me like cPanel is developing new tools and applications that are more geared towards web hosting companies that have 2 or 3 servers instead of 100s or 1000s. cPanel's leaving the command-line structure behind, gearing more towards the WHM for control. Meaning you have to log into the WHM to configure something. I'm not really in favor of this (but again, I am in a minority). GoDaddy probably has a few people that are like me that can function on the command-line and operate. But I would also venture a guess that GoDaddy has more than one server admin managing all of their servers. 200 servers with 50 server admins, that's 4 servers apiece that has to log in and make a MaxClients change. That's doable.
We tend to favor making changes either in the GUI, or via the API. The command line, in recent years, has been neglected by a number of features and enhancements. While having API calls for the new functionality helps, it's not exactly a replacement for command line utilities. To improve this part of our software, we've begun requiring new features and enhancements make it easier for large scale automation. Command line utilities, documentation on configuration files, documentation on templates, and similar things are what you should start seeing soon to help here.0 -
[Probably getting a bit off-topic for this thread...] This has kind of been my observation as well. Granted, you may have more stuff in the API now, I never delved too deeply into that. But CLI utilities have been sorely lacking in cPanel for quite a few years now. I suppose having a more robust API might help. But in order to use the API, something has to be written and then made available to perform that function from the API. With CLI, if the scripts and commands are available, a shell script can be made to perform that action (such as parking a domain name from the command line by running /usr/local/cpanel/whostmgr/bin/whostmgr directly). By forcing a GUI interface or API, you (cPanel developers) can certainly control more of the behavior, but it takes flexibility away from server admins. Forcing WHM or other GUIs for certain tasks can work for small scale hosts. But large scale hosts, even with 10 or 20 servers, it's not that feasible to log into that many WHM or GUIs to make changes. I suppose the API could be used and that may be the way you decide to go with this. But I would like to see greater attention paid to being able to automate or perform tasks in an "unattended" (server admin doesn't have to be there clicking on something) capacity. 0 -
]EasyApache 3 will already convert from Apache 2.2 to Apache 2.4. If you encounter problems with the conversion, we'd love to know about them, so we can fix them. Please file those in a new thread, so we can keep this one focused on EasyApache 4. Thank you.
I am aware of that. What your advice would be when we are talking about 1000 clients on a server with EA3 (Apache 2.2) using Wordpress, Joomla etc.. with a custom .htaccess etc..? Apache 2.4 uses different .htaccess directives + if the PHP handler in EA4 will be different - a permissions problems might appear. I know that a manual convertion on a per site basis would be possible. The current automatic script in EA will break the sites. So what is the solution?0 -
]I am aware of that. What your advice would be when we are talking about 1000 clients on a server with EA3 (Apache 2.2) using Wordpress, Joomla etc.. with a custom .htaccess etc..? Apache 2.4 uses different .htaccess directives + if the PHP handler in EA4 will be different - a permissions problems might appear. I know that a manual convertion on a per site basis would be possible. The current automatic script in EA will break the sites. So what is the solution?
Hello, In a situation like this, I would recommend making a clone of your server and doing the upgrade, and seeing what will break. EasyApache 4 will only offer Apache 2.4, so you will need to ensure your clients sites work with the upgraded directives for Apache 2.4. We're looking to ensure as much feature parity as possible with EA3 and EA4, so PHP handlers and such will still work as they have previously. I hope this helps!0 -
]A very important thing here is the PHP handler - Cpanel should officially choose the most stable and recommended php handler for the new setup --> EA4. suPHP ---> slow, almost depricated and not updated, not working with opcache accelerators, DSO --> not suitable for security reasons (not working with Cloudlinux as well), mod_ruid2 --> far from stable, most annoying issue is with the mod_security (yes, not fixed yet, I have tested it myself a week ago) fcgid --> most suitable option - compatible with Cloudlinux.
That is really a key question. suPHP is still propagated by cPanel. Perhaps it causes the least trouble with mom and dad hosting. I wanted to jump to mod_ruid2 but the issues in security and the instable behaviour are still a burden. Disadvantage of FCGID is the usage memory, right? suPHP is more demanding when it comes to CPU. I got the impression cPanel is betting on mod_ruid2. Would be nice to hear some thoughts from the cpanel-team.0 -
The fastest and most secure way to serve PHP under Apache is now lsapi from CloudLinux which we hope cPanel will be adding to the EA 4 build options. More info? [url=http://cloudlinux.com/blog/clnews/beta-modlsapi-supercharge-your-apache-php-hosting.php]Beta: mod_lsapi - supercharge your Apache PHP hosting 0 -
]The fastest and most secure way to serve PHP under Apache is now lsapi from CloudLinux which we hope cPanel will be adding to the EA 4 build options. More info? [url=http://cloudlinux.com/blog/clnews/beta-modlsapi-supercharge-your-apache-php-hosting.php]Beta: mod_lsapi - supercharge your Apache PHP hosting
Still in Beta, and last time I checked it still forced accounts using native PHP onto one of the alt-php branches. That means it would completely bypass EasyApache's PHP, which in turn means the server administrator is less in control of the defaults that users get to run PHP with.0 -
]Still in Beta, and last time I checked it still forced accounts using native PHP onto one of the alt-php branches. That means it would completely bypass EasyApache's PHP, which in turn means the server administrator is less in control of the defaults that users get to run PHP with.
Nope, the last new accounts we have set up are still on the native php. ( version 0.1-100 ) Yep, still in beta....... but more stable than cPanels new OWASP mod_sec rules :)0 -
] Kernow, the mod_security changes cPanel is making is VERY needed but the OWASP rules wreaked havoc on a clients dedicated server with only PIWIK and Joomla so, I installed the free Comodo WAF that we use on our production hosting servers. Now things are quiet again running smoothly. I do think the OWASP rules will get better over time but, we're not in a position to experiment and had to fall back on proven technology or risk loosing a lot of business. Another thing cPanel has to do here is way more work on controlling rules at the account level vs just the server level.
Yes, after disabling around 40 rules we also gave up and went back to Comodo. lsapi had loads of bugs as you might expect for the first few months, which is why we only ran it on one server. But we now use it on all servers as we think its stable enough for production use. It really is fast :)0 -
Past 2 days been playing with Docker and it's growing on me :) Maybe cpanel folks can come up with a CentOS based Docker image which bundles everything you need to rebuild custom RPMs for stuff like Apache and PHP ? 0 -
My wishlist: Modsecurity rules and management that work well / allow for quickly reacting to false positives. ConfigServer Firewall integration / support Ability to use modruid2/moditk with cache + apache 2.4 Docker support Improved log monitoring / integration (logstash, etc.) 0 -
]We'd like to know which PHP extensions and Apache modules, not already provided via EasyApache 3, do you routinely install. Once we know about those we can give thought to providing those with EasyApache 4.
mod_rpaf memcache We use this to translate CloudFlare IPs to client IPs. It would be nice if this were included with WHM too. cPHulk only recognizes and blocks the CloudFlare IP - not the actual IP of the bad guys.0 -
]Nope, the last new accounts we have set up are still on the native php. ( version 0.1-100 )
Are you sure? Inspired by your test, I've just tried again. First, I updated mod_lsapi to the latest version (0.2.3). Then I went to my test domain, and made sure that the PHP selector was using "native" not any of Cloud Linux's alt-php versions. 1. I turned off mod_lsapi for a test domain I was using. I loaded a PHP info page - I can see it's using PHP 5.5.22, and the ini file is at /usr/local/lib/php.ini. Confirmed: Native PHP. 2. Then I ran switch_mod_lsapi --enable-domain {my test domain} I then loaded PHP info again. Now it says it's using PHP 5.4.30, with the ini file at /opt/alt/php54/etc/php.ini . Definitely not native PHP. Could you check for me? Can you get a phpinfo() page loaded that shows "Server API" to be Litespeed 6.6 (because you're using mod_lsapi), and that also shows the loaded ini file to be /usr/local/lib/php.ini If you can do it, but I can't, I'll open a ticket with Cloud Linux, but I thought I'd ask you to check again (if you don't mind) to save me looking silly by opening a ticket needlessly.0 -
Morning, Your right the file used is /opt/alt/php54/etc/php.ini but in the clients cpanel under php options, its listed as "native" unless another version has been selected by the client. However what modules are available in the native version ( and all other versions) are controlled by you the system admin in the CloudLinux Manager. 0 -
]Your right the file used is /opt/alt/php54/etc/php.ini but in the clients cpanel under php options, its listed as "native" unless another version has been selected by the client.
In other words, it's exactly as I described further up this thread:]...last time I checked it still forced accounts using native PHP onto one of the alt-php branches.
It doesn't use the Native PHP. Case in point: On the server I tested on, native PHP was 5.5.x, but enabling mod_lsapi put the site onto 5.4.x. There's no way I can deploy it server-wide whilst that is the case. Imagine: The only way to stop everyone being moved back to PHP 5.4 would be to set them manually to use the alt-php55. But then I'd have loads of accounts that were on alt-php55 - some because they'd chosen to set PHP 5.5 manually, and others because it's the only way to keep them on the native PHP 5.5 the site owner had wanted. I'd have no way to know which was which, new accounts would still get put onto PHP 5.4, and imagine the fun and games when I used EasyApache to install PHP 5.6 as the new native PHP. That's why I said it's not production ready until they let you use mod_lsapi with native PHP.0 -
] It doesn't use the Native PHP. Case in point: On the server I tested on, native PHP was 5.5.x, but enabling mod_lsapi put the site onto 5.4.x.
I wouldn't know how to achieve that without manual adjustment of the clients account. It doesn't do that for us. Our native is php 5.5 and new accounts get set up on .......php 5.5 Perhaps you should put in a ticket to CL0 -
Hmm... New accounts get set up on PHP 5.5 with mod_lsapi enabled? 0 -
]Hmm... New accounts get set up on PHP 5.5 with mod_lsapi enabled?
Yes, correct. Since about a month ago we have mod-lsapi enabled by default. If it helps you, our Easyapache gets built with php 5.50 -
These changes look extremely interesting, in particular the multi-php domain support. The automatic updates also look pretty interesting too :) 0 -
So, when a user picks an old version of PHP, will they also be using an old version of Zend? That's my problem, I have users that have sites break because they need old versions of Zend to go with old PHP versions 0 -
Phusion Passenger 5 (Raptor) is a huge must for this release of EasyApache. We need the ability to run Ruby, Python, and JS (Node and Meteor) apps in a seamless fashion. This has to be figured out with this release. I have been running Passenger 5 now for 6 months on cPanel and it is a dream and works well with virtual hosts, but it is a serious hassle that it's not supported right out of the box. A lot of folks would be excited to see this introduced and would see cPanel as a viable option if this were the case. 0 -
Hello, Will you intend to support in EasyApache4 Apache's MPM Event and mod Proxy for using PHP-FPM? (Apache HTTPD 2.4.9+ required) I've been maintaining for years with this servers and it's the best performance and lowest memory consumption possible. 0 -
Hello, Will you intend to support in EasyApache4 Apache's MPM Event and mod Proxy for using PHP-FPM? (Apache HTTPD 2.4.9+ required) I've been maintaining for years with this servers and it's the best performance and lowest memory consumption possible.
I am very anxious to have PHP-FPM in my Cpanel box, but it's taking years for this...0 -
FYI there are third party apps that can get php-fpm in your cPanel box . Check out the cPanel app catalog 0 -
Is there an ETA for EasyApache4? 0 -
Is there an ETA for EasyApache4?
EA4 is planned for 11.52 which should be coming to EDGE very soon :)0 -
Hello, Will you intend to support in EasyApache4 Apache's MPM Event and mod Proxy for using PHP-FPM? (Apache HTTPD 2.4.9+ required) I've been maintaining for years with this servers and it's the best performance and lowest memory consumption possible.
Hi! Yep, you'll be able to achieve this setup with EA 4, however please note that in regards to PHP-FPM, we're only releasing an RPM with no API / UI support yet. Any user and pooling setup will need to be done manually.0
Please sign in to leave a comment.
Comments
98 comments