Chapter 4. Configuring Your Server

The default configuration of the Red Hat Linux Secure Server should work for most users. You may never need to change any of Apache's configuration directives. If you do want to change any of the default configuration options, you'll need to know what some of the options are, and know where to find them. This chapter covers the configuration options available to you.

After you've installed the Red Hat Linux Secure Server, the Apache Web server documentation is available at http://your_domain/manual/ or you can use the Apache documentation available on the Web at http://www.apache.org/docs/. The Apache Web server documentation contains a full list and complete descriptions of all of Apache's configuration options. For your convenience, short descriptions of the configuration directives used by your Red Hat Linux Secure Server are provided in this manual.

When you are looking through your Web server's configuration file, be aware that your default configuration includes both a non-secure and a secure Web server. The Red Hat Linux Secure Server (the secure Web server) runs as a virtual host, which is configured in the httpd.conf.ssl configuration file. For more information about virtual hosts, see the section called Using Virtual Hosts.

Please Note

We do not include FrontPage extensions, which would give the Red Hat Linux Secure Server the capability of working with Microsoft(R) FrontPage. Including FrontPage support is a problem for two reasons. First, the Microsoft license prohibits the inclusion of the extensions in a third party product. Secondly, the patch which would enable Apache to include FrontPage extensions is a very serious security risk. Much of the workaround involves granting root access, which is something that you should avoid for security. This type of risk should be unacceptable to anyone who is even somewhat concerned with the security of their Red Hat Linux Secure Server and their website.

Configuration Directives

Apache's configuration file is /etc/httpd/conf/httpd.conf; the SSL directives for your secure server are contained in /etc/httpd/conf/httpd.conf.ssl. The httpd.conf file is well-commented and somewhat self-explanatory. The default configuration of the Red Hat Linux Secure Server will work for most people, so you probably won't need to change the directives in either file. However, you may want to be familiar with the most important configuration options.

The empty srm.conf and access.conf files are also in the /etc/httpd/conf directory. The srm.conf and access.conf files were formerly used, along with httpd.conf, as configuration files for Apache.

If you need to configure your Red Hat Linux Secure Server, you simply edit httpd.conf or httpd.conf.ssl, and then either reload, or stop and start your Red Hat Linux Secure Server. Instructions on how to reload, stop and start your server can be found in the section called Starting and Stopping Your Server in Chapter 3.

Before you edit a configuration file, you should first copy the original file to something like httpd.confold (or to any name you want). Then, if you make a mistake while you're editing the configuration file, you'll have a backup to start over with.

If you do make a mistake, and your Red Hat Linux Secure Server doesn't work correctly, the first place to look is your recently edited configuration file. Make sure that you didn't make a typo. The next places to look are your Red Hat Linux Secure Server's error log (/etc/httpd/logs/ssl-error_log) or in your non-secure Web server's error log (/var/log/httpd/error_log). The error log may not be easy to interpret, depending on your level of experience. If you've just experienced a problem, however, the last entries in the error log should provide some clues about what has happened.

The next sections provide short descriptions of the directives which are included in httpd.conf, in the order that you'll find them. These descriptions are not exhaustive. If you need more information, please refer to the Apache documentation provided in HTML format at http://your_domain/manual/ or to the Apache group documentation at http://www.apache.org/docs/. For more information about mod_ssl directives, refer to the documentation included in HTML format as http://your_domain/manual/mod/mod_ssl.html, or see the mod_ssl User Manual at http://www.modssl.org/docs/2.6/.

ServerType

Your ServerType can be either inetd or standalone. By default, your Red Hat Linux Secure Server is set to ServerType standalone. ServerType standalone means that the server is started once and then that server handles all of the connections. ServerType inetd means that for every HTTP connection, a new instance of the server is started. Each server instance handles the connection and exits when the connection is ended. As you can probably imagine, using inetd is very inefficient. Another problem is that inetd may not work correctly, according to the Apache group. For those two reasons, you should leave your Red Hat Linux Secure Server's ServerType set to standalone.

ServerRoot

The ServerRoot is the directory which will contain subdirectories for the server's files. Both your secure and non-secure servers are set to use a ServerRoot of /etc/httpd.

LockFile

LockFile sets the path to the lockfile used when the Apache server is compiled with either USE_FCNTL_SERIALIZED_ACCEPT or USE_FLOCK_SERIALIZED_ACCEPT. LockFile should normally be left at its default value.

PidFile

PidFile names the file in which the server records its process ID (pid). Your Red Hat Linux Secure Server is set to record its pid in /var/run/httpd.pid.

ScoreBoardFile

The ScoreBoardFile stores internal server process information, which is used for communication between the parent server process and its child processes. Your Red Hat Linux Secure Server's ScoreBoardFile is set to /var/run/httpd.scoreboard.

ResourceConfig

The ResourceConfig directive instructs the server to read the file after ResourceConfig for more directives. The ResourceConfig directive is commented out.

AccessConfig

The AccessConfig directive instructs the server to read the file named after AccessConfig for more directives, after it has read the file named by ResourceConfig. The AccessConfig directive is commented out.

Timeout

Timeout defines, in seconds, the amount of time that your server will wait for receipts and transmissions during communications. Specifically, Timeout defines how long your server will wait to receive a GET request, how long it will wait to receive TCP packets on a POST or PUT request and how long it will wait between ACKs responding to TCP packets. Timeout is set to 300 seconds, which is appropriate for most situations.

KeepAlive

KeepAlive sets whether your server will allow persistent connections (i.e., more than one request per connection). KeepAlive can be used to prevent any one client from consuming too much of the server's resources. By default, KeepAlive is set to on, which means that your server allows persistent connections. You could set it to off, which would disable persistent connections. See the MaxKeepAliveRequests directive for a related way of limiting requests per connection.

MaxKeepAliveRequests

This directive sets the maximum number of requests allowed per persistent connection. The Apache Group recommends a high setting, which will improve your server's performance. MaxKeepAliveRequests is set to 100 by default, which should be appropriate for most situations.

KeepAliveTimeout

KeepAliveTimeout sets the number of seconds your server will wait for a subsequent request, after a request has been served, before it closes the connection. Once a request has been received, the Timeout directive applies instead.

MinSpareServers and MaxSpareServers

The Apache Web server dynamically adapts to the perceived load by maintaining an appropriate number of spare server processes based on the traffic. The server checks the number of servers waiting for a request and kills some if there are more than MaxSpareServers or creates some if the number of servers is less than MinSpareServers. Your server's default MinSpareServers is 5; your server's default MaxSpareServers is 20. These default settings should be appropriate in almost all situations. You should not increase the MinSpareServers to a very large number, since that will create a heavy processing load on your server even when traffic is light.

StartServers

StartServers sets how many server processes are created upon startup. Since your Web server dynamically kills and creates server processes based on traffic load, you won't ever need to change this parameter. Your Web server is set to start eight server processes at startup.

MaxClients

MaxClients sets a limit on the total number of server processes (i.e., simultaneously connected clients) that can run at one time. You want to keep MaxClients at a high number (your server's default is set to 150), because no one else will be allowed to connect once that number of simultaneously connected clients is reached. You can't set MaxClients to higher than 256 without recompiling Apache. The main reason for having MaxClients is so that a runaway Web server doesn't crash your operating system.

MaxRequestsPerChild

MaxRequestsPerChild sets the total number of requests each child server process serves before the child dies. The main reason for setting MaxRequestsPerChild is to avoid long-lived process induced memory leaks. The default MaxRequestsPerChild for your server is 100.

Listen

The Listen command identifies the ports on which your Red Hat Linux Secure Server will accept incoming requests. In the httpd.conf.ssl file, your Red Hat Linux Secure Server is set to listen to port 80 for non-secure Web communications and to port 443 for secure Web communications.

Listen can also be used to specify particular IP addresses over which the server will accept connections.

BindAddress

BindAddress is a way of specifying which IP addresses your server will listen to. You should use the Listen directive instead if you need this functionality. BindAddress is not used by your Web server; by default it is commented out in httpd.conf.

LoadModule

LoadModule is used to load in Dynamic Shared Object (DSO) modules. More information on the Red Hat Linux Secure Server's DSO support, including exactly how to use the LoadModule directive, can be found in the section called Adding Modules to Your Server. Note that the order of the modules is important, so don't move them around.

ClearModuleList

The ClearModuleList directive is located immediately before the long list of AddModule directives. ClearModuleList erases the server's built-in list of active modules. Then the list of AddModule directives re-creates the list, immediately after ClearModuleList.

AddModule

AddModule is the directive used by the Red Hat Linux Secure Server to create a complete list of all available modules. You will use the AddModule directive if you add in your own module as a DSO. For more information on how AddModule is used for DSO support, see the section called Adding Modules to Your Server.

ExtendedStatus

The ExtendedStatus directive controls whether Apache generates basic or detailed server status information, when the server-status handler is called. Server-status is called using Location tags; more information on calling server-status is included in the section called Location.

Port

Normally, Port defines the port that your server is listening to. Your Red Hat Linux Secure Server, however, is listening to more than one port by default, since the Listen directive is also being used. When Listen directives are in effect, your server listens at all of those ports. See the description of the Listen directive for more information about Listen.

The Port command is also used to specify the port number used to construct a canonical name for your server. See the UseCanonicalName directive for more information about your server's canonical name.

User

The User directive sets the userid employed by the server to answer requests. User's setting determines the server's access. Any files inaccessible to this user will also be inaccessible to your website's visitors. The default for User is nobody, an unprivileged user.

The User should only have privileges so that it can access files which are supposed to be visible to the outside world. The User is also the owner of any CGI processes spawned by the server. The User should not be allowed to execute any code which is not intended to be in response to HTTP requests.

	Please Note
	Unless you know exactly what you're doing, don't set the User to root. Setting root as the User will create some big security holes for your Red Hat Linux Secure Server.

The parent httpd process first runs as root during normal operations, but is then immediately handed off to the nobody user. The server must start as root because it needs to bind to a port below 1024 (the default port for secure Web communications is port 443; the default port for non-secure Web communications is port 80). Ports below 1024 are reserved for system use, so they can't be used by anyone but root. Once the server has attached itself to its port, however, it hands off the process to the User before it accepts any connection requests.

Group

The Group setting is similar to the User setting. The Group sets the group under which the server will answer requests. The default Group is also nobody.

ServerAdmin

ServerAdmin should be the e-mail address of the Red Hat Linux Secure Server's administrator. This e-mail address will show up in error messages on server generated Web pages, so users can report a problem by sending e-mail to the server administrator. ServerAdmin is set by default to root@localhost, but you should change it to your webmaster or system administrator's e-mail address.

Typically, a good way to set up ServerAdmin is to set it to webmaster@your_domain.com. Then alias webmaster to the person responsible for the Web server in /etc/aliases. Finally, run /usr/bin/newaliases to add the new alias.

ServerName

You can use ServerName to set a hostname for your server which is different from your host's real name. For example, you might want to use www.your_domain.com when your server's real name is actually foo.your_domain.com. Note that the ServerName must be a valid Domain Name Service (DNS) name that you have the right to use (don't just make up something).

If you do specify a ServerName, be sure its IP address and server name pair are included in your /etc/hosts file.

DocumentRoot

The DocumentRoot is the directory which contains most of the HTML files which will be served in response to requests. The default DocumentRoot for both the non-secure and secure Web servers is /home/httpd/html. For example, the server might receive a request for the following document:

http://your_domain/foo.html

The server will look for the following request in the default directory:

/home/httpd/html/foo.html

If you want to change the DocumentRoot so that it is no longer shared by the Red Hat Linux Secure Server and the non-secure Web server, see the section called Using Virtual Hosts for instructions.

Options

The Options directive controls which server features are available in a particular directory. For example, under the restrictive parameters specified for the root directory, Options is set to None. No features are enabled.

By default, in your /home/httpd/html directory, Options is set to include Indexes, FollowSymLinks and Includes. Indexes permits the server to generate a directory listing for a directory if no DirectoryIndex (i.e., index.html, etc.) is specified. FollowSymLinks allows the server to follow symbolic links in that directory. Includes means that server-side includes are permitted.

You'll also need to include Options statements for directories within virtual hosts directives, if you want your virtual hosts to recognize those Options. Your secure Web server is configured as a virtual host in httpd.conf.ssl.

For example, server side includes are already enabled inside the /home/httpd/html directory, because of the Options Includes line within the /home/httpd/html Directory directives section. However, if you want a virtual host to recognize that server side includes are allowed within /home/httpd/html, you'll need to include a section like the following for your virtual host:

<Directory /home/httpd/html>
Options Includes
</Directory>

AllowOverride

The AllowOverride directive sets whether or not any Options can be overridden by the declarations in a .htaccess file. By default, the DocumentRoot is set to allow no .htaccess overrides.

order

The order directive simply controls the order in which allow and deny directives are evaluated. Your server is configured to evaluate the allow directives before the deny directives for your /home/httpd/html directory.

allow

allow specifies which requester can access a given directory. The requester can be all, a domain name, an IP address, a partial IP address, a network/netmask pair, etc. Your /home/httpd/html directory is configured to allow requests from all (i.e., anyone).

deny

Deny works just like allow, but you're specifying who is denied access. Your /home/httpd/html directory isn't configured to deny requests from anyone.

UserDir

UserDir is the name of the subdirectory within each user's home directory where they should place personal HTML files which are to be served by the Web server. By default, the subdirectory is public_html. For example, the server might receive the following request:

http://your_domain/~username/foo.html

The server would look for the file:

/home/username/public_html/foo.html

In the above example, /home/username is the user's home directory (note that the default path to users' home directories may be different on your system).

Make sure that the permissions on the users' home directories are set correctly. Users' home directories must be set to 0755. The r and x bits must be set on the users' public_html directories (0755 will work). Files that will be served in users' public_html directories must be set to at least 0644.

DirectoryIndex

The DirectoryIndex is the default page served by the server when a user requests an index of a directory by specifying a forward slash (/) at the end of the directory name.

For example, when a user requests the page http://your_domain/this_directory/, they are going to get either the DirectoryIndex page if it exists, or a server-generated directory listing. The default DirectoryIndex directive looks like the following:

DirectoryIndex index.html index.htm index.shtml index.cgi

The server will try to find any one of these four index files, and will return the first one it finds. If it doesn't find any of these files, the server will generate and return a listing, in HTML format, of the subdirectories and files in the directory.

AccessFileName

AccessFileName names the file which the server should use for access control information in each directory. By default, your Web server is set to use .htaccess, if it exists, for access control information in each directory.

Immediately after the AccessFileName directive, a set of Files tags apply access control to any .htaccess files. These directives deny Web access to any .htaccess files for security reasons.

If you use a different file instead of .htaccess for directory access control information, be sure to change the <Files .htaccess> line to include the name of the file you're using instead of .htaccess.

CacheNegotiatedDocs

By default, your Red Hat Linux Secure Server asks proxy servers not to cache any documents which were negotiated on the basis of content (i.e., they may change over time or because of the input from the requester). If you uncomment CacheNegotiatedDocs, you are disabling that function and proxy servers will be allowed to cache the documents from then on.

UseCanonicalName

UseCanonicalName is set by default to on. UseCanonicalName allows the server to construct a URL that references itself, using ServerName and Port. When the server refers to itself in response to requests from clients, it uses this URL. If you set UseCanonicalName to off, the server will instead use the value that came in the request from the client to refer to itself.

TypesConfig

TypesConfig names the file which sets the default list of MIME type mappings (filename extensions to content types). The default TypesConfig file is /etc/mime.types. Instead of editing /etc/mime.types, the recommended way to add MIME type mappings is to use the AddType directive.

DefaultType

DefaultType sets a default content type for the Web server to use for documents whose MIME types can't be determined. Your Web server defaults to assume a plain text content type for any file with an indeterminate content type.

IfModule

The <IfModule> and </IfModule> tags surround directives that are conditional. The directives contained within the IfModule tags are processed under one of two conditions. The directives are processed if the module contained within the starting <IfModule> tag is compiled in to the Apache server. Or, if an "!" (an exclamation point) is included before the module name, the directives are processed only if the module in the starting <IfModule> tag is not compiled in.

The mod_mime_magic.c file is included in these IfModule tags. The mod_mime_magic module is like the UNIX file command, which looks at a few bytes of a file's contents, then uses "magic numbers" and other hints in order to figure out the MIME type of the file.

If the mod_mime_magic module is compiled in to Apache, these IfModule tags tell the mod_mime_magic module where the hints definition file is: conf/magic in this case.

The mod_mime_magic module is not compiled in by default. If you would like to use it, see the section called Adding Modules to Your Server, for instructions on how to add modules to your server.

HostnameLookups

HostnameLookups can be set to on or off. If you allow HostnameLookups (by setting it to on), your server will automatically resolve the IP address for each connection which requests a document from your Web server. Resolving the IP address means that your server will make one or more connections to the Domain Name System (DNS) in order to find out the hostname that corresponds to a particular IP address.

Generally, you should leave HostnameLookups set to off, because the DNS requests add a load to your server and may slow it down. If your server is busy, the effects of HostnameLookups may be quite noticeable.

HostnameLookups are also an issue for the Internet as a whole. All of the individual connections made to look up each hostname add up to a significant amount of traffic on the Internet. Therefore, for your own Web server's benefit, as well as for the good of the Internet as a whole, you should leave HostnameLookups set to off.

ErrorLog

ErrorLog names the file where server errors are logged. As this directive indicates, the error log file for your non-secure Web server is /var/log/httpd/error_log.

The error_log file for your Red Hat Linux Secure Server is /etc/httpd/logs/ssl-error_log. The ErrorLog directive which names the Red Hat Linux Secure Server's error log is included in virtual host commands in the httpd.conf.ssl file.

Error logs are a good place to look if your Web server ever generates any errors or fails and you aren't sure what happened.

LogLevel

LogLevel sets how verbose the error messages in the error logs will be. LogLevel can be set (from least verbose to most verbose) to emerg, alert, crit, error, warn, notice, info or debug. Your Red Hat Linux Secure Server's LogLevel is set to warn (a happy medium).

LogFormat

The LogFormat directives in your httpd.conf file set up a format for the messages in your access log; hopefully, this format will make your access log more readable.

CustomLog

CustomLog identifies the log file and the log file format.

You'll need to know the location of the access log file if you want to generate any access-based server performance statistics for your non-secure Web server. The Webalizer, which you may install along with your Red Hat Linux Secure Server, is a program which parses the access log to generate statistics about your Web server's performance.

Note that the default access (or transfer) log for your non-secure server is /var/log/httpd/access_log. The TransferLog for your secure server, /etc/httpd/logs/ssl-access_log, is set in httpd.conf.ssl.

CustomLog also sets the log file format to common. The common logfile format looks like this:

remotehost rfc931 authuser [date] "request" status bytes

remotehost: The remote hostname. If the hostname is not available from DNS, or if HostnameLookups is set to Off, then remotehost will be the IP address of the remote host.
rfc931: Not used. You'll see a - in the log file in its place.
authuser: If authentication was required, this is the username with which the user identified him or herself. Usually, this isn't used, so you'll see a - in its place.
[date]: The date and time of the request.
"request": The request string exactly as it came from the browser or client.
status: The HTTP status code which was returned to the browser or client.
bytes: The size of the document.

The CustomLog command can be used to set up specific logfiles to record referers (the URL for the Web page which linked to a page on your Web server) and/or agents (the browsers used to retrieve Web pages from your Web server). The relevant CustomLog lines are commented out, as shown, but you should uncomment them if you want those two logfiles for your non-secure server:

#CustomLog /var/log/httpd/referer_log referer
#CustomLog /var/log/httpd/agent_log agent

Alternatively, you can also set the CommonLog directive to use a combined log by uncommenting the following line:

#CustomLog /var/log/httpd/access_log combined

A combined log will add the referer and agent fields to the end of the common log fields. If you want to use a combined log, you'll need to comment out the CustomLog directive setting your access log to the common logfile format.

ServerSignature

The ServerSignature directive adds a line containing the Apache server version and the ServerName of the serving host to any server-generated documents (for example, error messages sent back to clients). ServerSignature is set to on by default. You can change it to off, so no signature line will be added, or you can change it to Email, which will add a mailto:ServerAdmin HTML tag to the signature line.

Alias

The Alias setting allows directories to be outside the DocumentRoot directory and yet still accessible to the Web server. Any URL ending in the alias will automatically resolve to the alias' path. By default, one alias is already set up. An icons directory can be accessed by the Web server, but the directory is not in the DocumentRoot. The icons directory, an alias, is actually /home/httpd/icons/, not /home/httpd/html/icons/.

ScriptAlias

The ScriptAlias setting defines where CGI scripts (or other types of scripts) can be found. Generally, you don't want to leave CGI scripts within the DocumentRoot. If CGI scripts are in DocumentRoot, they could potentially be viewed as text documents. Even if you don't care if people can see (and then use) your CGI scripts, revealing how they work creates opportunities for unscrupulous people to exploit any security holes in the script, and may create a security risk for your server. By default, the cgi-bin directory is a ScriptAlias of /cgi-bin/, and is actually located in /home/httpd/cgi-bin/.

Your /home/httpd/cgi-bin directory has Options ExecCGI set, meaning that execution of CGI scripts is permitted within that directory.

See the section called AddHandler and the section called Directory for instructions on how to execute CGI scripts in directories other than the CGI bin.

Redirect

When a Web page is moved, Redirect can be used to map the old URL to a new URL. The format is as follows:

Redirect /path/foo.html http://new_domain/path/foo.html

So, if an HTTP request is received for a page which was formerly found at http://your_domain/path/foo.html, the server will send back the new URL (http://new_domain/path/foo.html) to the client, which should attempt to fetch the document from the new URL.

IndexOptions

IndexOptions controls the appearance of server generated directory listings, by adding icons and file descriptions. Your Web server may generate a directory listing when it receives an HTTP request like the following:

http://www.your_domain.com/this_directory/

First, your Web server looks in that directory for a file from the list after the DirectoryIndex directive. If your Web server doesn't find one of those files, it creates an HTML directory listing of the subdirectories and files in the directory. You can modify the appearance of this directory listing using certain directives in httpd.conf, including IndexOptions.

Your default configuration sets FancyIndexing on. If FancyIndexing is turned on, clicking on the column headers in the directory listing will sort the order of the display by that header. Another click on the same header will switch from ascending to descending order and back. FancyIndexing also shows different icons for different files, depending upon file extensions.

IndexOptions has a number of other parameters which can be set to control the appearance of server generated directories. Parameters include IconHeight and IconWidth, to make the server include HTML HEIGHT and WIDTH tags for the icons in server generated Web pages; IconsAreLinks, for making the icons act as part of the HTML link anchor along with the filename, and others. See the Apache documentation for more details, if you'd like to control the appearance of your server generated directories.

AddIconByEncoding

This directive names icons which will be displayed by files with MIME encoding, in server generated directory listings. For example, by default, your Web server shows the compressed.gif icon next to MIME encoded x-compress and x-gzip files in server generated directory listings.

AddIconByType

This directive names icons which will be displayed next to files with MIME types in server generated directory listings. For example, your server is set to show the icon text.gif next to files with a mime-type of "text," in server generated directory listings.

AddIcon

AddIcon tells the server which icon to show in server generated directory listings for certain file types or for files with certain extensions. For example, your Web server is set to show the icon binary.gif for files with .bin or .exe extensions.

DefaultIcon

DefaultIcon names the icon to show in server generated directory listings for files which have no other icon specified. The unknown.gif image file is the DefaultIcon for those files by default.

AddDescription

You can use AddDescription to show text that you specify for certain files, in server generated directory listings. You can name specific files, wildcard expressions or file extensions to specify the files which this directive should apply to. For example, you could use the following line:

AddDescription "A file that ends in .ni" .ni

In server generated directory listings, all files with extensions of .ni would have the description A file that ends in .ni after the filename. Note that you'll also need FancyIndexing turned on.

ReadmeName

ReadmeName names the file which (if it exists in the directory) will be appended to the end of server generated directory listings. The Web server will first try to include the file as an HTML document and then try to include it as plain text. By default, ReadmeName is set to README.

HeaderName

HeaderName names the file which (if it exists in the directory) will be prepended to the start of server generated directory listings. Like ReadmeName, the server will try to include it as an HTML document if possible, or in plain text if not.

IndexIgnore

IndexIgnore lists file extensions, partial filenames, wildcard expressions or full filenames. The Web server will not include any files which match any of those parameters in server generated directory listings.

AddEncoding

AddEncoding names filename extensions which should specify a particular encoding type. AddEncoding can also be used to instruct some browsers (not all) to uncompress certain files as they are downloaded.

AddLanguage

AddLanguage associates filename extensions with specific content languages. This directive is mostly useful for content negotiation, when the server returns one of several documents based on the client's language preference as set in their browser.

LanguagePriority

LanguagePriority allows you to set precedence for different languages in which to serve files. This setting will be in effect if the client set no language preference in their browser.

AddType

Use the AddType directive to define MIME type and file extension pairs. For example, if you are using mod_php, your Web server is using the AddType directive to make your Web server recognize files with PHP extensions (.php3 .phps .phtml) as PHP MIME types.

The following AddType line tells your server to recognize the .shtml file extension (for server side includes):

AddType text/html .shtml

You'll need to include the above line within the virtual host tags for any virtual hosts which should allow server side includes.

AddHandler

AddHandler maps file extensions to specific handlers. For example, the cgi-script handler can be used matched with the extension .cgi to automatically treat a file ending with .cgi as a CGI script. This will work even for files outside of the ScriptAlias directory. You have such an AddHandler line in your httpd.conf file:

#AddHandler cgi-script .cgi

You'll have to uncomment the line. Then Apache will execute CGI scripts for files ending in .cgi, even if they are outside of the ScriptAlias, which is set by default to locate your /cgi-bin/ directory in /home/httpd/cgi-bin/.

You'll also need to set ExecCGI as an Options directive for any directory containing a CGI script. See the section called Directory for more information about setting ExecCGI for a directory. Additionally, you'll need to make sure the permissions are set correctly for the CGI scripts and the directories containing CGI scripts. CGI scripts and the entire directory path to the scripts must be set to 0755. Finally, the owner of the directory and the owner of the script file must be the same user.

You'll need to add the same AddHandler line to your VirtualHost setup, if you're using virtual hosts and you want them to also recognize CGI scripts outside the ScriptAlias.

In addition to CGI scripts, your Web server also uses AddHandler to process server-parsed HTML and imagemap files.

Action

Action allows you to specify a MIME content type and CGI script pair, so that whenever a file of that media type is requested, a particular CGI script will be executed.

MetaDir

MetaDir specifies the name of a directory where your Web server should look for files containing meta information (extra HTTP headers) to include when serving documents.

MetaSuffix

MetaSuffix specifies the filename suffix for the file that contains meta information (extra HTTP headers), which should be located in the MetaDir directory.

ErrorDocument

By default, in the event of a problem or error, your Web server outputs a simple (and usually cryptic) error message back to the requesting client. Instead of using the default, you can use ErrorDocument to configure your Web server so that it outputs a customized message or redirects the client to a local or external URL. ErrorDocument simply associates an HTTP response code with a message or a URL which will be sent back to the client.

BrowserMatch

The BrowserMatch directive allows your server to define environment variables and/or take appropriate actions based on the User-Agent HTTP header field, which identifies the client's browser. By default, your Web server uses BrowserMatch to deny connections to specific browsers with known problems and also to disable keepalives and HTTP header flushes for browsers that are known to have problems with those actions.

Location

The <Location> and </Location> tags allow you to specify access control based on the URL.

The first use of Location tags is located within IfModule mod_perl.c tags. These configuration directives are in effect if the mod_perl.c module is compiled in to Apache. See the section called Adding Modules to Your Server for more information about adding modules to Apache.

The Location tags name the /home/httpd/perl directory (an Alias for /perl) as the directory from which Perl scripts will be served. If a document is requested with an URL containing /perl in the path, your Web server will look in /home/httpd/perl/ for the appropriate Perl script.

Several other <Location> options are commented out in your httpd.conf file, including sections to allow HTTP put (e.g., Netscape Gold's Publish feature) and to allow access to local system documentation from localhost.

Additionally, if you want to allow people connecting from your domain to see server status reports, you should uncomment the following lines:

#<Location /server-status>
#    SetHandler server-status
#    Order deny,allow
#    Deny from all
#    Allow from .your_domain.com
#</Location>

You must replace .your_domain.com with your second level domain name.

If you want to provide server configuration reports (including installed modules and configuration directives) to requests from inside your domain, you'll need to uncomment the following lines:

#<Location /server-info>
#    SetHandler server-info
#    Order deny,allow
#    Deny from all
#    Allow from .your_domain.com
#</Location>

Again, you must fill in .your_domain.com.

Another use of the Location tags can be found in a commented-out section which is intended to track attacks on your Web server that exploit an old bug from pre-Apache 1.1 days. If you want to track these requests, uncomment the following lines:

#<Location /cgi-bin/phf*>
#    Deny from all
#    ErrorDocument 403 http://phf.apache.org/phf_abuse_log.cgi
#</Location>

If these lines are uncommented, your Web server will redirect any requests which end in /cgi-bin/phf* to a logging CGI script run by the Apache Group.

ProxyRequests

If you uncomment the IfModule tags surrounding the ProxyRequests section, your Apache server will also function as a proxy server. Apache proxy serving is enabled by the mod_proxy module which was compiled in and loaded with your Web server by default.

ProxyVia

The ProxyVia command controls whether or not an HTTP Via: header line is sent along with requests or replies which go through the Apache proxy server. The Via: header will show the hostname if ProxyVia is set to on, the hostname and Apache version for full, any Via: lines will be passed along unchanged for off, and Via: lines will be removed for block.

Cache Directives

A number of cache directives are commented out in the IfModule tags mentioned above. If you are using the proxy server functionality and you want to also enable the proxy cache, you should uncomment the cache directives as described. The default settings for your cache directives should be appropriate for most configurations.

CacheRoot sets the name of the directory which will contain cached files. The default CacheRoot is /var/cache/httpd.

CacheSize sets how much space the cache can use, in KB. The default CacheSize is 5 KB.

CacheGcInterval sets a number of hours. After the specified number of hours, files in the cache will be deleted if the cache is using more space than allowed by CacheSize. The default for CacheGcInterval is four hours.

Cached HTML documents will be retained (without a reload from the originating Web server) in the cache for a maximum number of hours set by CacheMaxExpire. The default is 24 hours.

The CacheLastModifiedFactor affects the creation of an expiration date for a document which did not come from its originating server with its own expiration date set. The default CacheLastModifiedFactor is set to 0.1, meaning that the expiration date for such documents equals one-tenth of the amount of time since the document was last modified.

CacheDefaultExpire is the expiration time in hours for a document that was received using a protocol that doesn't support expiration times. The default is set to one hour.

Any document that is retrieved from a host and/or domain that matches one set in NoCache will not be cached. If you know of hosts or domains from which you don't want to cache documents, uncomment NoCache and set their domains or hostnames here.

NameVirtualHost

You'll need to use the NameVirtualHost directive for the IP address (and port number if necessary) of any name-based virtual hosts you're setting up. The name-based virtual hosts configuration is used when you want to set up different virtual hosts for different domain names, but you don't have (or don't want to use) different IP addresses for all of the different domain names for which your Web server serves documents.

Please Note

You can't use name-based virtual hosts with your Red Hat Linux Secure Server, but you can set up name-based virtual hosts with your non-secure Web server. You can't use name-based virtual hosts with your Red Hat Linux Secure Server because the SSL handshake (when the browser accepts the secure Web server's authenticating certificate) occurs before the HTTP request which identifies the correct name-based virtual host. In other words, authentication occurs before there is any differentiation between name-based virtual hosts. If you want to use virtual hosts with your Red Hat Linux Secure Server, you'll need to use IP address-based virtual hosts.

If you're using name-based virtual hosts, uncomment the NameVirtualHost configuration directive and add the correct IP address for your server after NameVirtualHost. Then add more information about the different domains using the Virtual Host tags which surround the ServerName for each virtual host, plus any other configuration directives which are only applicable to that virtual host.

VirtualHost

The <VirtualHost> and </VirtualHost> tags surround any configuration directives which are intended to apply to a virtual host. Most configuration directives can be used within virtual host tags, and then they only apply to that particular virtual host.

A set of commented out VirtualHost tags surrounds some example configuration directives and placeholders for the information you'd need to fill in to set up a virtual host. Please see the section called Using Virtual Hosts, for more information about virtual hosts.

SSL Configuration Directives

The SSL directives in your server's httpd.conf.ssl file are included to enable secure Web communications. Short descriptions of the SSL directives used in your httpd.conf configuration file are provided next. For more information on SSL directives, please point your browser to http://your_domain/manual/mod/mod_ssl/. More information on SSL directives is also available at http://www.modssl.org/docs/2.6/ssl_reference.html, an individual chapter in a Web document about mod_ssl by Ralf Engelschall. That document, the mod_ssl User Manual, begins at http://www.modssl.org/docs/2.6/ and is a great reference source for mod_ssl (of course) and for Web cryptography in general. This document provides general information about securing your Web server in Chapter 3.

	Please Note
	Don't modify your SSL directives unless you're absolutely sure about what you're doing. For most users, the SSL directives are configured appropriately as installed.

The first set of SSL configuration directives, within the IfModule tags, applies to all SSL-enabled server processes on your machine.

When Apache starts, it reads your certificate and key files. Mod_ssl can be configured to ask for a pass phrase before this is allowed. The SSLPassPhraseDialog directive sets whether mod_ssl uses a built-in interactive dialog to ask for the pass phrase, or whether an external program is used to add extra security checks before asking for the pass phrase.

The SSLSessionCache directive tells your server where the SSL information cache is located. Using a cache for this information speeds up server responses to parallel requests from modern browsers.

The SSLSessionCacheTimeout directive sets the timeout in seconds for the cached information in the SSL Session Cache. The timeout is set to 300 seconds.

The SSLMutex directive provides configuration information for your SSL engine's semaphore. The semaphore or lock provides for mutual exclusion of operations which have to be done in a synchronized way by pre-forked server processes. Your server uses a physical lock file, located in /var/run/ssl_mutex.

The SSLRandomSeed directive provides configuration information for the Pseudo Random Number Generator (PRNG) at startup and/or just before a new SSL connection is made. Both startup and connect are set to use the built-in random seed source.

The SSL engine's logfile, /etc/httpd/logs/ssl_engine_log, is named by the SSLLog directive. Error messages will also be written to the server's error logfile: /etc/httpd/logs/error_log.

SSLLogLevel sets how verbose the error log messages are, in order from least to most verbose: none, error, warn, info, trace, debug. Your SSLLogLevel is set to warn.

The rest of the SSL configuration directives apply specifically to the SSL virtual host set up for you in httpd.conf.ssl.

The SSLEngine toggles SSL on or off for the virtual host.

The SSLCipherSuite is used to specify the cipher suite available for negotiation during an SSL handshake.

The SSLCertificateFile states the path to your certificate. After your certificate is created, it will be saved in /etc/httpd/conf/server.crt.

The SSLCertificateKeyFile states the path to your key. After your key is created, it will be saved in /etc/httpd/conf/server.key.

The Apache configuration directive SetEnvIf is used to disable HTTP keep-alive and to allow SSL to close the connection without a close notify alert from the client browser. This setting is necessary for certain browsers that don't reliably shut down the SSL connection.