Editor's note: Ryan Bloom has been one of the core developers of Apache 2.0. We spotted him at the Covalent booth during Linux World in New York last January and asked him to write a series of columns explaining the new version of Apache to O'Reilly Network readers. Here's his first column, covering what's new in Apache 2.0 and how to install it.
The Apache developers have been working on Apache 2.0 for the last two years, and on April 4, the first public beta of Apache 2.0 was released. This is the first in a series of six monthly columns in which we'll explain how Apache 2.0 differs from Apache 1.3, and why Apache users should care.
Apache's New Numbering Scheme
On Wednesday, March 28th, the Apache Group released Apache 2.0.15 as an alpha version. This is the second Apache 2.0 release to use the new numbering scheme.
In previous versions, the Apache Group released a series of alpha and beta releases, and then began to release point releases -- all of GA quality code -- so that 1.3.0, 1.3.1, 1.3.2, and so on were all considered released versions of Apache.
This means that the group is put in the position of needing to release point releases without ever having put them through an alpha or beta cycle. Starting with Apache 2.0.14, the Apache Group has changed our release strategy. Every release has a number, and releases always start as alphas. Once the release has been in use, it can be upgraded to a beta or GA quality. This allows each Apache release to be thoroughly tested in real-world situations before a decision is made regarding its quality. This model is very different from the way most open-source software projects are released. For users, this means that a package they download as an alpha one day, could be a beta the following day.
Related Apache Articles:
One of the most important changes is the added multi-threading support to Apache 2.0. Version 1.3 relied on processes to serve requests, and that was a performance hit on many operating systems. Threads combined with processes make Apache 2.0 more scalable.
The second advantage over Apache 1.3 is filtered input/output (I/O), which allows one module to modify the output of another module. An often-requested feature of Apache 1.3 was for CGI scripts to output SSI tags. This wasn't possible in version 1.3, however filtered I/O allows this to work in Apache 2.0.
Apache 2.0 will also provide support for SSL without any modifications to the core. There is already a
mod_tls, which although minimal currently, will be extended in time to provide full SSL support.
The first hurdle to using Apache 2.0 is configuration and installation of Apache. There are two forms of configuration -- compile-time and run-time. This article will focus on getting a tarball, compiling it, and then installing it.
Before we can begin, download the latest version of Apache 2.0. The best place to get a stable copy of Apache, is from the Apache web server home page.
If you are a developer who wants to download the latest development version, you should go to the Apache developers page, and read through the relevant links about getting code from CVS.
This article will assume that you are using the Apache 2.0.15 tarball, although future versions of Apache should be very similar. Once you have the tarball, unzip and untar it with the command
tar -xvzf httpd-2*.tar.gz .
Now we can get to work configuring Apache itself. In previous versions of Apache, there were two different models for configuring Apache, each of which had been rolled by the Apache Group itself. The first method was to use a text file that controlled which components were built. The second was an "autoconf-like" system, which in reality just modified the text file for you.
With Apache 2.0, the Apache developers decided they were more interested in writing a web server than maintaining a configuration system. So, Apache 2.0 uses
libtool to determine which components of Apache are built. Tarballs downloaded from the Apache site already have the configure script created, but for those who have downloaded a development version to generate the configure script, run the command
./buildconf. This will traverse all of the required directories to ensure that you have all of the software components required by Apache.
At this point, you should have a configure script at the top-level of the Apache 2.0 tree. This is the script that actually configures Apache. However, configure script has many options that allow users to control every aspect of how Apache is built. A complete list of options can be found by running:
Discussing every possible option is beyond the scope of this article, but I will cover some of the most common and most useful options.
--prefix. Specifies where to install Apache
--with-maintainer-mode. Compiles with full debugging options. This will be an important option, at least until the server reaches a stable release.
--with-mpm. Specifies which multiprocessing module will be used. MPMs are an integral part of Apache 2.0, and I will discuss them briefly below. A more in-depth discussion can be found online.
--enable-module. Specifies which modules should be compiled into Apache. This can be either a list of modules, or the keyword most, which configures a hard-coded list of modules.
--enable-mods-shared. Specifies which modules should be compiled as shared modules.
Ryan Bloom is a featured speaker at the upcoming O'Reilly Open Source Convention in San Diego, CA, July 23 - 27, 2001. Take this opportunity to rub elbows with open source leaders while relaxing in the beautiful setting of the beach-front Sheraton San Diego Hotel and Marina. For more information, visit our conference home page. You can register online.
Multiprocessing Modules (MPMs) let you tune Apache 2.0 for any site. What works on one site or operating system may not work well on another. To solve this problem, system administrators can specify how their Apache server runs. Some OSes have more options than others. For example, on Unix there are three standard MPMs:
Windows, on the other hand, has only one option:
Once the configure script has run, we must build the server. This is done by running
make in the top-level of the Apache source directory. The final step is to actually install the new server, which is done by running
make install. This command will copy the server binaries and support files into the directory specified with the
--prefix option to the configure script. If no prefix is specified, then
/usr/local/apache is used by default.
We are almost done now. If the install succeeded, you should be able to change to the installation directory and run
./bin/apachectl start. However, we need to know which port the server is listening on. If you installed as root, it should use port 80, the default HTTP port, however if you installed as some other user Apache defaults to port 8080. This can be modified by editing the
httpd.conf file, and searching for the
Port directive. Now, start up your favorite browser and request the page, either
http://localhost:8080/, depending on the port. You should see the default Apache web page. If you don't, the error log should tell you what happened.
You have just set up your first Apache 2.0 web server, and should now be serving pages. Remember that this server is not a released product yet, so there are likely to be some bugs. If you find any, please report them through the Apache bug database.
Next month, I will focus more on the run-time configuration as I discuss how to how to migrate your servers from Apache 1.3 to Apache 2.0.
Ryan Bloom is a member of the Apache Software Foundation, and the Vice President of the Apache Portable Run-time project.
Related Apache Articles
Getting, Installing, and Running Apache
Deploying Web Applications to Tomcat
Securing Your Apache Serve (Chapter 3 from Apache: The Definitive Guide)
AxKit: An XML-Delivery Toolkit for Apache
An Amble Through Apache Configuration
Read more Apache 2.0 Basics columns.
Return to the Linux DevCenter.
Copyright © 2009 O'Reilly Media, Inc.