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
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
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:
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:
blog comments powered by Disqus