Home arrow Apache arrow Building Apache the Way You Want It

Building Apache the Way You Want It

Have you ever wanted to customize Apache? This article will help you get started on building a customized version of Apache to suit your own needs. It is taken from chapter three of the book Pro Apache third edition, written by Peter Wainwright (Apress, 2004; ISBN: 1590593006).

  1. Building Apache the Way You Want It
  2. Building Apache from Source
  3. General Options
  4. Enabling or Disabling Modules in Bulk
  5. Changing the Module Order (Apache 1.3)
  6. Building Apache from Source As an RPM (Apache 2)
  7. Advanced Configuration
  8. Determining Apacheís Locations Individually
  9. Choosing a MultiProcessing Module (Apache 2)
  10. Building Apache with suExec support
  11. Configuring Apache 2 for Cross-Platform Builds
  12. Configuring the Build Environment
  13. Building Modules with apxs
By: Apress Publishing
Rating: starstarstarstarstar / 14
August 18, 2005

print this article



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

Why Build Apache Yourself?

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.

Verifying the Apache Source Archive

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.

>>> More Apache Articles          >>> More By Apress Publishing

blog comments powered by Disqus
escort Bursa Bursa escort Antalya eskort


- Apache Unveils Cassandra 1.2
- Apache on ARM Chips? Dell and Calxeda Help M...
- The Down Side of Open Source Software
- VMware Unveils Serengeti for Apache Hadoop
- SAP Takes Steps to Improve Hadoop Integration
- Looking to Hone Apache Hadoop Skills?
- How to Install Joomla on WAMPP
- Working with XAMPP and Wordpress
- GUI Available for Apache Camel
- Reduce Server Load for Apache and PHP Websit...
- Creating a VAMP (Vista, Apache, MySQL, PHP) ...
- Putting Apache in Jail
- Containing Intrusions in Apache
- Server Limits for Apache Security
- Setting Permissions in Apache

Developer Shed Affiliates


Dev Shed Tutorial Topics: