EasyApache4 Announcement

[kevinlevin]

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?

 

[JacobPerkins]

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!

 

[lorio]

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.

 

[kernow]

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?
Beta: mod_lsapi - supercharge your Apache PHP hosting

 

[JamesOakley]

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

 

[kernow]

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

 

[WebJIVE]

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.

This is VERY interesting and creative. What it proposes to step out of the box with CL (which your doing anyway) not only at the OS level but, at the core of what the server does, serving web content! This is very exciting and I hope that cPanel gives it a hard look and works with CL to make this happen.

We have to do a server refresh this year and I hope this is stable enough to deploy and move forward. The BIG challenge/risk for us is support from cPanel if we're using out-of-the-box solutions like this.

- - - Updated - - -

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

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.

 

[kernow]

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

 

[eva2000]

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 ?

 

[sonicthoughts]

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

 

[grayloon]

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.

 

[JamesOakley]

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.

 

[kernow]

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.

 

[JamesOakley]

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.

 

[kernow]

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 CL

 

[JamesOakley]

Hmm...

New accounts get set up on PHP 5.5 with mod_lsapi enabled?

 

[kernow]

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

 

[Ashley.S.]

These changes look extremely interesting, in particular the multi-php domain support. The automatic updates also look pretty interesting too

 

[shimmy]

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

 

[mywhm]

Please not forget about this:

https://features.cpanel.net/topic/a...ster-speed-and-lower-load-on-smallers-servers

Stand-alone nginx supported as an alternative to Apache