Nginx v1.10.0 Stable Version Released | Hacker News Reader

Nginx v1.10.0 Stable Version Released

nginx.org

76 pointsconductor39 comments

I have a love-hate relationship with nginx. I love that it's fast and rock solid. But recently I keep on getting tripped up when the directive I'm trying to configure is only available in the paid plan, the pricing of which puts it out of (my) reach.

Also, there really should be separate docs for the open source vs paid plan.

That said, I do plan on kicking the tires on the HTTP/2 support.

> the directive I'm trying to configure is only available in the paid plan

Sadly, this is how the developers of nginx can earn and continue to make good software. Some of the new features in this release has been directly supported by the commercial edition, and some has been open sourced after being made for the commercial edition because clients demanded them.

Also, the nginx team is open to a feature being sponsored by a third-party, non-client in order to add it to the open source edition. Some of the significant features in nginx have been built this way (http/2, spdy, websocket support etc.)

If nothing, even patching or writing modules for nginx is not that hard (assuming you know how to develop, and in C). It is one of the more well-designed codebases. (Some others are: Redis, Postgres, Git).

> there really should be separate docs for the open source vs paid plan

I thought nginx.org contained only open-source info, save for an occasional ad about the paid offering. Is there any documentation on nginx.org that doesn't apply to the open source edition?

http://nginx.org/en/docs/http/ngx_http_upstream_module.html

"Dynamically configurable group, available as part of our commercial subscription:"

"Additionally, the following parameters are available as part of our commercial subscription:"

"This directive is available as part of our commercial subscription."

I may not have been clear, but I understand and fully support their right to charge for software and services. I just haven't worked on any projects for which their prices fit in to the calculation.

As to documentation on nginx.org that doesn't apply to the open source edition, see http://nginx.org/en/docs/http/ngx_http_upstream_module.html#... -- there are quite a few more, that's just the last one I tried to use.

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

Hmm, so Ubuntu 14.04 LTS won't support it (ships OpenSSL 1.0.1f), need to upgrade to 16.04.

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

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

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

> 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. This actually supports other distributions and packaging systems, but unfortunately most packages there are for SuSE.

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.

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(!)

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.

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.

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.

Nginx is annoyingly complicated in a microservices environment.

IP addresses of upstream servers change, and sometimes DNS doesn't resolve until another service is brought up. Nginx does not work well in such an environment unless you (1) have ugly configuration hacks, (2) add OpenResty/LUA to your configuration, (3) add a watchdog process, or (4) buy their nginx Plus version and keep track of how many instances of nginx you have.

I want simple. If you need a webserver that can use DNS, Nginx is a lot of extra work.

I use it just fine in my Kubernetes deployment. Nginx resolves via DNS to the microservices I run, without having to do complicated configuration hacks.

Would something like that work for you?

Depending on how you are using it, Kubernetes may be hiding the problem for you via Kubernetes-managed load balancers.

If the IP address of the microservice nginx depends on changes, in a standard nginx config, nginx will not be updated. A Kubernetes health check could also hide this issue.

My favourite bits in this release:

1. Fix of the repeated-tries of non-idempotent requests bug.

2. Dynamic modules.

3. HTTP/2!!

4. reuseport in listen.

5. SSLv3 disabled by default.

6. UDP Load Balancing.

> UDP Load Blancing

Isn't that just a feature creep?

Doesn't look like anything that would be useful in a web server and load balancing of UDP is different than TCP. Layer 3 load balancing (e.g. LVS) would probably be more suitable.

Nginx is not a web server. Nginx is a reverse-proxy.

Nginx's sees a massive share of its usage as a web server, sure, but – from the very beginning – it was always intended to be a good reverse-proxy.

Apart from http, nginx also supports mail (imap, pop3, smtp), stream sockets (tcp and unix), and few third-party ones too (like rtmp). And now, UDP as well.

