EasyApache 4 HTTP2 Support

Weverton Velludo shared this idea 10 months ago
Pre-Release

Support to mod_http2 to speedup hosted domains access.

http://httpwg.org/specs/rfc7540.html

Moderator note: This was implemented in EasyApache 3 already, so I've adjusted this request to be specifically for EasyApache 4.

Best Answer
photo

Howdy!

We've moved this RPM to the EA4-experimental repository. If you've installed the version before this that was on my personal OpenSuse account (the comment which I have now deleted), please follow the instructions below:

  1. # yum remove ea-apache24-mod_http2 ea-nghttp2 ea-libnghttp2
  2. # rm -fv /etc/yum.repos.d/EA4-mod_http2.repo
  3. # yum downgrade 'ea-apache24*'
  4. # yum install ea4-experimental
  5. # yum clean all ; yum install ea-apache24-mod_http2

If all went well, you should be back with http2 running. If you got RPM dependency issues with Apache, you'll probably need to downgrade 'ea-apache24*' again.

For users who are just catching up, you can install and test HTTP2 by running:

  1. # yum install ea4-experimental
  2. # yum install ea-apache24-mod_http2

Place this .conf file down in '/etc/apache2/conf.d/http2.conf'

  1. <IfModule http2_module>
  2. LogLevel http2:info
  3. Protocols h2 h2c http/1.1
  4. </IfModule>

Restart Apache

  1. /scripts/restartsrv_httpd

Please note, there was a brief period where it didn't link properly. A 'yum update' should pull down the latest changes. Please provide feedback and let us know how it goes!

Comments (25)

photo
4

It appears that mod_spdy was donated to the Apache foundation for inclusion in Apache core for the HTTP2 protocol, which should be released by Apache sometime in 2015. Running mod_spdy requires a custom installation of OpenSSL, which we do not support at this time. We look forward to Apache integrating mod_spdy with the Apache core next year. However at this time, we will unfortunately not be implementing mod_spdy at this time.

photo
5

why we need to start this all over again? Is clearly that once was requested in EA3, we want it in EA4 too. There was no point in marking the old post as completed and closing, since first of all cPanel doesn't want to officially support it in EA3 and is not even started in EA4. Once you release a new version with less features than the last one, is no longer called an upgrade, more likely a downgrade.

photo
3

EasyApache 3 has no support for http2, it only provides a way to personalize the options to compile Apache and you have to set your own compilation of openSSL.

cPanel has taken this post about to EasyApache 4 to close the post for EA3, even it has not been completed.

photo
3

It supports the EA3 but needs many manual settings ...

I believe that could be available as several other modules supported ...

photo
1

First, thank you so much to everyone here for your quick, verbose feedback. I do hear your frustrations, and am glad to see that you're still interested in providing your feedback!

Our biggest hesitation with this is that in order to use HTTP2, you need to have OpenSSL 1.0.2. Taking ownership of, and shipping our own RPM for, OpenSSL is something we cannot consider lightly, and is something that we currently aren't planning to do. We definitely understand that it's something that many of our customers want, but we currently haven't decided to take on that burden. Thanks for your continued attention, and definitely let me know if I can answer any questions!

photo
11

Using a custom installation of OpenSSL just for the entire web server stack would help to solve a lot of issues.

cPanel needs to put more effort into the core services related to serving sites, and less into cPanel/WHM features like SSL stores, external authentication systems, and security analysis.

photo
3

yes just using OpenSSL 1.0.2+ for apache would solve this. That's what I do for CentOS and Nginx's HTTP/2 requirements. But it's source compiled and not rpms. It's why i've stuck with EA3 vs EA4 too

source compiled OpenSSL 1.0.2+ statically just for nginx also allows you more timely openssl related updates that RPM would provide - just look at last few openssl rpm updates especially slow, or will not fix or delay from redhat etc.

It's a fine line between using official OpenSSL rpms and keeping OpenSSL up to date in a more timely manner than rpm repo would provide.

As a web hosting cpanel and LAMP solution, you can't afford to have lengthy delays for security fixes that are delayed in OpenSSL rpm repo sourced vs being able to compile from direct source the latest release.

cpanel should allow Apache to support either system OpenSSL 1.0.1e usage or statically compile against own OpenSSL 1.0.2+. Flexibility allows cpanel's Apache to meet the changing needs at the time more quickly.

photo
photo
2

We deployed a while back http2 on our Nginx reverse proxies which were running CentOS 6 by statically compiling OpenSSL 1.0.2. It works really well and doesn't force us to upgrade to a newer distribution. Maybe cPanel can do something like this?

photo
1

There are certainly a host of possible ways we might implement this. If we get closer to actually doing it, we'll definitely let everyone know here!

photo
6

Hey all! No further updates yet, but I did realize that there was an old mod_spdy request that was not merged in here. We wanted to merge them together in order to get a more accurate count of people asking for HTTP/2 support. I will post here as soon as there is an update to provide!

For anyone looking for a bit of backstory: https://developers.googleblog.com/2014/06/modspdy-is-now-apache-project.html

photo
1

This site is so poorly coded I can't tell if my post was sent of not using mobile.

Anyways. Enabling h2 without Chacha20/Poly1305 forces android to keep AES-NI libraries loaded the entire time your site is open in a tab. This drains Android batteries at a MUCH higher rate.

If you can't figure out how to get us back to EasyApache 3, where we can do this stuff ourselves, I'm moving all my customers to your competitors. EasyApache4 is SEVENTY PERCENT slower at serving websites than we had EA3 running.

photo
1

Howdy!

Thanks for the heads up, I'm adding this patch in now.

I'd like to work with you to see if we can figure out what's going on that's causing your systems to be slower. Mind emailing me?

Thanks!

Edit: I've patched and updated builds. If you have the above installed, a yum update should pull down the changes. I really appreciate your feedback!

photo
1

My main problem is the fact that I've had to choose between sites that wreck people's batteries, or not having h2.

For business customers who have employees that have to login to their sites from their phones a lot, draining their batteries isn't really an option.

I have an extra box sitting around at moment with absolutely no paying customers on it (I planned on attempting exactly what you are doing next week). I'll test this on it later tonight. Now that I have customers using the multi-php I'm going to have to pay extra attention to how it affects that though.

TBH I'm not overly a huge fan of this RPM system. It's only a matter of time before people start playing with it and borking their entire install force overwriting system files.

photo
1

Not to mention doing this RPM build is a WHOLE lot more involved than unzipping a file somewhere and telling EA what options you want it to pass.

Grab Source RPM

Extract

Apply Patches

Resource

Build RPM

Check for dependencies

Apply RPM

.... It used to be unzip a tar to a certain place and add some text to a file.... Maybe run a yum command.

It basically feels like the things we've been paying you for got deleted so it could be easier for cPanel devs and you've dumped the extra work on us, because let's be honest. cPanel hasn't been the greatest here lately. We won't even be able to install SSL certificates into accounts on cPanel without CAA records later this year and no one at cPanel even had a clue about it until it was mentioned in a feature request. Wasn't even on the radar to be looked into adding at the time according to staff.

Seems as if you guys want to make things easier for yourselves no matter what repercussions it has to the customers.

The fact that people are building web server rpms and adding them to repos that don't even know about the current common pitfalls of building a web server from hand kind of shakes my confidence in what's going on there at cPanel.

photo
3

@wired420: @cPanelJacob clearly wrote it is all SUPER EXPERIMENTAL. It is not the finished product, it is just a feature for testing. Don't get me wrong but a few hundreds people have starred this issue and you are now flooding their mailboxes with your complaints about things rather unrelated to HTTP/2. Regards,

photo
photo
1

Hey everyone! Comments were locked overnight. Please do keep the conversation specific to *this* request, and take any other conversation you want to have to the forums or to a personal email conversation.

photo
1

@cPanelJacob

Thanks for the 'howto'. We tried this out on one our our productions servers running Centos 6 and it works great so far with no errors encountered. Our other servers run CloudLinux 6/7 with mod_lsapi is that module likely to cause a problem with HTTP2 ?

photo
2

Hi Chris,

I'm glad to hear it! This is a *very* experimental setup. It's so experimental that I'm keeping it on my personal OpenSuse account until we can get it through our QA & security team. Unfortunately, CloudLinux will most likely not ship these packages until we get them into our EA4 mainline repo, which could be a while. I'll work on getting these into our EA4-experimental repositories this week.

photo
1

Great news Jacob :-)

As long as it will work with mod_lsapi at the end we are very happy! :-)

photo
photo
1

3) Put this text into a new file '/etc/apache2/conf.d/http2.conf'

Can do adding automatically without manually file edit?

photo
3

This will be done when we officially release http2 support. We want to ensure the protocols work for most people on setup before we enable it by default.

photo
photo
3

Howdy!

We've moved this RPM to the EA4-experimental repository. If you've installed the version before this that was on my personal OpenSuse account (the comment which I have now deleted), please follow the instructions below:

  1. # yum remove ea-apache24-mod_http2 ea-nghttp2 ea-libnghttp2
  2. # rm -fv /etc/yum.repos.d/EA4-mod_http2.repo
  3. # yum downgrade 'ea-apache24*'
  4. # yum install ea4-experimental
  5. # yum clean all ; yum install ea-apache24-mod_http2

If all went well, you should be back with http2 running. If you got RPM dependency issues with Apache, you'll probably need to downgrade 'ea-apache24*' again.

For users who are just catching up, you can install and test HTTP2 by running:

  1. # yum install ea4-experimental
  2. # yum install ea-apache24-mod_http2

Place this .conf file down in '/etc/apache2/conf.d/http2.conf'

  1. <IfModule http2_module>
  2. LogLevel http2:info
  3. Protocols h2 h2c http/1.1
  4. </IfModule>

Restart Apache

  1. /scripts/restartsrv_httpd

Please note, there was a brief period where it didn't link properly. A 'yum update' should pull down the latest changes. Please provide feedback and let us know how it goes!

photo
1

Removed earlier version and installed latest, all working great and noticed some websites do now load faster!

proper job! :)

photo
photo
1

Just wanted to update this post for anyone having issues with Mod_Security

White listing rule 960034 in /etc/apache2/conf.d/userdata/ssl/2_4/USER/modsec.conf

[Mon Mar 20 20:40:54.551880 2017] [:error] [pid 30929:tid 139631531427584] [client XXXX] ModSecurity: Access denied with code 403 (phase 2). Match of "within %{tx.allowed_http_versions}" against "REQUEST_PROTOCOL" required. [file

"/etc/apache2/conf.d/modsec_vendor_configs/OWASP/rules/REQUEST-20-PROTOCOL-ENFORCEMENT.conf"] [line "412"] [id "960034"] [rev "2"] [msg "HTTP protocol version is not allowed by policy"] [data "HTTP/2.0"] [severity "CRITICAL"] [ver "OWASP

_CRS/3.0.0"] [maturity "9"] [accuracy "9"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-protocol"] [tag "OWASP_CRS/POLICY/PROTOCOL_NOT_ALLOWED"] [tag "WASCTC/WASC-21"] [tag "OWASP_TOP_10/A6"] [tag "

PCI/6.5.10"] [hostname "http://www.mydomain.com";] [uri "/"] [unique_id "AAAAAI6zHdKoX-RUuoY7zgAAAAE"]

photo
1

I have just tested. http2 is running smoothly without any issue :)