Configuring the Apache Server


The primary file for configuring your Apache Web server is httpd.conf (located in the /etc/httpd/conf directory). A few years ago, the Apache project began recommending not using additional configuration files, such as srm.conf and access.conf , and simply put everything in httpd.conf . In recent releases, however, there has been a trend toward having modules and other components that are used with Apache have their own configuration files (usually located in the /etc/httpd/conf.d directory).

All Apache configuration files are plain-text files and can be edited with your favorite text editor. The /etc/httpd/conf/httpd.conf file is reproduced in its entirety in the following section, with explanations inserted after related blocks of options (intended to supplement the comments provided with each file).

Some individual modules, scripts and other services related to Apache, such as perl, php, ssl, webalizer, and mysql, have individual configuration files that may interest you. Those files are contained in the /etc/httpd/conf.d directory. The "Configuring modules and related services (/etc/httpd/conf.d/*.conf)" section later in this chapter discusses modules and related features.

Cross-Reference 

More information on Apache can be obtained on your own Web server, from http://localhost/manual/ (if the httpd-manual package is installed).

Configuring the Web Server (httpd.conf)

The httpd.conf file is the primary configuration file for the Apache Web server. It contains options that pertain to the general operation of the server. The default filename ( /etc/httpd/conf/httpd.conf ) can be overridden by the -f filename command-line argument to the httpd daemon or the ServerConfigFile directive. The following sections list the contents of the httpd.conf file and describe how to use the file.

Note 

If you get "access denied " errors when someone tries to access your Web server, check your SELinux settings. (See Chapter 10 for more on SELinux.) By running the Security Level Configuration window, and selecting HTTPD Service on the SELinux tab, you can see how access is being restricted for your Web server. It's possible that certain scripts and user content may not be able to be run or displayed with restrictive SELinux policies. Port 80 on your firewall must also be open to allow Web service.

The first section contains comments about the httpd.conf file:

 # # Based on the NCSA server configuration files originally by Rob McCool # # This is the main Apache server configuration file. It contains the # configuration directives that give the server its instructions. # See <URL:http://httpd.apache.org/docs-2.0/> for detailed information # about the directives. # # Do NOT simply read the instructions in here without understanding # what they do. They're here only as hints or reminders. If you are # unsure consult the online docs. You have been warned . # # The configuration directives are grouped into three basic sections: # 1. Directives that control the operation of the Apache server # process as a whole (the 'global environment'). # 2. Directives that define parameters of the main or default server, # which responds to requests that aren't handled by a virtual host. # These directives also provide default values for the settings # of all virtual hosts. # 3. Settings for virtual hosts , which allow Web requests to be sent # to different IP addresses or hostnames and have them handled by # the same Apache server process. # # Configuration and logfile names : If the filenames you specify for # many of the server's control files begin with "/" (or "drive:/" for # Win32), the server will use that explicit path . If the filenames do # *not* begin with "/", the value of ServerRoot is prepended -- so # "logs/foo.log"with ServerRoot set to "/usr/local/apache" will be # interpreted by the server as "/usr/local/apache/logs/foo.log". # 

This section consists entirely of comments. It basically tells you how information is grouped together in this file and how the httpd daemon accesses this file. By default, log files are in the /var/log/httpd directory.

Setting the Global Environment

In "Section 1: Global Environment" of the httpd.conf file, you set directives that affect the general workings of the Apache server. Here is what the different directives are for:

 ### Section 1: Global Environment # # The directives in this section affect overall operation of Apache, # such as the number of concurrent requests it can handle or where it # can find its configuration files. # 
Revealing Subcomponents

The ServerTokens directive lets you prevent remote computers from finding out what subcomponents you are running on your Apache server. Comment out this directive if you don't mind exposing this information. To prevent exposure, ServerTokens is set as follows :

 # # Don't give away too much information about all the subcomponents # we are running. Comment out this line if you don't mind remote sites # finding out what major optional modules you are running ServerTokens OS 
Setting the Server Root Directory

The ServerRoot directive specifies the directory that contains the configuration files, a link to the log file directory, and a link to the module directory. An alternative ServerRoot path name can be specified using the -d command-line argument to httpd .

 # ServerRoot: The top of the directory tree under which the server's # configuration, error, and log files are kept. # # NOTE! If you intend to place this on an NFS (or other network) mounted # filesystem then please read the LockFile documentation (available # at <URL:http://httpd.apache.org/docs-2.0/mod/ core .html#lockfile>); # you will save yourself a lot of trouble. # # Do NOT add a slash at the end of the directory path. # ServerRoot "/etc/httpd" 
Storing the Server's PID File

The Apache Web server keeps track of the PID for the running server process. You can change the locations of this file using the entry described next :

 # # PidFile: The file in which the server should record its process # identification number when it starts. # PidFile run/httpd.pid 

Apache uses the PidFile to store the process ID of the first (root-owned) master daemon process. This information is used by the /etc/init.d/httpd script when shutting down the server and also by the server-status handler (as described later).

Configuring Timeout Values

You can set several values that relate to timeout. Some of these values are described in the text following the code:

 # # Timeout: The number of seconds before receives and sends time out. # Timeout 120 # # KeepAlive: Whether or not to allow persistent connections (more than # one request per connection). Set to "Off" to deactivate. # KeepAlive Off # # MaxKeepAliveRequests: The maximum number of requests to allow # during a persistent connection. Set to 0 to allow unlimited amount. # We recommend you leave this number high, for maximum performance. # MaxKeepAliveRequests 100 # # KeepAliveTimeout: Number of seconds to wait for the next request from # the same client on the same connection. # KeepAliveTimeout 15 

The Timeout directive determines the number of seconds that Apache will hold a connection open between the receipt of packets, between the receipt of acknowledgments on sent responses, or while receiving an incoming request. The default of two minutes (120 seconds) can be lowered if you find an excessive number of open, idle connections on your machine.

The KeepAlive directive instructs Apache to hold a connection open for a period of time after a request has been handled. This enables subsequent requests from the same client to be processed faster, as a new connection doesn't need to be created for each request.

The MaxKeepAliveRequests directive sets a limit on the number of requests that can be handled with one open connection. The default value is certainly reasonable because most connections will hit the KeepAliveTimeout before MaxKeepAliveRequests .

The KeepAliveTimeout directive specifies the number of seconds to hold the connection while awaiting another request. You might want to increase the default (15 seconds). Reasons for having a longer timeout could be to allow all the images on the page to be downloaded on the same connection or to take into account how long it may take a client to peruse your average page and select a link from it. The Web application you are using may also need a longer persistent connection. (Of course, a longer KeepAliveTimeout prevents each server from moving on to another client during this time period, so you may find that you need to add more request processes to account for that.)

Setting the Number of Server Processes

To operate efficiently , a Web server has to be able to handle lots of incoming requests for content simultaneously . To be ready for requests for Web content, Apache (as it is set up in Fedora) has multiple server processes ( httpd daemons) running and listening to service requests. Those servers can, in turn , direct requests to multiple threads to service the content requests.

With the Multi-Processing Module (MPM) feature (introduced in Apache 2.0), support for threads was added to Apache. On an operating system that supports Native POSIX Thread Libraries (which Fedora and RHEL do), threading allows Apache to improve performance by needing fewer process slots and less memory for the number of servers it needs. Adding threads consumes fewer resources than adding processes.

For a low-volume Web server, you can probably leave the parameters alone that support the MPM feature. You will probably have enough processes to handle your incoming requests, but not so many that they will be a drain on your server. However, if your server needs to serve up lots of content consistently, or needs to respond occasionally to large spikes of requests, you should consider tuning the MPM-related parameters in the httpd.conf file.

Here are a few issues to consider if you want to change any of the MPM-related parameters:

  • RAM is critical - Every process and thread that is active consumes some amount of memory. If the number of active processes and threads goes beyond the amount of RAM you have, your computer will begin to use swap space and performance will degrade quickly. Make sure this is enough RAM on your system to handle the maximum number of server processes and threads you expect to run on your Apache Web server.

  • Configure for maximum load - Apache is able to create new server processes and threads as they are needed. You don't need to have the maximum number of processes and threads available at all times. Instead, you can configure the maximum number of servers and threads that Apache can dynamically add as demand on the server requires.

  • Configure for performance - Performance degrades when Apache has to start a new thread (small amount), start a server process (greater amount), or use swap space (greatest amount). In the perfect world, the exact number of servers you need should be the default number of servers running, with a few spares to handle reasonable spikes. If response is critical, you might opt to have more servers running than you need so that performance isn't hurt when spikes come.

When Apache starts up, it launches a set number of httpd server processes (one parent and multiple child httpd processes) to handle incoming requests for content for the Web server. Parameters for defining how many httpd server processes are available include those that set:

  • How many child server processes should be started by the parent httpd server ( StartServers )

  • The minimum number of server processes kept spare ( MinSpareServers )

  • The maximum number of server processes kept spare ( MaxSpareServers )

  • The maximum value MaxClients can be over the life of the server ( ServerLimit )

  • The maximum number of server processes allowed to start ( MaxClients )

  • The maximum number of requests a process can serve ( MaxRequestsPerChild)

Parameters for defining how many threads are available for each httpd server process include those that set:

  • The minimum number of spare threads that should always be available, after which more will be created ( MinSpareThreads )

  • The maximum number for spare threads, after which active threads will be deleted to get back to the number of threads per child ( MaxSpareThreads )

  • The number of threads always available to each child process ( ThreadsPerChild )

The following code example shows how MPM-specific parameters in the httpd.conf file are set for the prefork.c module (non-threaded module for managing servers processes) and worker.c (multithread, multiprocess Web server module).

 ## ## Server-Pool Size Regulation (MPM specific) ## <IfModule prefork.c> StartServers 8 MinSpareServers 5 MaxSpareServers 20 ServerLimit 256 MaxClients 256 MaxRequestsPerChild 4000 </IfModule> <IfModule worker.c> StartServers 2 MaxClients 150 MinSpareThreads 25 MaxSpareThreads 75 ThreadsPerChild 25 MaxRequestsPerChild 0 </IfModule> 

Apache starts a master daemon process owned by root that binds to the appropriate port, and then switches to a nonprivileged user. More servers (equivalent to the value of the StartServers directive in prefork.c ) will then be started as the same nonprivileged user (the apache user in this case).

Apache attempts to intelligently start and kill servers based on the current load. If the amount of traffic decreases and there are too many idle servers, some will be killed (down to the number of servers noted in MinSpareServers ). Similarly, if many requests arrive in close proximity and there are too few servers waiting for new connections, more servers will be started (up to the number of servers noted in MaxClients ).

Note 

Getting the value of MaxClients right is critical, because it puts a lid on the total number of simultaneous client connections that can be active at a time. If the number of MaxClients servers are in use, no more will be created and subsequent requests to the server will fail.

Using the values specified above, when the daemon is started, the parent and eight child server processes will run, waiting for connections (as defined by StartServers ). As more requests arrive, Apache will ensure that at least five server processes are ready to answer requests. When requests have been fulfilled and no new connections arrive, Apache will begin killing processes until the number of idle Web server processes is below 20. The value of StartServers should always be somewhere between MinSpareServers and MaxSpareServers .

Apache limits the total number of simultaneous threads with the MaxClients directive. The default value is 150, which should be sufficiently high. However, if you find that you frequently have nearly that many threads running, remember that any connection beyond the 150th will be rejected. In such cases, if your hardware is sufficiently powerful (and if your network connection can handle the load), you should increase the value of MaxClients .

Note 

You can see the state of your Apache server processes and get a feel for the server's activity by viewing the server-status page for your server, as described later in this chapter. The ps -fU apache command will show you if the apache server processes (httpd daemon) are currently running.

To minimize the effect of possible memory leaks (and to keep the server pool "fresh"), each server process is limited in the number of requests that it can handle (equal to the value of MaxRequestsPerChild ). After servicing 4000 requests (the value specified above), the process will be killed. It is even more accurate to say that each process can service 4000 connections because all KeepAlive requests (occurring prior to encountering a KeepAliveTimeout ) are calculated as just one request.

In a multiprocessor environment, setting thread values described previously can both limit the number of threads that servers can consume and supply as many threads as you will allow to handle server processing. MinSpareThreads and MaxSpareThreads control the number of threads available that are not being used. More are added if available threads fall below MinSpareThreads . If spare threads go above MaxSpareThreads , some are dropped.

Binding to Specific Addresses

You can bind to specific IP addresses using the Listen directive. Listen directives can be used to add to the default bindings you already have:

 # Listen: Allows you to bind Apache to specific IP addresses and/or # ports, in addition to the default. See also the <VirtualHost> # directive. # # Change this to Listen on specific IP addresses as shown below to # prevent Apache from glomming onto all bound IP addresses (0.0.0.0) #Listen 12.34.56.78:80 Listen 80 

The Listen directive is more flexible than the BindAddress and Port directives. Multiple Listen commands can be specified, enabling you to specify several IP address/port number combinations. It can also be used to specify just IP addresses (in which case the Port directive is still necessary) or just port numbers .

By default, Apache listens to port 80 (for standard http services) and port 443 (for secure https services) on all interfaces on the local computer (which is where Web browsers expect to find Web content). Listening on only localhost:80 restricts access only to users on the local machines. If you have multiple network interface cards, you can limit which interfaces apache will listen on (for example, you can have a Web server only intended for the company LAN which is not exposed to your Internet interface).

Selecting Modules in httpd.conf

During the compilation process, individual Apache modules can be selected for dynamic linking. Dynamically linked modules are not loaded into memory with the httpd server process unless LoadModule directives explicitly identify those modules to be loaded. The blocks of code that follow select several modules to be loaded into memory by using the LoadModule directive with the module name and the path to the module (relative to ServerRoot ). The following text shows a partial listing of these modules:

 # # Dynamic Shared Object (DSO) Support # Example: # LoadModule foo_module modules/mod_foo.so # LoadModule access_module modules/mod_access.so LoadModule auth_module modules/mod_auth.so LoadModule auth_anon_module modules/mod_auth_anon.so LoadModule auth_dbm_module modules/mod_auth_dbm.so LoadModule auth_digest_module modules/mod_auth_digest.so LoadModule include_module modules/mod_include.so LoadModule log_config_module modules/mod_log_config.so . . . LoadModule actions_module modules/mod_actions.so LoadModule speling_module modules/mod_speling.so LoadModule userdir_module modules/mod_userdir.so LoadModule alias_module modules/mod_alias.so LoadModule rewrite_module modules/mod_rewrite.so 

Apache modules are included in the list of active modules via the LoadModule directive. The ClearModuleList directive removes all entries from the current list of active modules. Each of the standard modules that come with Apache is described in Table 21-1.

Table 21-1: Dynamic Shared Object (DSO) Modules
Open table as spreadsheet

Module

Description

mod_actions

Conditionally executes CGI scripts based on the file's MIME type or the request method.

mod_alias

Allows for redirection and mapping parts of the physical file system into logical entities accessible through the Web server.

mod_asis

Enables files to be transferred without adding any HTTP headers (for example, the Status, Location, and Content-type header fields).

mod_auth_basic

Provides HTTP Basic Authentication. It is used in combination with authentication modules (such as mod_authn_file) and authorization modules (such as mod_authz_user).

mod_authn_anon

Similar to anonymous FTP, this module enables predefined user names access to authenticated areas by using a valid e-mail address as a password.

mod_authn_dbm

Provides access control based on user name/password pairs. The authentication information is stored in a DBM binary database file, with encrypted passwords.

mod_authz_dbm

Provides access control to authenticated users based on group name. The authentication information is stored in a DBM binary database file.

mod_auth_digest

Provides MD5 Digest user authentication.

mod_authnz_ldap

Lets you use an LDAP directory to store the HTTP Basic authentication database.

mod_autoindex

Implements automatically generated directory indexes.

mod_cache

Allows local or proxied Web content to be cached. Used with the mod_disk_cache or mod_mem_cache modules.

mod_cern_meta

Offers a method of emulating CERN HTTPD meta file semantics.

mod_cgi

Controls the execution of files that are parsed by the "cgi-script" handler or that have a MIME type of x-httpd-cgi. ScriptAlias sets the default directory.

mod_dav

Provides Web-based Distributed Authoring and Versioning (WebDAV) to upload Web content using copy, create, move, and delete resources.

mod_dav_fs

Used to provide file system features to the mod_dav module, used with Web-based Distributed Authoring and Versioning (WebDAV).

mod_deflate

Includes the DEFLATE output filter, to compress data before it is sent to the client.

mod_dir

Sets the list of filenames that may be used if no explicit filename is selected in a URL that references a directory.

mod_disk_cache

Enables a disk-based storage manager to use with mod_proxy .

mod_env

Controls environment variables passed to CGI scripts.

mod_ext_filter

Before delivering a resonse to the client, pass it through an external filter.

mod_expires

Implements time limits on cached documents by using the Expires HTTP header.

mod_file_cache

Allows caching of frequently requested static files.

mod_headers

Enables the creation and generation of custom HTTP headers.

mod_include

Implements Server-Side Includes (SSI), which are HTML documents that include conditional statements parsed by the server prior to being sent to a client. This module also has the ability to include files one into another.

mod_info

Provides a detailed summary of the server's configuration, including a list of actively loaded modules and the current settings of every directive defined within each module.

mod_ldap

Used to speed performance of Web sites using LDAP servers.

mod_logio

Can be used to log bytes of data that are sent and received.

mod_log_config

Enables a customized format for information contained within the log files.

mod_mem_cache

Used with mod_cache to provide memory-based storage.

mod_mime

Alters the handling of documents based on predefined values or the MIME type of the file.

mod_mime_magic

Similar to the UNIX file command, this module attempts to determine the MIME type of a file based on a few bytes of the file's contents.

mod_negotiation

Provides for the conditional display of documents based on the Content-Encoding, Content-Language, Content-Length, and Content-Type HTTP header fields.

mod_proxy

Implements an HTTP 1.1 proxy/gateway server.

mod_proxy_balancer

Extension to mod_proxy to handle load balancing.

mod_proxy_connect

Extension to mod_proxy to handle CONNECT requests.

mod_proxy_ftp

Extension to mod_proxy to handle FTP requests.

mod_proxy_http

Extension to mod_proxy to handle HTTP requests.

mod_rewrite

Provides a flexible and extensible method for redirecting client requests and mapping incoming URLs to other locations in the file system.

mod_setenvif

Conditionally sets environment variables based on the contents of various HTTP header fields.

mod_speling

Attempts to correct misspellings automatically in requested URLs.

mod_ssl

Implements cryptography using SSL and TLS protocols.

mod_status

Provides a summary of the activities of each individual httpd server process, including CPU and bandwidth usage levels.

mod_suexec

Lets CGI scripts run with permission of a particular user or group.

mod_userdir

Specifies locations that can contain individual users' HTML documents.

mod_usertrack

Uses cookies to track the progress of users through a Web site.

mod_vhost_alias

Contains support for dynamically configured mass virtual hosting.

If a particular module contains features that are not necessary, it can easily be commented out of the preceding list. In fact, it is a good security practice to comment out unused modules. Similarly, you might want to add the features or functionality of a third-party module (for example, mod_perl , which integrates the Perl runtime library for faster Perl script execution, or mod_php , which provides a scripting language embedded within HTML documents) by including those modules in the list.

Note 

Some modules, including core, prefork, http_core, and mod_so, are compiled into the httpd daemon in Fedora and RHEL. To see the list of modules compiled into the daemon, type the httpd -l command.

Besides those modules shown here, a group of authentication modules (mod_authn* and mod_authz*) were added to Apache for this release to facilitate finer control over authentication of users, groups, aliases, and hosts. More information about each module (and the directives that can be defined within it) can be found on your server at http://localhost/manual/mod/ .

Including Module-Specific Configuration Files

The following lines cause Apache to load configuration files from the /etc/httpd/conf.d directory. This directory contains configuration files associated with specific modules.

 # # Load config files from the config directory "/etc/httpd/conf.d". # Include conf.d/*.conf 
Cross-Reference 

The "Configuring modules and related services (/etc/httpd/conf.d/*.conf)" section, later in this chapter, describes some of the configuration files in the conf.d directory that may interest you.

Choosing the Server's User and Group

The httpd daemon doesn't have to run as the root user; the fact that it doesn't run as root by default makes your system more secure. By setting User and Group entries, you can have the httpd daemon run using the permissions associated with a different user and group:

 # If you wish httpd to run as a different user or group, you must run # httpd as root initially and it will switch. # # User/Group: The name (or #number) of the user/group to run httpd as. # . On SCO (ODT 3) use "User nouser" and "Group nogroup". # . On HPUX you may not be able to use shared memory as nobody, and # the suggested workaround is to create a user www and use that user. # NOTE that some kernels refuse to setgid(Group) or semctl (IPC_SET) # when the value of (unsigned)Group is above 60000; # don't use Group #-1 on these systems! # User apache Group apache 

By default, apache is defined as both the user and group for the server. If you change the User and Group directives, you should specify a nonprivileged entity. This minimizes the risk of damage if your site is compromised. The first daemon process that is started runs as root. This is necessary to bind the server to a low-numbered port and to switch to the user and group specified by the User and Group directives. All other processes run under the user ID (UID) and group ID (GID) defined by those directives.

Setting the Main Server's Configuration

The second section of the http.conf file relates to directives handled by your main server (the one defined by the ServerName directive). In other words, these values are used by the default server and for all virtual hosts, unless they are explicitly changed for a virtual host. To change the same directives for particular virtual hosts, add them within virtual host containers.

Setting an E-Mail Address

You can identify an address where users can send e-mail if there is a problem with your server. This is done with the ServerAdmin directive:

 # # ServerAdmin: Your address, where problems with the server should be # e-mailed. This address appears on some server-generated pages, such # as error documents. e.g. admin@your-domain.com # ServerAdmin you@your.address 

The ServerAdmin directive can be set to any valid e-mail address. The default is root@localhost .

Setting the Server Name

If your server name is anything but your exact registered host or domain name, you should identify your server name here. As the comments point out, the ServerName directive can be set to a value other than the actual hostname of your machine. However, this other name should still point to your machine in DNS if the server is to be a public Internet server. Frequently, www is just an alias for the real name of the machine (for example, a machine may respond to www.linuxtoys.net , but its real name may be al.linuxtoys.net ).

 ServerName jukebox.linuxtoys.net 

Apache tries to use your hostname as the ServerName , if you don't enter a valid server name. It is recommended that you explicitly enter a ServerName here.

Setting Canonical Names

Use the UseCanonicalName directive to create a self-referencing URL, as follows:

 ## UseCanonicalName: Determines how Apache constructs self-referencing # URLs and the SERVER_NAME and SERVER_PORT variables. # When set "Off", Apache will use the Hostname and Port supplied # by the client. When set "On", Apache will use the value of the # ServerName directive. # UseCanonicalName Off 

The UseCanonicalName directive provides a form of naming consistency. When it is set to On , Apache uses the ServerName and Port directives to create a URL that references a file on the same machine (for example, http://www.linuxtoys.net/docs/ ). When UseCanonicalName is Off , the URL consists of whatever the client specified (for example, the URL could be http://al.linuxtoys.net/docs/ or http://al/docs/ if the client is within the same domain).

This can be problematic , particularly when access-control rules require user name and password authentication: if the client is authenticated for the host al.linuxtoys.net but a link sends him or her to www.linuxtoys.net (physically the same machine), the client will be prompted to enter a user name and password again. It is recommended that UseCanonicalName be set to On . In the preceding situation, the authentication would not need to be repeated, because any reference to the same server would always be interpreted as www.linuxtoys.net .

Identifying HTTP Content Directories

There are several directives for determining the location of your server's Web content. The main location for your Web content is set to /var/www/html by the DocumentRoot directive. (Note that this location has changed from early versions of Red Hat Linux. The location was formerly in /home/http .)

 # DocumentRoot: The directory out of which you will serve your # documents. By default, all requests are taken from the directory, but # symbolic links and aliases may be used to point to other locations. DocumentRoot "/var/www/html" 
Setting Access Options and Overrides

You can set individual access permissions for each directory in the Web server's directory structure. The default is fairly restrictive. Here is the default:

 <Directory /> Options FollowSymLinks AllowOverride None </Directory> 

This segment sets up a default block of permissions for the Options and AllowOverride directives. The <Directory /> </Directory> tags enclose the directives that are to be applied to the / directory (which is /var/www/html by default, as defined by DocumentRoot).

The Options FollowSymLinks directive instructs the server that symbolic links within the directory can be followed to allow content that resides in other locations on the computer. None of the other special server features will be active in the / directory, or in any directory below that, without being explicitly specified later. Next, the following access options are specifically set for the root of your Web server ( /var/www/html ). (I removed the comments here for clarity.)

 <Directory "/var/www/html"> Options Indexes FollowSymLinks AllowOverride None Order allow,deny Allow from all </Directory> 

If you have changed the value of DocumentRoot earlier in this file, you need to change the /var/www/html to match that value. The Options set for the directory are Indexes and FollowSymLinks . Those and other special server features are described in Table 21-2. The AllowOverride None directive instructs the server that an .htaccess file (or the value of AccessFileName ) cannot override any of the special access features. You can replace None with any of the special access features described in Table 21-3.

Table 21-2: Special Server Features for the Options Directive
Open table as spreadsheet

Feature

Description

ExecCGI

The execution of CGI scripts is permitted.

FollowSymLinks

The server will traverse symbolic links.

Includes

Server-Side Includes are permitted.

IncludesNOEXEC

Server-Side Includes are permitted, except the # exec element.

Indexes

If none of the files specified in the DirectoryIndex directive exists, a directory index will be generated by mod_autoindex.

MultiViews

The server allows content negotiation based on preferences from the user's browser, such as preferred language, character set, and media type.

SymLinksIfOwnerMatch

The server will traverse symbolic links only if the owner of the target is the same as the owner of the link.

None

None of the features above are enabled.

All

All the features above are enabled, with the exception of MultiViews . This must be explicitly enabled.

Table 21-3: Special Access Features for the AllowOverride Directive
Open table as spreadsheet

Feature

Description

AuthConfig

Enables authentication-related directives ( AuthName, AuthType, AuthUserFile, AuthGroupFile, Require , and so on).

FileInfo

Enables MIME-related directives ( AddType, AddEncoding, AddLanguage, LanguagePriority , and so on).

Indexes

Enables directives related to directory indexing ( FancyIndexing, DirectoryIndex, IndexOptions, IndexIgnore, HeaderName, ReadmeName, AddIcon, AddDescription , and so on).

Limit

Enables directives controlling host access ( Allow, Deny , and Order ).

Options

Enables the Options directive (as described in Table 21-5).

None

None of the access features above can be overridden.

All

All the access features above can be overridden.

Note 

Remember that unless you specifically enable a feature described in Tables 21-2 and 21-3, that feature is not enabled for your server (with the exceptions of Indexes and FollowSymLinks ).

Identifying User Directories

If you have multiple users on your server and you want each to be able to publish their own Web content, it is common practice to identify a directory name that users can create in their own home directories to store that content. When you identify the name that is appended to a user's home directory, that directory is used to respond to requests to the server for the user's name ( ~ user ). This directory name used to be set to public_html by default; however, it is now turned off by default.

To allow access to your users' personal Web pages, add a comment character ( # ) to the UserDir disable line. Then remove the # from the UserDir public_html line to make users' personal public_html directories accessible through the Web server. After removing extra comment lines, the following text shows what the enabled section looks like:

 # UserDir: The name of the directory which is appended onto a user's # home directory if a ~user request is received. <ifModule mod_userdir.c> # UserDir disable UserDir public_html </IfModule> 

Besides uncommenting the UserDir public_html line shown in the previous example, you must make both the user's home directory and public_html directory executable by everyone in order for the UserDir directive to allow access to a particular user's public_html directory. For example, the user cjb could type the following to make those directories accessible.

 $  chmod 711 /home/cjb  $  mkdir /home/cjb/public_html  $  chmod 755 /home/cjb/public_html  

For UserDir to work, the mod_userdir module must also be loaded (which it is by default).

There are two ways in which the UserDir directive can handle an incoming request that includes a user name (for example, ~cjb ). One possible format identifies the physical path name of the individual users' publicly accessible directories. The other can specify a URL to which the request is redirected. A few examples are presented in Table 21-4, using the URL http://www.mybox.com/~cjb/proj/c004.html as a sample request.

Table 21-4: UserDir Path Name and URL Examples
Open table as spreadsheet

UserDir Directive

Referenced Path or URL

UserDir public_html

~cjb/public_html/proj/c004.html

UserDir /public/*/WWW

/public/cjb/WWW/proj/c004.html

UserDir /usr/local/web

/usr/local/web/cjb/proj/c004.html

UserDir http://www.mybox.com/users

http://www.mybox.com/users/cjb/proj/c004.html

UserDir http://www.mybox.com/~*

http://www.mybox.com/~cjb/proj/c004.html

UserDir http://www.mybox.com/*/html

http://www.mybox.com/cjb/html/proj/c004.html

The UserDir directive can also be used to explicitly allow or deny URL-to-path name translation for particular users. For example, it is a good idea to include the following line to avoid publishing data that shouldn't be made public:

 UserDir disable root 

Alternatively, use the following lines to disable the translations for all but a few users:

 UserDir disable UserDir enable wilhelm cjb jsmith 
Note 

You should always be careful about content you publish about yourself on the Internet (names, addresses, personal information,and so on) and also keep in mind that you can be held accountable for the content you publish on your Web server. When you allow others to publish on your Web server, your liability can extend to what those users publish as well. Be sure to have a clear policy about what is acceptable (and legal) to publish on your Web server and give that information you those you allow to use the server.

Setting Default Index Files for Directories

The DirectoryIndex directive establishes a list of files that is used when an incoming request specifies a directory rather than a file. For example, a client requests the URL http://www.mybox.com/~jsmith . Because it's a directory, it is automatically translated to http://www.mybox.com/~jsmith/ . Now that directory is searched for any of the files listed in the DirectoryIndex directive. The first match (from the default list of image from book  index.html and index.html.var ) is used as the default document in that directory. If none of the files exist and the Indexes option (as in the httpd.conf file) is selected, the server will automatically generate an index of the files in the directory.

 # DirectoryIndex: sets the file that Apache will serve if a directory # is requested. # # The index.html.var file (a type-map) is used to deliver content- # negotiated documents. The MultiViews Option can be used for the # same purpose, but it is much slower. # DirectoryIndex index.html index.html.var 
Setting Directory-Access Control

You and your users can add an access file to each directory to control access to that directory. By default, the AccessFileName directive sets .htaccess as the file containing this information. The following lines set this filename and prevent the contents of that file from being viewed by visitors to the Web site. If you change the file to a name other than .htaccess , be sure to change the line below ( "^\.ht" ) that denies access to that file.

 # # AccessFileName: The name of the file to look for in each directory # for access control information. # AccessFileName .htaccess <Files ~ "^\.ht"> Order allow,deny Deny from all </Files> 

You can add the same access directives to a .htaccess file as you do to the httpd.conf file. In general, it is more efficient to use a <Directory> directive in the httpd.conf file than it is to create a .htaccess file. With a <Directory> directive, you can specifically identify the access associated with that directory alone. Because directives you put in .htaccess apply to all directories below the current directory, any time you add a .htaccess file to a directory, Apache must search all directories above that point (for example, /, /var, /var/www . and so on) to include settings from possible .htaccess files in those directories as well.

Setting MIME-Type Defaults

The location of the MIME type definitions file is defined by the TypesConfig directive. The DefaultType directive sets the MIME type:

 # TypesConfig describes where the mime.types file (or equivalent) is # to be found. # TypesConfig /etc/mime.types # # DefaultType is the default MIME type the server will use for a # document if it cannot otherwise determine one, such as from filename. # extensions If your server contains mostly text or HTML documents, # "text/plain" is a good value. If most of the content is binary, such # as applications or images, you may want to use "application/octet- # stream" instead to keep browsers from trying to display binary files # as though they are text. # DefaultType text/plain 

Using the mod_mime_magic module, a server can look for hints to help figure out what type of file is being requested. You must make sure this module is loaded to Apache for it to be used (it is loaded by default). The module can use hints from the /usr/share/magic.mime (off by default) and /etc/httpd/conf/magic (on by default) files to determine the contents of a requested file. Here are the directives that cause that module to be used:

 <IfModule mod_mime_magic.c> # MIMEMagicFile /usr/share/magic.mime MIMEMagicFile conf/magic </IfModule> 
Setting Hostname Lookups

With the Apache Web server, you can have the server look up addresses for incoming client requests. Turning on the HostnameLookups entry can do this:

 # HostnameLookups: Log the names of clients or just their IP addresses HostnameLookups Off 

If the HostnameLookups directive is turned on, every incoming connection will generate a DNS lookup to translate the client's IP address into a hostname. If your site receives many requests, the server's response time could be adversely affected. The HostnameLookups should be turned off unless you use a log file analysis program or statistics package that requires fully qualified domain names and cannot perform the lookups on its own. The logresolve program that is installed with the Apache distribution can be scheduled to edit log files by performing host name lookups during off-peak hours.

Configuring HTTP Logging

You can set several values related to logging of Apache information. When a relative path name is shown, the directory set by ServerRoot ( /etc/httpd/ by default ) is appended (for example, /etc/httpd/logs/error_log ). As shown in the following example, you can set the location of error logs, the level of log warnings, and some log nicknames:

 # # ErrorLog: The location of the error log file. # If you do not specify an ErrorLog directive within a <VirtualHost> # container, error messages relating to that virtual host will be # logged here. If you *do* define an error logfile for a <VirtualHost> # container, that host's errors will be logged there and not here. # ErrorLog logs/error_log # # LogLevel: Control the number of messages logged to the error_log. # Possible values include: debug, info , notice, warn, error, crit, # alert, emerg. # LogLevel warn # # The following directives define some format nicknames for use with # a CustomLog directive (see below). # LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\"\"%{User- Agent}i\"" combined LogFormat "%h %l %u %t \"%r\" %>s %b" common LogFormat "%{Referer}i -> %U" referer LogFormat "%{User-agent}i" agent # # Location and format of the access logfile (Common Logfile Format). # If you do not define any access logfiles within a <VirtualHost> # container, they will be logged here. Contrariwise, if you *do* # define per-<VirtualHost> access logfiles, transactions will be # logged therein and *not* in this file. # # CustomLog logs/access_log common # If you would like to have separate agent and referer logfiles, # uncomment the following directives. # #CustomLog logs/referer_log referer #CustomLog logs/agent_log agent # # For a single logfile with access, agent, and referer information # (Combined Logfile Format), use the following directive: # CustomLog logs/access_log combined 

These lines deal with how server errors, client tracking information, and incoming requests are logged. The ErrorLog directive, which can specify an absolute path name or a path name relative to the ServerRoot (which is /etc/httpd by default), indicates where the server should store error messages. In this case the specified file is logs/error_log , which expands to /etc/httpd/logs/error_log (which in reality is a symlink to the error_log file in the /var/log/httpd directory).

The LogLevel directive controls the severity and quantity of messages that appear in the error log. Messages can range from the particularly verbose debug log level to the particularly silent emerg log level. With debug , a message is logged anytime the configuration files are read, when an access-control mechanism is used, or if the number of active servers has changed. With emerg , only critical system-level failures that create panic conditions for the server are logged.

The level specified by the LogLevel directive indicates the least-severe message that will be logged - all messages at that severity and above are recorded. For example, if LogLevel is set to warn , the error log will contain messages at the warn, error, crit, alert , and emerg levels. The default value of warn is a good choice for normal use (it will log only significant events that may eventually require operator intervention), but info and debug are perfect for testing a server's configuration or tracking down the exact location of errors.

The four LogFormat lines define (for later use) four types of log file formats: combined, common, referer, and agent. You can also add a fifth format called combinedio . The tokens available within the LogFormat directive are described in Table 21-5. The LogFormat definitions can be modified to your own personal preference, and other custom formats can be created as needed.

Table 21-5: Available Tokens within LogFormat
Open table as spreadsheet

Token

Description

%a

The IP address of the client machine.

%b

The number of bytes sent to the client (excluding header information).

%{VAR}e

The contents of the environment variable VAR .

%f

The filename referenced by the requested URL.

%h

The hostname of the client machine.

%{Header}i

The contents of the specified header line in the HTTP request.

%l

As reported by the identd daemon (if available), the user on the client machine who initiated the request.

%{Note}n

The contents of the message Note from a different module.

%{Header}o

The contents of the specified header line in the HTTP response.

%p

The port number on which the request was received.

%P

The PID of the server process that handled the request.

%r

The actual HTTP request from the client.

%s

The server response code generated by the request.

%t

The current local time and date. The time format can be altered using %{Format}t , where Format is described in the strftime(3) man page.

%T

The number of seconds required to fulfill the client request.

%u

If access-control rules require user name and password authentication, this represents the user name supplied by the client.

%U

The URL requested by the client.

%v

The hostname and domain name of the server according to the Domain Name System (DNS).

%V

The hostname and domain name of the server handling the request according to the ServerName directive.

The common format includes the client host's name or IP address, the user name as reported by the ident daemon and the server's authentication method (if applicable ), the local time at which the request was made, the actual HTTP request, the server response code, and the number of bytes transferred. This format is a de facto standard among Web servers (and lately even among FTP servers).

For the purpose of connection tracking, the referer format stores the URL (from the same site or an external server) that linked to the document just delivered (relative to the ServerRoot ). For example, if the page http://www.example.com/corp/about_us.html contained a link to your home page at http://www.mybox.com/linuxguy/bio.html , when a client accessed that link, the referer log on www.mybox.com would look like:

 http://www.example.com/corp/about_us.html -> /linuxguy/bio.html 

This information can be used to determine which path each client took to reach your site.

The agent format stores the contents of the User-agent: HTTP header for each incoming connection. This field typically indicates the browser name and version, the language, and the operating system or architecture on which the browser was run. On a Pentium II running Fedora, Mozilla will produce the following entry:

 Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) 

The combined format includes all the information from the other three log file formats into one line. This format is useful for storing all connection-related log entries in one centralized file. The combinedio format, which is commented out by default, can be enabled (by removing the # character) to log the actual number of bytes received (%I) and sent (%0), provided the mod_logio module is loaded.

The CustomLog directive assigns one of the defined LogFormat formats to a filename (again, specified as an absolute path name or a path name relative to the ServerRoot ). The only uncommented definition assigns combined format to the /etc/httpd/logs/access_log file. To retain the agent or referer information separately, uncomment the definitions. Also, you could choose to comment out the CustomLog logs/access_log combined line and use the definition for the common format instead.

Adding a Signature

Any page that is generated by the Apache server can have a signature line added to the bottom of the page. Examples of server-generated pages include a directory listing, error page, a status page, or an info page. The ServerSignature directive can be set to On, Off , or EMail . Here is how ServerSignature appears by default:

 # Optionally add a line containing the server version and virtual # host name to server-generated pages (error documents, FTP directory # listings, mod_status and mod_info output etc., but not CGI generated # documents). # Set to "EMail" to also include a mailto: link to the ServerAdmin. # Set to one of: On  Off  EMail # ServerSignature On 

With ServerSignature On , a line similar to the following appears at the bottom of server-generated pages:

  Apache/2.0.48 (Fedora) Server at toys.linuxtoys.net Port 80  

With ServerSignature set to EMail , a link to the Web page's administrative e-mail account is added to the signature line (the server name becomes the link). If the directive is set to Off , the line doesn't appear at all.

Aliasing Relocated Content

There are various ways to define alias content. These include the Alias and the ScriptAlias directives. Here are alias-related settings in httpd.conf (with comments removed):

 # # Aliases: Add here as many aliases as you need (with no limit). The format is # Alias fakename realname # Alias /icons/ "/var/www/icons/" <Directory "/var/www/icons"> Options Indexes MultiViews AllowOverride None Order allow,deny Allow from all </Directory> # ScriptAlias: This controls which directories contain server scripts. ScriptAlias /cgi-bin/ "/var/www/cgi-bin/" # "/var/www/cgi-bin" should be changed to whatever your ScriptAliased # CGI directory exists, if you have that configured. # <Directory "/var/www/cgi-bin"> AllowOverride None Options None Order allow,deny Allow from all </Directory> 

The Alias directive points to a file system location (not necessarily within the DocumentRoot). For example, with the following line in place, requests for documents in /bigjob ( http://www.mybox.com/bigjob/index.html ) would result in the retrieval of /home/newguy/proj/index.html .

 Alias /bigjob /home/newguy/proj 

The icons alias allows access to the Apache icons used by the Web server for your Web site. The icons directory is accessible from the /var/www directory.

The ScriptAlias directive performs a related function, but directories that it aliases contain executable code (most likely CGI scripts). The syntax is the same as for the Alias directive. Pay special attention whenever you use ScriptAlias . Because ScriptAlias defines where scripts are located that can be run from Web content on the server, you should make sure that you only assign directories that contain scripts that are secured and won't open security holes in your system.

Redirecting Requests for Old Content

As content changes on your Web server, some content will become obsolete while other content may move to a different place in the file system or to a different server. Using the Redirect directive, you can redirect requests for old content to new locations.

By default, there are no Redirect directives set for your Apache server. However, you can uncomment the following example and tailor it to your needs:

 # Redirect permanent /foo http://www.example.com/bar 

Redirect can be used to instruct clients that the document they seek has moved elsewhere (to the same server or to an external location) by simply indicating the old and new locations. If the previous Redirect option were in place, a client's attempt to access http://www.mybox.com/foo would redirect to http://www.example.com/bar .

Besides using permanent as the service for Redirect (which results in a redirect status 301), you could instead use temp (a redirect status of 302), seeother (a replaced status of 303), or gone (a permanently removed status of 401). You could also give any status code between 300 and 399 as the service, which represent different error responses. (These numbers are HTTP status codes.)

Cross Reference 

The HTTP status codes are defined as part of the HTTP protocol in RFC 2616. Refer to that document at www.w3.org/Protocols/rfc2616/rfc2616.txt .

Defining Indexing

It's possible to have your Apache server show different icons for different types of files. To use this feature, IndexOptions should be set to FancyIndexing , and AddIconByEncoding, AddIconByType , and AddIcon directives should be used:

 # Directives controlling display of server-generated directory listings. # FancyIndexing is if you want fancy directory indexing or standard. # VersionSort is whether files containing version numbers should be # compared in the natural way, so that `apache-1.3.9.tar' is placed # before `apache-1.3.12.tar'. # IndexOptions FancyIndexing VersionSort NameWidth=* # # AddIcon* directives tell the server which icon to show for different # files or filename extensions. These are only displayed for # FancyIndexed directories. # AddIconByEncoding (CMP,/icons/compressed.gif) x-compress x-gzip AddIconByType (TXT,/icons/text.gif) text/* AddIconByType (IMG,/icons/image2.gif) image/* AddIconByType (SND,/icons/sound2.gif) audio/* AddIconByType (VID,/icons/movie.gif) video/* AddIcon /icons/binary.gif .bin .exe AddIcon /icons/ binhex .gif .hqx AddIcon /icons/tar.gif .tar AddIcon /icons/world2.gif .wrl .wrl.gz .vrml .vrm .iv AddIcon /icons/compressed.gif .Z .z .tgz .gz .zip AddIcon /icons/a.gif .ps .ai .eps AddIcon /icons/layout.gif .html .shtml .htm .pdf AddIcon /icons/text.gif .txt AddIcon /icons/c.gif .c AddIcon /icons/p.gif .pl .py AddIcon /icons/f.gif .for AddIcon /icons/dvi.gif .dvi AddIcon /icons/uuencoded.gif .uu AddIcon /icons/script.gif .conf .sh .shar .csh .ksh .tcl AddIcon /icons/tex.gif .tex AddIcon /icons/bomb.gif core AddIcon /icons/back.gif .. AddIcon /icons/hand.right.gif README AddIcon /icons/folder.gif ^^DIRECTORY^^ AddIcon /icons/blank.gif ^^BLANKICON^^ # # DefaultIcon: which icon to show for files which do not have an icon # explicitly set. # DefaultIcon /icons/unknown.gif # # AddDescription: allows you to place short description after a file in # server-generated indexes. These are only displayed for FancyIndexed # directories. # Format: AddDescription "description" filename # #AddDescription "GZIP compressed document" .gz #AddDescription "tar archive" .tar #AddDescription "GZIP compressed tar archive" .tgz # # ReadmeName: the name of the README file the server will look for by # default, and append to directory listings. # # HeaderName is the name of a file which should be prepended to # directory indexes. # ReadmeName README.html HeaderName HEADER.html # # IndexIgnore is a set of filenames which directory indexing should # ignore and not include in the listing. Shell-style wildcarding is # permitted. # IndexIgnore .??* *~ *# HEADER* README* RCS CVS *,v *,t 

The previous block of options deals with how server-generated directory indexes are handled. The IndexOptions FancyIndexing VersionSort NameWidth=* directive enables an autogenerated directory index to include several bits of information about each file or directory, including an icon representing the file type, the filename, the last modification time for the file, the file's size, and a description of the file. Figure 21-2 shows an example of a directory using default FancyIndexing settings.

image from book
Figure 21-2: Change how directories are displayed from Apache using IndexOptions.

The VersionSort option allows files that include version numbers to be sorted as would be most natural (so, for example, version-2 would come before version-10 with this option on). The NameWidth=* option allows filenames of any length to be displayed. You change the asterisk to a number representing the maximum number of characters that can be displayed in the Name column. If IndexOptions is not set to FancyIndexing , the index only lists the file's name.

The AddIconByEncoding directive is used to configure the output of FancyIndexing . It causes a particular icon to be displayed for files matching a particular MIME encoding. In the AddIconByEncoding line in the previous example, compressed.gif (with an alternative image tag of CMP for browsers that don't load images) will be displayed for files with a MIME encoding of x-compress and x-gzip. The AddIconByType directive has the same syntax but matches files based on their MIME type.

The AddIcon directive performs a similar function, but the icons are displayed based on a pattern in the filename. In the lines above, for example, bomb.gif will be displayed for files ending with core , and binary.gif will be displayed for files ending in .bin and .exe . The image from book  folder.gif icon represents a subdirectory.

If there is a conflict between the AddIcon, AddIconByEncoding , or AddIconByType directives, the AddIcon directive has precedence. The DefaultIcon directive specifies the image to be displayed ( image from book  unknown.gif , according to the line above) if no previous directive has associated an icon with a particular file.

The HeaderName and ReadmeName directives specify files that will be inserted at the top and bottom of the autogenerated directory index, if they exist. Using the default values, the server first looks for HEADER.html , then HEADER , to include at the top of the "fancy index." At the end of the index, README.html or README (whichever is located first) is inserted.

The IndexIgnore directive specifies files that should not appear in an autogenerated directory index. The line above excludes:

  • Any filename starting with a dot and containing at least two additional characters.

  • Any filename ending with a tilde (~) or what is commonly called a hash mark (#) (typically used by text editors as temporary files or backup files).

  • Filenames beginning with HEADER or README (the files displayed at the top and bottom of the directory listing, according to the HeaderName and ReadmeName directives).

  • The RCS (Revision Control System) or CVS (Concurrent Versions System) directories.

Defining Encoding and Language

The AddEncoding directive lets you set compression definitions that can be used by browsers to encode data as it arrives. The AddLanguage directive lets you indicate the language of a document, based on its file suffix.

 # # AddEncoding: allows you to have certain browsers (Mosaic/X 2.1+) # uncompress information on fly. Note: Not all browsers support this. # Despite name similarity, the following Add* directives have nothing # to do with the FancyIndexing customization directives above. # AddEncoding x-compress Z AddEncoding x-gzip gz tgz # # DefaultLanguage and AddLanguage allows you to specify the language of # a document. You can then use content negotiation to give a browser a # file in a language it can understand. . . . # Spanish (es) - Swedish (sv) - Catalan (ca) - Czech(cz) # Polish (pl) - Brazilian Portuguese (pt-br) - Japanese (ja) # Russian (ru) # AddLanguage da .dk AddLanguage nl .nl AddLanguage en .en AddLanguage et .ee AddLanguage fr .fr . . . # LanguagePriority: allows you to give precedence to some languages # in case of a tie during content negotiation. # # Just list the languages in decreasing order of preference. We have # more or less alphabetized them. You probably want to change this. # LanguagePriority en da nl et fr de el it ja ko no pl pt pt-br ru ltz ca es sv tw 

The AddEncoding directive supplements or overrides mappings provided by the TypesConfig file ( /etc/mime.types by default). Knowledge of the MIME type/encoding may allow certain browsers to manipulate files automatically as they are being downloaded or retrieved.

The AddLanguage directive performs similar mappings, associating a MIME language definition with a filename extension. The LanguagePriority directive determines the precedence if a particular file exists in several languages (and if the client does not specify a preference). Using the preceding definition, if the file image from book  index.html were requested from a directory that contained the files index.html.de, index.html.en, index.html.fr , and index.html.it , the index.html.en file would be sent to the client.

Using LanguagePriority , you can set which language is used in case a decision on what language to use can't be made during content negotiation. If you are expecting multilanguage use of your Web content, you should check (and probably change) the priority here.

Choosing Character Sets

The default character set to use and character sets to use for files with particular file extensions are set using the AddDefaultCharset an AddCharset directives, respectively. Although UTF-8 is the default character set, it is recommended to set it here specifically (as shown). Other standard ISO fonts, as well as some nonstandard fonts, are set using AddCharset directives.

 AddDefaultCharset UTF-8 # AddCharset ISO-8859-1 .iso8859-1 .latin1 AddCharset ISO-8859-2 .iso8859-2 .latin2 .cen AddCharset ISO-8859-3 .iso8859-3 .latin3 AddCharset ISO-8859-4 .iso8859-4 .latin4 AddCharset ISO-8859-5 .iso8859-5 .latin5 .cyr .iso-ru AddCharset ISO-8859-6 .iso8859-6 .latin6 .arb . . . 

You can retrieve an official list character sets and the file extensions that are assigned to them at www.iana.org/assignments/character-sets .

Adding MIME Types and Handlers

With the AddType directive, you can enhance the MIME types assigned for your Apache Web server without editing the /etc/mime.types file. With the AddHandler directive, you can map selected file extensions to handlers (that result in certain actions being taken):

 # AddType allows you to add to or override the MIME configuration # file mime.types for specific file types. AddType application/x-tar .tgz # # For server-parsed imagemap files: # AddHandler imap-file map # # For type maps (negotiated resources): # (This is enabled by default to allow the Apache "It Worked" page # to be distributed in multiple languages.) # AddHandler type-map var 

Defining Actions and Headers

Some types of media can be set to execute a script when they are opened. Likewise, certain handler names, when opened, can be set to perform specified scripts. The Action directive can be used to configure these scripts:

 # Action lets you define media types that execute a script whenever # a matching file is called. This eliminates the need for repeated URL # pathnames for oft-used CGI file processors. # Format: Action media/type /cgi-script/location # Format: Action handler-name /cgi-script/location 

The Action directive maps a CGI script to a handler or a MIME type, whereas the Script directive maps a CGI script to a particular HTTP request method ( GET, POST, PUT , or DELETE ). These options allow scripts to be executed whenever a file of the appropriate MIME type is requested, a handler is called, or a request method is invoked.

Customizing Error Responses

For different error conditions that occur, you can define specific responses. The responses can be in plain text, redirects to pages on the local server, or redirects to external pages:

 # # Customizable error responses come in three flavors: # 1) plain text 2) local redirects 3) external redirects # # Some examples: #ErrorDocument 500 "The server made a boo boo." #ErrorDocument 404 /missing.html #ErrorDocument 404 "/cgi-bin/missing_handler.pl" #ErrorDocument 402 http://www.example.com/subscription_info.html # 

As the comments suggest, the ErrorDocument directive can customize any server response code, redirecting it to an external page, a local file or CGI script, or to a simple text sentence . Table 21-6 lists the most common server response codes and their meanings.

Table 21-6: HTTP Response Codes
Open table as spreadsheet

Response Code

Meaning

200 OK

The request was successfully processed.

201 Created

Using the POST request method, a new file was successfully stored on the server.

202 Accepted

The request has been received and is currently being processed.

204 No Content

The request was successful, but there is no change in the current page displayed to the client.

301 Moved Permanently

The requested page has been permanently moved, and future references to that page should use the new URL that is displayed.

302 Moved Temporarily

The requested page has been temporarily relocated. Future references should continue to use the same URL, but the current connection is being redirected.

304 Not Modified

A cached version of the page is identical to the requested page.

400 Bad Request

The client's request contains invalid syntax.

401 Unauthorized

The client specified an invalid user name/password combination.

402 Payment Required

The client must provide a means to complete a monetary transaction.

403 Forbidden

Access-control mechanisms deny the client's request.

404 Not Found

The requested page does not exist on the server.

500 Internal Server Error

Usually encountered when running a CGI program, this response code indicates that the program or script contains invalid code or was given input that it cannot handle.

501 Not Implemented

The request method (for example, GET, POST, PUT, DELETE, HEAD ) is not understood by the server.

502 Bad Gateway

Using the Web server as a proxy, an error was encountered in fulfilling the request to an external host.

503 Service Unavailable

The server is currently processing too many requests.

505 HTTP Version Not Supported

The request version (for example, HTTP/1.0, HTTP/1.1) is not understood by the server.

To make it easier to internationalize error messages and standardize how these messages are presented, the latest version of Apache includes what are referred to as variant pages (ending in a .var suffix). These variant pages, which offer variable output based on language, are stored in the /var/www/error directory.

 Alias /error/ "/var/www/error/" <IfModule mod_negotiation.c> <IfModule mod_include.c> <Directory "/var/www/error"> AllowOverride None Options IncludesNoExec AddOutputFilter Includes html AddHandler type-map var Order allow,deny Allow from all LanguagePriority en es de fr ForceLanguagePriority Prefer Fallback </Directory> ErrorDocument 400 /error/HTTP_BAD_REQUEST.html.var ErrorDocument 401 /error/HTTP_UNAUTHORIZED.html.var ErrorDocument 403 /error/HTTP_FORBIDDEN.html.var ErrorDocument 404 /error/HTTP_NOT_FOUND.html.var ErrorDocument 405 /error/HTTP_METHOD_NOT_ALLOWED.html.var . . . 

The ErrorDocument directive associates a particular error code number with a particular .var file that contains multiple possible responses based on language.

Setting Responses to Browsers

If file extensions are not enough to determine a file's MIME type, you can define hints with the MimeMagicFile directive. With the BrowserMatch directive, you can set responses to conditions based on particular browser types:

 # # The following directives modify normal HTTP response behavior to # handle known problems with browser implementations . # BrowserMatch "Mozilla/2" nokeepalive BrowserMatch "MSIE 4\.0b2;" nokeepalive downgrade-1.0 force-response-1.0 BrowserMatch "RealPlayer 4\.0" force-response-1.0 BrowserMatch "Java/1\.0" force-response-1.0 BrowserMatch "JDK/1\.0" force-response-1.0 # # The following directive disables redirects on non-GET requests for # a directory that does not include the trailing slash. This fixes a # problem with Microsoft WebFolders which does not appropriately handle # redirects for folders with DAV methods . # Same deal with Apple's DAV filesystem and Gnome VFS support for DAV. # BrowserMatch "Microsoft Data Access Internet Publishing Provider" redirect-carefully BrowserMatch "MS FrontPage" redirect-carefully BrowserMatch "^WebDrive" redirect-carefully BrowserMatch "^WebDAVFS/1.[0123]" redirect-carefully BrowserMatch "^gnome-vfs" redirect-carefully BrowserMatch "^XML Spy" redirect-carefully BrowserMatch "Dreamweaver-WebDAV-SCM1" redirect- carefully 

The BrowserMatch directive enables you to set environment variables based on the contents of the User-agent: header field. The force-response-1.0 variable causes a HTTP/1.0 response, indicating that Apache will respond to the browser in basic HTTP 1.0 operations.

Note 

If you are following the httpd.conf file, you notice that we are skipping descriptions of the server-status lines and server-info lines. They are described in the "Monitoring Server Activities" section later in this chapter.

Enabling Proxy and Caching Services

Proxy and caching services are turned off by default. You can turn them on by uncommenting the following directives:

 # # Proxy Server directives. Uncomment the following lines to # enable the proxy server: # #<IfModule mod_proxy.c> # ProxyRequests On # #<Proxy:*> # Order deny,allow # Deny from all # Allow from .example.com #</Proxy> # # Enable/disable the handling of HTTP/1.1 "Via:" headers. # ("Full" adds server version; "Block" removes outgoing Via: headers) # Set to one of: Off  On  Full  Block # #ProxyVia On # To enable a cache of proxied content, uncomment the following lines. # See http:/httpd.apache.org/docs-2.0/mod/mod_cache.html for more details. # #<IfModule mod_disk_cache.c> # CacheEnable disk / # CacheRoot "/var/cache/mod_proxy" #</IfModule> #</IfModule> # End of proxy directives. 

Apache can function as a proxy server, a caching server, or a combination of the two. If ProxyRequests is set to Off , the server will simply cache files without acting as a proxy. If CacheRoot (which specifies the directory used to contain the cache files) is undefined, no caching will be performed. Both proxy and caching services are Off (commented out) by default.

If you turn on caching, the CacheRoot should exist on a file system with enough free space to accommodate the cache, which is limited by the CacheSize directive. However, you should have 20 to 40 percent more space available in the file system because cache cleanup (to maintain the CacheSize , in kilobytes) occurs only periodically (which you can set using the CacheGcInterval directive).

You can add other directives to this example to enable other caching features. The CacheMaxExpire directive can indicate the maximum number of hours that a document will exist in the cache without checking the original document for modifications. The CacheLastModifiedFactor applies to documents that do not have an expiration time, even though the protocol would support one. To formulate an expiration date, the factor (a floating-point number) is multiplied by the number of hours since the document's last modification. For example, if the document were modified three days ago and the CacheLastModifiedFactor were 0.25, the document would expire from the cache in 18 hours (as long as this value is still below the value of CacheMaxExpire ).

The CacheDefaultExpire directive (specifying the number of hours before a document expires) applies to documents received via protocols that do not support expiration times. The NoCache directive contains a space-separated list of IP addresses, hostnames, or keywords in hostnames that should not have documents cached.

Here's how the caching server behaves if you uncomment the previous Cache lines:

  • The cached files would exist in /var/cache/mod_proxy .

  • Cache size is limited to 500 Kbytes.

You might want to allow a much larger CacheSize , and possibly set a short CacheGcInterval , but otherwise the supplied values are reasonable. The CacheGcInterval value can be a floating-point number (for example, 1.25 indicates 75 minutes).

Configuring Virtual Hosting

If you have one Web server computer, but more than one domain that you want to serve with that computer, you can set up Apache to do virtual hosting. With name-based virtual hosting, a single IP address can be the access point for multiple domain names on the same computer. With IP-based virtual hosting, you have a different IP address for each virtual host.

With virtual hosting, when a request comes into your Apache server from a Web browser through a particular IP address on your computer, Apache checks the domain name being requested and displays the content associated with that domain name. As an administrator of a Web server that supports virtual hosting, you must make sure that everything that needs to be configured for that virtual server is set up properly (you must define such things as locations for the Web content, log files, administrative contact, and so on).

Virtual hosting is defined with the VirtualHost tags. Information related to virtual hosts in the /etc/httpd/conf/httpd.conf file is shown in the following code:

 ### Section 3: Virtual Hosts # # VirtualHost: If you want to maintain multiple domains/hostnames on # your machine you can setup VirtualHost containers for them. Most # configurations use only name-based virtual hosts so the server # doesn't need to worry about IP addresses. This is indicated by the # asterisks in the directives below. # # Please see the documentation at # <URL:http://httpd.apache.org/docs-2.0/vhosts/> # for further details before you try to setup virtual hosts. # # You may use the command line option '-S' to verify your virtual host # configuration. # # Use name-based virtual hosting. # #NameVirtualHost *:80 # # NOTE: NameVirtualHost cannot be used without a port specifier # (e.g. :80) if mod_ssl is being used, due to the nature of the # SSL protocol. # # VirtualHost example: # Almost any Apache directive may go into a VirtualHost container. # The first VirtualHost section is used for requests without a known # server name. # #<VirtualHost *:80> # ServerAdmin webmaster@dummy-host.example.com # DocumentRoot /www/docs/dummy-host.example.com # ServerName dummy-host.example.com # ErrorLog logs/dummy-host.example.com-error_log # CustomLog logs/ dummy -host.example.com-access_log common #</VirtualHost> 

The following example lists virtual host directives that would allow you to host the domains handsonhistory.com and linuxtoys.net on the same computer:

 NameVirtualHost *:80 <VirtualHost *:80> DocumentRoot /var/www/handsonhistory ServerName www.handsonhistory.com ServerAlias handsonhistory.com ServerAdmin webmaster@handsonhistory.com ErrorLog logs/handsonhistory.com-error_log CustomLog logs/handsonhistory.com-access_log common </VirtualHost> <VirtualHost *:80> DocumentRoot /var/www/linuxtoys ServerName www.linuxtoys.net ServerAlias linuxtoys.net ServerAdmin webmaster@linuxtoys.net ErrorLog logs/linuxtoys.net-error_log CustomLog logs/linuxtoys.net-access_log common </VirtualHost> 

To experiment with virtual hosts, you can add the new host name to your local /etc/hosts file and point at your localhost IP address. For example:

 127.0.0.1 www.linuxtoys.net 

If you see the content you set up for your virtual host, and not the Fedora error page or default content you set up, then you probably set up your virtual host properly.

Configuring Modules and Related Services (/etc/httpd/conf.d/*.conf)

Any module that requires special configuration will typically have a configuration file ( .conf file) in the /etc/httpd/conf.d directory. Here are modular configuration files that might be contained in that directory, along with some ways of using those files and the packages associated with them (use yum install package to install each package you want):

  • auth_kerb.conf - Configure Kerberos authentication over a Web (HTTP) connection. The example in this file suggests using Kerberos authentication over an SSL connection. (Install the mod_auth_kerb package.)

  • auth_mysql.conf - Configure authentication based on data you add to a MySQL database. Comments in the file describe how to set up the database and then use it to do user or group authentication before allowing a client to access your Web content. (Install the mod_auth_mysql package.)

  • auth_pgsql.conf - Configure authentication based on data in a PostgreSQL database. (Install the mod_auth_pgsql package.)

  • authz_ldap.conf - Configure authentication to access an LDAP database to authenticate users. (Install the mod_authz_ldap package.)

  • htdig.conf - Identify the location of the htdig search content that can be used on your Web site ( /usr/share/htdig is the default location). To see the htdig search screen from a Web browser, type http://localhost/htdig . The htdig system lets you set up tools for indexing and searching your Web site or company intranet. It is optional for your Web server. (Install the htdig-web package.)

  • mailman.conf - Set up mailman list server software to allow features such as making mailing-list archives available from Apache. (Install the mailman package.)

  • manual.conf - Defines the location of Apache manuals ( /var/www/manual ) on the server for different languages. Type http://localhost/manual in a browser window. . (Install the httpd-manual package.)

  • mrtg.conf - Defines the location of daily mrtg output ( /var/www/mrtg ), which tracks network traffic. Type http://localhost/mrtg in a browser window. (Install the mrtg package.)

  • perl.conf - Identifies and loads the mod_perl module so that your Web pages can include Perl code. (Install the mod_perl package.)

  • php.conf - Identifies and loads the libphp4 module so that your Web pages can include PHP scripting language. There is also a DirectoryIndex setting that allows an index.php file you add to a directory to be served as a directory index. (Install the php package.)

  • python.conf - Identifies and loads the mod_python module so Web pages can include Apache handlers written in Python. (Install the mod_python package.)

  • squirrelmail.conf - Identifies the location of the SquirrelMail Web-based mail interface so that it can be incorporated into your Apache Web server. To see the SquirrelMail login screen, type http://localhost/webmail into a browser window. (Install the squirrelmail package.)

  • ssl.conf - Configure SSL support so that Apache knows how to serve pages requested over a secure connection (https). (Install the mod_ssl package.)

  • subversion.conf - Loads the mod_dav_svn and mod_authz_svn modules to let you access a Subversion repository from Apache. By uncommenting lines in this file, you can set /home/svnroot as the location where you hold authorization files. (Install the mod_dav_svn package.)

  • webalizer.conf - Lets you identify who can access the webalizer data (statistics about your Web site). (Install the webalizer package.)

  • wordtrans.conf - Identifies the location of the WordTrans language translation window so that it can be incorporated into your Apache Web server. To see the WordTrans login screen, type http://localhost/wordtrans into a browser window. (Install the mod_auth_pgsql package.)

These configuration files are read when the httpd server starts. The information in these files could have been added to httpd.conf . However, files are put here so that different packages can add their own configuration settings without having the RPM software package incorporate some automated method of adding their configuration information to the httpd. conf file.




Fedora 6 and Red Hat Enterprise Linux Bible
Fedora 6 and Red Hat Enterprise Linux Bible
ISBN: 047008278X
EAN: 2147483647
Year: 2007
Pages: 279

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net