* From the Inside Flap

Preface Abstract
The intention of this book is to serve as a broad-based tutorial and reference for the Apache Web server. The book presumes some level of familiarity with computers, but no particular networking background. Though the main discussion focuses on e-commerce, the appendices cover a variety of peripheral information, such as name resolution, TCP/IP, and regular expressions, necessary for creating a functioning Web server. In addition, such topics as electronic payment and database interaction, which are particularly important for e-commerce sites, are covered from a Web administration perspective.Apache

The Apache Web server is the crown jewel of the open source software movement. It costs nothing to obtain, performs better than the competition, and is thus more widely used than all other Web servers combined. At this writing, 61.5 percent of all Web sites worldwide are using the Apache server.

The propagation of open source software is tightly analogous to biological natural selection-the Linuxes and sendmails of the world eventually end up on the cover of Time magazine and are swallowed by the hype machine, while legions of DOS utilities slide slowly but inexorably to the /dev/null of history. Apache would not be popular if it didn't work well.

Apache has another virtue not quite so common in the open source world: it is simple enough that any reasonably competent computer user can master it. God knows I'm no huge fan of Microsoft, but if you gave me a choice between bringing my mother up to speed on either Linux or Windows 2000, I'd pick Windows quicker than you could say "Thomas Penfield Jackson." This is no slur on Linux, by the way; operating systems, particularly multiuser operating systems, are hugely complex. The only way to make them accessible to the average user is to dumb them down.

The collection of tasks delegated to Apache is thankfully not quite so vast. Those of you approaching Apache with little more than self-confidence and a sense of adventure will be relieved to know that the configuration and care of the server itself really isn't a particularly complex task. The trick, depending on your level of experience, will probably be to grasp the fundamental concepts of the operating system, learn the commands to make the machine do what you want it to do, and absorb the jargon. If you're already up on one or more of these topics, then you're really in for a pleasant surprise.A Brief History

The Apache server is descended from the httpd server created by Rob McCool at the National Center for Supercomputing Applications (NCSA). In 1995, httpd was the most popular Web server in existence, but when McCool left NCSA in 1994, development of the program was stalled. A small group of Web administrators formed the core of what came to be known as the Apache Group. The members included

Brian Behlendorf

Roy T. Fielding

Rob Hartill

David Robinson

Cliff Skolnick

Randy Terbush

Robert S. Thau

Andrew Wilson

Together with contributions from Eric Hagberg, Frank Peters, and Nicolas Pioch, the Apache Group incorporated published bug fixes for httpd 1.3, added some new features, and released Apache 0.6.2 in April 1995.

Since then, the Apache group, as they came to be known, has been fine tuning and enhancing the base software. Software ports are now available for virtually all the major operating systems, though the Unix platform remains the forerunner.

The Apache Web server is the end result of an enormous coordinated effort by some extremely skilled programmers. You may ask yourself what motivated them to give Apache away rather than get in line for an IPO. I quote here from the apache Web site:Apache exists to provide a robust and commercial-grade reference implementation of the HTTP protocol. It must remain a platform upon which individuals and institutions can build reliable systems, both for experimental purposes and for mission-critical purposes. We believe the tools of online publishing should be in the hands of everyone, and software companies should make their money providing value-added services such as specialized modules and support, amongst other things. We realize that it is often seen as an economic advantage for one company to "own" a market-in the software industry, that means to control tightly a particular conduit such that all others must pay. This is typically done by "owning" the protocols through which companies conduct business, at the expense of all those other companies. To the extent that the protocols of the World Wide Web remain "unowned" by a single company, the Web will remain a level playing field for companies large and small. Thus, "ownership" of the protocol must be prevented, and the existence of a robust reference implementation of the protocol, available absolutely for free to all companies, is a tremendously good thing.Open Source Software

Apache is an open source product. Traditional shrink-wrapped software typically includes only the executable object code, not the human-readable source code from which it is compiled. Apache and the other open source products include with their distributions not only the executable object code, but also the source code files from which it was created.

From the end user's standpoint, this makes a lot of sense. For example, while I was writing this book, we had a problem in my office. A large commercial software package running on a large commercial operating system got into a state where it stopped responding to input and was, in fact, unkillable. We tried a stack trace and a few other things, but without the source code, there really wasn't a lot we could do. We finally dumped out everything we could and shipped it off to the software vendor for analysis. Presumably, they'll get back to us in a week or two.

As you might imagine, this was pretty frustrating. If we'd been using open source software, we'd probably already have come up with a workaround, if not an actual fix. We're not even real clear on what the problem is, and even if we did know, we have no means of recompiling the software to fix it. We are entirely at the mercy of our vendors.

Of course, this cuts both ways. Because no one is really getting paid for keeping up the open source version of Apache, there is no toll-free number you can dial at 2:00 a.m. if something goes wrong with your server and you can't figure out how to fix it. Support exists in the form of newsgroups and Web sites, but it occurs at the convenience of the supporter, not by demand of the "supportee."

Apache and the other open source software products benefit from their constant exposure to the developer community. Because there are more developers working on each open source project than even the wealthiest corporation could afford to hire, flawed source code is located and fixed more quickly.

