Modules and Apache HTTP Server 2.0

In Apache HTTP Server 2.0, the module system has been changed to allow modules to be chained together or combined in new and interesting ways. Common Gateway Interface (CGI) scripts, for example, can generate server-parsed HTML documents which can then be processed by mod_include. This opens up a tremendous number of possibilities with regards to how modules can be combined to achieve a specific goal.

The way this works is that each request is served by exactly one handler module followed by zero or more filter modules.

Under Apache HTTP Server 1.3, for example, a Perl script would be handled in its entirety by the Perl module (mod_perl). Under Apache HTTP Server 2.0, the request is initially handled by the core module - which serves static files - and is then filtered by mod_perl.

Exactly how to use this, and all other new features of Apache HTTP Server 2.0, is beyond the scope of this document; however, the change has ramifications if the PATH_INFO directive is used for a document which is handled by a module that is now implemented as a filter, as each contains trailing path information after the true file name. The core module, which initially handles the request, does not by default understand PATH_INFO and returns Not Found errors for requests that contain such information. As an alternative, use the AcceptPathInfo directive to coerce the core module into accepting requests with PATH_INFO.

The following is an example of this directive: 

AcceptPathInfo on

For more on this topic, refer to the following documentation on the Apache Software Foundation's website:

The suexec Module

In Apache HTTP Server 2.0, the mod_suexec module uses the SuexecUserGroup directive, rather than the User and Group directives, which is used for configuring virtual hosts. The User and Group directives can still be used in general, but are deprecated for configuring virtual hosts.

For example, the following is a sample Apache HTTP Server 1.3 directive: 

<VirtualHost vhost.example.com:80>
  User someone
  Group somegroup
</VirtualHost>

To migrate this setting to Apache HTTP Server 2.0, use the following structure: 

<VirtualHost vhost.example.com:80>
  SuexecUserGroup someone somegroup
</VirtualHost>

The mod_ssl Module

