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:
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:
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 2 distributions look like this instead:
httpd-2.N.NN.tar.gz (Unix gzip 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
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.
blog comments powered by Disqus