28.4 Installing, Activating, and Configuring Modules
The Apache software is built in a modular fashion: all functionality
except some core tasks is handled by modules. This has progressed so far
that even HTTP is processed by a module (http_core).
Apache modules can be compiled into the Apache binary at build time or
dynamically loaded at runtime. Refer to
Section 28.4.2, Activation and Deactivation for details of how
to load modules dynamically.
Apache modules can be divided into four different categories:
- Base Modules
Base modules are compiled into Apache by default. Apache in SUSE Linux
has only mod_so (needed to load other modules) and http_core compiled
in. All others are available as shared objects: rather than being
included in the server binary itself, they can be included at runtime.
- Extension Modules
In general, modules labeled as extensions are included in the Apache
software package, but are usually not compiled into the server
they are available as shared objects that can be loaded into Apache at
- External Modules
Modules labeled external are not included in the official Apache
provides several of them readily available for use.
- Multiprocessing Modules
MPMs are responsible for accepting and handling requests to the Web
server, representing the core of the Web server software.
28.4.1 Module Installation
If you have followed the default way of installing Apache (described in
Section 28.1.2, Installation), it is installed
with all base and extension modules, the multiprocessing module Prefork
MPM, and the external modules mod_php5 and mod_python.
You can install additional external modules by starting YaST and
choosing apache. Among other packages, the result list
contains all available external Apache modules.
. Now choose
and search for
28.4.2 Activation and Deactivation
Using YaST, you can activate or deactivate the script language modules
(PHP5, Perl, Python, and Ruby) with the
module configuration described in
HTTP Server Wizard. All other
modules can be enabled or disabled as described in
If you prefer to activate or deactivate the modules manually, use the
commands a2enmod mod_foo
or a2dismod mod_foo,
respectively. a2enmod -l outputs a list of all
currently active modules.
IMPORTANT: Including Configuration Files for External Modules
If you have activated external modules manually, make sure to load
their configuration files in all virtual host configurations.
Configuration files for external modules are located under
/etc/apache2/conf.d/ and are not loaded by
default. If you need the same modules on each virtual host, you can
include *.conf from this directory. Otherwise
include individual files. See
/etc/apache2/vhost.d/vhost.template for examples.
28.4.3 Base and Extension Modules
All base and extension modules are described in detail in the Apache
documentation. Only a brief description of the most important modules is
available here. Refer to
to learn details about each module.
Provides methods to execute a script whenever a certain MIME type
(such as application/pdf), a file with a
specific extension (like .rpm), or a certain
request method (such as GET) is requested.
This module is enabled by default.
Provides Alias and
Redirect directives with which you can map a
URl to a specific directory (Alias) or
redirect a requested URL to another location. This module is enabled
The authentication modules provide different authentication methods:
basic authentication with mod_auth_basic or digest authentication
with mod_auth_digest. Digest authentication in Apache 2.2 is
mod_auth_basic and mod_auth_digest must be combined with an
authentication provider module, mod_authn_* (for example,
mod_authn_file for text file–based authentication) and with an
authorization module mod_authz_* (for example, mod_authz_user for
More information about this topic is available in the
Authentication HOWTO at
Autoindex generates directory listings when no index file (for
example, index.html) is present. The look and
feel of these indexes is configurable. This module is enabled by
default. However, directory listings are disabled by default via the
Options directive—overwrite this
setting in your virtual host configuration. The default configuration
file for this module is located at
mod_cgi is needed to execute CGI scripts. This module is enabled by
Using this module, Apache can be configured to compress given file
types on the fly before delivering them.
mod_dir provides the DirectoryIndex
directive with which you can configure which files are automatically
delivered when a directory is requested
(index.html by default). It also provides an
automatic redirect to the correct URl when a directory request does
not contain a trailing slash. This module is enabled by default.
Controls the environment that is passed to CGI scripts or SSI pages.
Environment variables can be set or unset or passed from the shell
that invoked the httpd process. This module is enabled by default.
With mod_expires, you can control how often proxy and browser caches
refresh your documents by sending an Expires
header. This module is enabled by default.
mod_include lets you use Server Side Includes (SSI), which provide a
basic functionality to generate HTML pages dynamically. This module
is enabled by default.
Provides a comprehensive overview of the server configuration under
https://localhost/server-info/. For security reasons, you should
always limit access to this URL. By default only
localhost is allowed to
access this URL. mod_info is configured at
With this module, you can configure the looks of the Apache log
files. This module is enabled by default.
The mime module takes care that a file is delivered with the correct
MIME header based on the filename's extension (for example
text/html for HTML documents). This module
is enabled by default.
Necessary for content negotiation. See
for more information. This module is enabled by default.
Provides the functionality of mod_alias, but offers more features and
flexibility. With mod_rewrite, you can redirect URLs based on
multiple rules, request headers, and more.
Sets environment variables based on details of the client's request,
such as the browser string the client sends, or the client's IP
address. This module is enabled by default.
mod_speling attempts to automatically correct typographical errors in
URLs, such as capitalization errors.
Enables encrypted connections between Web server and clients. See
Section 28.6, Setting Up a Secure Web Server with SSL for details. This module is enabled
Provides information on server activity and performance under
https://localhost/server-status/. For security reasons, you should
always limit access to this URL. By default, only
localhost is allowed to
access this URl. mod_status is configured at
mod_suexec lets you run CGI scripts under a different user and group.
This module is enabled by default.
Enables user-specific directories available under
UserDir directive must be specified in the
configuration. This module is enabled by default.
28.4.4 Multiprocessing Modules
provides two different multiprocessing modules (MPMs) for use with
The prefork MPM implements a nonthreaded, preforking Web server. It
makes the Web server behave similarly to Apache version 1.x in that it
isolates each request and handles it by forking a separate child
process. Thus problematic requests cannot affect others, avoiding a
lockup of the Web server.
While providing stability with this process-based approach, the prefork
MPM consumes more system resources than its counterpart, the worker
MPM. The prefork MPM is considered the default MPM for Unix-based
IMPORTANT: MPMs in This Document
This document assumes Apache is used with the prefork MPM.
The worker MPM provides a multithreaded Web server. A thread is a
lighter form of a process. The advantage of a thread
over a process is its lower resource consumption. Instead of only
forking child processes, the worker MPM serves requests by using
threads with server processes. The preforked child processes are
multithreaded. This approach makes Apache perform better by consuming
fewer system resources than the prefork MPM.
One major disadvantage is the stability of the worker MPM: if a thread
becomes corrupt, all threads of a process can be affected. In the worst
case, this may result in a server crash. Especially when using the
Common Gateway Interface (CGI) with Apache under heavy load, internal
server errors might occur due to threads unable to communicate with
system resources. Another argument against using the worker MPM with
Apache is that not all available Apache modules are thread-safe and
thus cannot be used in conjunction with the worker MPM.
WARNING: Using PHP Modules with MPMs
Not all available PHP modules are thread-safe. Using the worker MPM
with mod_php is strongly discouraged.
28.4.5 External Modules
Find a list of all external modules shipped with
here. Find the module's documentation in the listed directory.
Adds support to Apache to provide Novell AppArmor confinement to individual CGI
scripts handled by modules like mod_php5 and mod_perl.
Using mod_mono allows you to run ASP.NET pages in your server.
Package Name: apache2-mod_mono
mod_perl enables you to run Perl scripts in an embedded interpreter.
The persistent interpreter embedded in the server avoids the overhead
of starting an external interpreter and the penalty of Perl start-up
Package Name: apache2-mod_perl
Configuration File: /etc/apache2/conf.d/mod_perl.conf
PHP is a server-side, cross-platform HTML embedded scripting
Package Name: apache2-mod_php5
Configuration File: /etc/apache2/conf.d/php5.conf
mod_python allows embedding Python within the Apache HTTP server for
a considerable boost in performance and added flexibility in
designing Web-based applications.
Package Name: apache2-mod_python
mod_tidy validates each outgoing HTML page by means of the TidyLib.
In case of a validation error, a page with an error list is
delivered. Otherwise the original HTML page is delivered.
Package Name: apache2-mod_tidy
Configuration File: /etc/apache2/mod_tidy.conf
More Information: /usr/share/doc/packages/apache2-mod_tidy
Apache can be extended by advanced users by writing custom modules. To
develop modules for Apache or compile third-party modules, the package
apache2-devel is required along with the
corresponding development tools. apache2-devel
also contains the apxs2 tools, which are necessary
for compiling additional modules for Apache.
apxs2 enables the compilation and installation of
modules from source code (including the required changes to the
configuration files), which creates dynamic shared
objects (DSOs) that can be loaded into Apache at runtime.
The apxs2 binaries are located under
/usr/sbin/apxs2—suitable for building an
extension module that works with any MPM. The installation location is
prefork MPM modules. The installation location is
/usr/sbin/apxs2-worker—suitable for worker
MPM modules. The installation location is
Install and activate a module from source code with the commands
cd /path/to/module/source; apxs2 -cia
compiles the module, -i installs it, and
-a activates it). Other options of
apxs2 are described in the
apxs2(1) man page.