The configuration for mod_ssl has been moved from the httpd.conf file into the /etc/httpd/conf.d/ssl.conf file. For this file to be loaded, and for mod_ssl to work, the statement Include conf.d/*.conf must be in the httpd.conf file as described in .

ServerName directives in SSL virtual hosts must explicitly specify the port number.

For example, the following is a sample Apache HTTP Server 1.3 directive: 

<VirtualHost _default_:443>
  # General setup for the virtual host
  ServerName ssl.example.name
  ...
</VirtualHost>

To migrate this setting to Apache HTTP Server 2.0, use the following structure: 

<VirtualHost _default_:443>
  # General setup for the virtual host
  ServerName ssl.host.name:443
  ...
</VirtualHost>

It is also important to note that both the SSLLog and SSLLogLevel directives have been removed. The mod_ssl module now obeys the ErrorLog and LogLevel directives. Refer to and for more information about these directives.

For more on this topic, refer to the following documentation on the Apache Software Foundation's website:

The mod_proxy Module

Proxy access control statements are now placed inside a <Proxy> block rather than a <Directory proxy:>.

The caching functionality of the old mod_proxy has been split out into the following three modules:

These generally use directives similar to the older versions of the mod_proxy module, but it is advisable to verify each directive before migrating any cache settings.

For more on this topic, refer to the following documentation on the Apache Software Foundation's website:

The mod_include Module

The mod_include module is now implemented as a filter and is therefore enabled differently. Refer to for more about filters.

For example, the following is a sample Apache HTTP Server 1.3 directive: 

AddType text/html .shtml
AddHandler server-parsed .shtml

To migrate this setting to Apache HTTP Server 2.0, use the following structure: 

AddType text/html .shtml
AddOutputFilter INCLUDES .shtml

Note that the Options +Includes directive is still required for the <Directory> container or in a .htaccess file.

For more on this topic, refer to the following documentation on the Apache Software Foundation's website:

The mod_auth_dbm and mod_auth_db Modules

Apache HTTP Server 1.3 supported two authentication modules, mod_auth_db and mod_auth_dbm, which used Berkeley Databases and DBM databases respectively. These modules have been combined into a single module named mod_auth_dbm in Apache HTTP Server 2.0, which can access several different database formats. To migrate from mod_auth_db, configuration files should be adjusted by replacing AuthDBUserFile and AuthDBGroupFile with the mod_auth_dbm equivalents, AuthDBMUserFile and AuthDBMGroupFile. Also, the directive AuthDBMType DB must be added to indicate the type of database file in use.

The following example shows a sample mod_auth_db configuration for Apache HTTP Server 1.3: 

<Location /private/>
  AuthType Basic
  AuthName "My Private Files"
  AuthDBUserFile /var/www/authdb
  require valid-user
</Location>

To migrate this setting to version 2.0 of Apache HTTP Server, use the following structure: 

<Location /private/>
  AuthType Basic
  AuthName "My Private Files"
  AuthDBMUserFile /var/www/authdb
  AuthDBMType DB
  require valid-user
</Location>

Note that the AuthDBMUserFile directive can also be used in .htaccess files.

The dbmmanage Perl script, used to manipulate username and password databases, has been replaced by htdbm in Apache HTTP Server 2.0. The htdbm program offers equivalent functionality and, like mod_auth_dbm, can operate a variety of database formats; the -T option can be used on the command line to specify the format to use.

shows how to migrate from a DBM-format database to htdbm format using dbmmanage.

Table 23.1. Migrating from dbmmanage to htdbm

Action dbmmanage command (1.3) Equivalent htdbm command (2.0)
Add user to database (using given password) dbmmanage authdb add username password htdbm -b -TDB authdb username password
Add user to database (prompts for password) dbmmanage authdb adduser username htdbm -TDB authdb username
Remove user from database dbmmanage authdb delete username htdbm -x -TDB authdb username
List users in database dbmmanage authdb view htdbm -l -TDB authdb
Verify a password dbmmanage authdb check username htdbm -v -TDB authdb username

The -m and -s options work with both dbmmanage and htdbm, enabling the use of the MD5 or SHA1 algorithms for hashing passwords, respectively.

When creating a new database with htdbm, the -c option must be used.

For more on this topic, refer to the following documentation on the Apache Software Foundation's website:

The mod_perl Module

The configuration for mod_perl has been moved from httpd.conf into the file /etc/httpd/conf.d/perl.conf. For this file to be loaded, and hence for mod_perl to work, the statement Include conf.d/*.conf must be included in httpd.conf as described in .

Occurrences of Apache:: in httpd.conf must be replaced with ModPerl::. Additionally, the manner in which handlers are registered has been changed.

This is a sample Apache HTTP Server 1.3 mod_perl configuration: 

<Directory /var/www/perl>
  SetHandler perl-script
  PerlHandler Apache::Registry
  Options +ExecCGI
</Directory>

This is the equivalent mod_perl for Apache HTTP Server 2.0: 

<Directory /var/www/perl>
  SetHandler perl-script
  PerlResponseHandler ModPerl::Registry
  Options +ExecCGI
</Directory>

Most modules for mod_perl 1.x should work without modification with mod_perl 2.x. XS modules require recompilation and may require minor Makefile modifications.

The mod_python Module

Configuration for mod_python has moved from httpd.conf to the /etc/httpd/conf.d/python.conf file. For this file to be loaded, and hence for mod_python to work, the statement Include conf.d/*.conf must be in httpd.conf as described in .

PHP

The configuration for PHP has been moved from httpd.conf into the file /etc/httpd/conf.d/php.conf. For this file to be loaded, the statement Include conf.d/*.conf must be in httpd.conf as described in .

Any PHP configuration directives used in Apache HTTP Server 1.3 are now fully compatible, when migrating to Apache HTTP Server 2.0 on Community Enterprise Operating System.

In PHP version 4.2.0 and later the default set of predefined variables which are available in the global scope has changed. Individual input and server variables are, by default, no longer placed directly into the global scope. This change may cause scripts to break. Revert to the old behavior by setting register_globals to On in the file /etc/php.ini.

For more on this topic, refer to the following URL for details concerning the global scope changes:

The mod_authz_ldap Module

Community Enterprise Linux ships with the mod_authz_ldap module for the Apache HTTP Server. This module uses the short form of the distinguished name for a subject and the issuer of the client SSL certificate to determine the distinguished name of the user within an LDAP directory. It is also capable of authorizing users based on attributes of that user's LDAP directory entry, determining access to assets based on the user and group privileges of the asset, and denying access for users with expired passwords. The mod_ssl module is required when using the mod_authz_ldap module.

The mod_authz_ldap module does not authenticate a user to an LDAP directory using an encrypted password hash. This functionality is provided by the experimental mod_auth_ldap module. Refer to the mod_auth_ldap module documentation online at for details on the status of this module.

The /etc/httpd/conf.d/authz_ldap.conf file configures the mod_authz_ldap module.

Refer to /usr/share/doc/mod_authz_ldap-<version>/index.html (replacing <version> with the version number of the package) or for more information on configuring the mod_authz_ldap third party module.