APACHE COMES IN ready-to-install binary packages, which for many applications is perfectly adequate. Apache also comes with source code, making it possible to build the entire server from scratch with a suitable compiler.

However, even if you decide to start off by installing a binary distribution, all binary Apache distributions come with a complete copy of the source code included, so you can easily build a customized version of Apache to suit your particular needs.

In this chapter, you’ll look at the following topics:

• Verifying the integrity of the Apache source archive

• Building Apache from source

• Customizing Apache’s default settings

• Determining which modules are included

• Building Apache as a dynamic server

• Advanced building options

• Building and installing modules with the apxs utility

Given the additional work involved, it might seem redundant to go to the trouble of building Apache from source when perfectly good binary distributions are already available for almost any platform you might care to choose. However, there are advantages to building Apache yourself:

Changing the default settings to something more appropriate: Apache has built-in defaults for all configuration settings, including the server root, the location of the configuration file, and the document root. The only notable exception is the network port Apache listens to, which is required in Apache 2 to be defined by the configuration. By setting these at build time, you don’t have to specify them in the configuration, and you can ensure that Apache’s default settings are safe—that is, they don’t point anywhere you don’t want them to point.

The Apache installation process will also substitute your new settings into all scripts and configuration files automatically, so all the parts of the installation are internally self-consistent.

Optimizing the server for your platform: By compiling Apache on the platform where it’s to be installed, you can take advantage of the capabilities offered by the operating system or hardware that a  prebuilt binary can’t take advantage of. For example, although any  x86 processor will run a supplied Apache binary, you can build an optimized binary that takes full advantage of the newer processor features by using a compiler that’s aware of them. There’s no point in retaining a binary that’s built to work on a 386 processor when you  can rebuild it to take advantage of a Pentium 4.

In addition, some platforms have facilities such as advanced memory mapping and shared memory capabilities that Apache can use to improve its performance if the build process detects them. Memory mapping allows data on disk to be presented as memory, making both read and write access to it much faster. Shared memory allows  Apache to efficiently share information between different processes and is useful for many things, including in-memory caches of various information such as Apache’s scoreboard table of running processes.

The prebuilt Apache binaries can’t make assumptions about the availability of these features, so they have to take the lowest  common denominator to maximize compatibility. The great thing about building from source is that Apache works out all of this itself, so all you have to do is start it off and sit back.

Choosing which modules to include: Apache is a modular server, with different parts of the server’s functionality provided by different sections, called modules. You can choose which of these modules you want and build a server precisely customized to your requirements  with all extraneous features removed.

Apache can also build its modules statically into the server or load them dynamically when it’s run. For both static and dynamic servers, you can tell Apache exactly which modules you want to include and which you want to exclude. This allows you to add modules not normally included into the Apache binary, including third-party modules, or to remove modules that you don’t need, to make the server both faster and less prone to inadvertent misconfiguration.

Making changes to the source and applying patches: If no other module or feature supplies this ability, having the source code allows you to add to or modify Apache yourself. Some additional features for Apache don’t come as modules but as patches to the source code  that must be applied before Apache is built. For example, adding SSL to older Apache distributions required this. Also, new patches for implementing or altering features that aren’t yet officially part of Apache appear all the time.

Assuming you’ve decided to build Apache, you’ll need a copy of the source, of course. Source code for both Apache 1.3 and Apache 2 is available from http://httpd.apache.org; use the Download link to retrieve a copy of either version from the closest mirror site.   Depending on your needs, you can choose either the more venerable but well-tried Apache 1.3 or the newer and less-honed (but much  more powerful) Apache 2. Apache 1.3 distributions have a name with the following form:

apache-1.3.NN.tar.gz (Unix gzip archive)
apache-1.3.NN.tar.Z (Unix compress archive)

Apache 2 distributions look like this instead:

httpd-2.N.NN.tar.gz (Unix gzip archive)
httpd-2.N.NN.tar.Z (Unix compress archive)
httpd-2.N.NN-win32-src.zip (Windows ZIP archive)

The configuration process is actually similar across the versions, even though the underlying setup has been fundamentally overhauled for Apache 2 (the devil is, of course, in the details). However, before you start the configuration process you should verify that your source is actually correct.

Before you proceed to customize and build your Apache source distribution, you should take the precaution to verify that what you have is what the Apache Software Foundation actually released. Although the chances may be slim, it’s possible your distribution has been modified or tampered with. Clearly this is less than ideal, so to make sure you have a correct and unmodified copy of the code, you can make use of two verification tools: md5sum and pgp/gpg.

Verifying with md5sum

md5sum (sometimes just md5) computes an MD5 checksum for a block of data—in this case, the source distribution—and writes it out as a 32-character string. The checksum algorithm is one-way, meaning   you can’t derive any information about the original file from it, and although theoretically it’s possible for two different files to generate the same checksum, it’s very improbable. You can use md5sum to check that your file generates the same checksum as the official distribution:

$ md5sum httpd-2.0.47.tar.gz 63f16638c18b140b649fab32b54d7f9c httpd-2.0.47.tar.gz

If you retrieve the checksum from http://httpd.apache.org (not a mirror) by clicking the MD5 link next to the distribution you downloaded, you see that this is the correct value and that therefore your archive is also correct.

Verifying with PGP/GPG

Verifying the MD5 checksum is usually enough for most purposes, but to be absolutely safe, you can’t just check that the archive is correct but that it really was distributed by someone responsible. To do this, you can verify the signature of each archive using either PGP or the equivalent GPG. For more information on how these tools work and  how to use them, see http://www.openpgp.org/ and http://www.gnupg.org/.

Verifying the signature of a file allows you to detect the slim but theoretically possible case where the Apache Software Foundation’s own Web site, or one of its mirrors, has been compromised or that someone has modified the information on an intermediate proxy so  that the pages you’re accessing look like but actually aren’t the originals.

Assuming that you’re using GPG, you first download the public keys for the Apache developers. This is a file called KEYS and is available at http://www.apache.org/dist/ httpd/KEYS. You then import these keys into GPG with this:

$ gpg -import KEYS

Having done this, you download the signature file for the archive you want to verify. This has the same name as the archive file followed with an .asc extension and can be retrieved from http://http.apache.org by clicking the PGP link next to the distribution you downloaded. Save the signature file into the same place you have the archive and then verify that the two match with this:

$ gpg httpd-2.0.47.tar.gz.asc

If the signature agrees with the file, you get a number of messages ending with this (in the case of the previous example):

gpg: Signature made Mon 07 Jul 2003 16:56:49 CEST using DSA key ID DE885DD3
gpg: Good signature from "Sander Striker <striker@apache.org>"
gpg:                aka "Sander Striker <striker@striker.nl>"
gpg: checking the trustdb
gpg: checking at depth 0 signed=0 ot(-/q/n/m/f/u)=0/0/0/0/0/1
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: 4C1E ADAD B4EF 5007 579C 919C 6635 B6C0 DE88 5DD3

If, however, they don’t agree, you get a different message:

gpg: BAD signature from ...

In this event, you shouldn’t proceed further with this archive. Better, you should notify the foundation that you’ve found a possibly compromised archive!

Assuming you got a good signature, you’re most of the way there. However, GPG doesn’t know who the signer was. You know the signature is good, but you don’t know that the person who created the signature is trusted. To do that, you need either to establish that the public key of the signer really does belong to him or to verify the public key of any other individual who has signed it with their private key.

You can take the first step by checking the fingerprint of the signer’s public key from the ID given on the first line and then importing the signatures of that key. You can find the fingerprint with this:

$ gpg -fingerprint DE885DD3

The bottom line of the output from this command should match the Primary Key fingerprint line you got from verifying the signature file. Now you can import the signatures for this key:

$ gpg --keyserver pgpkeys.mit.edu --recv-key DE885DD3

Now all you need to do is verify that any of those signatures are actually good; traditionally, the best way to do this is to meet someone face to face. If you can’t do that, you can import more signatures for each of the public keys until you get one for someone you can actually meet. Having done this, you can edit the verified key to tell GPG you trust it (and to what degree you trust it), which in turn will influence each key signed by it. This is called the Web of Trust, and you can find more information on how it works and how to enter it in the GNU Privacy Handbook at http://www.gnupg.org/ gph/en/manual.html#AEN335.