5 ms·

Note that accepting HTTP/2 connections over TLS requires the “Application-Layer Protocol Negotiation” (ALPN) TLS extension support, which is available only sinc

by dchest 11y ago

Note that accepting HTTP/2 connections over TLS requires the “Application-Layer Protocol Negotiation” (ALPN) TLS extension support, which is available only since OpenSSL version 1.0.2. Using the “Next Protocol Negotiation” (NPN) TLS extension for this purpose (available since OpenSSL version 1.0.1) is not guaranteed. http://nginx.org/en/docs/http/ngx_http_v2_module.html http://nginx.org/en/docs/http/ngx_http_v2_module.html Hmm, so Ubuntu 14.04 LTS won't support it (ships OpenSSL 1.0.1f), need to upgrade to 16.04.

jzelinskie 11y ago
I've manually compiled and tested HTTP2 support on 14.04 LTS (OpenSSL 1.0.1f) for the past few months and it's worked fine. I wish they had elaborated on "is not guaranteed".
- pritambaral 11y ago
  The requirement for ALPN is a client-side requirement. Chrome is dropping NPN and moving to ALPN in recent releases[0]. 0: http://blog.chromium.org/2016/02/transitioning-from-spdy-to-http2.html http://blog.chromium.org/2016/02/transitioning-from-spdy-to-...
pritambaral 11y ago
Nor Debian Stable's version of OpenSSL. At work, we use Debian stable with openssl picked specifically from unstable. apt-pinning FTW!
- takeda 11y ago
  > apt-pinning FTW! You should take look at OpenSuSE's zypper. - 3 sat solver for dependencies (not just greedy algorithm; If there are conflicts it can propose you possible solutions that include uninstalling upgrading/downgrading packages) - packages stick by default to the repositories they were installed from - patches (i.e. sets of updated packages to address specific issue) it tells you what was fixed. You can for example only install patches that fix specific security issue, by using --cve opetion. - zypper ps tells you which processes need to be restarted after upgrade to make changes effective - OBS (Open Build System), basically it's like a github for packages. You upload spec files and it generates packages for you. You can fork someone's definitions and make customizations etc. The repo is searchable from http://software.opensuse.org http://software.opensuse.org. This actually supports other distributions and packaging systems, but unfortunately most packages there are for SuSE.
  - pritambaral 11y ago
    Wow, that reads like features a modern package manager should have! Now I am torn three-ways on the question of the next distro/package manager I should try out: nix is a strong attraction because it also does a lot of cool stuff (especially the multiple versions thing, which I think is a better solution than 3-sat solving), and Ubuntu's snap{d,craft,-whatever} because it is a better real-world solution for third-party packaging needs.
- 0x0 11y ago
  Sounds risky. What if (I mean, when) there's another critical vuln, you need to update, but unstable has moved on so the libssl/openssl package deps are unsatisfiable on stable (for example, depending on unstable-only libc6?). Or the ABI breaks all reverse dependencies. You might have to end up upgrading to unstable to get a consistent system, but then you might have broken your own (web-)apps with a too new/different base system... Not to mention you're on unstable, which have had fun bugs in the past like accepting empty passwords for pam/ssh logins(!)
  - pritambaral 11y ago
    Well, we keep an eye on what gets pulled in when installing from non-default repos. It hasn't yet ever happened that pulling in a small, single package from Debian unstable has overrode too many Debian stable packages, only the ones related to it. There's a lot of difference between "unstable" and "Debian unstable". The latter is actually quite stable (which may be why Ubuntu feels safe enough to build on it). Breaking libc is a major step, and Debian wouldn't take such a step lightly. It rarely happens even with rolling release distros – and in the case of Debian – the true rolling, unstable distro is Debian testing. Before such a things rolls into Debian unstable, we've already received ample notice. ---- > which have had fun bugs in the past like ... I think those were just bugs. They didn't happen because they were in unstable, and even stable has had nasty bugs.
    - 0x0 11y ago
      My experience has been that many packages in unstable tend to get a Depends: on an unstable-only libc6, and effectively require a nearly full dist-upgrade to be installable, after a while. At least it was like this a few major versions back, maybe it's less brutal on jessie at the moment.
      - pritambaral 11y ago
        Eventually, Debian stable becomes too old, and Debian unstable keeps getting farther and farther from it. We will eventually move to something newer, maybe the latest Ubuntu LTS. It's always a tradeoff between stability and freshness, which is subjective and varies from sysadmin to sysadmin. Worst case scenario: we have to build newer packages ourselves on top of an old, stable repo. That is also not too hard for us. ---- We do have one server running Arch though; we run every service on it that we have in production and some more, and less effort has gone into to it than any of our production servers individually. I think that's primarily because packaging for Arch is just so simple.

