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

Changing the Module Order (Apache 1.3) - 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



One of the consistent bugbears of configuring Apache 1.3 servers is getting the loading order of the modules correct. This is because the order in which the modules are loaded into the server determines the order in which the Apache core calls them to handle requests.

Apache 2 does away with all of this by allowing modules to specify their own ordering preferences. As a result, the ordering problem no longer exists in Apache 2, and neither do the compile-time options to change it.

For administrators still using Apache 1.3, it remains a problem, so the configure script provides options to allow you to reorder modules. With a dynamic server, this step isnít essential because you can change the order of modules just by changing the order of the LoadModule directives that load them:

# load modules in inverse priority
LoadModule vhost_alias_module libexec/mod_vhost_alias.so
LoadModule setenvif_module libexec/mod_setenvif.so

However, getting the order right at compile time will result in an httpd.conf with the modules already in the correct order. A static server has no such ability, so the build process is the only chance you get to determine the default running order.

Because of this, Apache 1.3 provides the ClearModuleList and AddModule directives. These allow the running order of modules to be explicitly defined, overriding the order in a static Apache server and the LoadModule directives of a dynamic server:

# initial loading order comprises static modules
# add dynamic modules added to the end - that is at higher priority
(LoadModule directives)
# erase existing loading order
# define new loading order
AddModule mod_vhost_alias.c
AddModule mod_setenvif.c

The loading order is important because modules listed later in the configuration file get processed first when URLs are passed to modules for handling. If a module lower down the list completes the processing of a request, modules at the top of the list will never see the request, and any configuration defined for them will not be used. This is significant for two particular cases:

Authentication modules such as mod_auth, mod_auth_anon, and mod_auth_dbm are processed in the opposite order to the order in which theyíre loaded. If you want DBM authentication to be applied first, you need to ensure that itís loaded last. One reason for doing this is to authenticate most users from a database but allow Apache to fall back to basic authentication for one or two administrators so they can still gain access in the event the database is damaged or lost.

Aliasing and redirection modules such as mod_alias, mod_vhost_alias, mod_speling, and mod_rewrite modify URLs based on the inverse of the order in which theyíre loaded. For this reason, mod_vhost_alias usually loads first, so the others have a chance to act. In addition, for mod_rewrite to be used together with mod_alias, mod_alias must be loaded first.

By looking at the configuration file, you can see the running order for dynamic servers. For static servers, httpd -l lists the modules in the server in the order theyíre loaded. Servers can have both types of modules, in which case the static modules load first and the dynamic ones second. You can override this by using ClearModuleList, followed by AddModule directives to reconstruct the module order. This is also the only way to make a static module come before a dynamic one.

You can alter the running order of modules at build time with the --permute-module option. This takes a parameter of two module names, which are then swapped with each other in the loading order:

$ ./configure --permute-module=auth:auth_anon

This causes mod_auth (which is normally loaded before mod_auth_anon) to be loaded after it, so you can perform file-based authentication before anonymous authentication. Because Apache simply swaps the modules without regard the position of any other modules, this is most useful when modules are adjacent or near each other, such as the various authentication modules. This also means that the previous is equivalent to this:

$ ./configure --permute-module=auth_anon:auth

Alternatively, you can also specify two special tokens to move a module to either the start of the list or the end:

$ ./configure --permute-module=BEGIN:vhost_alias $ ./configure --permute-module=setenvif:END

Both these examples are real-world ones. mod_vhost_alias should usually be the last of the aliasing modules to be polled as outlined previously, and mod_setenvif should usually be one of the first, so it can set variables in time for other modules to take notice of them.

The END syntax is handy for ensuring that a module comes after another, irrespective of their original loading order. However, itíll also cause the module to be processed before all other modules, which might have unforeseen side effects. Likewise, using BEGIN to move a module to the beginning of the list will cause it to be processed last, which will cause problems if it needs to operate before another module.

Fortunately, Apacheís default order is sensible and rarely needs to be modified, so use of this option is thankfully rare, and itís eliminated entirely in Apache 2. In a case when itís important to move a lot of modules around, itís almost always simpler to ignore the build-time configuration and use the ClearModuleList and AddModule directives instead.

