- Sample Step-by-Step Installation
- Configuration Reference
- Configuration Special Topics
This chapter is from the book
This chapter is from the book
This chapter is from the book
3.3 Configuration Special Topics
The final section of this chapter examines some special configuration issues on which we've touched only tangentially in previous discussions.
3.3.1 Shadow Source Trees
The --shadow[=Dir] option is very interesting. It can be used to build Apache inside a temporary location without copying the entire Apache source tree (15MB in size). This option is useful mainly in two situations. First, you can use it when you want to build Apache on a cluster of machines in parallel and want to avoid conflicts (the source then generally stays on an NFS-mounted file system). Second, when the Apache source tree resides on a read-only file system (typically a CD-ROM), you must ensure that the build process can write the object files. Both problems are efficiently resolved through shadow trees.
A shadow tree consists of a copy of all directories of the original tree, but with all files inside these directories being replaced by symbolic links to the original files. Such a tree can be created more quickly than a direct tree copy can, and it requires less disk space. You simply specify an additional --shadow option on the APACI command line, and Apache automatically builds inside this tree in the background.
Shadow trees may be employed in two ways:
-
You can specify only "--shadow". In this case, the shadow tree is made only for the src/ subdirectory of the Apache source tree and placed side-by-side to this directory. It is named "src.platform", where platform is the platform identification string. Use this option when you want to build for multiple architectures in parallel.
The flexibility of Apache means that one can easily add third-party modules to extend Apache's functionality.
-
You can specify "--shadow=Dir". In this case, the shadow tree is made for the entire Apache source tree and placed under Dir. Use this option when you want to build from a read-only media.
3.3.2 On-the-Fly Addition of Third-Party Modules
As you may have recognized in our example installation (Section 3.1), third-party modules can be added to the Apache source tree in three ways:
-
They can be automatically added and activated by a script. For instance, mod_ssl uses this approach.
-
They can be automatically added by a script but activated manually by the user. For instance, mod_perl uses this approach.
-
They can be manually added and activated by the user. Most Apache modules provided by third parties use this approach.
This little inconsistency arises because larger modules have more requirements; to make the life of the user easier, these modules partly automate the steps. Don't be alarmed if the complex modules differ. The basic way for manually adding a third-party module in APACI involves three steps:
-
Obtain the module source. For small modules, it is typically a mod_foo-.c source file. For larger modules, it may be a directory containing at least Makefile.tmpl, moc_bar.c, and a few additional source files (conventionally named bar_xxx. c).
Third-party modules differ mainly in size: either they are single source modules or they are contained in their own directory.
-
Add the module source to the Apache source tree somewhere under src/modules. The location selected depends on the module. With a single mod_foo.c, you usually place the source under src/modules/-extra/ by using --add-module=/path/to/foo/mod_foo.c. For larger modules that require their own subdirectory under src/modules/ (say, src/modules/bar), you must establish this directory manually by running "cp -rp /path/to/bar/ src/modules/bar/" and later activate it by using --activate-module=src/modules/bar/libbar.a.
-
Once the third-party modules are fully integrated into the source tree of Apache, you can treat them just like the distributed modules. In both cases, you enable the module for building via --enable-module=foo or --enable-module=bar. The same idea applies when building as a DSO: a simple --enable-shared=foo or --enable-shared=bar is all that is needed.
3.3.3 Module Order and Permutations
You may have recognized the harmless-looking APACI option --permute--module=Name1: Name2. We briefly mentioned that it can be used for changing the order of modules. To fully understand this option and its utility, more knowledge of Apache internals are required.
Use -permutemodule to change the module order at installation time and the execution order at runtime.
As explained in Chapter 2, the functionality of Apache is implemented by modules. An API dispatches the HTTP request processing. During this dispatching a fixed module order is used that is derived from the order employed when building the modules. Actually, it mirrors the order of the AddModule/SharedModule lines in the file src/Configuration.apaci, which APACI generates from src/Configuration.tmpl. When a module comes later in this file, it is dispatched earlier in the processing. For instance, mod_rewrite comes after mod_alias in this file, so mod_rewrite gets control for each API step before mod_alias. As a result, mod_rewrite can manipulate URLs before mod_alias can, but it cannot override results of mod_alias.
For all distributed modules, the order is pre-configured in a reasonable way. Nevertheless, sometimes you may want to change the order of one or more modules. For instance, to give mod_alias higher priority over mod_re-write, you would use the following:
$ ./configure ... --permute-module=alias:rewrite ...
Now mod_rewrite can post-process URLs that were manipulated by mod_alias. On the other hand, when you add a third-party module, it is always appended to the end of src/Configuration.apaci;hence, it gets the highest priority by default. This order often isn't reasonable. For instance, when you have added another URL manipulation module (say, mod_foo), it might be reasonable to ensure that it operates after mod_rewrite and mod_alias. This goal can be achieved by using the following APACI command line:
$ ./configure ... --add-module=/path/to/mod_foo.c --permute-module=foo:BEGIN...
This command moves mod_foo to the beginning of the module list and gives it the lowest priority. More complex module order adjustments can be achieved by combining multiple --permute-module options.