by dchest 11y ago

jzelinskie 11y ago

I've manually compiled and tested HTTP2 support on 14.04 LTS (OpenSSL 1.0.1f) for the past few months and it's worked fine. I wish they had elaborated on "is not guaranteed".

pritambaral 11y ago
The requirement for ALPN is a client-side requirement. Chrome is dropping NPN and moving to ALPN in recent releases[0]. 0: http://blog.chromium.org/2016/02/transitioning-from-spdy-to-http2.html http://blog.chromium.org/2016/02/transitioning-from-spdy-to-...

pritambaral 11y ago

Nor Debian Stable's version of OpenSSL. At work, we use Debian stable with openssl picked specifically from unstable. apt-pinning FTW!

takeda 11y ago
> apt-pinning FTW! You should take look at OpenSuSE's zypper. - 3 sat solver for dependencies (not just greedy algorithm; If there are conflicts it can propose you possible solutions that include uninstalling upgrading/downgrading packages) - packages stick by default to the repositories they were installed from - patches (i.e. sets of updated packages to address specific issue) it tells you what was fixed. You can for example only install patches that fix specific security issue, by using --cve opetion. - zypper ps tells you which processes need to be restarted after upgrade to make changes effective - OBS (Open Build System), basically it's like a github for packages. You upload spec files and it generates packages for you. You can fork someone's definitions and make customizations etc. The repo is searchable from http://software.opensuse.org http://software.opensuse.org. This actually supports other distributions and packaging systems, but unfortunately most packages there are for SuSE.
- pritambaral 11y ago
  Wow, that reads like features a modern package manager should have! Now I am torn three-ways on the question of the next distro/package manager I should try out: nix is a strong attraction because it also does a lot of cool stuff (especially the multiple versions thing, which I think is a better solution than 3-sat solving), and Ubuntu's snap{d,craft,-whatever} because it is a better real-world solution for third-party packaging needs.
0x0 11y ago
Sounds risky. What if (I mean, when) there's another critical vuln, you need to update, but unstable has moved on so the libssl/openssl package deps are unsatisfiable on stable (for example, depending on unstable-only libc6?). Or the ABI breaks all reverse dependencies. You might have to end up upgrading to unstable to get a consistent system, but then you might have broken your own (web-)apps with a too new/different base system... Not to mention you're on unstable, which have had fun bugs in the past like accepting empty passwords for pam/ssh logins(!)
- pritambaral 11y ago
  Well, we keep an eye on what gets pulled in when installing from non-default repos. It hasn't yet ever happened that pulling in a small, single package from Debian unstable has overrode too many Debian stable packages, only the ones related to it. There's a lot of difference between "unstable" and "Debian unstable". The latter is actually quite stable (which may be why Ubuntu feels safe enough to build on it). Breaking libc is a major step, and Debian wouldn't take such a step lightly. It rarely happens even with rolling release distros – and in the case of Debian – the true rolling, unstable distro is Debian testing. Before such a things rolls into Debian unstable, we've already received ample notice. ---- > which have had fun bugs in the past like ... I think those were just bugs. They didn't happen because they were in unstable, and even stable has had nasty bugs.
  - 0x0 11y ago
    My experience has been that many packages in unstable tend to get a Depends: on an unstable-only libc6, and effectively require a nearly full dist-upgrade to be installable, after a while. At least it was like this a few major versions back, maybe it's less brutal on jessie at the moment.
    - pritambaral 11y ago
      Eventually, Debian stable becomes too old, and Debian unstable keeps getting farther and farther from it. We will eventually move to something newer, maybe the latest Ubuntu LTS. It's always a tradeoff between stability and freshness, which is subjective and varies from sysadmin to sysadmin. Worst case scenario: we have to build newer packages ourselves on top of an old, stable repo. That is also not too hard for us. ---- We do have one server running Arch though; we run every service on it that we have in production and some more, and less effort has gone into to it than any of our production servers individually. I think that's primarily because packaging for Arch is just so simple.