Upgrading Apache - Apache

New versions of Apache are released quite frequently—the latest stable and beta versions are available from the Apache Web site along with notifications of bugs fixed and features added. In general, any recent version of Apache should run with an existing configuration, even if it supports new features.

The important exception is that when upgrading from Apache 1.3 to Apache 2; it may be better to transfer custom configuration details from the old httpd.conf to the new. To avoid mixing up custom and default directives, it may be wise to consider using an Include directive to store changes and additions in a different file to the main configuration to make future migrations simpler (this is described in Chapter 4).

Since version 1.3.4, Apache comes with a unified configuration file rather than three individual files. It isn’t necessary to merge an existing configuration when upgrading to a later version of Apache 1.3 because the other two files are still looked for. However, Apache 2 removes this feature, so Include directives will be needed to restore the original behavior—these and other issues are discussed in more detail in Chapter 4.

NOTE It’s not obligatory to upgrade simply because a new release is available. Unless a software bug or security vulnerability has been fixed that specifically applies to your configuration or platform, or a desired feature is now available, the maxim “if it isn’t broken, don’t fix it” applies. In particular, don’t even consider upgrading a production server to a beta release unless it’s critical to do so, and even so, use a test server to try the new release first. It’s generally far better to apply a work-around to a known bug than to potentially introduce several unknown ones in order to fix it.

Note that if you’re installing Apache from a binary distribution over an existing installation using install-bindist.sh, the script is intelligent enough to copy the new configuration files with .default extensions, leaving the existing files in place. Once the upgrade is installed, you can restart the server. Unless something unusual has occurred, the new Apache should start up with the old configuration without complaint.

In fact, it’s often possible to upgrade Apache just by replacing the existing httpd executable with the new version. However, the new httpd file cannot be copied over the old file if the server is running. Such an attempt would produce an error message such as the following:

$ cp httpd /usr/local/apache/bin
cp: cannot create regular file 'http': Text file busy

Because the old file can be moved aside without disturbing the running server, the following command sequence in the bin directory can be used for carrying out an update:

$ mv httpd httpd.old
$ cp /bindist/bin/httpd httpd
$ apachectl stop
$ apachectl start

Note it’s not sufficient to use kill -HUP to restart the server if you intend to run a new binary; this will only cause the running server to perform a restart. To replace it, the server must be actually shut down and restarted using the new executable.

If you choose to just update the binary, be aware that some of the utility programs that come with Apache may cease to work unless you also replace them with new versions; apxs, the utility for compiling modules for Apache, is one that’s likely to break. Other scripts such as apachectl or htpasswd may continue to run but may be improved in newer releases so should probably be upgraded at the same time.

If you installed Apache from a package, you can upgrade it by performing a package upgrade. For example, using the RPM example from earlier, you can simply execute this:

$ rpm -Uvh apache-1.3.28-1.i386.rpm

This will protect existing configuration files where they have changed and install the new ones with an .rpmnew extension. You may then integrate any new configuration changes you like at your leisure. If you also installed packages such as apache-devel or apache-manual (depending on the platform), you should take care to also upgrade these at the same time. This will even serve to upgrade from Apache 1.3 to Apache 2, but there may be more issues to resolve afterward, in particular in relation to changes in Apache’s configuration syntax.

Before moving on to configuring and testing the server, there are few other issues worth considering.

Time

If you’re planning to run an Internet-accessible server, it’s a good idea to make sure the server’s clock is accurate so that time-dependent information such as the Expires header, cookies, and log messages (particularly when tracking suspicious activity) is handled correctly.

Given Internet connectivity, the ideal solution is to use a time synchronization protocol and receive accurate time from the Internet. The Network Time Protocol (NTP) is one that’s in widespread use and for which free software is available on many platforms. See http://www.eecis.udel.edu/~ntp/ for more information.

Multiple Installations

It’s possible to install Apache more than once. There are several reasons why you might want to do this. For example, you might want to separate a secure server using SSL with a restricted set of features from a more capable nonsecure server. Or you might want to run a privileged server with access restrictions independent of the main server. Running a second server is also an excellent way to test a new release in parallel with the current installation before changing it over to the main server.

One way to do this is to invoke install-bindist.sh with different installation roots. A more concise way, at least in terms of disk space consumed, is to use the same installation but use Apache’s -f option to specify alternative server configuration files.

Whatever the reason, as long as the server configurations use different IP addresses and/or ports, there’s no limit to how many different running installations of Apache you may have.

TIP As an alternative, to keep configurations mostly identical, consider using the -D option to enable optional sections of a single configuration.