Apache Modules
Apache is designed in a modular fashion, so that the base server can be a small easily debugged application, while nearly unlimited additional functionality can be added easily by loading additional modules. The base process can then be smaller, and only those additional features that are needed can be loaded. This Webmin module allows you to select the available Apache modules that you'd like to be loaded.
The first module listed in the figure above is mod_so, which is the module that provides shared object loading at run-time. This module is required if you are using run-time module loading and is the only module other than core.c that cannot be a dynamically loaded module. It must be compiled into the Apache binary at build time if you will be using dynamically loaded modules. Dynamic Shared Objects are not supported by all operating systems, currently, but they are supported by the majority of modern systems including Unix variants that support loadable .so libraries and Windows systems in the form of DLLs. There are several other modules in common use listed in the above figure, some of which will be discussed below. A good place to go to find out more about available standard modules and third party modules is Apache modules and Apache Module Registry.
Configured modules are loaded into the Apache process on startup, thus it is possible to add new modules without recompiling the server. The modular nature of Apache is one of it's primary benefits over other webservers. Without modules, Apache would be just another webserver. But because modules are relatively easy to program, the variety available has proliferated, providing functionality for Apache that is unavailable in any other webserver product, commercial or Open Source.
About Apache Modules
Because of the importance modules play in the configuration and management of an Apache webserver, it is worthwhile to step out of Webmin for a short time to discuss some of the lower-level details of Apache and its modules. While the usage of these modules via Webmin is discussed throughout this chapter, an overview of the modules will help put the modular structure of Apache into perspective, and hopefully make clearer the interaction between Webmin and the underlying configuration files.
 | The official Apache modules documentation page is an informative, and more comprehensive list of modules that are part of the Apache distribution. Only the most commonly used modules and their purposes will be discussed here. A similar page covers the Apache 2.0 modules. |
Apache Core
The Apache Core module provides the basic functionality that is required to provide web service as described by RFC 2616. The features in core are always available in any Apache installation, regardless of what other modules are available.
XXX
Multi-Processing Modules
Beginning with Apache version 2.0, a new model (or more accurately, a number of new models) for handling connection concurrency has been added the system. Concurrency in Apache versions prior to 2.0 used a model known as connection-per-process, with some enhancements to that model like pre-forking. New versions provide what are known as Multi-Processing Modules which allows Apache to use the concurrency model that makes the most sense for a give operating system. most Unix and Unix-like systems use a module called worker which implements a hybrid model utilizing a pool of multi-threaded processes.
When the worker module is enabled, Apache runs a single control process that is responsible for launching child processes. The child processes spawn a configurable fixed number of threads each, and these individual threads listen for connections and serve them. Threads are lighter weight, or less resource intensive, than real processes, and thus a machine of a given capacity can provide higher throughput from a worker style Apache than from a traditionl pre-forking Apache. This was a primary motivation in the development of the new Apache 2.0 service modules.
If your Unix variant doesn't support threads, or supports them in an incompatible way, Apache will likely use the prefork model instead. Windows machines will likely use the mpm_winnt Multi-Processing module, which creates a single control process which spawns a child process, which in turn creates threads to handle requests. Since Webmin only runs on Unix-like operating systems at this time, you will likely have no use for the Windows module.
mod_access
This module provides access control based on client hostname, IP address and other information taken from the client request. This module also provides some of the functionality involved in supporting directory .htaccess files to control access to certain parts of the server.
mod_auth
User authentication of several types is supported by Apache. The oldest and most commonly used is supported by this module. It is known alternately as HTTP Basic Authentication or NCSA authentication. This method authenticates users from a plain text file located somewhere on the system. The password file can be generated using the htpasswd program that is included with Apache.
| To generate a password file using htpasswd, simply run the program with the -c option, a new filename, and the first username to add to the file: [joe@delilah mydocs]$ htpasswd -c .htpasswd joe This file can then be used by the mod_auth module to authenticate users based on this file. This must be explicitly configured in the Apache configuration file, or in the local .htaccess file. Creating an .htaccess file is discussed in the tutorial section of this chapter. |
mod_cgi
The CGI module must be used in order to run scripts or programs on the server to generate content dynamically for users. It is possible to configure at runtime the file types that will be handled by the CGI module. XXX
mod_expires
The HTTP specification defines a set of rules for clients and intermediary devices (specificially, web caching proxies, like Squid) to follow when deciding whether to serve a cached document, revalidate the object, or fetch a new copy. A primary method for the website maintainer to dictate the result of these decisions for any given object is the Expires header. This module provides a flexible, and simple method for configuring server wide, as well as per-directory or by file type.
mod_rewrite
This module provides a completely flexible (some would say too flexible) means of redirecting user requests to different URLs based on some information. The basis of this module is a regular expressions based parser and rewriting engine. The URL alterations can depend on a large variety of additional data, including environment variables, client headers, time, external database lookups, and more.
| To fully understand URL rewriting, it may be worth your time to study the URL Rewriting Guide written be Ralf Engelschall, the original author of the mod_rewrite module. |
mod_ssl
Normally, the HTTP protocol is not encrypted, and thus, not secure from prying eyes at any stage along the request path. Ordinarily, this is OK, and man-in-the-middle security problems of this sort are extremely rare (because the vast majority ISP and backbone administrators are honest folks who have no inclination to snoop on your web browsing habits). However, for extremely private matters, such as online banking, investing, or making online purchases, it is important to have a more secure means of communication. The solution is Secure Sockets Layer, also known as simply SSL. The Open Source implementation is called OpenSSL, and it is the core of the mod_ssl Apache module.
To use SSL connections, you must generate or purchase an SSL certificate from one of several Certificate Authorities. A locally generated certificate can be used for authentication within a company, or for a small number of users whom you already have a trust relationship with. However, if your secure site will be used by a number of users who have no direct relationship with you, a certificate from a trusted certificate authority will be required so the user will know that the site is operated by who it claims to be.
| Certificate Authorities, or CAs as they are often called, supported by most modern browsers include VeriSign, GeoTrust, and Thawte Consulting in the US. Options outside of the US include Internet Publishing Services and BelSign. |
mod_suexec
In many web hosting environments, a single server is shared by a number of users, and it would be inappropriate to allow the files of all users to be viewed by any other user. Because CGI scripts are run, by default, with the permissions of the webserver itself, and the webserver must have access to all content and scripts, it would be possible for a malicious user to use a CGI script to browse the contents of any other users private directories using Apache as an intermediary. In order to combat this problem in virtual hosting environments, the server may be configured to run CGI scripts as a specified user rather than as the more privileged Apache user (usually nobody). This module makes this feature possible by performing a suexec function on the created process when CGI scripts are run. There is some complexity in this solution, and many security pitfalls to beware of, but it is a required step to providing a secured virtual hosting environment with CGI script capabilities.