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 can load (Figure 7-3).

Figure 7-3: Apache Modules

The first module listed in the figure above is mod_so [http://www.apache.org/docs/mod/mod_so.html], which is the module that provides shared object loading at runtime. 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 thirdparty modules is Apache modules [http://www.apache.org/docs/mod/indexbytype.html] and Apache Module Registry [http://modules.apache.org/].

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 its primary benefits over other web servers. Without modules, Apache would be just another web server. But because modules are relatively easy to program, the variety available has proliferated, providing functionality for Apache that is unavailable in any other web server product, commercial or Open Source.

About Apache Modules

Because of the importance modules play in the configuration and management of an Apache web server, 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.

Note 

The official Apache modules [http://httpd.apache.org/docs/mod/] 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 [http://httpd.apache.org/docs-2.0/mod/].

Apache Core

The Apache Core module [http://httpd.apache.org/docs/mod/core.html] 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. Most of the basic network, system, and HTTP limits and functions are handled by the core module, and many of the configuration directives are available with no additional modules required.

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 to the system. Concurrency in Apache versions prior to 2.0 used a model known as connectionper-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 traditional preforking 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 that spawns a child process, which in turn creates threads to handle requests. Because 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 host name, 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.

Note 

To generate a password file using htpasswd, simply run the program with the -c option, a new file name, 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. Configuration of the CGI module can be handled separately for virtual hosts, or it may be applied globally to all virtual hosts on the server, or a combination of global defaults with specific differences in some virtual hosts.

mod_expires

The HTTP specification defines a set of rules for clients and intermediary devices (specifically, web-caching proxies, like Squid) to follow when deciding whether to serve a cached document, re-validate 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 an extremely flexible (some would say too flexible) means of redirecting user requests to different URLs based on information contained in the request. 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.

Note 

To fully understand URL rewriting, it may be worth your time to study the URL Rewriting Guide [http://httpd.apache.org/docs-2.0/misc/rewriteguide.html] written by 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 okay, and man-inthemiddle 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.

Note 

Certificate Authorities, or CAs as they are often called, supported by most modern browsers include VeriSign [http://www.verisign.com/], GeoTrust [http://www.geotrust.com/], and Thawte Consulting [http://www.thawte.com/] in the U.S. Options outside of the U.S. include Internet Publishing Services [http://www.ips.es/] and BelSign [http://www.belsign.be/].

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 web server itself, and the web server 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 there are many security pitfalls to beware of, but it is a required step to providing a secured virtual hosting environment with CGI script capabilities.