Biggest discovery when researching this was due to the ALPN requirement in Chrome [1], openssl 1.02 being required for ALPN, and the vagaries of Linux distro release schedules, Ubuntu 16.04 is the only LTS distro than can serve HTTP/2 to Chrome users.
When they're eventually announced, RHEL/CentOS 8 (Fedora already has the necessary openssl) and Debian 9 will also work. But right now Ubuntu is your only bet unless you want to build and maintain your own openssl. Which you don't.
Interesting. What's the maintenance policy for jessie-backports? If it's best-effort it might be better to avoid suggesting people use it for a package as frequently updated as openssl.
Given what I'm seeing on the Nginx build currently in backports, I might rely on backports for dependencies, but I'd seriously consider building your own Nginx from source and/or pay attention yourself to security warnings.
the configuration they provide is wrong on many things
1/ it says "An nginx config for your first million users",
but: worker_connections 768;
2/ html5-sse.conf:
proxy_buffering off;
bad idea for a loaded server / backend
proxy_cache off;
will enable proxy_cache, which is not defined anywhere, so this will actually fail to validate - and proxy_cache is already disabled when you're doing proxy_buffering off;
3/ https.conf:
resolver 8.8.8.8 8.8.4.4 valid=300s;
bad idea to trust anything but a local resolver, why do you trust internet to tell you IP addresses where you will go for ssl stapling info?
1/ The article doesn't claim to support one million concurrent users. Top level directives are Ubuntu/RHEL defaults, but if you have a preferred scalability config please file an issue!
2a/ buffering is well known to break SSE. As the article notes, if you're not using SSE you should disable that include.
2a/ ok, I misread what was the intention, maybe it's a good idea then
3/ it's not about "better maintained", it's about trusting the internet on sensitive data, which you should never do, because dns is easily spoofed and nginx resolver was not written to operate in a hostile environment. if you don't have a local caching resolver on your machine (which you should), even trusting your cloud provider dns is better than trusting goog one. nginx documentation even says " To prevent DNS spoofing, it is recommended configuring DNS servers in a properly secured trusted local network. " on http://nginx.org/r/resolver
proxy_set_header in html5-sse.conf will discard all other proxy_set_header included in proxy.conf a level above: "These directives are inherited from the previous level if and only if there are no proxy_set_header directives defined on the current level", http://nginx.org/r/proxy_set_header
> 3/ If you think your own DNS server is going to be better maintained than Google's, sure. But not everyone else would.
Be careful here, Google will rate limit you very severely and waiting 10s for DNS responses inside Nginx is no fun. Most cloud providers will give you a good resolver via DHCP that is much more forgiving when you accidentally abuse it.
Biggest discovery when researching this was due to the ALPN requirement in Chrome [1], openssl 1.02 being required for ALPN, and the vagaries of Linux distro release schedules, Ubuntu 16.04 is the only LTS distro than can serve HTTP/2 to Chrome users.
When they're eventually announced, RHEL/CentOS 8 (Fedora already has the necessary openssl) and Debian 9 will also work. But right now Ubuntu is your only bet unless you want to build and maintain your own openssl. Which you don't.
[1] https://bugs.chromium.org/p/chromium/issues/detail?id=527066