Live data from Hacker News

Nginx 1.9.11 with Dynamic Modules

mailman.nginx.org

21–30 of 63 posts

Re: Nginx 1.9.11 with Dynamic Modules

#21
post #11

Earlier quoted context omitted.

Unfortunately, it looks like it may not be something will be able to work with. Instead of an ABI like Apache uses, Nginx went with signature checking. To load a precompiled module, the signature has to match. This means we would have to compile many different binary modules for every configuration people might have, and for every version of Nginx. Like several dozen. As it stands, though, the module system would be…

I would think that containers would help obviate such concerns, since it would be rather trivial to keep even a hundred images in place for an automated compilation run. Of course, serving the output would be harder, but still not impossible.

Generating all those binaries would still be a pain, but you're right that containers could help.

We'd also need to write a script that looked at your nginx install and figured out what would be the right precompiled module to download.

Re: Nginx 1.9.11 with Dynamic Modules

#22
post #8
post #4

Is this going to make it easier to get luajit on a stock nginx server? I just see a single bullet point regarding "Dynamic modules", anywhere I can get more info?

Probably not. The lua module hooks into internal symbols not considered part of the module API.

Nginx doesn't really have a module API. While lua reaches deep inside, loadable modules already have to be compiled for the specific nginx version, which means this module isn't in a different situation from any of the others.

Re: Nginx 1.9.11 with Dynamic Modules

#24
post #23

Does Dynamic modules will help to enable mod_pagespeed easily?

Sadly, probably not: https://news.ycombinator.com/item?id=11066250

Compiling a module is still a lot more straight-forward than recompiling the whole of Nginx, which is probably the main obstacle to people using it (at least it is in my case).

Re: Nginx 1.9.11 with Dynamic Modules

#26
post #23

Earlier quoted context omitted.

Sadly, probably not: https://news.ycombinator.com/item?id=11066250

Compiling a module is still a lot more straight-forward than recompiling the whole of Nginx, which is probably the main obstacle to people using it (at least it is in my case).

Cool. We're working now to make this possible.

(And, in fact, to work at all when compiling against 1.9.11, since the addition of dynamic modules broke us: https://github.com/pagespeed/ngx_pagespeed/issues/1110 )

Re: Nginx 1.9.11 with Dynamic Modules

#27
post #11
post #3

This is great news for the pagespeed people.

Unfortunately, it looks like it may not be something will be able to work with. Instead of an ABI like Apache uses, Nginx went with signature checking. To load a precompiled module, the signature has to match. This means we would have to compile many different binary modules for every configuration people might have, and for every version of Nginx. Like several dozen. As it stands, though, the module system would be…

Actually, it's still a pain for package maintainers. Take a look at mod_wsgi for apache as an example, it's maintained as a completely separate package (the rpmspec and dist-git trees are totally independent from apache) - when the httpd package gets upgraded mod_wsgi doesn't have to be rebuilt at all. This is important, in fact, because rebuilding a package means updating the spec file, bumping the release, and submitting a new build to koji - not something you want to do for loadable modules every time httpd is updated.

This is going to create headaches for anyone wanting to package nginx, either they will have to compile all the modules when building nginx (creating many sub-packages) or there will have to be coordination between package maintainers to do a mass rebuild of all loadable modules every time the nginx package gets bumped. Neither situation is desirable, and I hope they release a stable ABI because until then nobody is going to waste time packaging loadable modules.

Re: Nginx 1.9.11 with Dynamic Modules

#28
post #5

A little more explanation of what that means from the docs: In NGINX 1.9.11 onwards a new way of loading modules dynamically has been introduced. This means that selected modules can be loaded into NGINX at runtime based on configuration files. They can also be unloaded by editing the configuration files and reloading NGINX. https://www.nginx.com/resources/wiki/extending/converting/

[deleted]

Re: Nginx 1.9.11 with Dynamic Modules

#29
We support nginx in our products, due to high demand for it, but we don't really like the way it has historically handled modules. Having to custom-build to do interesting things is very far away from the "plug and play" experience that our users expect and can get with Apache.

While I'm not on the bandwagon that says all Apache installations would be better on nginx (and I still run Apache on all of our servers, except nginx test machines), I do think this makes the case quite a bit more compelling, particularly for people who package and distribute the web server (OS vendors, control panel maintainers like me, container builders, etc.).

Re: Nginx 1.9.11 with Dynamic Modules

#30
post #5

A little more explanation of what that means from the docs: In NGINX 1.9.11 onwards a new way of loading modules dynamically has been introduced. This means that selected modules can be loaded into NGINX at runtime based on configuration files. They can also be unloaded by editing the configuration files and reloading NGINX. https://www.nginx.com/resources/wiki/extending/converting/

Hugely important. Compiling your own Nginx has never been trivial in modern development pipelines, and until now that's been the only way to use external modules.

Honest question: Why do you think it was non-trivial? What is/was complex?
Post reply on HN