Stronghold uses a modular architecture that consists of a core Apache server enhanced by a number of modules. Each module implements a different feature set, and you can add, remove, enable, or disable modules to change the total feature set of your server.

This chapter explains

• Stronghold's modules
  
  

  By default, most of the included modules are compiled into Stronghold during installation. "Stronghold Modules" on page 8-2 describes each of the modules distributed with Stronghold Web Server and indicates which ones are compiled into the server by default.

• how to add and remove modules
  
  

  There are several different methods of adding and removing modules from the server. "Adding and Removing Modules" on page 8-5 compares these methods and describes how to use each one.

Since Stronghold's resource requirements are directly proportional to the size of the binary, you may want to pare the server down by removing modules you don't need. You can find out which modules are active in at any time by accessing the server information report described in "Server Information Reports" on page 1-13, or by using the -l flag with the httpsd command:

# httpsd -l

In addition to the modules bundled with Stronghold, many third-party modules are available through the Apache Module Registry at http://modules.apache.org/. Apache modules are compatible with Stronghold. If you are interested in writing your own modules for Stronghold, consult the Apache API Notes at http://www.apache.org/docs/API.html.

Each of Stronghold's modules supports a discrete feature set, and most modules utilize configuration directives. In Chapter 7, each directive entry specifies the module associated with that directive. You can only use a directive if its supporting module is active. If you remove a module, be sure to comment out its directives in httpd.conf, or use <IfModule> to exclude it dynamically as described in "Containers" on page 6-3.

The following modules are bundled with Stronghold, though not all are compiled in by default:

Module	Default?	Description
mod_access		Provides host-based access using the allow, deny, and order directives
mod_actions		Executes scripts based on the file type of the requested document, using the Action and Script directives
mod_alias		Provides file and directory aliasing and redirection
mod_asis		Allows .asis files when httpsd.conf includes this line: AddType httpd/send-as-is asis
mod_auth		Conducts basic authentication
mod_auth_anon		Allows anonymous logins
mod_auth_db		Provides user authentication using Berkeley DB files
mod_auth_dbm		Provides user authentication using DBM files
mod_autoindex		Generates directory indices on the fly
mod_cern_meta		Allows CERN-compatible meta information files
mod_cgi		The Common Gateway Interface, which executes external programs and returns their output to clients. CGI is explained in detail in Chapter 10.
mod_digest		Performs HTTP Digest authentication
mod_dir		Sets the default file to return when the requested URL specifies a directory but not a file
mod_ecash		Facilitates online commerce with clients that support Ecash (US version only)
mod_env		Passes environment variables to CGI programs
mod_expires		Applies an Expires HTTP header field to resources
mod_headers		Generates arbitrary HTTP response headers
mod_imap		Processes server-side imagemaps
mod_include		Parses server-side includes
mod_info		Generates HTML-based server information pages showing the current configuration
mod_log_agent		Logs user agents for NCSA compatibility. However, we recommend using mod_log_config and the CustomLog directive for this purpose.
mod_log_config		Formats the transfer log according to the LogFormat directive
mod_log_referer		Logs referers for NCSA compatibility. However, we recommend using mod_log_config and the CustomLog directive for this purpose.
mod_mime		Maps filenames to MIME types
mod_mime_magic		Maps file structures to MIME types
mod_negotiation		Performs content negotiation
mod_php		Provides HTML-embedded, server-side scripting controlled by the directives in "PHP/FI 2.0 Embedded Scripting" on page 7-84. PHP is explained in detail in Chapter 13.
mod_proxy		Performs proxying and caching
mod_rewrite		Maps URIs to filenames using rewrite rules
mod_setenvif		Sets environment variables conditionally based on regular expression matching
mod_so		Loads shared object files on startup or restart; see "Dynamic Shared Object Support" on page 8-6
mod_speling		Performs spell-checking on failed URLs
mod_ssl		Performs SSL/TLS authentication and encryption
mod_status		Generates HTML-based server status reports showing current server activity
mod_unique_id		Assigns a unique identifier to each request and stores it in an environment variable
mod_userdir		Enables user Web directories
mod_usertrack		Performs session tracking with Netscape cookies

Before you decide to remove one of these modules, be sure you know how its absence affects Stronghold's functionality. For example, you can safely remove mod_status if you are not interested in real-time, HTML-formatted status reports. Removing mod_ssl, however, is not recommended because any HTTPS request will fail.

Stronghold Web Server provides three different methods of adding and removing modules:

• dynamic shared object (DSO) support
  
  

  Dynamic shared object support, provided by mod_so, allows the server to load modules at startup without first having them compiled into the server binary. Under this efficient new scheme, only the server core and mod_so need to be compiled together; all other modules can be loaded at startup.

• dynamic module linking
  
  

  Dynamic module linking saves time by allowing you to edit httpd.conf and reload the server to change the set of active modules. However, it requires that all modules be compiled into the server binary.

• recompiling the server binary
  
  

  The traditional method of adding and removing modules is to recompile the Stronghold binary executable file with a different set of modules. This can take longer, but it can also result in a leaner binary if you do not need to change the module set frequently.

Dynamic shared object (DSO) support allows the server to load modules at startup instead of having them compiled into the server binary. DSO is supported by mod_so, which must be compiled in statically. When mod_so and the server core are compiled statically, they can load other modules at startup that are designated in httpd.conf. DSO support also allows multiple instances of the server to run with different module sets configured with different httpd.conf files.

Although DSO provides a convenient way to add and remove modules quickly, dynamically loaded modules do not perform as efficiently as statically compiled modules. It is recommended that all necessary modules be compiled statically, and that only new, temporary, or seldom-used modules be loaded dynamically.

In order to use DSO support, you must

• edit the Configuration file so that the server core is compiled with mod_so and other required modules and modules that should be dynamically loadable are converted to shared object files
  
  

  This usually needs to be done only once, although you can repeat the process to add DSO support for any third-party modules that you later acquire. After that, the modules that have been converted to shared object files are always available for loading at startup.

• edit the httpd.conf file so that the modules you want to activate are listed for loading at server startup or restart
  
  

  This can easily be done whenever you want to change the set of dynamically loaded modules.

1. Switch to the ServerRoot/src/ directory.
   
   
2. Open the Configuration file using a text editor.
   
   
3. Make sure the following line is uncommented:
   
   

   AddModule modules/standard/mod_so.o
   
   

   This module must be compiled into Stronghold in order to support DSO.

4. For each module that you want to be able to load dynamically, change the AddModule directive to SharedModule.
   
   

   If you have acquired raw source code for third-party modules that you want to load dynamically, add a new SharedModule line for each.

   NOTE:

   The mod_so module cannot be loaded dynamically; it must be compiled in statically.

   
   
5. In all SharedModules lines, change the .o module filename extension to .so. For example, the following line
   
   

   SharedModule modules/standard/mod_dir.o
   
   

   should be changed to

   SharedModule modules/standard/mod_dir.so
   
   

6. Run Configure:
   
   

   # ./Configure
   
   

7. Rebuild HTTPSD:
   
   

   # make
   
   

8. Stop the server:
   
   

   # ../bin/stop-server
   
   

9. Back up the old binary:
   
   

   # mv ../httpsd ../httpsd-bak
   
   

10. Install the new binary:
    
    

    # cp httpsd ..
    
    

The modules designated with SharedModule are now available as shared object files. Before you start the server again (with the ServerRoot/bin/start-server script), you must edit httpd.conf and specify the shared object files that the server will load on startup.

1. Open the ServerRoot/conf/httpd.conf file using a text editor.
   
   
2. In the global server configuration (above all containers in the file), use a LoadModule directive for each module that the server should load at startup.
   
   

   The LoadModule directive has a syntax similar to that of the obsolete Configuration Module directive. For example:

   LoadModule status_module src/modules/mod_status.so
   
   

3. Use a LoadFile directive for each additional object file to load at startup.
   
   

   The LoadFile directive facilitates patches and other auxiliary object code. Its value is one or filenames, either in an absolute path or relative to ServerRoot. For example:

   LoadFile src/enreq.so
   
   

4. Remove modules that should not be loaded at startup either by deleting their LoadModule lines or commenting them out.
   
   
5. Save the modified server configuration file.
   
   
6. Restart the server:
   
   

   # ServerRoot/bin/reload-server
   
   

Stronghold's dynamic module linking system allows you to change the set of active modules without recompiling the server, provided that all the modules you want to use are already compiled. You can use this feature to streamline Stronghold's feature set, but you cannot use it to add modules that are not already compiled. For example, you could recompile Stronghold with all available modules, then use dynamic module linking to narrow down the number of modules that Stronghold actually uses.

The list of modules that are currently compiled is the default list of "active" modules. Dynamic linking first "clears" this list, then applies a new list that Stronghold reads from the httpd.conf file each time it starts. This simplifies module configuration, because you only need to edit httpd.conf and restart Stronghold to implement module changes.

1. In httpd.conf, add the following line:
   
   

   ClearModuleList
   
   

   This clears the default list of active modules.

2. Add the AddModule directive, followed by a new list of active modules. For example:
   
   

   AddModule mod_ssl mod_cgi mod_dir mod_userdir mod_alias
   
   

   Use the module names as they appear in the ServerRoot/src/Configuration file.

3. Save the modified httpd.conf file.
   
   
4. Switch to the ServerRoot directory.
   
   
5. Restart Stronghold by stopping and then starting it:
   
   

   # bin/stop-server
   # bin/start-server
   
   

   NOTE:

   You must use this method instead of the reload-server script whenever you change the dynamic module list.

   
   

If you want to remove an active module, simply delete it from the AddModule list and restart Stronghold. Likewise, you can add modules to the list at any time, then restart Stronghold to implement them.

The Configuration file already contains the code you need to install any module that comes with Stronghold, including the optional modules described later in this chapter. The precompiled modules described on page 8-2 are compiled into Stronghold when you first install it. Optional modules are commented out of Configuration. By uncommenting a line of module code, you can recompile the server to include that module. Commenting out a line of module code and recompiling the server excludes the module.

If you want to reconfigure the PHP module for database support, you must follow the instructions in "Recompiling The PHP Modules" on page 13-3, then recompile Stronghold as described in this section.

The order of the module list in Configuration affects how the modules are compiled. In general, use these guidelines for dealing with the module list:

• Do not change the order of the module list unless you are sure you know what you are doing.
  
  
• If you add third-party modules to the list, place them at the bottom of the list, but above mod_ssl.
  
  
• Always remove a module by commenting it out rather than deleting it, so that you do not lose its place in the list.
  
  

Many third-party modules have not been thoroughly tested for use with Stronghold 2.4.1 and Apache 1.3.2. If you have an existing server with third-party modules that you wish to compile into Stronghold 2.4.1, do so with caution. When using an existing Configuration file or modifying the new Configuration file to include new modules, note these changes:

• The source code has been reorganized; modules are now located in subdirectories of a new ServerRoot/src/modules/ directory.
  
  
• The Module directive has been changed to AddModule.
  
  
• The EXTRA_LFLAGS variable has been changed to EXTRA_LDFLAGS.
  
  
• The -DMAXIMUM_DNS definition is now obsolete.
  
  
• The -DSERVER_SUBVERSION=\"string\" compile-time option has been replaced with the run-time API call ap_add_version_component().
  
  
• The mod_dir module has been divided into mod_dir and mod_autoindex.
  
  
• The mod_auth_msql module is no longer included in the distribution.
  
  

1. Switch to the ServerRoot/src directory:
   
   

   # cd ServerRoot/src
   
   

   NOTE:

   This is the directory created during installation, and it may vary from the default.

   
   
2. Edit the Configuration file to reflect which modules or patches you want.
   
   
   • To add an existing module, uncomment the module code line by removing the opening hash mark (#).
     
     
   • To add a new module, place it at the end of the module list using the following syntax:
     
     AddModule modules/directory/object.o
     
     

     Always use a path relative to ServerRoot/src/.

   • To remove a module, comment it out by adding a hash mark to the beginning of the module code line.
     
     
3. Save the modified Configuration file.
   
   
4. To add a patch, use the patch utility to specify the patch you want to install:
   
   

   # patch -s < patchfile
   
   

5. Run Configure:
   
   

   # ./Configure
   
   

6. Rebuild HTTPSD:
   
   

   # make
   
   

7. Stop the server:
   
   

   # ../bin/stop-server
   
   

8. Back up the old binary:
   
   

   # mv ../httpsd ../httpsd-bak
   
   

9. Install the new binaries:
   
   

   # cp httpsd ..
   
   

10. Start the server:
    
    

    # ../bin/start-server
    
    

[Top] [Prev] [Next] [Last]

© 1998 C2Net International Feedback: stronghold-docs@c2.net