Apache Cookbook
The Apache Web server is a remarkable piece of software. The basic package
distributed by the Apache Software Foundation is quite complete and very
powerful, and a lot of effort has gone into keeping it from suffering software
bloat. One facet of the package makes it especially remarkable: it includes
extensibility by design. In short, if the Apache package right out of the box
does not do what you want, you can generally extend it so that it does. Dozens
of extensions (called modules) are included as part of the package distributed
by the Apache Software Foundation. And if one of these doesn’t meet your
needs, with several million users out there, there is an excellent chance
someone else has already done your work for you, someone who has concocted a
recipe of changes or enhancements to the server that will satisfy your
requirements.
This book is a collection of these recipes. Its sources include tips from the firehose of the Usenet newsgroups, the Apache FAQ, Apache-related mailing lists, mail containing “how-to†questions, questions and problems posed on IRC chat channels, and volunteered submissions.
All of the items in this book come from real-life situations, encountered either by us or by other people who have asked for our help. The topics range from basic compilation of the source code to complex problems involving the treatment of URLs that require SSL encryption.
We’ve collected more than a hundred different problems and their solutions, largely based on how often they occurred, and have grouped them roughly by subject as shown in What’s in This Book.
Primarily, these recipes are useful to webmasters who are responsible for the entire server; however, many are equally applicable to users who want to customize the behavior in their own Web directories through the use of
We’ve written the Apache Cookbook to be a practical reference, rather than a theoretical discourse: reading it recipe by recipe, chapter by chapter, isn’t going to reveal a plot (“Roy Fielding in the Library with an RFC!â€[1] ). It’s intended to provide point solutions to specific problems, located through the table of contents or the index.
Because much of the material in this book is drawn from question-and-answer
discussions and consultations, we have tried to make it as complete as possible.
Of course, this means that we have included “recipes†for some questions to
which there are currently no satisfactory answers (at least to our knowledge).
This has not been done to tease, annoy, or frustrate you; such recipes are
included to provide completeness, so that you will know those problems have been
considered rather than ignored.
Very few problems remain insoluble forever, and these incomplete recipes are the ones that will receive immediate attention on the book’s Web site and in revisions of the book. If a reader has figured out a way to do something the book mentions but doesn’t explain, or omits mentioning entirely, our research team can be notified, and that solution will go on the Web site and in the next revision.
Who knows, you may be the one to provide such a solution!
For this Cookbook to be useful, you need to install the Apache Web server
software. So what better way to start than with a set of recipes that deal with
the installation?
There are many ways of installing this package; one of the features of open software like Apache is that anyone may make an installation kit. This allows vendors (such as Debian, FreeBSD, Red Hat, Mandrake, Hewlett-Packard, and so on) to customize the Apache file locations and default configuration settings so that these settings fit with the rest of their software. Unfortunately, one of the consequences of customization is that the various prepackaged installation kits are almost all different from one another, which means that when it comes to getting assistance, you need to find someone familiar with the kit you’re using.
In addition to installing it from a prepackaged kit, of which the variations are legion, there’s always the option of building and installing it from the source yourself. This has both advantages and disadvantages; on the one hand, you know exactly what you installed and where you put it, but, on the other hand, it’s possible that binary add-on packages will expect files to be in locations other than those you have chosen.
If setting up the Web server is something you’re going to do once and never again, using a packaged solution prepared by your system vendor is probably the way to go. However, if you anticipate applying source patches, adding or removing modules, or just fiddling with the server in general, building it yourself from the ground up is probably the preferred method. (The authors of this book, being confirmed bit-twiddlers, always build from source.)
This chapter covers some of the more common prepackaged installation varieties and also how to build the server from the source yourself.
Throughout the chapter, we assume that you will be using dynamic shared objects (DSOs) rather than building modules statically into the server. The DSO approach is highly recommended; it not only makes it easy to update individual modules without having to rebuild the entire server, but it also makes adding or removing modules from the server’s configuration a simple matter of editing the configuration file.
DSOs on Unixish systems typically have a
You have a Red Hat Linux server and want to install or upgrade the Apache Web
server on it using the packages that Red Hat prepares and maintains.
If you are a member of the Red Hat Network (RHN), Red Hat’s subscription
service, you can use Red Hat’s up2date tool to maintain your Apache
package:
The
If you use the packages Red Hat maintains for its own platform, you will
benefit from a simple and relatively standard installation. However, you can
only update versions for which Red Hat has put together an RPM package, which
typically means that you may be lagging weeks to months behind the latest stable
version.
There is also the issue of platform compatibility; for instance, at some point the version of Apache provided for Red Hat Linux changed from 1.3 to 2.0, and newer versions of the operating system will probably only have the 2.0 packages available. Similarly, if you run an older version of Red Hat Linux, the newer packages will probably not install properly on your system.
It’s a good idea to install the
This book is a collection of these recipes. Its sources include tips from the firehose of the Usenet newsgroups, the Apache FAQ, Apache-related mailing lists, mail containing “how-to†questions, questions and problems posed on IRC chat channels, and volunteered submissions.
All of the items in this book come from real-life situations, encountered either by us or by other people who have asked for our help. The topics range from basic compilation of the source code to complex problems involving the treatment of URLs that require SSL encryption.
We’ve collected more than a hundred different problems and their solutions, largely based on how often they occurred, and have grouped them roughly by subject as shown in What’s in This Book.
Primarily, these recipes are useful to webmasters who are responsible for the entire server; however, many are equally applicable to users who want to customize the behavior in their own Web directories through the use of
.htaccess files.We’ve written the Apache Cookbook to be a practical reference, rather than a theoretical discourse: reading it recipe by recipe, chapter by chapter, isn’t going to reveal a plot (“Roy Fielding in the Library with an RFC!â€[1] ). It’s intended to provide point solutions to specific problems, located through the table of contents or the index.
What’s in This Book
Very few problems remain insoluble forever, and these incomplete recipes are the ones that will receive immediate attention on the book’s Web site and in revisions of the book. If a reader has figured out a way to do something the book mentions but doesn’t explain, or omits mentioning entirely, our research team can be notified, and that solution will go on the Web site and in the next revision.
Who knows, you may be the one to provide such a solution!
Chapter 1. Installation
There are many ways of installing this package; one of the features of open software like Apache is that anyone may make an installation kit. This allows vendors (such as Debian, FreeBSD, Red Hat, Mandrake, Hewlett-Packard, and so on) to customize the Apache file locations and default configuration settings so that these settings fit with the rest of their software. Unfortunately, one of the consequences of customization is that the various prepackaged installation kits are almost all different from one another, which means that when it comes to getting assistance, you need to find someone familiar with the kit you’re using.
In addition to installing it from a prepackaged kit, of which the variations are legion, there’s always the option of building and installing it from the source yourself. This has both advantages and disadvantages; on the one hand, you know exactly what you installed and where you put it, but, on the other hand, it’s possible that binary add-on packages will expect files to be in locations other than those you have chosen.
If setting up the Web server is something you’re going to do once and never again, using a packaged solution prepared by your system vendor is probably the way to go. However, if you anticipate applying source patches, adding or removing modules, or just fiddling with the server in general, building it yourself from the ground up is probably the preferred method. (The authors of this book, being confirmed bit-twiddlers, always build from source.)
This chapter covers some of the more common prepackaged installation varieties and also how to build the server from the source yourself.
Throughout the chapter, we assume that you will be using dynamic shared objects (DSOs) rather than building modules statically into the server. The DSO approach is highly recommended; it not only makes it easy to update individual modules without having to rebuild the entire server, but it also makes adding or removing modules from the server’s configuration a simple matter of editing the configuration file.
DSOs on Unixish systems typically have a
.so
extension; on Windows, they end with a .dll
suffix.Installing from Red Hat Linux’s Packages
Problem
Solution
# up2date -ui apache apache-devel apache-manual
If you’re running a more recent version:# up2date -ui httpd httpd-devel httpd-manual
If you aren’t a member of RHN, you can still download the packages from one
of Red Hat’s servers (either ftp://ftp.redhat.com or ftp://updates.redhat.com), and install it
with the following command:# rpm -Uvh apache
Discussion
-Uvh option to the rpm command tells it to:-
Upgrade any existing version of the package already on the system or install
it for the first time if it isn’t.
-
Explain the process, so that you can receive positive feedback that the
installation is proceeding smoothly.
-
Display a pretty line of octothorpes (
#) across the screen, marking the progress of the installation.
There is also the issue of platform compatibility; for instance, at some point the version of Apache provided for Red Hat Linux changed from 1.3 to 2.0, and newer versions of the operating system will probably only have the 2.0 packages available. Similarly, if you run an older version of Red Hat Linux, the newer packages will probably not install properly on your system.
It’s a good idea to install the
apache-devel
package as well. It’s quite small, so it won’t have much impact on your disk
usage; however, it includes files and features that a lot of third-party modules
will need in order to install properly.
No comments:
Post a Comment