One of most needed features expected of a good reverse-proxy is load-balancing. Nginx is already quite good at it, but lacked UDP load balancing (like HAproxy – another reverse-proxy – does). That is no longer the case, and I'm sure the people that have asked HAproxy to support UDP will be pleased that nginx does it now.

As a reverse proxy though, it is hardly the best, either in performance or compliance. As far as in creating an (unjustified) reputation for itself, it is superior.

www.slideshare.net/bryan_call/choosing-a-proxy-server-apachecon-2014

www.slideshare.net/AllThingsOpen/battle-of-the-stacks

Just for the information: Jim Jagielski, the director of Apache Foundation, who won't miss any opportunity to say how he hates nginx, and how bad nginx is. Well done!

It's called "Battling FUD" :-)

Since those are slides without the actual talk, any idea why HAProxy was excluded in many comparisons?

It feels a bit biased.

For reverse-proxy/LB it kinda sucks. No standard healthchecks for a long-long time and nowdays only in commercial version? Yes, you can compile in 3d party plugin but that just underscores the lacking.

You're completely wrong. Opensource version has always had in-flight healthchecks that work just perfect, see: https://www.youtube.com/watch?v=yQvcHy_tPjI

1. He's not wrong, those are not healthchecks, essentially when connection fails (nginx immediatelly tries next server) this works well when service is stopped and host sends response that the port is closed. It fails miserable when host is actually down (which is what happens most of the time in real world). This also won't help you when the server is up and application is broken and returns errors, which is another very common scenario.

2. This test is unfair, it relies on default settings, where nginx has defaults to retry immediately and never give up. HAProxy by default has this option (option redispatch) disabled because it offers larger range of load balancing algorithms and in some cases this setting might not make sense. The point is that you can configure it to behave the same way.

3. In terms of in-flight health checks HAProxy has actual ones (in addition to the above redispatch mechanism) with observe option[1] and on-error[2] it can be programmed to for example simulate healthcheck down when application generates too many 5xx errors.

[1] http://cbonte.github.io/haproxy-dconv/configuration-1.6.html...

[2] http://cbonte.github.io/haproxy-dconv/configuration-1.6.html...

Yep, serving 503 or otherwise broken app to users is not acceptable LB behavior. Nginx aficionados fail to comprehend that somehow. Which I guess shows that nginx is web server first and proxy/LB second.

I suppose its support for static content and other HTTP-ish-server features mislead people. I use it, saw the mail stuff and figured it was "weird". Had no idea it could do general TCP proxying.

Dynamic modules will be the best thing since sliced bread. I have wanted to use a StatsD plugin for metrics but having to manually compile has kept me from doing so for 2 years. I don't want that technical debt sticking around.

Sounds like you should be automating more stuff, there is little reason compiling something like nginx should cause technical debt. Especially since nginx versions in stable distros are usually really old versions, and when it comes to security take a while to get patched up.

While thats true that it could be more automated, its a whole lot easier to automate an "apt-get install nginx-statsd" than manually compiling and having to make sure it doesn't break between versions. Basically I don't want to "own" the process.

It's like the old joke: New linux users use the default kernel of a distro because it 'just works', power users compile their own kernel to get every drop of performance, and senior users use the default kernel because it 'just works'...

Yup, plus you get the benefit of thousands of other people running the exact same setup which helps report/fix bugs.

HTTP/2 has been available for a while now. iirc, SSLv3 has also been disabled for a while.

TFA is a stable channel announcement. Everything in it has been available for a while now, but under the mainline channel. Like a new release of Ubuntu getting Linux 4.4 while Arch and Gentoo are on 4.5 already.

UDP loadbalancing is huge, since HAProxy can't do it you had to do it with LVS.

Feels like feature creep. What would you use UDP load balancing for? Layer 3 load balancing is probably the best approach for load balancing UDP traffic.

Edit: If you have to downvote, go ahead, but at least state why you don't agree, so I can know why I'm wrong and can revise my opinion.

I'll upvote you b/c I have the same question.

Reply on news.ycombinator.com