Installing Apache 2.0
Pages: 1, 2
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:
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:
- Prefork -- Same model as Apache 1.3. The parent process creates a set of child processes that are ready to serve a request. Each child process has one thread, and can serve one request at a time. When the server gets busy, it spawns a new child process to increase the number of requests that can be handled.
- Threaded -- Similar to Prefork, except each child has a static number of threads. The exact number is specified at run-time in the
- Perchild -- The parent process creates a specified number of child processes, each with a minimal number of threads. As the server gets busy, the processes create more threads to handle heavier traffic.
Windows, on the other hand, has only one option:
- Winnt -- A model similar to Apache 1.3, where there are two process, the parent is responsible for monitoring the child and ensuring there is always a process serving requests.
Building the server
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
Read more Apache 2.0 Basics columns.
Return to the Linux DevCenter.