If you have upgraded your server from a previous version of Red Hat Linux upon
which the Apache HTTP Server was already installed, then the new stock
configuration file for the Apache HTTP Server 2.0 package will be installed as
/etc/httpd/conf/httpd.conf.rpmnew and your original
version 1.3 httpd.conf will not be touched. It is,
of course, entirely up to you whether you use the new configuration file
and migrate your old settings to it, or use your existing file as a base
and modify it to suit; however, some parts of the file have changed more
than others and a mixed approach is generally the best. The stock
configuration files for both version 1.3 and version 2.0 are divided
into three sections. The goal of this guide is to suggest
what is hopefully the easiest route.
This command will highlight the modifications you have made. If you do
not have a copy of the original file, extract it from an RPM package
using the rpm2cpio and cpio
commands, as in the following example:
Finally, it is useful to know that the Apache HTTP Server has a testing mode to
check your configuration for errors. To use access it, type the
following command:
Global Environment Configuration
The global environment section of the configuration file contains
directives which affect the overall operation of the Apache HTTP Server, such as the
number of concurrent requests it can handle and the locations of the
various files it uses. This section requires a large number of
changes compared with the others and it is therefore recommended that
you base this section on the Apache HTTP Server 2.0 configuration file and migrate
your old settings into it.
Selecting Which Interfaces and Ports To Bind To
The BindAddress and Port
directives no longer exist; their functionality is now provided by a
more flexible Listen directive.
If you had set Port 80 in your 1.3 version
configuration file, you should change it to Listen
80 instead. If you had set Port to some
value other than 80 then you must also append
the port number to the contents of your
ServerName directive.
For example, the following is a sample Apache HTTP Server 1.3 directive:
Port 123
ServerName www.example.com |
To migrate this setting to Apache HTTP Server 2.0, use the following
structure:
Listen 123
ServerName www.example.com:123 |
For more on this topic, refer to the following documentation on the
Apache Software Foundation's website:
Server-pool Size Regulation
In Apache HTTP Server 2.0, the responsibility for accepting requests and
dispatching child-processes to handle them has been abstracted into
a group of modules called Multi-Processing
Modules (MPMs). Unlike other
modules, only one module from the MPM group can be loaded by the
Apache HTTP Server because an MPM module is responsible for basic
request handling and dispatching. There are three MPM modules that
ship with version 2.0: prefork, worker, and perchild.
The original Apache HTTP Server 1.3 behavior has been moved into the
prefork MPM. Currently only the prefork MPM is
available on Red Hat Linux, although other MPMs may be made
available at some later date.
The MPM supplied by default on Red Hat Linux is prefork which
accepts the same directives as Apache HTTP Server 1.3. The following directives
may be migrated directly:
StartServers
MinSpareServers
MaxSpareServers
MaxClients
MaxRequestsPerChild
For more on this topic, refer to the following documentation on the
Apache Software Foundation's website:
Dynamic Shared Object (DSO) Support
There are many changes required here and it is highly recommended
that anyone trying to modify an Apache 1.3 configuration to suit
Apache 2.0 (as opposed to migrating your changes into the Apache 2.0
configuration) copy this section from the stock Red Hat Linux Apache HTTP Server
2.0 configuration file.
 | Important |
|---|
| | If you do decide to try and modify your original file, please note
that it is of paramount importance that your
httpd.conf contains the following directive:
Omission of this directive will result in the failure of all modules packaged in
their own RPMs (such as mod_perl,
php, and mod_ssl).
|
Those who still do not want to copy the section from the
stock Apache HTTP Server 2.0 configuration should note the following:
The AddModule and
ClearModuleList directives no longer
exist. These directives where used to ensure that modules could
be enabled in the correct order. The Apache 2.0 API allows
modules to specify their ordering, eliminating the
need for these two directives.
The order of the LoadModule lines is no
longer relevant.
Many modules have been added, removed, renamed, split
up, or incorporated with each other.
LoadModule lines for modules packaged in
their own RPMs (mod_ssl,
php, mod_perl, and the
like) are no longer necessary as they can be found in the
relevant file in the /etc/httpd/conf.d/
directory.
The various HAVE_XXX definitions are no
longer defined.
Other Global Environment Changes
The following directives have been removed from Apache HTTP Server 2.0's
configuration:
ServerType —
The Apache HTTP Server can only be run as ServerType
standalone making this directive irrelevant.
AccessConfig and
ResourceConfig — These
directives have been removed since they mirror the
functionality of the Include directive. If
you have AccessConfig and
ResourceConfig directives set then you need
to replace these with Include
directives.
To ensure that the files are read in the order
implied by the older directives the Include
directives should be placed at the end of
httpd.conf, with the one corresponding to
ResourceConfig preceding the one
corresponding to AccessConfig. If you were
making use of the default values you will need to include them
explicitly as conf/srm.conf and
conf/access.conf.
Main Server Configuration
The main server configuration section of the configuration file sets
up the main server, which responds to any requests that are not handled
by a <VirtualHost> definition. Values here
also provide defaults for any <VirtualHost>
containers you may define.
The directives used in this section have changed little between
Apache HTTP Server 1.3 and version 2.0. If your main server configuration is
heavily customized you may find it easier to modify your existing
configuration to suit Apache 2.0. Users with only lightly customized
main server sections should migrate their changes into the stock
Apache 2.0 configuration.
UserDir Mapping
The UserDir directive is used to enable URLs such
as http://example.com/~jim/ to map to a
subdirectory within the home directory of the user
jim, such as
/home/jim/public_html. A side-effect of this
feature allows a potential attacker to determine whether a given
username is present on the system, so the default configuration for
Apache HTTP Server 2.0 disables this directive.
To enable UserDir mapping, change the
directive in httpd.conf from:
to the following:
For more on this topic, refer to the following documentation on the
Apache Software Foundation's website:
Logging
The following logging directives have been removed:
AgentLog
RefererLog
RefererIgnore
However, agent and referrer logs are still available using the
CustomLog and LogFormat
directives.
For more on this topic, refer to the following documentation on the
Apache Software Foundation's website:
Directory Indexing
The deprecated FancyIndexing directive has now
been removed. The same functionality is available through the
FancyIndexing option within
the IndexOptions directive.
The new VersionSort option to the
IndexOptions directive causes files containing
version numbers to be sorted in the natural way, so that
httpd-2.0.6.tar would appear before
httpd-2.0.36.tar in a directory index
page.
The defaults for the ReadmeName and
HeaderName directives have changed from
README and HEADER to
README.html and
HEADER.html.
For more on this topic, refer to the following documentation on the
Apache Software Foundation's website:
http://httpd.apache.org/docs-2.0/mod/mod_autoindex.html#indexoptions
http://httpd.apache.org/docs-2.0/mod/mod_autoindex.html#readmename
http://httpd.apache.org/docs-2.0/mod/mod_autoindex.html#headername
Content Negotiation
The CacheNegotiatedDocs directive now takes the
argument on or off. Existing
instances of CacheNegotiatedDocs should be
replaced with CacheNegotiatedDocs on.
For more on this topic, refer to the following documentation on the
Apache Software Foundation's website:
Error Documents
To use a hard-coded message with the
ErrorDocument directive, the message should be
enclosed in a pair of double quotes, rather than just preceded by a
double quote as required in Apache 1.3.
To migrate an ErrorDocument setting to Apache HTTP Server
2.0, use the following structure:
ErrorDocument 404 "The document was not found" |
Note that there is a trailing double quote in the example
ErrorDocument directive above.
For more on this topic, refer to the following documentation on the
Apache Software Foundation's website:
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. 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 1.3, for example, a PHP script would be handled in its
entirety by the PHP module. Under Apache 2.0, the request is initially
handled by the core module — which serves
static files — and is then filtered by the
PHP module.
Exactly how to use this and all the other new features of Apache 2.0
for that matter is beyond the scope of this document; however, the
change has ramifications if you have used
PATH_INFO, which contains trailing path information
after the true filename, in a document which is handled by a module
that is now implemented as a filter. The core module, which initially
handles the request, does not by default understand
PATH_INFO and will return 404 Not
Found errors for requests that contain such
information. You can use the AcceptPathInfo
directive to coerce the core module into accepting requests with
PATH_INFO. Below is an example of this directive:
For more on this topic, refer to the following documentation on the
Apache Software Foundation's website:
http://httpd.apache.org/docs-2.0/mod/core.html#acceptpathinfo
http://httpd.apache.org/docs-2.0/handler.html
http://httpd.apache.org/docs-2.0/filter.html
The mod_ssl Module
The configuration for mod_ssl has been moved
from httpd.conf into the file
/etc/httpd/conf.d/ssl.conf. For this file to
be loaded, and hence for mod_ssl to work, you
must have the statement Include conf.d/*.conf in
your httpd.conf as described in the Section called Dynamic Shared Object (DSO) Support.
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:
##
## SSL Virtual Host Context
##
<VirtualHost _default_:443>
# General setup for the virtual host
ServerName ssl.host.name
...
</VirtualHost> |
To migrate this setting to Apache HTTP Server 2.0, use the following
structure:
##
## SSL Virtual Host Context
##
<VirtualHost _default_:443>
# General setup for the virtual host
ServerName ssl.host.name:443
...
</VirtualHost> |
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:
mod_cache
mod_disk_cache
mod_file_cache
These generally use the same or similar directives as the older
versions of the mod_proxy module.
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 (see the Section called Modules and Apache HTTP Server 2.0 for more on
filters) and is therefore enabled differently.
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 just as before, the Options +Includes
directive is still required for the <Directory> section 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 in version 1.3, configuration files
should be adjusted by replacing AuthDBUserFile
and AuthDBGroupFile with the
mod_auth_dbm equivalents:
AuthDBMUserFile and
AuthDBMGroupFile. Also, you must add the
directive AuthDBMType DB to indicate the type of
database file in use.
The following example shows a sample
mod_auth_db configuration for Apache 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.
Table 14-1 shows how to migrate from a DBM-format
database to htdbm format using
dbmmanage.
Table 14-1. Migrating from dbmmanage to htdbm
| Action | dbmmanage command (Apache 1.3) | Equivalent htdbm command (Apache 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_perlto work, you
must have the statement Include conf.d/*.conf in
your httpd.conf as described in the Section called Dynamic Shared Object (DSO) Support.
Occurances of Apache:: in your
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
PerlModule ModPerl::Registry
PerlHandler ModPerl::Registry::handler
Options +ExecCGI
</Directory> |
Most modules for mod_perl 1.x should work without modification
with mod_perl 2.x. XS modules will require recompilation and may
possibly require minor Makefile modifications.
The mod_python Module
The configuration for mod_python; has been
moved from httpd.conf into the file
/etc/httpd/conf.d/python.conf. For this file
to be loaded, and hence for mod_python; to
work, you must have the statement Include
conf.d/*.conf in your httpd.conf as
described in the Section called Dynamic Shared Object (DSO) Support.
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, you must have the statement Include
conf.d/*.conf in your httpd.conf as
described in the Section called Dynamic Shared Object (DSO) Support.
The PHP is now implemented as a filter and must therefore be
enabled in a different manor. See the Section called Modules and Apache HTTP Server 2.0 for more about filters.
Under Apache HTTP Server 1.3, PHP was implemented using the following
directives:
AddType application/x-httpd-php .php
AddType application/x-httpd-php-source .phps |
Under Apache HTTP Server 2.0, use the following directives instead:
<Files *.php>
SetOutputFilter PHP
SetInputFilter PHP
</Files> |
In PHP 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. You may 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: