EasyApache4 Announcement

[MattDees]

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:

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



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.



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.

 

[cPanelDon]

Modern software releases that stay up-to-date via RPMs and YUM is my favorite aspect. I would expect an option to allow automated updates to include major new versions and not just minor versions, though understandably not by default and just as a preference for people wishing to be on the latest releases, such as on a system used for web site development or where compatibility with out-of-date web applications is not a concern.

 

[JamesOakley]

A few questions come instantly to mind - I'm sure more will become clear as you start to release docs to show it will all work. But:

• What's the plan for Tomcat? (Not that I ever understood why it was installed with EasyApache in the first place!)
• What of the custom modules that currently go in /var/cpanel/easy/apache/custom_opt_mods? (I'm sure there's a plan, but I'm trying to picture how things will work).
• What of scripts that currently fire in /scripts/after_apache_make_install or /scripts/posteasyapache (and other similar hook-points)?

I can see this will need a lot of time on a test server before I can be sure everything I currently include in an Apache / PHP recompile will all work, but those are the few theoretical questions that come to mind on first reading this.

 

[MattDees]

What's the plan for Tomcat? (Not that I ever understood why it was installed with EasyApache in the first place!)

We will be providing RPMs for mod_jk at some point in the future, currently it is on the bottom of our backlog.

What of the custom modules that currently go in /var/cpanel/easy/apache/custom_opt_mods? (I'm sure there's a plan, but I'm trying to picture how things will work).

This will be an opt-in upgrade at first and we will be trying to provide a migration path for any commonly used modules. If your host has a module that they use, you may need to write an RPM for it that builds against ours. We will be providing documents, tutorials & resources on how to do this.

What of scripts that currently fire in /scripts/after_apache_make_install or /scripts/posteasyapache (and other similar hook-points)?

We haven't explored this yet, however we can provide hooks from within the RPM installation itself using the Standard Hooks system or one can integrate into this using more distro-standard methods.

 

[Tcalp]

I assume you guys are slowly gearing this more and more towards 'domain level settings' instead of cPanel account level settings (based upon the PHP version enhancement listed above). I think in a general basis it's certainly moving in the direction that it should, hopefully that will bring forward other enhancements such as per-service SSL support and domain level IP control / multi-ip per account.

 

[WebJIVE]

Question, what about any existing .htaccess files pointing to previous PHP versions we already have compiled and installed?

Also, will Apache 2.4 break compatibly with any existing sites after the migration? We tried migrating to Apache 2.4 at one time and a lot of sites started getting 500 errors.

 

[Kent Brockman]

Question, what about any existing .htaccess files pointing to previous PHP versions we already have compiled and installed?

Also, will Apache 2.4 break compatibly with any existing sites after the migration? We tried migrating to Apache 2.4 at one time and a lot of sites started getting 500 errors.

Yes, I guess the htaccess files may contain commands that have been deprecated on 2.4. What course of action will be taken in such scenarios is an interesting question.

I bet the most problematic cases will be those with very old websites with custom programming, which is, in my case, nearly the 30% of our customer base

- - - Updated - - -

Another question I can recall is: when multiple PHP versions are allowed to coexist, how will the system deal with PHP DSO or cgi's, where there are a daemon always up and listening? Will then consume more RAM?

 

[JamesOakley]

This will be an opt-in upgrade at first

I think the point is that this would need to remain opt-in for quite some time. There will be a lot of edge-cases, uncommon uses, and so on that may prove knotty for server administrators to find the best implementation for in EA4. Forcing them to move over too fast could cause chaos, as things don't work, previously installed Apache modules have to be left out for the time being, etc. There will also be third-parties to work with, making sure that people like Cloud Linux, CloudFlare and others have all been able to migrate and test the code they had that integrated into the EA3 processes.

If your host has a module that they use, you may need to write an RPM for it that builds against ours. We will be providing documents, tutorials & resources on how to do this.

At the moment, for me at least, it's just mod_reqtimeout and mod_remoteip from https://documentation.cpanel.net/display/EA/Custom+Modules, although I'm sure others will have more unusual modules to move across.

 

[eva2000]

Interesting.. I get that RPM/YUM is easier but you might loose some flexibility that source installs provide ?

My main concern would be with PHP and custom compiled options via /var/cpanel/easy/apache/rawopts/all_php5 etc. How is that going to be dealt with when PHP becomes a RPM only maintained system ? One of the items I add is a PHP configscan .ini directory for custom php.ini options. I guess with PHP as RPM package, does that mean you're follow OS standard paths and also include a configscan .ini directory by default ?

Another one that's related to PHP would be how LiteSpeed Enterprise Cpanel plugin will handle building matching PHP versions once Apache and PHP move to RPM based and how that relates to multiple PHP versions feature in EasyApache4 under LiteSpeed Enterprise (for compatibility).

I guess with major changes like this, it would be great with WHM/Cpanel licensing would make allowances for a secondary developer/staging license option - so folks could clone or replicate production systems on a staging environment and test out the EasyApache4 migration without messing up live production systems. This way you'd more likely get more early adopters and feedback from folks testing EasyApache4 migration :D

 

[JamesOakley]

EasyApache is a collection of scripts / hooks / add-on modules to make installing Apache and PHP from source easy.

Although this change is being called EasyApache 4, it seems to me to be better described as "we're moving away from EasyApache as the supported method to install Apache and PHP, and adopting an RPM and package-based mechanism instead".

If that's the scope of the change, that doesn't automatically make it good or bad - but it would be helpful to talk about it as what it is. If I've misunderstood, and this truly will be a new version of EasyApache, still recognisably the same family of tools, then please can someone from cPanel spell out what I've missed.

We can all see some big advantages to an RPM-based installation, but also some major things get lost; as @eva2000 just pointed out, there is (on the face of it) much less scope to customize.

Surely these systems have to run in parallel until everyone has found ways to do all that they used to do with the new system?

We will be providing RPMs for mod_jk at some point in the future, currently it is on the bottom of our backlog.

Sorry, Matt - I never came back to you on this. I wasn't referring so much to mod_jk as the installation of the TomCat system itself, complete with its own separate-port webserver.

 

[eva2000]

Another question is with EA4 being opt-in. Can it be rolled back to EA3 system if there's issues ? Or does that involve a whole WHM/Cpanel reinstall ?

 

[diracuser]

I agree with eva2000:

I guess with major changes like this, it would be great with WHM/Cpanel licensing would make allowances for a secondary developer/staging license option - so folks could clone or replicate production systems on a staging environment and test out the EasyApache4 migration without messing up live production systems. This way you'd more likely get more early adopters and feedback from folks testing EasyApache4 migration :D

This type of changes we can't apply in productions systems, we need first test it in a clone system.

 

[cPanelKenneth]

Many customizations will still be possible, just done differently. In general these are:

• If you require compile-time customizations (e.g. different flags for gcc) you'll need to build your own RPMs.
• If you require a custom PHP extension, or Apache module, that we don't provide. You'll need to build your own RPM (or use apxs to install it)

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.

We also realize that some of the customizations people do are to work around what we provide with EasyApache 3. For example people commonly use something like all_php5 to install php-fpm. With EasyApache 4, we'll provide php-fpm.

We still want an interface that is focused exclusively on making it easy to install Apache and PHP. What you're seeing in the screen shots is the more general purpose package management interface.

 

[JamesOakley]

We'd like to know which PHP extensions and Apache modules, not already provided via EasyApache 3, do you routinely install.

Apache:
mod_cloudflare
mod_geoip
mod_remoteip
mod_reqtimeout

PHP (PECL):
geoip
memcache-beta
timezonedb
uploadprogress

 

[eva2000]

Off the top of my head, PHP PECL wise

• geoip 1.1.0+
• igbinary 1.2.1
• memcached 2.2.0 with libmemcached 1.0.18 using igbinary serializer
• memcache 3.0.8
• pcntl
• apc cache 3.1.15-dev for PHP 5.5+
• imagick 3.1.2 or 3.2.x latest RC

general config wise I also add in

--with-config-file-scan-dir=

so my customisations can each have their own *.ini file as well as move all php.ini optimisations to their own .ini that survive updates or php.ini changes.

 

[MattDees]

Thanks for all the responses, these sorts of discussion

EasyApache is a collection of scripts / hooks / add-on modules to make installing Apache and PHP from source easy.

Although this change is being called EasyApache 4, it seems to me to be better described as "we're moving away from EasyApache as the supported method to install Apache and PHP, and adopting an RPM and package-based mechanism instead".

If that's the scope of the change, that doesn't automatically make it good or bad - but it would be helpful to talk about it as what it is. If I've misunderstood, and this truly will be a new version of EasyApache, still recognisably the same family of tools, then please can someone from cPanel spell out what I've missed.

I'll be clear, this is not the same family tools in the sense that the codebases are related, it provides a similar feature set in the sense that it makes for easy selection of apache & php packages and providing for the ability to do the sort of customizations that were allowed in EA3 via standard tools (RPM, yum, mock, etc)

Providing manual changes will still be possible by forking our spec files and compiling your own RPMs and placing them into your own yum repo. We will document this process - it's not terribly difficult and much easier than EA3 optmods (especially since the toolchain is extensively documented).

Question, what about any existing .htaccess files pointing to previous PHP versions we already have compiled and installed?

Also, will Apache 2.4 break compatibly with any existing sites after the migration? We tried migrating to Apache 2.4 at one time and a lot of sites started getting 500 errors.

There is always the potential for breakage when performing this type of migration - also why this will be an opt-in process at first so we can start the process. If you have any idea of the sort of issues you encountered in migration, I'd like to hear about them so that we can prepare accordingly. Sometimes these issues are as simple as using an extra module in apache (mod_access_compat, for example) however it's hard for me to comment on this without specifics.

Another question I can recall is: when multiple PHP versions are allowed to coexist, how will the system deal with PHP DSO or cgi's, where there are a daemon always up and listening? Will then consume more RAM?

There will be a single PHP DSO per version, this is a limitation of PHP and the zend framework itself. Other than that, you can expect higher ram usage due to more binaries being in memory.

Another question is with EA4 being opt-in. Can it be rolled back to EA3 system if there's issues ? Or does that involve a whole WHM/Cpanel reinstall ?

While the ability to switch back and forth will certainly exist we haven't decided if we are going to build the ability to move back to EA3 into the UI migration tools. The main concern here is about when people move to EA4, make changes and then move back and the expectation that their changes will persist. Ensuring that end-users vhosts are in place between versions isn't an issue (as that is just a matter of running /scripts/rebuildhttpdconf) however providing a seemless switch between the two is a point of concern.

We'll certainly provide information on how to do these steps manually at the very minimum.

 

[briansol]

How would things like xcache that require php.ini changes be effected? I have struggled with upgrading php version through EA in the past because it would immediately make my xcache build mis-matched.

 

[JacobPerkins]

How would things like xcache that require php.ini changes be effected? I have struggled with upgrading php version through EA in the past because it would immediately make my xcache build mis-matched.

Items like this that require adjustment of files after the installation of the RPM would likely be handled by pre and post scripts within the RPM itself. However, this hasn't been fully defined yet, so this might change.

 

[Kent Brockman]

There will be a single PHP DSO per version, this is a limitation of PHP and the zend framework itself. Other than that, you can expect higher ram usage due to more binaries being in memory.

Not sure if I understood:

• Only one of the installed PHP versions will be able to run as DSO?
• Or if you install, by example, PHP 5.3 and 5.4 you can set 5.3 to be DSO and 5.4 to use fastcgi? (beisdes that, I know it could use tons of RAM, and the UI should warn about that)

 

[myusername]

I'd like to request support for different versions of PHP 'per directory' in each account, because that's going to be the next thing people ask for. Since you are in the same area working on code for different PHP versions per account, maybe now would be a good time to just tackle both issues.

The reason for this request is of course that some people might have one section of their site that requires an old PHP while the rest of the site would be fine running the latest.

I would imagine a UI in cPanel similar to the way that the password protection thing works, where a list of dirs is presented on screen and the user can click on those to set an override PHP version from the account's default.