Hacker News Reader

Hacker News

Comment by jaryd | Hacker News Reader

Full thread

jaryd

Hey guys,

Looking for a consensus on the most stable way to update nginx installations from source.

Thanks!

View on HN

I prefer to custom build deb packages (on Ubuntu myself) using a project called brew2deb:

https://github.com/tmm1/brew2deb

It provides a DSL for describing how to build and package something, including patching, and already has a nginx formula:

https://github.com/tmm1/brew2deb/blob/master/packages/nginx/...

Will likely be adding in this patch today...

It's a relatively simple task if you're on a Debian derivative to take the source .deb & add a new patch to it.

I second the idea of building your own deb.

But if you're going to learn a DSL for building debs, why not just learn how to build debs? Your distro already provides the necessary build formula, along with well-integrated startup scripts, etc.

To start out, just build as given:

    apt-get build-dep nginx
    apt-get source nginx
    cd nginx-$VERSION
    dpkg-buildpackage

Then to customize, go into the source tree and update whatever you want to update, and rebuild. You'll see there's already a debian/patches directory where you can drop patches to apply automatically.

I tend to just keep the "debian" directory in source control, so I can take a fresh upstream tarball, check out my debian rules into it, and kick off the build.

I've done custom debian packages from scratch and always found it a pain. I've also done customized source builds and still prefer this approach because its simple, slimmer, easily version controlled, and wrapped up in a single command.

But there are many ways to fry an egg. I prefer this way, but overall having a package is a big plus for commonality between systems and convenience vs simply building from source.

I've just done that on Gentoo source installed nginx by following these simple steps:

* Get old version config flags with -V, e.g /opt/nginx/sbin/nginx -V

Mine had:

nginx: configure arguments: --prefix=/opt/nginx --with-http_ssl_module --with-cc-opt=-Wno-error --add-module=/usr/lib/ruby/gems/1.8/gems/passenger-3.0.9/ext/nginx

Download tarball:

* wget http://nginx.org/download/nginx-1.0.14.tar.gz

Extract and configure passing the same flags:

* tar zxvf nginx-1.0.14.tar.gz && cd nginx-1.0.14

* ./configure --prefix=/opt/nginx --with-http_ssl_module --with-cc-opt=-Wno-error --add-module=/usr/lib/ruby/gems/1.8/gems/passenger-3.0.9/ext/nginx

Compile and install

* make && make install clean

The make install action will check for old directories and files so no need to worry about stuff being overriden.

Verify your nginx version with:

/opt/nginx/sbin/nginx -v

nginx version: nginx/1.0.14

This is poor advice that could be potentially damaging. Instead of manually building and installing from upstream source code you should bump the package version locally to ensure your system isn't littered with orphaned files later on. You'll get the benefit of portage's sandbox and other package management features too. If Gentoo's ebuild had Gentoo-specific patches, you'll get these compiled into the latest version as well. Sometimes these patches are very important.

A better approach to follow is (note this is only a rough guide from memory):

  cp -R /usr/portage/www-client/nginx /usr/local/portage/www-client
  cd /usr/local/portage/www-client/nginx
  mv nginx-1.0.13.ebuild nginx-1.0.14.ebuild
  ebuild nginx-1.0.14.ebuild digest
  emerge -1q nginx

I agree that it's a bad way to install new software but I was merely suggesting a way to upgrade nginx that was installed this way in the first place, I assumed the OP meant that by asking for a "stable way to update nginx installations from source.". The fact that I did it on Gentoo is irrelevant here.

I love portage, I use it whenever I can. In this case, I think I've did it like that because something was messed up with Passenger support in the port. It's the only package installed from source (bypassing portage) on my system and it's not an orphan in a way that /opt was dedicated purely for such scenarions. I can see all such packages by listing /opt assuming I keep the install prefix convention.

In any case, thanks for pointing that this is a wrong way to install packages, someone might benefit from this indeed.

Indeed this is what I was looking for (however I will be updating the software on CentOS) sprinkled with a few snippets of wisdom from the above posters.

Thank you all for your thoughtful replies.

My I suggest upgrading passenger some time :)

If you don't care about uptime just replace the old binary with the new binary and then restart the server.

This is from a book called "Nginx HTTP server":

1. Replace the old Nginx binary (by default, /usr/local/nginx/sbin/nginx) with the new one.

2. Find the pid of the Nginx master process, for example, with ps x | grep nginx | grep master or by looking at the value found in the pid file.

3. Send a USR2 (12) signal to the master process—kill –USR2 , replacing with the pid found in step 2. This will initiate the upgrade by renaming the old .pid file and running the new binary.

4. Send a WINCH (28) signal to the old master process—kill –WINCH , replacing with the pid found in step 2. This will engage a graceful shutdown of the old worker processes.

5. Make sure that all the old worker processes are terminated, and then send a QUIT signal to the old master process—kill –QUIT , replacing with the pid found in step 2.

Actually, this is from nginx documentation: http://nginx.org/en/docs/control.html

The above steps aren't optimal.

The makefile in the nginx source shows you how to do a hitless upgrade. This is what I do from the shell after correctly installing, essentially translated from the makefile.

kill -USR2 `cat /var/run/nginx.pid` && sleep 1 && test -f /var/run/nginx.pid.oldbin && kill -QUIT `cat /var/run/nginx.pid.oldbin` && echo restart successful

Obviously, modify paths to the pid files as appropriate.

Reply on news.ycombinator.com