Configuration directives, or simply directives, are lines in a configuration file that control some aspect of how Apache functions. A configuration directive is composed of a keyword followed by one or more arguments (values) separated by SPACEs. For example, the following configuration directive sets Timeout to 300 (seconds): Timeout 300 You must enclose arguments that contain SPACEs within double quotation marks. Keywords are not case sensitive, but arguments (pathnames, filenames, and so on) often are.
httpd.conf The most important file that holds Apache configuration directives is, by default, /etc/httpd/conf/httpd.conf. This file holds global directives that affect all content served by Apache. An Include directive (page 810) within httpd.conf can incorporate the contents of another file as though it were part of httpd.conf.
.htaccess Local directives can appear in .htaccess files (above). A .htaccess file can appear in any directory within the document root hierarchy; it affects files in the directory hierarchy rooted at the directory the .htaccess file appears in.
Pathnames When you specify an absolute pathname in a configuration directive, the directive uses that pathname without modifying it. When you specify a relative pathname, such as a simple filename or the name of a directory, Apache prepends to the name the value specified by the ServerRoot (page 809) directive (/etc/httpd by default). Directives I: Directives You May Want to Modify as You Get StartedWhen it starts, Apache reads the /etc/httpd/conf/httpd.conf configuration file (by default) for instructions governing every aspect of how Apache runs and delivers content. The httpd.conf file shipped by Red Hat is more than 1,000 lines long. This section details some lines you may want to change as you are getting started with Apache. You can use each of the following directives in httpd.conf; the Context line in each explanation shows which other files the directives can appear in. Context is explained on page 798. The section titled "Directives II: Advanced Directives" on page 802 describes more directives.
Listen Specifies the port(s) that Apache listens for requests on. Listen [IP-address:]portnumber where IP-address is the IP address that Apache listens on and portnumber is the number of the port that Apache listens on for the given IP-address. When IP-address is absent or is set to 0.0.0.0, Apache listens on all network interfaces. At least one Listen directive must appear in httpd.conf or Apache will not work.
FEDORA The following minimal directive from the httpd.conf file listens for requests on all interfaces on port 80: Listen 80
RHEL The following Listen directive from httpd.conf is equivalent to the preceding one: Listen 0.0.0.0:80 The next directive changes the port from the default value of 80 to 8080: Listen 8080 When you specify a port other than 80, each request to the server must include a port number (as in www.example.org:8080) or the kernel will return a Connection Refused message. Use multiple Listen directives to cause Apache to listen on multiple IP addresses and ports. For example, accepts connections on all network interfaces on port 80, on 192.168.1.1 on port 8080, and on 192.168.1.2 on port 443. Listen 80 Listen 192.168.1.1:8080 Listen 192.168.1.2:443 accepts connections on all network interfaces on port 80, on 192.168.1.1 on port 8080, and on 192.168.1.2 on port 443. Context: server config Default: none (Apache will not start without this directive) Red Hat: Listen 80
ServerAdmin Sets the email address displayed on error pages. ServerAdmin email-address where email-address is the email address of the person responsible for managing the Web content. Under most versions of Apache, this address appears on Apache-generated error pages. However, Red Hat Linux sets ServerSignature (page 810) to On which causes Apache to display information about the server, not an email address, on error pages. If you want to display an email address on error pages set ServerSignature to EMail. Make sure email-address points to an email account that someone checks frequently. Users can use this address to get help with the Web site or to inform the administrator of problems. There is no default value for ServerAdmin; if you do not use this directive, the value is undefined and no email address appears on error pages. Because webmaster is a common name, you can use webmaster at your domain and use the /etc/aliases file (page 633) to forward mail that is sent to webmaster to the person who is responsible for maintaining the Web site. Contexts: server config, virtual host Default: none Red Hat: RHEL none, FEDORA root@localhost
ServerName Specifies the server's name and the port it listens on. ServerName FQDN [:port] where FQDN is the fully qualified domain name or IP address of the server and port is the optional port number Apache listens on. The domain name of the server must be able to be resolved by DNS and may differ from the hostname of the system running the server. If you do not specify a ServerName, Apache performs a DNS reverse name resolution (page 729) on the system's IP address and assigns that value to ServerName. If the reverse lookup fails, Apache assigns the system's IP address to ServerName. Red Hat Linux provides the following ServerName template in the httpd.conf file: #ServerName www.example.com:80 Copy this line, remove the #, and substitute the FQDN or IP address of the server in place of www.example.com. Change the 80 to the port number Apache listens on if it is not port 80. The ports specified by ServerName and Listen (page 795) must be the same if you want the FQDN specified by ServerName tied to the IP address specified by the Listen directive. Apache uses ServerName to construct a URI when it redirects a client (page 817). Contexts: server config, virtual host Default: none Red Hat: none
DocumentRoot Points to the root of the directory hierarchy that holds the server's content. DocumentRoot dirname where dirname is the absolute pathname of the directory at the root of the directory hierarchy that holds the content Apache serves. Do not use a trailing slash. You can put the document root wherever you like, as long as the user apache has read access to the ordinary files and execute access to the directory files in the directory hierarchy. The FHS (page 176) specifies /srv as the top-level directory for this purpose. The following directive puts the document root at /home/www: DocumentRoot /home/www Contexts: server config, virtual host Default: /usr/local/apache/htdocs Red Hat: /var/www/html
UserDir Allows users to publish content from their home directories. UserDir dirname | disabled | enabled user-list where dirname is the name of a directory that, if it appears in a local user's home directory, Apache publishes to the Web. The disabled keyword prevents content from being published from users' home directories; enabled causes content to be published from the home directories of users specified in the SPACE-separated user-list. When you do not specify a dirname, Apache publishes content to ~/public_html. Apache can combine the effects of multiple UserDir directives. Suppose you have the following directives: UserDir disabled UserDir enabled user1 user2 user3 UserDir web The first directive turns off user publishing for all users. The second directive enables user publishing for three users. The third directive makes web the name of the directory that, if it appears in one of the specified users' home directories, Apache publishes to the Web. To cause a browser to display the content published by a user, specify in the location bar the name of the Web site followed by a /~ and the user's username. For example, if Sam published content in the public_html directory in his home directory and the URI of the Web site was www.example.com, you would enter http://www.example.com/~sam to display Sam's Web page. To display a user's Web page, Apache must have execute permission (as user apache) for the user's home directory and the directory holding the content, and read permission for the content files. Red Hat Linux provides the following ServerName directive and template in the httpd.conf file: UserDir disable #UserDir public_html Put a pound sign (#) in front of the first line and remove the pound sign from the second line to allow users to publish content from directories named public_html in their home directories. Contexts: server config, virtual host Default: RHEL public_html, FEDORA none Red Hat: disabled
DirectoryIndex Specifies which file to display when a user asks for a directory. DirectoryIndex filename [filename ...] where filename is the name of the file that Apache serves. This directive specifies a list of filenames. When a client requests a directory, Apache attempts to find a file in the specified directory whose name matches a file in the list. When Apache finds a match, it returns that file. When this directive is absent or when none of the files specified by this directive exists in the specified directory, Apache displays a directory listing as specified by the IndexOptions directive (page 807). FEDORA provides the following DirectoryIndex directive in the httpd.conf file: DirectoryIndex index.php index.html index.htm index.shtml This directive causes Apache to return from the specified directory the file named index.php, index.html, index.htm, or index.shtml. The index.php is the name of a PHP document; index.html and index.htm are the names of the standard, default HTML documents; and index.shtml is a secure HTML document. If you supply CGI documents, you may want to add the index.cgi value to this directive. The name index is standard but arbitrary. A .var filename extension denotes a content-negotiated document that allows Apache to serve the Apache manual and other documents in one of several languages as specified by the client. If you are not providing content in different languages, you can omit this filename extension from the DirectoryIndex directive. Contexts: server config, virtual host Default: index.html Red Hat: RHEL index.html index.html.var FEDORA index.php index.html index.htm index.shtml Contexts and ContainersTo make it flexible and easy to customize, Apache uses configuration directives, contexts, and containers. Configuration directives were covered in the previous section. This section discusses contexts and containers, which are critical to managing an Apache server. ContextsFour locations, called contexts, define where a configuration directive can appear. This chapter marks each configuration directive to indicate which context(s) it can appear in. Table 26-1 describes each of these contexts.
Directives in files incorporated by means of the Include directive (page 810) are part of the context they are included in and must be allowed in that context. Putting a directive in the wrong context generates a configuration error and can cause Apache not to serve content correctly or not to start. ContainersContainers, or special directives, are directives that group other directives. Containers are delimited by XML-style tags. Three examples are shown here: <Directory> ... </Directory> <Location> ... </Location> <VirtualHost> ... </VirtualHost> Look in httpd.conf for examples of containers. Like other directives, containers are limited to use within specified contexts. This section describes some of the more frequently used containers.
<Directory> Applies directives to directories within specified directory hierarchies. <Directory directory > ... </Directory> where directory is an absolute pathname specifying the root of the directory hierarchy that holds the directories the directives in the container apply to. The directory can include wildcards; a * does not match a /. A <Directory> container provides the same functionality as a .htaccess file. While an administrator can use a <Directory> container in the httpd.conf file, regular users cannot. Regular users can use .htaccess files to control access to their own directories. The directives in the <Directory> container shown in the following example apply to the /var/www/html/corp directory hierarchy: The Deny directive denies access to all clients, the Allow directive grants clients from the 192.168.10. subnet access, and the AllowOverride directive (page 813) enables the use of .htaccess files in the hierarchy: <Directory /var/www/html/corp> Deny from all Allow from 192.168.10. AllowOverride All </Directory> Contexts: server config, virtual host
<Files> Applies directives to specified ordinary files. <Files directory> ... </Files> where directory is an absolute pathname specifying the root of the directory hierarchy that holds the ordinary files the directives in the container apply to. The directory can include wildcards; a * does not match a /. This container is similar to <Directory> but applies to ordinary files and not to directories. The following directive, from the Red Hat httpd.conf file, denies access to all files whose filenames start with .ht. The tilde (~) changes how Apache interprets the following string. Without a tilde, the string is a simple shell match that interprets shell special characters (page 221). With a tilde, Apache interprets the string as a regular expression (page 967): <Files ~ "^\.ht"> Order allow,deny Deny from all </Files> Contexts: server config, virtual host, directory, .htaccess
<IfModule> Applies directives if a specified module is loaded. <IfModule [!]module-name> ... </IfModule> where module-name is the name of the module (page 820) that is tested for. Apache executes the directives in this container if module-name is loaded or with ! if module-name is not loaded. Apache will not start if you specify a configuration directive that is specific to a module that is not loaded. The following <IfModule> container from the Red Hat httpd.conf file depends on the mod_mime_magic.c module being loaded. If this module is loaded, Apache runs the MIMEMagicFile directive, which tells the mod_mime_magic.c module where its hints file is located. <IfModule mod_mime_magic.c> MIMEMagicFile conf/magic </IfModule> See page 815 for another example of the <IfModule> container. Contexts: server config, virtual host, directory, .htaccess
<Limit> Limits access-control directives to specified HTTP methods. <Limit method [method] ... > ... </Limit> where method is an HTTP method. An HTTP method specifies which action is to be performed on a URI. The most frequently used methods are GET, PUT, POST, and OPTIONS; method names are case sensitive. GET, the default method, sends any data indicated by the URI. PUT stores data from the body section of the communication at the specified URI. POST creates a new document containing the body of the request at the specified URI. OPTIONS requests information about the capability of the server. This container binds a group of access-control directives to specified HTTP methods: Only methods named by the <Limit> container are affected by this group of directives. The following example disables HTTP uploads (PUTs) from systems that are not in a subdomain of example.com: <Limit PUT> order deny,allow deny from all allow from .example.com </Limit> Caution: Use <LimitExcept> instead of <Limit> It is safer to use the <LimitExcept> container instead of the <Limit> container, as the former protects against arbitrary methods. When you use <Limit>, you must be careful to name explicitly all possible methods that the group of directives could affect. It is safer still not to put access-control directives in any container. Contexts: server config, virtual host, directory, .htaccess
<LimitExcept> Limits access-control directives to all except specified HTTP methods. <LimitExcept method [method] ... > ... </LimitExcept> where method is an HTTP method. See <Limit> for a discussion of methods. This container causes a group of access-control directives not to be bound to specified HTTP methods: Methods not named in <LimitExcept> are affected by this group of directives. The access-control directives within the following <LimitExcept> container affect HTTP methods other than GET and POST. You could put this container in a <Directory> container to limit its scope: <LimitExcept GET POST OPTIONS> Order deny,allow Deny from all </LimitExcept> Contexts: server config, virtual host, directory, .htaccess
<Location> Applies directives to specified URIs. <Location URI > ... </Location> where URI points to content and specifies a file or the root of the directory hierarchy that the directives in the container apply to. While the <Directory> container points within the local filesystem, <Location> points outside the local filesystem. The URI can include wildcards; a * does not match a /. The following <Location> container limits access to http://server/pop to clients from the example.net domain, where server is the FQDN of the server: <Location /pop> Order deny,allow Deny from all Allow from .example.net </Location> Contexts: server config, virtual host Caution: Use <Location> with care Use this powerful container with care. Do not use it to replace the <Directory> container: When several URIs point to the same location in a filesystem, a client may be able to circumvent the desired access control by using a URI not specified by this container.
<LocationMatch> Applies directives to matched URIs. <LocationMatch regexp> ... </LocationMatch> where regexp is a regular expression that matches one or more URIs. This container works the same way as <Location>, except that it applies to any URIs that regexp matches: # Disable autoindex for the root directory and present a # default welcome page if no other index page is present. # <LocationMatch "^/$"> Options -Indexes ErrorDocument 403 /error/noindex.html </LocationMatch> Contexts: server config, virtual host
<VirtualHost> Applies directives to a specified virtual host. <VirtualHost addr[:port] [addr[:port]] ... > ... </VirtualHost> where addr is an FQDN or IP address of the virtual host and port is the port that Apache listens on for the virtual host. This container holds commands that Apache applies to a virtual host. For an example and more information, refer to "Virtual Hosts" on page 818. Context: server config Directives II: Advanced DirectivesThis section discusses configuration directives that you may want to use after you have gained some experience with Apache. Directives That Control Processes
MaxClients Specifies the maximum number of child processes. MaxClients num where num is the maximum number of child processes (servers) Apache runs at one time, including idle processes and those serving requests. When Apache is running num processes and there are no idle processes, Apache issues Server too busy errors to new connections; it does not start new child processes. A value of 150 is usually sufficient, even for moderately busy sites. Context: server config Default: 256 Red Hat: 150
MaxRequestsPerChild Specifies the maximum number of requests a child process can serve. MaxRequestsPerChild num where num is the maximum number of requests a child process (server) can serve during its lifetime. After a child process serves num requests, it does not process any more requests but dies after it finishes processing its current requests. At this point additional requests are processed by other processes from the server pool. Set num to 0 to not set a limit on the number of requests a child can process, except for the effects of MinSpareServers. By limiting the life of processes, this directive can prevent memory leaks from consuming too much system memory. However, setting MaxRequestsPerChild to a small value can hurt performance by causing Apache to create new child servers constantly. Context: server config Default: 10000 Red Hat: 4000
MaxSpareServers Specifies the maximum number of idle processes. MaxSpareServers num where num is the maximum number of idle processes (servers) Apache keeps running to serve requests as they come in. Do not set this number too high, as each process consumes system resources. Context: server config Default: 10 Red Hat: 20
MinSpareServers Specifies the minimum number of idle processes. MinSpareServers num where num is the minimum number of idle processes (servers) Apache keeps running to serve requests as they come in. More idle processes occupy more computer resources; increase this value for busy sites only. Context: server config Default: 5 Red Hat: 5
StartServers Specifies the number of child processes that Apache starts with. StartServers num where num is the number of child processes, or servers, that Apache starts when it is brought up. This value is significant only when Apache starts; MinSpareServers and MaxSpareServers control the number of idle processes once Apache is up and running. Starting Apache with multiple servers ensures that a pool of servers is waiting to serve requests immediately. Context: server config Default: 5 Red Hat: 8 Networking Directives
HostnameLookups Specifies whether Apache puts a client's hostname or its IP address in the logs. HostnameLookups On | Off | Double On: Performs DNS reverse name resolution (page 729) to determine the hostname of each client for logging purposes. Off: Logs each client's IP address. Double: To provide greater security, performs DNS reverse name resolution (page 729) to determine the hostname of each client, performs a forward DNS lookup to verify the original IP address, and logs the hostname. Contexts: server config, virtual host, directory Default: Off Red Hat: Off Tip: Lookups can consume a lot of system resources Use the On and Double options with caution: They can consume a lot of resources on a busy system. You can use a program such as logresolve to perform reverse name resolution offline for statistical purposes. If you perform hostname resolution offline, you run the risk that the name may have changed; you usually want the name that was current at the time of the request. To minimize this problem, perform the hostname resolution as soon as possible after writing the log.
Timeout Specifies the time Apache waits for network operations to complete. Timeout num where num is the number of seconds that Apache waits for network operations to finish. You can usually set this directive to a lower value; five minutes is a long time to wait on a busy server. The Apache documentation says that the default is not lower "because there may still be odd places in the code where the timer is not reset when a packet is sent." Context: server config Default: 300 Red Hat: 120
UseCanonicalName Specifies the method the server uses to identify itself. UseCanonicalName On | Off | DNS On: Apache uses the value of the ServerName directive (page 796) as its identity. Off: Apache uses the name and port from the incoming request as its identity. DNS: Apache performs a DNS reverse name resolution (page 729) on the IP address from the incoming request and uses the result as its identity. Rarely used. This directive is important when a server has more than one name and needs to perform a redirect. Red Hat sets this directive to Off because the ServerName directive (page 796) is commented out. Once you set ServerName, change UseCanonicalName to On. See page 817 for a discussion of redirects and this directive. Contexts: server config, virtual host, directory Default: RHEL On, FEDORA Off Red Hat: RHEL Off, FEDORA On Logging Directives
ErrorLog Specifies where Apache sends error messages. ErrorLog filename | syslog[:facility] where filename specifies the name of the file, relative to ServerRoot (page 809), that Apache sends error messages to; syslog specifies that Apache send errors to syslogd (page 562); and facility specifies which syslogd facility to use. The default facility is local7. Contexts: server config, virtual host Default: logs/error_log Red Hat: logs/error_log
LogLevel Specifies the level of error messages that Apache logs. LogLevel level where level specifies that Apache log errors of that level and higher (more urgent). Choose level from the following list, which is presented here in order of decreasing urgency and increasing verbosity:
Contexts: server config, virtual host Default: warn Red Hat: warn Directives That Control Content
AddHandler Creates a mapping between filename extensions and a builtin Apache handler. AddHandler handler extension [extension] ... where handler is the name of a builtin handler and extension is a filename extension that maps to the handler. Handlers are actions that are built into Apache and are directly related to loaded modules. Apache uses a handler when a client requests a file with a specified filename extension. For example, the following AddHandler directive causes Apache to process files that have a filename extension of .cgi with the cgi-script handler: AddHandler cgi-script .cgi Contexts: server config, virtual host, directory, .htaccess Default: none Red Hat: type-map var
Alias Maps a URI to a directory or file. Alias alias pathname where alias must match part of the URI that the client requested to invoke the alias and pathname is the absolute pathname of the target of the alias, usually a directory. For example, the following alias causes Apache to serve /usr/local/pix/milk.jpg when a client requests http://www.example.com/pix/milk.jpg: Alias /pix /usr/local/pix In some cases, you need to use a <Directory> container (page 799) to grant access to aliased content. Contexts: server config, virtual host Default: None Red Hat: provides two aliases, one for /icons/ and one for /error/
ErrorDocument Specifies the action Apache takes when the specified error occurs. ErrorDocument code action where code is the error code (page 826) that this directive defines a response for and action is one of the following: string: Defines the message that Apache returns to the client. absolute pathname: Points to a local script or other content that Apache redirects the client to. URI: Points to an external script or other content that Apache redirects the client to. When you do not specify this directive for a given error code, Apache returns a hardcoded error message when that error occurs. See page 816 for an explanation of how an ErrorDocument directive returns the Red Hat test page when the system is first installed. Some examples of ErrorDocument directives follow: ErrorDocument 403 "Sorry, access is forbidden." ErrorDocument 403 /cgi-bin/uh-uh.pl ErrorDocument 403 http://errors.example.com/not_allowed.html Contexts: server config, virtual host, directory, .htaccess Default: none; Apache returns hardcoded error messages Red Hat: 403 /error/noindex.html; refer to "Red Hat test page" on page 816.
IndexOptions Specifies how Apache displays directory listings. IndexOptions [±] option [[±]option] ... where option can be any combination of the following: DescriptionWidth=n: Sets the width of the description column to n characters. Use * in place of n to accommodate the widest description. FancyIndexing: In directory listings, displays column headers that are links. When you click one of these links, Apache sorts the display based on the content of the column. Clicking a second time reverses the order. FoldersFirst: Sorts the listing so that directories come before plain files. Use only with FancyIndexing. HTMLTable: FEDORA Displays a directory listing in a table. IconsAreLinks: Makes the icons clickable. Use only with FancyIndexing. IconHeight=n: Sets the height of icons to n pixels. Use only with IconWidth. IconWidth=n: Sets the width of icons to n pixels. Use only with IconHeight. IgnoreCase: Ignores case when sorting names. IgnoreClient: Ignores options the client supplied in the URI. NameWidth=n: Sets the width of the filename column to n characters. Use * in place of n to accommodate the widest filename. ScanHTMLTitles: Extracts and displays titles from HTML documents. Use only with FancyIndexing. Not normally used because it is CPU and disk intensive. SuppressColumnSorting: Suppresses clickable column headings that can be used for sorting columns. Use only with FancyIndexing. SuppressDescription: Suppresses file descriptions. Use only with FancyIndexing. SuppressHTMLPreamble: Suppresses the contents of the file specified by the HeaderName directive, even if that file exists. SuppressIcon: Suppresses icons. Use only with FancyIndexing. SuppressLastModified: Suppresses the modification date. Use only with FancyIndexing. SuppressRules: Suppresses horizontal lines. Use only with FancyIndexing. SuppressSize: Suppresses file sizes. Use only with FancyIndexing. VersionSort: Sorts version numbers (in filenames) in a natural way; character strings, except for substrings of digits, are not affected. As an example, suppose a client requests a URI that points to a directory (such as http://www.example.com/support/) and none of the files specified by the Directory-Index directive (page 797) is present in that directory. If the directory hierarchy is controlled by a .htaccess file and AllowOverride (page 813) has been set to allow indexing, then Apache displays a directory listing according to the options specified by this directive. When this directive appears more than once within a directory, Apache merges the options from the directives. Use + and to merge options with options from higher-level directories. (Unless you use + or with all options, Apache discards any options set in higher-level directories.) For example, the following directives and containers set the options for /custsup/download to VersionSort; Apache discards FancyIndexing and IgnoreCase in the download directory because there is no + or before VersionSort in the second <Directory> container: <Directory /custsup> IndexOptions FancyIndexing IndexOptions IgnoreCase </Directory <Directory /custsup/download> IndexOptions VersionSort </Directory> Because + appears before VersionSort, the next directives and containers set the options for /custsup/download to FancyIndexing, IgnoreCase, and VersionSort: <Directory /custsup> IndexOptions FancyIndexing IndexOptions IgnoreCase </Directory <Directory /custsup/download> IndexOptions +VersionSort </Directory> Contexts: server config, virtual host, directory, .htaccess Default: none; lists only filenames Red Hat: FancyIndexing VersionSort NameWidth=*
ServerRoot Specifies the root directory for server files (not content). ServerRoot directory where directory specifies the pathname of the root directory for files that make up the server. Apache prepends directory to relative pathnames in httpd.conf. This directive does not specify the location of the content that Apache serves; the DocumentRoot directive (page 796) performs that function. Do not change this value unless you move the server files. Context: server config Default: /usr/local/apache Red Hat: /etc/httpd
ServerTokens Specifies the server information that Apache returns to a client. ServerTokens Prod | Major | Minor | Min | OS | Full Prod: Returns the product name (Apache). Also ProductOnly. Major: Returns the major release number of the server (Apache/2). Minor: Returns the major and minor release numbers of the server (Apache/2.2). Minimal: Returns the complete version (Apache/2.2.0). Also Min. OS: Returns the name of the operating system and the complete version (Apache/2.2.0 (Red Hat Linux)). Provides less information that might help a malicious user than Full does. Full: Same as OS, plus sends the names and versions of non-Apache group modules (Apache/2.2.0 (Red Hat Linux) PHP/5.1.2). Unless you want clients to know the details of the software you are running for some reason, set ServerTokens to reveal as little as possible. Context: server config Default: Full Red Hat: OS
ServerSignature Adds a line to server-generated pages. ServerSignature On | Off | EMail On: Turns the signature line on. The signature line contains the server version as specified by the ServerTokens directive (page 809) and the name specified by the <VirtualHost> container (page 802). Off: Turns the signature line off. EMail: To the signature line, adds a mailto: link to the server email address. This option produces output that can attract spam. See ServerAdmin (page 795) for information on specifying an email address. Contexts: server config, virtual host, directory, .htaccess Default: Off Red Hat: On
Group Sets the GID of the processes that run the servers. Group #groupid | groupname where groupid is a GID value, preceded by a #, and groupname is the name of a group. The processes (servers) that Apache spawns are run as the group specified by this directive. See the User directive (page 812) for more information. Context: server config Default: #1 Red Hat: apache
Include Loads directives from files. Include filename | directory where filename is the relative pathname of a file that contains directives. Apache prepends ServerRoot (page 809) to filename. The directives in filename are included in the file holding this directive at the location of the directive. Because filename can include wildcards, it can specify more than one file. The directory is the relative pathname that specifies the root of a directory hierarchy that holds files containing directives. Apache prepends ServerRoot to directory. The directives in ordinary files in this hierarchy are included in the file holding this directive at the location of the directive. The directory can include wildcards. When you install Apache and its modules, rpm puts configuration files, which have a filename extension of conf, in the conf.d directory within the ServerRoot directory. The Include directive in the Red Hat httpd.conf file incorporates module configuration files for whichever modules are installed. Contexts: server config, virtual host, directory Default: none Red Hat: conf.d/*.conf
LoadModule Loads a module. LoadModule module filename where module is the name of an external DSO module and filename is the relative pathname of the named module. Apache prepends ServerRoot (page 809) to filename. Apache loads the external module specified by this directive. For more information refer to "Modules" on page 820. Context: server config Default: none; nothing is loaded by default if this directive is omitted Red Hat: loads more than 40 modules; refer to httpd.conf for the list
Options Controls server features by directory. Options [±]option [[±]option ...] This directive controls which server features are enabled for a directory hierarchy. The directory hierarchy is specified by the container this directive appears in. A + or the absence of a turns an option on and a turns it off. The option may be one of the following: None None of the features this directive can control are enabled. All All of the features this directive can control are enabled, except for Multi-Views, which you must explicitly enable. ExecCGI Apache can execute CGI scripts (page 821). FollowSymLinks Apache follows symbolic links. Includes Permits SSIs (server-side includes, page 821). SSIs are containers embedded in HTML pages that are evaluated on the server before the content is passed to the client. IncludesNOEXEC The same as Includes but disables the #exec and #exec cgi commands that are part of SSIs. Does not prevent the #include command from referencing CGI scripts. Indexes Generates a directory listing if DirectoryIndex (page 797) is not set. MultiViews Allows multiviews (page 818). SymLinksIfOwnerMatch The same as FollowSymLinks but follows the link only if the file or directory being pointed to has the same owner as the link. The following Options directive from the Red Hat httpd.conf file sets the Indexes and FollowSymLinks options and, because the <Directory> container specifies the /var/www/html directory hierarchy (the document root), affects all content: <Directory "/var/www/html"> Options Indexes FollowSymLinks ... <Directory> Context: directory Default: All Red Hat: None
ScriptAlias Maps a URI to a directory or file and declares the target to be a server (CGI) script. ScriptAlias alias pathname where alias must match part of the URI the client requested to invoke the Script-Alias and pathname is the absolute pathname of the target of the alias, usually a directory. Similar to the Alias directive, this directive specifies that the target is a CGI script (page 821). The following ScriptAlias directive from the Red Hat httpd.conf file maps client requests that include /cgi-bin/ to the /var/www/cgi-bin directory (and indicates that these requests will be treated as CGI requests): ScriptAlias /cgi-bin/ "/var/www/cgi-bin/" Contexts: server config, virtual host Default: none Red Hat: /cgi-bin/ "/var/www/cgi-bin"
User Sets the UID of the processes that run the servers. User #userid | username where userid is a UID value, preceded by a #, and username is the name of a local user. The processes (servers) that Apache spawns are run as the user specified by this directive. Apache must start as root to listen on a privileged port. For reasons of security, Apache's child processes (servers) run as nonprivileged users. The default UID of 1 does not map to a user under Red Hat Linux. Instead, Red Hat's httpd package creates a user named apache during installation and sets User to that user. Context: server config Default: #1 Red Hat: apache Security: Do not set User to root or 0 For a more secure system, do not set User to root or 0 (zero) and do not allow the apache user to have write access to the DocumentRoot directory hierarchy (except as needed for storing data), especially not to configuration files. Security Directives
Allow Specifies which clients can access specified content. Allow from All | host [host ...] | env=var [env=var ...] This directive, which must be written as Allow from, grants access to a directory hierarchy to the specified clients. The directory hierarchy is specified by the container or .htaccess file this directive appears in. All: Serves content to any client. host: Serves content to the client(s) specified by host, which can take several forms: host can be an FQDN, a partial domain name (such as example.com), an IP address, a partial IP address, or a network/netmask pair. var: Serves content when the environment variable named var is set. You can set a variable with the SetEnvIf directive. See the Order directive (page 814) for an example. Contexts: directory, .htaccess Default: none; default behavior depends on the Order directive Red Hat: All
AllowOverride Specifies the classes of directives that are allowed in .htaccess files. AllowOverride All | None | directive-class [directive-class ...] This directive specifies whether Apache read .htaccess files in the directory hierarchy specified by its container. If Apache does reads .htaccess files, this directive specifies which kinds of directives are valid within .htaccess files. None: Ignores .htaccess files. All: Allows all classes of directives in .htaccess files. The directive-class is one of the following directive class identifiers: AuthConfig: Class of directives that control authorization (AuthName, AuthType, Require, and so on). This class is used mostly in .htaccess files to require a username and password to access the content. For more information refer to "Authentication Modules and .htaccess" on page 824. FileInfo: Class of directives that controls document types (DefaultType, ErrorDocument, SetHandler, and so on). Indexes: Class of directives relating to directory indexing (DirectoryIndex, Fancy-Indexing, IndexOptions, and so on). Limit: Class of client access directives (Allow, Deny, and Order). Options: Class of directives controlling directory features. Context: directory Default: All Red Hat: None
Deny Specifies which clients are not allowed to access specified content. Deny from All | host [host ...] | env=var [env=var ...] This directive, which must be written as Deny from, denies access to a directory hierarchy to the specified clients. The directory hierarchy is specified by the container or .htaccess file this directive appears in. See the Order directive (page 814) for an example. All: Denies content to all clients. host: Denies content to the client(s) specified by host, which can take several forms: host can be an FQDN, a partial domain name (such as example.com), an IP address, a partial IP address, or a network/netmask pair. var: Denies content when the environment variable named var is set. You can set a variable with the SetEnvIf directive. Contexts: directory, .htaccess Default: none Red Hat: none
Order Specifies default access and the order in which Allow and Deny directives are evaluated. Order Deny, Allow | Allow, Deny Deny, Allow: Allows access by default; denies access only to clients specified in Deny directives. (First evaluates Deny directives, then evaluates Allow directives.) Allow, Deny: Denies access by default; allows access only to clients specified in Allow directives. (First evaluates Allow directives, then evaluates Deny directives.) Access granted or denied by this directive applies to the directory hierarchy specified by the container or .htaccess file this directive appears in. There must not be SPACEs on either side of the comma. Although Red Hat Linux has a default of Allow, Deny, which denies access to all clients not specified by Allow directives, the next directive in httpd.conf, Allow from all, grants access to all clients: Order allow,deny Allow from all You can restrict access by specifying Deny, Allow to deny all access and then specifying only those clients you want to grant access to in an Allow directive. The following directives grant access to clients from the example.net domain only and would typically appear within a <Directory> container (page 799): Order deny,allow Deny from all Allow from .example.net Contexts: directory, .htaccess Default: Deny, Allow Red Hat: Allow, Deny |