However, only modules added with an AddModule directive after ClearModuleList will be available to the server, irrespective of whether theyíre present in the running executable. Although you can simply remove a dynamic module, this is essentially the only way for you to disable a statically linked module. You still incur the cost of carrying the inactive module as a dead weight within the running server, however.

Checking the Generated Configuration

You can capture the running commentary output by the configure script to a file for later analysis. The following command on a Unix platform lets you view the output while the configure process runs and also records the output in a file:

$ ./configure | tee configure.output

Itís good to check the output from the configure script before proceeding to the compilation stageóitíll tell you which modules are available, and of those modules, which ones youíve chosen to build and which you have chosen to ignore.

Itíll also tell you whether Apache has found system libraries for certain features or has defaulted to using an internal version or disabling the featureóthis can have potentially important ramifications for the availability of features in the server that arenít always apparent otherwise. You may not immediately realize that mod_rewrite isnít built to use DBM database maps because it didnít find a DBM implementation to use unless you review the output of the configuration process.

Similarly, Apache requires and comes bundled with a cut-down version of the Expat XML parser. If you already have Expat installed, Apache will use it in preference to building its own copy. This can be important because some third-party modules and frameworks can sometimes behave unreliably if Apache uses a different Expat from the rest of the system. The solution is simple: If you do have Expat but in a directory Apache doesnít expect, then you need to add the --with-expat= <directory> option.

See the section ďConfiguring Apacheís Library and Include PathĒ later in the chapter for more on this and other features that may require additional coaxing including DBM, LDAP, and SSL support.

Both Apache 1.3 and Apache 2 store their default configuration information in a template file and generate an active configuration from it according to the options you request and the capabilities of the operating system. Although you donít need to worry about this in most cases, it can be handy to refer to the files containing the generated configuration both to check the results and also to redo the configuration if need be.

The Generated Configuration in Apache 1.3

Apache 1.3 holds most of its default configuration in a file called Configuration in the src directory, and itís still possible, although largely deprecated in these more modern times, to configure Apache by editing it. Examining it can also be educational as a glimpse into how Apache is put together, even if you choose not to build Apache yourself.

The Apache 1.3 configuration process results in a file called src/Configuration.apaci (so as not to overwrite src/Configuration) and then uses a second script, src/Configure, to produce the files necessary for building Apache based on its contents. You use this script directly if you edit the Apache 1.3 Configuration file by hand; you can also use it to set up the Apache source without altering the configuration settings.

The Generated Configuration in Apache 2

Apache 2 has an almost completely overhauled build configuration system thatís much more easily maintained, as well as being more extensible and similar to other packages that also use autoconf. Despite this, it behaves almost exactly like the familiar APACI configuration interface of Apache 1.3. As a result, most aspects of configuring an Apache source distribution are the same for either version of the server, but there are just enough differences to be inconvenient.

Apache 2 holds most of its default configuration in a file called configure.in, which is presupplied, but it can be regenerated using the buildconf script provided. However, this should only ever be necessary for developers who are pulling the Apache source code from the code repository via CVS. This file isnít designed for editingó Apache 2 intends to determine as much as possible from the platform and the rest from arguments to the configure script, rather than encourage hand editing of preset values.

The Apache 2 configuration process generates build instructions throughout the source tree and additionally creates some useful files that allow you to check and re-create the results:

  • config.nice: This file contains a formatted multiline command line for rerunning the configure script using the same arguments you passed to it the first time. This makes it an executable script that allows you to repeat your steps, as well as provide a convenient way to modify and store your configuration parameters.

  • config.log: This file contains any messages that were produced by the compiler during the various build checks. Usually, itíll contain nothing except a few line number references from configure. These are intended to prefix the different points at which messages might arise, should any appear.

  • config.status: This file contains a script that performs the actual configuration of the source tree using the options that were specified by configure but without analyzing the operating system for the build criteria, stored in config.cache.

>>> 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: