How best to update nginx
I have Nginx installed in /opt/nginx/ with a dir tree of:
clientbodytemp
conf
fastcgi_temp
html
logs
proxy_temp
sbin
scgi_temp
uwsgi_temp
I use nginx.conf for all my websites and their configurations, with each site given a folder in the html dir.
How best to update my current Nginx to the latest build?
Really would appreciate any advice.
15 Replies
If memory serves, copy the config.nice file from your previous build of it to get the same config options, pop that in with the latest source, build, install.
But it might be worth the effort to migrate to the distro package.
@Guspaz:
Well, using your distribution's package manager is the proper way, but it seems you installed it from source (bad idea)…
Only if your distribution is up to date. On my Ubuntu 8.04 servers, compiling your own is really easiest overall. The official repositories aren't nearly up to date (even backports is 0.6.something), and while I tracked a private ppa at one point it disappeared without much fanfare.
Of course, some packages are easier than others, but nginx is pretty simple. Figure out the build config options you want, save it in a shell script and re-use over time. You really only need to transfer the single binary over to the resulting server.
I did borrow/update an init.d script though to tie it into normal startup.
To the OP, you should be able to run nginx manually with the -V option to see what options your current version was built with, and then use them (as is or as a starting point) for your own compilation. The nginx build process has a configure step, though it's not autoconf based, and in my experience it's quite easy to build.
This assumes you didn't do your own source build (which given that you have it in /opt may or may not be true). If you built it yourself and just want the update process, most of the time you just really need the nginx binary to be updated - configurations are generally compatible unless you want to use new features. If you haven't touched them you can update the various *_param and config files, or just diff yours with the source tree to see if anything changed.
Of course, you might also ask yourself if it's really necessary. Even though there is a later version available, unless you need a specific feature or it has a specific security fix, there's nothing forcing you to upgrade.
– David
Changes with nginx 0.8.54 14 Dec 2010
*) Bugfix: if there was a single server for given IPv6 address:port
pair, then captures in regular expressions in a "server_name"
directive did not work.
*) Bugfix: a segmentation fault might occur in a worker process, if the
"auth_basic" directive was used.
Thanks to Michail Laletin.
*) Bugfix: compatibility with ngxhttpeval_module; the bug had
appeared in 0.8.42.
So unless any of those effect you I wouldn't bother.
@db3l:
Only if your distribution is up to date. On my Ubuntu 8.04 servers, compiling your own is really easiest overall. The official repositories aren't nearly up to date (even backports is 0.6.something), and while I tracked a private ppa at one point it disappeared without much fanfare.
Sure, but while 8.04 LTS is still supported on servers until 2013 (overlapping 11.04 LTS), 10.04 LTS has been out for a year. It's perfectly fine to run 8.04 LTS still, but if you're running 8.04 LTS and compiling packages from source to get newer versions, why stick with the old version of the distro? I mean, the whole point of running an LTS release for so long is to get stability in terms of packages, right?
@Guspaz:
Well, using your distribution's package manager is the proper way, but it seems you installed it from source (bad idea)…
[citation needed]
@Guspaz:
Sure, but while 8.04 LTS is still supported on servers until 2013 (overlapping 11.04 LTS), 10.04 LTS has been out for a year. It's perfectly fine to run 8.04 LTS still, but if you're running 8.04 LTS and compiling packages from source to get newer versions, why stick with the old version of the distro? I mean, the whole point of running an LTS release for so long is to get stability in terms of packages, right?
Well, there's a vast difference between a single package and the entire distribution, and in my case at the moment I've chosen just to bring nginx (which is just about the only externally communicating bit of code on the node, and the only thing I've built from source) more up to date than to change the entire platform of packages. In some other cases (like PostgreSQL) there are nicely maintained backports to let me do that, but it just happens nginx isn't in that category.
That's not to say I'm not testing and preparing for a shift to a later LTS at some point in advance of 8.04's end of life, but that process is orthogonal to managing packages on my current stable platform.
In any event, I merely wanted to point out that there are some times when it's a valid choice to build from source, even with today's distributions and packaging systems.
– David
@Guspaz:
Sure, but while 8.04 LTS is still supported on servers until 2013 (overlapping 11.04 LTS)…
11.04 won't be an LTS release, 12.04 will be (which still overlaps).
nginx 1.0.0 stable
@Guspaz:
Well, using your distribution's package manager is the proper way, but it seems you installed it from source (bad idea)…
If memory serves, copy the config.nice file from your previous build of it to get the same config options, pop that in with the latest source, build, install.
But it might be worth the effort to migrate to the distro package.
Why is it a bad idea to compile from source? I updated my nginx installation from 0.8.54 to 1.0 just now from source in about 2 minutes.
@texascrane:
@Guspaz:Well, using your distribution's package manager is the proper way, but it seems you installed it from source (bad idea)…
If memory serves, copy the config.nice file from your previous build of it to get the same config options, pop that in with the latest source, build, install.
But it might be worth the effort to migrate to the distro package.
Why is it a bad idea to compile from source? I updated my nginx installation from 0.8.54 to 1.0 just now from source in about 2 minutes.
Because people often compile from source when they don't have to, and then don't update from source as often as they should. Distributions provide a quick and easy way to update every single package on a system to the latest version, or between different versions of the distro. When people start compiling stuff from source, they need to individually update anything they compiled. They're also probably not doing that as often as their distro, and they're certainly not backporting fixes.
The packages compiled from source are also probably not using the same paths/configuration/etc that the distro package would, which may make it incompatible with packaged versions of dependent or related software, adding further complexity and room for error.
@Guspaz:
Because people often compile from source when they don't have to, and then don't update from source as often as they should. Distributions provide a quick and easy way to update every single package on a system to the latest version, or between different versions of the distro. When people start compiling stuff from source, they need to individually update anything they compiled. They're also probably not doing that as often as their distro, and they're certainly not backporting fixes.
The packages compiled from source are also probably not using the same paths/configuration/etc that the distro package would, which may make it incompatible with packaged versions of dependent or related software, adding further complexity and room for error.
All of that makes sense and I use APT for everything… except nginx. From my perspective, I like to have granular control over what modules are installed on something as important as my web server (and make sure that I'm running the latest version). Nginx has no dependencies (unless you add them) and compiling from source is very easy.
If updating to the latest stable version of nginx every few months (or making a decision not to update) is too much trouble for a system admin, well…
By the way … nginx 1.0 is now the stable release and was launched today!
I want the cache_purge and uploadprogress modules compiled into my nginx.
However, instead of compiling from source, it's more convenient for me to edit the existing deb package, change modules in the debian/rules file, apply a new source tarball for an upstream release using the uupdate debian script, and then recompile the package. Or in some cases, take a package from a newer release and backport it.
It's neater than compiling from source and it maintains all the customized scripts, correct folder locations, logrotate configs, etc. for your distro.
And if you need it on a few machines, it's easier to distribute the customized packages. Plus other people can get the benefit of your work. (