Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Nginx 1.9.11 with Dynamic Modules

mailman.nginx.org

Post reply on HN
Print view View original

41–50 of 63 posts

Re: Nginx 1.9.11 with Dynamic Modules

#41

Post by taf2 »

sgt wrote: post #35
pmlnr wrote: post #34

Earlier quoted context omitted.

Compiling nginx is surprisingly easy and straightforward; a perfect example to get started with packaging for yourself.

Indeed - but having built an nginx module, it's hard to convince others to use it. Often, nginx users are simply using the binary packages from their Linux distribution, and if they compile their own, they'll have to remember that they have a version that's compiled from source on the system and not the packaged one.

Exactly and then when it is time to patch nginx you can't just install a new binary and reload - you have to have documented exactly right set of modules previously compiled. Depending on the modules this can be time consuming and error prone. Not impossible, but adds additional automation requirements.

Re: Nginx 1.9.11 with Dynamic Modules

#42

Post by pnommensen »

We've just posted a blog post "Introducing Dynamic Modules in NGINX 1.9.11." https://www.nginx.com/blog/dynamic-modules-nginx-1-9-11/

We'll take a read through the comments here and are looking forward to answering questions and receive feedback. You may also email the NGINX development mailing list (info in blog post).

(I work @ NGINX).

Re: Nginx 1.9.11 with Dynamic Modules

#43

Post by Florin_Andrei »

snuxoll wrote: post #27
cbr wrote: 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…

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 subm…

Wow. That basically means their current module scheme is useless for package maintainers.

Re: Nginx 1.9.11 with Dynamic Modules

#44

Post by snuxoll »

Florin_Andrei wrote: post #43
snuxoll wrote: post #27

Earlier quoted context omitted.

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 subm…

Wow. That basically means their current module scheme is useless for package maintainers.

Pretty much. Like I said, technically you could just have the build for nginx also include all of the modules and just split them up into sub-packages, but that defeats the entire point of having loadable modules that can be compiled independently.

Re: Nginx 1.9.11 with Dynamic Modules

#45

Post by snuxoll »

falcolas wrote: post #37
xorcist wrote: post #33

Earlier quoted context omitted.

How does containers help? Building a hundred different nginx's shouldn't be neither harder nor easier if you stuff the binary in a container or not.

It gives you one image per configuration, instead of one build machine, or one stored VM. It makes it easier for a single machine to iterate over dozens or hundreds of build environments with a minimum of overhead. For example, one Ubuntu machine with Docker can create build environments for every Linux based distro (and version thereof) that exists, and iterate through all of them when it comes time to build. The se…

Every distribution on the planet handles this with chroots for doing builds and it works out just fine without needing to do gymnastics with docker. Fedora, for example, has a farm of build hosts that are architecture specific (so there is no cross-compiling outside of bootstrapping a new build target), from there a new chroot gets created for every build and the build runs isolated within it. They've been using this same system to maintain packages for up to 7 different releases at once (counting the EPEL repositories) with no issues, I fail to see any benefit docker brings to the table here - and really, nginx should just provide a stable ABI.

Re: Nginx 1.9.11 with Dynamic Modules

#46

Post by voltagex_ »

snuxoll wrote: post #44
Florin_Andrei wrote: post #43

Earlier quoted context omitted.

Wow. That basically means their current module scheme is useless for package maintainers.

Pretty much. Like I said, technically you could just have the build for nginx also include all of the modules and just split them up into sub-packages, but that defeats the entire point of having loadable modules that can be compiled independently.

This is off topic, but I think there should be more tutorials for developers along the lines of "how to make life easier for packagers".

Sidenote: creating Debian packages is an intimidating task.

Re: Nginx 1.9.11 with Dynamic Modules

#48

Post by snuxoll »

voltagex_ wrote: post #46
snuxoll wrote: post #44

Earlier quoted context omitted.

Pretty much. Like I said, technically you could just have the build for nginx also include all of the modules and just split them up into sub-packages, but that defeats the entire point of having loadable modules that can be compiled independently.

This is off topic, but I think there should be more tutorials for developers along the lines of "how to make life easier for packagers". Sidenote: creating Debian packages is an intimidating task.

1. Don't use a million dependencies that aren't already included in the majority of distributions. As a packager, I have no desire to maintain 20 complicated libraries you decided to depend on just to include your application in the package collection. A couple is fine, and the flatter your dependency tree is the less painful it is for a package maintainer to deal with. If you must include a dependency then please keep the transitive ones under control!

2. Use a standard build/packaging system. autotools, cmake, scons, setuptools/distutils, maven, gem (read: not bundler), cpan, etc. Whatever is considered a "standard" way of building and releasing software in the language you are writing it in is acceptable, using hacked together Makefiles and build scripts is generally a quick way to make packagers hate you and not want to waste time getting your software built.

3. Don't vendor dependencies - if you do then support the use of system-installed libraries in their place. I won't package software that insists on vending dependencies, I'm happy to package an extra library or two but I don't have that option if you don't support it.

4. Please support a standard installation mechanism if at all possible. I can relocate your build artifacts to the buildroot if necessary, but then I have to maintain it as the upstream changes - and distributions may be inconsistent with each other. If you are using a standard build system this should come for practically free unless you've done some nasty hacks, in which case please reconsider the modifications you have made.

Debian packaging is pretty simple but I find the decision to use Makefile's for debian/rules to be a little annoying. rpmspec's are a lot clearer and rpm macro's are a lot easier to intuit since you can easily use rpmspec -e to see what they expand to, versus the blackbox that is the debhelper scripts sometimes.

If you are new to packaging seriously take a look at making RPM's your first stop, rpmdev-newspec has a lot of templates for spec files that make getting started with any project that uses a standard build system super-easy (automake, cmake, python, ruby, perl, etc).

Re: Nginx 1.9.11 with Dynamic Modules

#49

Post by frik »

akurtzhs wrote: post #40
frik wrote: post #20

Is this going to make it easier to enable stub_status module without compiling Nginx? (or buying NginxPlus) http://nginx.org/en/docs/http/ngx_http_stub_status_module.ht...

What problems are you having using stub_status? I'm using the nginx mainline PPA and didn't have a problem enabling it.

  This module is not built by default, it should be enabled 
  with the --with-http_stub_status_module configuration 
  parameter
I had to compile Nginx myself, because that module was absent. As you can read also on various community pages, boards, etc.

Nginx is the only server software that I have to compile myself, just to get a basic status feature. It's a way to upsale people to their NginxPlus which offer a lot more status data in the binary.

Re: Nginx 1.9.11 with Dynamic Modules

#50

Post by lumannnn »

pnommensen wrote: post #42

We've just posted a blog post "Introducing Dynamic Modules in NGINX 1.9.11." https://www.nginx.com/blog/dynamic-modules-nginx-1-9-11/ We'll take a read through the comments here and are looking forward to answering questions and receive feedback. You may also email the NGINX development mailing list (info in blog post). (I work @ NGINX).

Hey :)

I've just created a separate HN submission pointing to your blog post.

I hope you don't mind.

Keep up the amazing work!

Post reply on HN