Home arrow Apache arrow Page 3 - Building Apache the Way You Want It

General Options - Apache

Have you ever wanted to customize Apache? This article will help you get started on building a customized version of Apache to suit your own needs. It is taken from chapter three of the book Pro Apache third edition, written by Peter Wainwright (Apress, 2004; ISBN: 1590593006).

  1. Building Apache the Way You Want It
  2. Building Apache from Source
  3. General Options
  4. Enabling or Disabling Modules in Bulk
  5. Changing the Module Order (Apache 1.3)
  6. Building Apache from Source As an RPM (Apache 2)
  7. Advanced Configuration
  8. Determining Apacheís Locations Individually
  9. Choosing a MultiProcessing Module (Apache 2)
  10. Building Apache with suExec support
  11. Configuring Apache 2 for Cross-Platform Builds
  12. Configuring the Build Environment
  13. Building Modules with apxs
By: Apress Publishing
Rating: starstarstarstarstar / 14
August 18, 2005

print this article



Before plunging into detail about various configuration parameters, itís worth pointing out a few options that adjust the overall configuration process or provide information about the process and about configure itself. Some of these options are unique to Apache 1.3, and others are new in Apache 2 (see Table 3-1).

Table 3-1. Apache 2 configure Script Options  


Description Compatibility


Prints out a complete list of the configuration

parameters and their allowed parameters and

permutations, along with their default settings.

Because new options appear from time to time, itís

well worth printing out a copy of this output for

reference, or even saving it:

$ ./configure --help > configure.help

You can find some additional options for

Apache 2 by running the configure scripts in the

subdirectories of srclib: apr, apr-util, and pcre.


Specifies an alternative name for config.cache, Apache 2 only

which stores the results of the operating system

analysis performed by configure and thatís used

by config.status mentioned previously.


Suppresses most of configureís output. Mostly useful


for driving configure from another application such

as a GUI configuration tool and for administrators

who just want to know when itís all over.


Goes through the configuration process and Apache 2 only

produces the usual messages on the screen but

doesnít actually create or modify any files.


Displays the complete list of locations that Apache Apache 1.3 only

will use to install and subsequently look for its various

components. This includes the server root, document

root, the names and locations of the configuration file

and error log, where loadable modules are kept, and

so on. Itís useful for checking that directives to change

Apacheís locations are working as expected.

Table 3-1.  Apache 2 configure Script Options (Continued)  





The location of the source code, in the event youíre using a configure script located outside of the distribution.

Apache 2 only


Produces extra long output from the configuration

Apache 1.3 only



Displays the version number of autoconf that was used to create the configure script itself.

Apache 2 only

Setting the Default Server Port, User, and Group

A number of the configuration directives that you have to set in httpd.conf can be preset using a corresponding option at build time. In particular, you can set the user and group under which the server runs and the port number to which itíll listen. What makes these different from other values that might seem to be just as importantófor example, the document rootóis that, for varying reasons, it may be particularly useful or even necessary to specify them in advance.

The port is a required setting of Apache 2; the server wonít start without it being explicitly configured. Specifying it at build time will cause Apache to add a corresponding line into httpd.conf. Without it, youíll need to edit httpd.conf, so if you want to create an immediately usable Apache, you must set it here, too. You can change it with the --with-port option, for example:

$ ./configure --with-port=80 ...

In Apache 1.3 the default port number in httpd.conf is set to 80 automatically, so this option neednít be specified for a server running on the standard HTTP port. Of course, editing httpd.conf to add or change it isnít a great burden, either.

The user and group affect the suExec wrapper (covered shortly), so you must set them at build time. In Apache 1.3 you use the --server-uid and --server-gid options to do this. The corresponding Apache 2 options are --with-server-uid and --with-server-gid. For example, to set the user to httpd and the group to the httpd group, youíd use the following for versions 1.3 and 2, respectively:

[1.3]$ ./configure --server-uid=httpd --server-gid=httpd ...
[2.0]$ ./configure --with-server-uid=httpd --with-server-gid=httpd ...

You can set a number of other directives in httpd.conf that relate to the locations of things such as the document root and the default CGI directory by overriding parts of Apacheís default layout. I cover this in detail in the ďAdvanced ConfigurationĒ section a little later in the chapter.

Determining Which Modules to Include

Other than optimizing Apache for the platform itís to run on, the most useful aspect of building Apache is to control which modules are included or excluded. If you want to build a dynamic server, itís often simpler to build everything dynamically and then subsequently weed out the modules you donít want from the server configuration. However, choosing modules at build time is essential for static servers because you canít subsequently change your mind. It can also be useful on platforms where some modules simply wonít build and you need to suppress them to avoid a fatal error during compilation.

Apache will build a default subset of the modules available unless you tell it otherwise; you can do this explicitly by naming additional modules individually, or you can ask for bigger subsets. You can also remove modules from the list, which allows you to specify that you want most or all of the modules built, and then make exceptions for the modules you actually donít want.

You specify module preferences using the enable and disable options. The syntax of these is one of the areas where the Apache 2 and Apache 1.3 configure scripts differ quite significantly. In fact, itís likely to be one of the bigger problem areas for administrators looking to migrate. However, although the Apache 2 syntax is more flexible, it still offers essentially the same functionality. To simplify the task for administrators who are looking to migrate, Iíll present the various ways you can control the module list with examples for both versions of Apache.

Iíll also tackle building Apache as a fully static server first before going on to building it as a fully or partly dynamic server.

Enabling or Disabling Individual Modules

Apache 1.3 provides the generic --enable-module option, which takes a single module name as a parameter. To enable mod_auth_dbm and add it to the list of modules that will be built, use this:

[1.3] $ ./configure --enable-module=auth_dbm

Apache 2 replaces this with a more flexible syntax that provides a specific option for each available module. To fit in with the naming convention for options, module names with underscores are specified with Ė (minus) signs instead, so the previous command in Apache 2 becomes either one of these:

[2.0] $ ./configure --enable-auth-dbm
[2.0] $ ./configure --enable-auth-dbm=yes

Disabling a module is similar. To remove mod_include and mod_userdir, which by default are included, use this:

[1.3] $ ./configure --disable-module=include --disable-module=userdir

or in Apache 2, use this:

[2.0] $ ./configure --disable-include --disable-userdir
[2.0] $ ./configure --enable-include=no --enable-userdir=no

As mentioned earlier, in Apache 2 you can use the new --enable-modules option along with a list of module names. Notice the pluralóthis isnít the same as Apache 1.3ís --enable-module. Unfortunately, thereís as yet no equivalent --disable-modules option. So to enable DBM authentication, URL rewriting, and all the proxy modules but disable user directories, as-is responses, and the FTP proxy, you could use this:

[2.0] $ ./configure --enable-modules="auth_dbm rewrite proxy" \
                  --disable-userdir --disable-asis --disable-proxy_ftp"

This adds mod_auth_dbm, mod_rewrite, and mod_proxy and then removes mod_userdir, mod_asis, and mod_proxy_ftp (which was enabled when you enabled mod_proxy).

You can obtain the list of available modules, and their default state of inclusion or exclusion, from the configure --help command. This produces an output that includes the following section (this particular example is from an Apache 1.3 distribution because Apache 2ís configure doesnít yet provide this information):

[access=yes      actions=yes    alias=yes      ]
[asis=yes        auth=yes       auth_anon=no   ]
[auth_db=no      auth_dbm=no    auth_digest=no ]
[autoindex=yes   cern_meta=no   cgi=yes        ]
[digest=no       dir=yes        env=yes        ]
[example=no      expires=no     headers=no     ]
[imap=yes        include=yes    info=no        ] [log_agent=no    log_config=yes log_referer=no ]
[mime=yes        mime_magic=no  mmap_static=no ] [negotiation=yes proxy=no       rewrite=no     ]
[setenvif=yes    so=no          speling=no     ]
[status=yes      unique_id=no   userdir=yes    ]
[usertrack=no    vhost_alias=no                ]

This tells you the names of the modules to use with configure and which modules Apache will build by default. Unfortunately, it doesnít take account of any other parameters you might add, so you canít use it to check the result of specifying a list of enable and disable options.

Once youíve run the configure script and set up the source code for compilation and installation, you can build and install Apache with this:

$ make
# make install

Once this is done, you can go to the Apache installation directory, make any changes to httpd.conf that you needósuch as the hostname, port number, and server administratoróand start up Apache. You could also just type make install, but doing it in two steps will allow you to perform a last-minute check on the results of the build before you actually install Apache.

>>> More Apache Articles          >>> More By Apress Publishing

blog comments powered by Disqus
escort Bursa Bursa escort Antalya eskort


- Apache Unveils Cassandra 1.2
- Apache on ARM Chips? Dell and Calxeda Help M...
- The Down Side of Open Source Software
- VMware Unveils Serengeti for Apache Hadoop
- SAP Takes Steps to Improve Hadoop Integration
- Looking to Hone Apache Hadoop Skills?
- How to Install Joomla on WAMPP
- Working with XAMPP and Wordpress
- GUI Available for Apache Camel
- Reduce Server Load for Apache and PHP Websit...
- Creating a VAMP (Vista, Apache, MySQL, PHP) ...
- Putting Apache in Jail
- Containing Intrusions in Apache
- Server Limits for Apache Security
- Setting Permissions in Apache

Developer Shed Affiliates


Dev Shed Tutorial Topics: