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.
If your httpd.conf is a modified version of the default Red Hat version and you have saved a copy of the original then you may find it easiest to invoke the diff command, as in the following example:
diff -u httpd.conf.orig httpd.conf | less |
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:
rpm2cpio apache-1.3.23-11.i386.rpm | cpio -i --make |
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:
apachectl configtest |
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.
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:
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:
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.
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.
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.
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:
UserDir disable |
to the following:
UserDir public_html |
For more on this topic, refer to the following documentation on the Apache Software Foundation's website:
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:
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:
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:
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:
The contents of all <VirtualHost> containers should be migrated in the same way as the main server section as described in the Section called Main Server Configuration.
Important | |
---|---|
Note that SSL/TLS virtual host configuration has been moved out of the main server configuration file and into /etc/httpd/conf.d/ssl.conf. |
For more on this topic, refer to the following documentation on the Apache Software Foundation's website:
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:
AcceptPathInfo on |
For more on this topic, refer to the following documentation on the Apache Software Foundation's website:
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:
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 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:
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 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 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.
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: