14

I am running debian jessie on my server and recently upgraded to new nginx web server with http/2 support (nginx 1.10). As today, it works great and webserver is delivering content with http2 protocol.

I have read, that chrome is dropping NPN support and only allows ALPN after 15.5.2016. ALPN is extension, which requires openssl 1.0.2 installed, but on debian jessie is only openssl 1.0.1 (also on debian backports and another repositories, there is no openssl 1.0.2 version for this debian).

And there is the problem - i have upgraded from SPDY to http2 and in few days, i will have to turn off http2 and cannot use SPDY because this version of nignx have only http2. I have also read, that this version of debian will stuck with openssl 1.0.1 and only debian stretch will have openssl 1.0.2. But to release date there is almost year and chrome will be dropping support soon, so i do not want to loose the benefit of http2 protocol.

Is there any solution, how to install openssl 1.0.2 on this system, without building own build (bad maintenance) or waiting for backports repository to have it? I also don't want two versions of openssl on my system if one of them must be linked and maintained manually.

Thanks for any help.

gxx
  • 5,483
  • 2
  • 21
  • 42
Juraj Nemec
  • 264
  • 1
  • 3
  • 11
  • You could use `apt pinning` and use `openssl` out of `Debian stretch`. – gxx May 06 '16 at 17:54
  • @gf_ At a very high risk of breaking your system. _A lot of things_ depend on OpenSSL. – Michael Hampton May 06 '16 at 17:58
  • @MichaelHampton Well, I can't judge regarding the level of the risk, I doubt it's very high. I'm going with Kurt Roeckx, one of the maintainers, who tried to get `1.0.2` into `jessie` just shortly after the freeze (which was rejected back then): "This version should be compatible with the 1.0.1 version. I don't expect anything to break moving from 1.0.1 to 1.0.2." (I would be more aware of `libc6`.) – gxx May 06 '16 at 18:03
  • @gf_ "Getting it in" in that context would require recompiling everything that uses OpenSSL. I'm not surprised that that was rejected; Debian likes old and stable. In the context of your suggestion, it means also pulling in every stretch package that uses OpenSSL, and that's a lot of stuff. – Michael Hampton May 06 '16 at 18:06
  • @MichaelHampton I'm quite aware of the Debian policies and I'm not surprised as well that this got rejected back then (didn't wanted to say this or create this impression). But: (maybe my wording was incorrect): Doing `apt-get install -t stretch nginx` (on a vanilla `Debian jessie` with `nginx` installed) will pull in: `nginx nginx-common nginx-full libnginx-mod-http-auth-pam libnginx-mod-http-geoip libnginx-mod-http-image-filter libnginx-mod-http-xslt-filter libnginx-mod-mail libnginx-mod-stream libssl1.0.2`. (These are ten packages..) – gxx May 06 '16 at 18:57
  • This gives you: `nginx version: nginx/1.10.0 built with OpenSSL 1.0.2g 1 Mar 2016`. Yes, there is some risk involved, and it's not a complete stable system anymore, but, _because_ it's Debian, the testing branch is quite stable as well. – gxx May 06 '16 at 19:45
  • Hi all. Thanks, I can try something like this. How likely this "update" from stretch should break someting else on the server? I see only `libssl1.0.2` in addition to nginx packages, so maybe only this library should cause some troubles to another packages? There are no critical applications on the server, only websites and similar, so that the system would not be "stable" anymore may not be such a problem. And when the packages will be in backports repository, can I switch to more "official" way? Thanks anyway. – Juraj Nemec May 08 '16 at 08:49
  • @JurajNemec Please ping me via @, otherwise I won't get notified. The way I've described is "official", maybe it's not that common, but still one to solve your problem..actually I can't think of different ways, if you don't want to compile yourself, which is quite understandable; no other answers / comments up until now might be a sign as well. Regarding the backports: I guess, `libssl1.0.2` won't be backported, as this needs to much dependencies which would then have to be backported as well. Regarding the risk: As I wrote, I think / guess the risk is quite small. To decrease the risk level.. – gxx May 08 '16 at 11:08
  • ...even further, you could run `LXC` or a `chroot` with a separate network namespace and install `nginx` in there. In case something breaks, just the "container" will be damaged, not your / the host. Does this help? Should I write an answer which you could accept? – gxx May 08 '16 at 11:10
  • @gf_ Hi. Thanks for your effort. This seem like acceptable path for me. You can write answer with this description and I accept it. I will test this approach this week and hopefully it would work without big problems :) – Juraj Nemec May 09 '16 at 12:13

6 Answers6

16

Update 2016/08/08: nginx in jessie-backports (version 1.9.10-1~bpo8+3 was built against openssl >= 1.0.2~. Getting ALPN working now if running jessie just requires the packages out of jessie-backports, no need anymore to pull packages out of stretch.

--

Original answer: Well, here goes my answer, according to the comments: In my opinion, there aren't that many ways to solve this as of today, 2016/05/09. Basically you've to try somehow to get a modern nginx into your system, compiled against >= openssl 1.0.2~.

The only two options I see currently: Either you compile for yourself, which you don't want to do, which is quite understandable, or you pull in modern packages out of Debian stretch into your system. This involves some risks, because you're mixing a stable environment with another one, but in my opinion these risks are quite low, because you're using Debian.

So, let's go and try out this:

  • Add the Debian stretch repository to your apt sources. Don't use /etc/apt/sources.list for this, but instead use a dedicated file inside /etc/apt/sources.list.d/ to keep it clean, personally I'm using stretch.list.

    Put these lines inside there:

    deb http://httpredir.debian.org/debian/ stretch main contrib non-free
deb-src http://httpredir.debian.org/debian/ stretch main contrib non-free

deb http://security.debian.org/ stretch/updates main contrib non-free
deb-src http://security.debian.org/ stretch/updates main contrib non-free

# stretch-updates, previously known as 'volatile'
deb http://httpredir.debian.org/debian/ stretch-updates main contrib non-free
deb-src http://httpredir.debian.org/debian/ stretch-updates main contrib non-free

  • Set up apt pinning to make sure you only pull in packages out of Debian stretch which you're specifying. The file to use for this is /etc/apt/preferences, inside there, put:

    Package: *
Pin: release n=jessie
Pin-Priority: 900

Package: * 
Pin: release a=jessie-backports
Pin-Priority: 500

Package: *
Pin: release n=stretch
Pin-Priority: 100

    (You might have to alter the suites and priorities to fit your environment.)

  • Run apt-get update (via sudo / as root) to update the package cache.

  • Install nginx from Debian stretch: apt-get install -t stretch nginx (do this via sudo / as root). Profit!

  • As I described in my comment(s), to even lower the risks involved, you could use something like a chroot or a container-solution like LXC. In case you want to go the chroot way, you have to set up a network interface inside there: To do this, have a look at this blogpost for example, which gives an introduction to network namespaces.

  • Hope this helps; in case you've got more question, feel free to contact me. I would appreciate feedback and I'm interested in how it goes.

gxx
  • 5,483
  • 2
  • 21
  • 42
  • I have installed nginx today by your answer description and everything seems to work great! The only thing, I needed to do extra, was to remove the old nginx installation, because I had nginx 1.10 from nginx repository and that version is not compatible with debian repositories package (but I have done this also when I was upgrading from debian nginx to 1.10, so it was not problem). Thank you for your effort and help! – Juraj Nemec May 15 '16 at 12:16
  • @JurajNemec Great! Thanks a lot for the feedback! Did you check for `ALPN` support already? – gxx May 15 '16 at 12:25
  • Yes. Checked it by [http2 test](https://tools.keycdn.com/http2-test) and [SSL Labs test](https://www.ssllabs.com/ssltest/index.html), both states, that there is ALPN support. Also `nginx -V` gives info, that the version is compiled with openssl 1.0.2+. So I think that it is working correctly. – Juraj Nemec May 15 '16 at 12:35
  • @JurajNemec Great, sounds good! If possible for you, I would be interested to get a small update after you ran this setup for a while, maybe four or eight weeks. Thanks! – gxx May 15 '16 at 12:45
  • @JurajNemec It seems, Google made the switch and removed NPN. Does your setup still work as expected? – gxx May 29 '16 at 12:45
  • I have checked these websites with chrome and all of them seems to be running on http2 protocol. Seems ok to me :-) Thanks again. – Juraj Nemec May 31 '16 at 17:34
  • @JurajNemec Great! :) – gxx May 31 '16 at 18:20
  • works like a charm!! – Mario Jun 20 '16 at 08:13
11

Another method is to install OpenSSL 1.0.2 from jessie-backports and use Ubuntu 16.04 LTS builds from nginx's own repository. That way you're at least using an OpenSSL package built for Jessie.

Add to /etc/apt/sources.list:

# jessie-backports, from stretch-level but with no dependencies
deb http://httpredir.debian.org/debian/ jessie-backports main contrib non-free
deb-src http://httpredir.debian.org/debian/ jessie-backports main contrib non-free

# Nginx repository - use Ubuntu 16.04 LTS Xenial to get packages compiled with OpenSSL 1.0.2
deb http://nginx.org/packages/mainline/ubuntu/ xenial nginx
deb-src http://nginx.org/packages/mainline/ubuntu/ xenial nginx

Then run:

apt-get update
apt-get install -t jessie-backports openssl
apt-get install nginx

This obviously puts you into an officially unsupported configuration, but perhaps that's better than not having a package at all - and it worked for me. Plus, using nginx's repo means you get fresh updates.

GreenReaper
  • 351
  • 3
  • 8
  • Could you please elaborate / clarify why one would go this route? Regarding "Plus, using nginx's repo means you get fresh updates.": You're getting "fresh updates" as well using the way I've described. – gxx Jul 12 '16 at 23:35
  • nginx's packages are updated on the same day as their release, because they are part of their release process, not Debian's release process. I included the mainline packages, not the stable packages, but you can get stable by just removing /mainline in the above paths. Which you prefer is up to you. – GreenReaper Jul 12 '16 at 23:40
  • To expand on the above: stretch is the current 'testing' release, and so has a minimum delay based on [how long it takes to move from testing](https://www.debian.org/devel/testing); and that's assuming it makes it into unstable immediately - for example, 1.10.0 was [released 26 Apr](http://nginx.org/), but [pushed to unstable 29 Apr](http://metadata.ftp-master.debian.org/changelogs//main/n/nginx/nginx_1.10.1-1_changelog) and [migrated to stretch on 5 May](https://packages.qa.debian.org/n/nginx/news/20160505T163912Z.html) ([see PTS](https://packages.qa.debian.org/n/nginx.html)). – GreenReaper Jul 12 '16 at 23:50
  • 1
    I'm quite aware of these facts, thanks. :) I think the question boils down to if one needs "new packages" (just because (?)) if trying to provide stable services. AFAIK, many people choose Debian (and this is the OS the question is about) because it's stable. There is quite some risk involved running new versions of software. But anyway, I guess there is no general rule how one does handle this, because environments, expectations and needs differ. Besides: Thanks for your input, I'm sure it's of value to people; my lines before don't mean any kind of offense. – gxx Jul 13 '16 at 00:01
  • 1
    As you say, it's a question of degree. If you want to be on the bleeding edge, you could compile builds daily. In my case, being at least on the *leading* edge technology-wise is a plus. ALPN itself is probably not a *need* for most sites - but it is highly-desired by those wishing to use HTTP/2 (especially if you'd previously had it while using NPN); and this target group is also more likely to be interested in the kind of features which pop up in mainline nginx prior to stable. I manage ten cache nodes, and typically try it on a smaller one to test under load before rolling it out further. – GreenReaper Jul 13 '16 at 00:30
  • This worked fast and painlessly, thanks for the answer! – mehov Aug 04 '17 at 14:37
0

Another method is to use jessie-backports and then rebuild easily nginx

add to /etc/apt/sources.list backports

deb http://ftp.debian.org/debian jessie-backports main

and then run as root

apt-get update
apt-get install -t jessie-backports openssl

and then rebuild nginx. Follow instructions on https://wiki.debian.org/BuildingAPackage

StanleyD
  • 151
  • 4
0

For me the easiest way to fix this was to use a different Nginx Docker image, see the official Nginx build on Docker Hub. The default Docker Nginx build uses Debian Jessie so that won't fix your problem, but they also offer an alternative build based on Alpine Linux. Its latest builds do use OpenSSL 1.0.2!

This solution thus assumes that you installed Docker and are fine with running Nginx on Alpine Linux instead of Debian Jessie.

To start your Nginx container:

sudo docker run --name nginx-container -p 80:80 -p 443:443 -v /path/to/your/nginx/directory/:/etc/nginx/ /path/to/your/files/to/serve/:/usr/share/nginx/html/ -d nginx:1.11-alpine

Short explanation to get you started with Docker:

  • docker run: downloads the Docker image (in this case nginx:1.11-alpine) if you don't have it yet and starts a Docker container based on this image
  • --name nginx-container: gives the Docker container a name (you can view all running Docker containers using sudo docker ps or use sudo docker ps -a to also view stopped containers)
  • -p 80:80 -p 443:443: binds ports 80 and 443 on your host machine to respectively ports 80 and 443 in the Docker container
  • -v /path/to/your/nginx/directory/:/etc/nginx/: mounts the directory on your host system which contains your Nginx configuration to the /etc/nginx/ directory in the Docker container
  • /path/to/your/files/to/serve/:/usr/share/nginx/html/: mounts a directory on your host system which contains files you want Nginx to serve
  • -d: starts the container in the background (you can stop the container using docker stop nginx-container)
  • nginx:1.11-alpine: use this image to start your container from (the official Nginx Docker images are listed here)

Also useful:

  • use sudo docker exec nginx-container <command> to run a command in the container, for example sudo docker exec nginx-container nginx -s reload to reload Nginx after you've changed the configuration files on the host system
  • Or use sudo docker exec -it nginx-container bash to enter a bash shell in the container so you can work there directly (not recommended, but sometimes useful)
Sicco
  • 101
  • 4
0

An alternative way is to use BoringSSL instead, which does not hurt OpenSSL surroundings. Here is details to refer to, https://www.admon.org/hardwares/enable-http2-support-for-nginx-on-debian-jessie

user402005
  • 1
  • 1
    Link-only answers tend to become less helpful after links expire. Please include relevant part of linked page into your answer. – sendmoreinfo Feb 24 '17 at 18:50
0

In my situation I've used the Dotdeb apt repository. The instructions of this website gives an option to add a repository which allows you to install Nginx with “full” HTTP2 support. The current version is 1.14 which is one minor behind the last release, so you won't be too far behind (current backport is 1.10).

HarmenB
  • 1