I would also suggest that the initial quality of open source code tends to be higher than that which was commercially developed. Because open source developers are motivated by the simple love of programming, you tend to get the best of the best working on open source software. Contrast this with traditional software shops, where much of the day is spent in meetings, on the phone, and trading stocks.Organization of This Book

This book is designed for use by Apache administrators of all skill levels. It assumes some familiarity with basic computer concepts, but no Web administration background is necessary. For those of you who are completely new to Apache, there is a lengthy introductory section, which spells out everything you need to know get started.

Having mastered the basic concepts, you will generally have one or two pet features (Virtual Hosting, for example) that you wish to implement as soon as possible. The chapters of this book are structured as independent essays on various topics. They can be read in any order you like.

Apache is increasingly refined by its exposure to the real world. New features are proposed and implemented every day, sometimes as enhancements of the core server functionality, more often as new or improved modules. For that reason, even expert users will, from time to time, need to expand their sphere of competence. Hopefully, this book has something to offer even to the experienced Apache administrator.

Finally, the appendices discuss a variety of networking and programming topics. Many of them aren't strictly Apache related, but because Apache needs a functioning network, your Web administration career will likely include a certain amount of general-purpose network administration and programming skills. The appendices aren't comprehensive, but I'd like to think they'll be handy.Part I: The Basics

Part I covers the basic concepts and techniques of Apache administration. It walks you through the process of obtaining and installing an Apache server configured to meet your needs. If you haven't had previous exposure to Apache, you should read the first four chapters in sequence, particularly Chapter 1, "Basic Concepts." The information in Chapters 1 through 4, together with the appendices, is enough to get you going from a standing start. Part II: Advanced Administration

Part II describes the more advanced features of Apache. Once you've got a handle on the basic concepts, you can feel free to jump around the chapters in Part II more or less at will. Each chapter is intended as a self-contained essay on whatever topic is suggested by the title.Part III: e-Commerce

Part III discusses topics of particular interest to e-commerce sites, database connectivity, and the mechanisms of collecting money over the Web. The last chapter is a case study in creating the infrastructure of an e-commerce site.Appendices

The appendices contain information which is either too raw to fit in with the rest of the book (for example, directive syntax) or more in the nature of background information (for example, Appendix G, "Unix Concepts"). Some are presented in the form of short tutorial essays; others are straightforward references.How To Use This Book

Throughout the book you'll find example commands and configuration directives, always accompanied by at least some explanation and sometimes by example output. In general, I don't provide detailed syntax information for directives and system commands in the regular chapters. That sort of thing is found in the appendices, particularly in Appendix A, "Core Directives," and Appendix B, "Other Directives." Hopefully, you'll be able to glean from the context the general nature of any command with which you are unfamiliar.

The success or failure of any given Apache transaction depends on the internal server configuration, the content being transferred, the configuration of the underlying operating system, and the vagaries of the network support services. Therefore, it is impossible to say with absolute certainty that the examples presented herein will run on your particular machine. You have my solemn vow that I typed each and every one of them in and they worked for me.

In some cases, the starting configuration of a particular chapter was developed in an earlier chapter. For example, the Virtual hosts which are secured in Chapter 8 were created in Chapter 4. If the meaning of a particular configuration directive is unclear, consult the index and read about its ancestry in an earlier chapter.

Note that the example OS commands are frankly prejudiced toward the Unix environment in general and Linux in particular. This is no coincidence; my main test server as I was writing this book was a Linux machine, though some work was also done on Windows NT, Windows 95, and Mac OS X.

One Unix convention that I'm fond of, but that you don't generally see in Apache documentation, is the practice of specifying some environment variable to contain a lengthy directory path. Throughout this book you will sometimes see the Unix system variable$APACHE

used to indicate the main directory in which Apache is installed. (This directory is known as ServerRoot in the configuration files.)

Finally, I tried to subdivide the discussion of the individual directives with some sort of meaningful headers. While most of the Apache directives have names that give a reasonably proficient computer user some idea of their function (for example, AddModule and Port), others refer to functionality that is specific to Apache and difficult to describe in twenty characters or less (for example, DocumentRoot). To make it easier for you to find what you're after just by flipping through the book, I'm using headers such as Where to Find HTML Files: DocumentRoot.

In general, I think this is a pretty good idea and I'm sticking by it. However, there was one unforeseen and rather lamentable side effect: From time to time, I found myself discussing a directive whose name was so self-explanatory that I could find no good way to rephrase it. I couldn't avoid putting in a header, because that's bad formatting and my editor would yell at me. In such cases, I was left with no alternative but to spell out an explanation of functionality that was already painfully obvious from the directive name, such as Specify an SSL Level: SSLLogLevel.

You have my apologies in advance.

If you have any questions, comments, corrections, or suggestions for improvement, please feel free to contact me at s_hawkins@mindspring.Hydra

As an afterword, some of you may be wondering about the significance of the critter on the cover of the book. It's called a hydra, and it was painted by by a guy named Tom Post. The theme of the cover art on Prentice Hall's open source books is mythological beasties, and the hydra is actually a pretty good choice for Apache. Apache, you see, is typically found with many instances of itself running on the same machine, not unlike the multiple heads of the hydra. Get it? Credit to my editor, Miles Williams, for picking out a a mythological character with sharp teeth and not sticking me with a unicorn or a nymph or something like that.