10

I install NGinx from source since the packages from the ubuntu repository are quite old. I was wondering what is the best method to upgrade these types of installations?

My current workflow involves.

  • Downloading the new source
  • Install the software with the same paths.
  • Restarting the software.

Something tells me this is not the best route.

Suggestions?

The Pixel Developer
  • 847
  • 3
  • 9
  • 20

6 Answers6

9

You are right to think this isn't the best route. This route requires many manual steps, and is very error prone, and doesn't scale well.

When working with linux distributions, you should stick to the package management as much as possible.

The advantages of using package management:

  • Dependency support
  • Easy installation/removal
  • Software inventory
  • Upgrade/Downgrade support, including handling of configuration files
  • The source package basically documents your build process, and automated it for you once it's written.
  • Package signing
  • and more.

When you start working from source only, you loose all of these great features, and things start to get messy pretty quickly.

In order to solve your spesific problem, you should check out the ubuntu backports repository, maybe they have an updated version for NGinx that you can use.

If they don't have a suitable version, then the best solution would be to create a backported ubuntu package yourself. It really isn't that hard, and it's less work than compiling it from source manually each time. Backporting requires, basically, taking the source package from ubuntu, replacing the old upsteam tar.gz file with the latest one that you want, and rebuilding the package.

You can use this guide to help you backport the package.

Tom Feiner
  • 16,758
  • 8
  • 29
  • 24
8

I found it quite convenient to installed different version in separate locations and just symlink to the version you want to use, like:

lrwxr-xr-x  1 root  wheel     7B Jun  7 18:26 /usr/local/foo -> foo-1.0
drwxr-xr-x  2 root  wheel   512B Jun  7 18:26 /usr/local/foo-1.0
drwxr-xr-x  2 root  wheel   512B Jun  7 18:26 /usr/local/foo-1.1

The benefits are:

  • minimized service downtime during an upgrade
  • easy rollback
  • you can still use the same o' path, like /usr/local/foo/bin/bar

Of course you still have to re-apply any configuration changes you've done to the previous version, but for that you can use some versioning system (RCS/SVN/GIT) or configuration management tool like Bcfg2.

And, of course this is suitable only for a handful or less hosts.

therek
  • 682
  • 5
  • 6
  • This is what I do in the few cases where building packages isn't a suitable answer, except I usually use /opt instead of /usr/local. – freiheit Jun 07 '09 at 18:27
2

Next time... how about compiling it into a *.rpm or *.deb?

elcuco
  • 357
  • 1
  • 4
  • 10
1

If you're going to be installing this on a single machine, then doing it from source every time is problem the best way. If you are going to be installing this on several machines and you want to make sure it's consistent, it's probably worth learning how to make Debian packages. You could probably use the packaging in Ubuntu as a base.

David Pashley
  • 23,151
  • 2
  • 41
  • 71
1

There isn't a great way. The reason that effective package management was created was to solve this very problem. Upgrading and uninstalling source-compiled things is hard.

I agree with Tom and David.

If this is a one-off case, then re-compiling from source is probably your best bet. If it's on an array of machines, it's definitely time to move to the supported package management.

Matt Simmons
  • 20,218
  • 10
  • 67
  • 114
0

i'm afraid this is the only way. if you have more servers to maintain - consider having separate test environment where you compile and possibly package result of your compilation.

this will slightly standardize your setups and ease deployment on many servers. also you'll not need gcc on production machines [ which many will consider as security benefit ].

pQd
  • 29,561
  • 5
  • 64
  • 106