3.2 Using Apache

3.2.1 Configuration

As the usage and administration of Apache is covered by many other publications, this document will only give an overview, as it is necessary to understand how Apache works as a basis for the following parts of this document.

There are basically four ways to configure Apache:

1. Building / Installing Apache
   Configuring Apache by choosing modules, setting the compiler and flags used for building, selecting the installation path and so on. Further information can be found in [1].
2. Command-line parameters
   Configuring Apache at start-up. The available command-line options can also be found in [1].
3. Global configuration files
   Apache uses a global configuration file, which is processed at the server's start-up. It is named httpd.conf, by default, and resides in the conf/ directory within the server root directory.
4. Local configuration files
   Apache can also be configured by local configuration files, named .htaccess by default, on a per-directory basis. These files are taken into account while processing a request when Apache walks through the file system hierarchy to find the requested documents. For example they enable different authors to configure their web-space on their own.

Figure 3.2: Configuring the Apache HTTP Server via configuration files (View PDF)

The last two possibilities describe the configuration of Apache via text files as it can be seen in figure 3.2. The following parts will focus on explaining the structure of these configuration files and give examples on how to use them.

3.2.1.1 Global and local configuration files

3.2.1.1.1 Global configuration

The configuration directives(G) in the main Apache server configuration file httpd.conf 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 the 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 HTTP requests to be sent to different IP addresses and/or hostnames and have them handled by the same Apache server instance.

Directives placed in the main configuration files apply to the entire server. If you wish to change the configuration for only a part of the server, you can scope your directives by placing them in <Directory>, <DirectoryMatch>, <Files>, <FilesMatch>, <Location>, and <LocationMatch> sections. These sections limit the application of the directives which they enclose to particular file system locations or URLs.
The <Directory> sections apply to 'real' directories at any position in the file system, whereas <Location> sections apply to the Request URIs.

Apache has the capability to serve many different websites with different host names simultaneously. This is called Virtual Hosting. Therefore directives can also be scoped by placing them inside <VirtualHost> sections, so that they will only apply to requests for a particular website.
In the global server configuration file the webmaster can configure the server with the provided directives and limit the options the users have in the per-directory configuration files (.htaccess files).

Changes to the main configuration files are only recognized by Apache when it is started or restarted.

3.2.1.1.2 Local configuration

Apache allows for decentralized management of configuration via special files placed inside the web tree, allowing users to configure their web space on their own to a certain degree, that is granted by the administrator in the main configuration files. The special files are usually called .htaccess, but any name can be specified in the 'AccessFileName' directive. Since .htaccess files are read on every request, changes made in these files take immediate effect. Directives placed in .htaccess files apply to the directory where you place the file and all sub-directories, overwriting all directives in previous files.

Because .htaccess files are evaluated for each request, you don't need to restart the Apache server when you make a change. This makes them useful if multiple users are sharing a single Apache system. Another benefit of these files is, a syntax error in .htaccess files affects only a part of the server, but the system can continue working.

The two main disadvantages of using .htaccess are the performance impact and the extending of access to the configuration data to others. The first is somewhat manageable through the judicious use of the AllowOverride directive, the latter is a matter of trust and performing risk assessment.

3.2.1.2 Syntax

Apache gets its instructions through configuration directives used in the configuration files. There are two types of directives, simple ones and sectioning directives, which again can contain one or more directives.

Apache processes the files on a line by line reading any line that is neither empty nor a comment line beginning with the character '#'. The first word in such a line is the name of the directive whereas the remaining ones are treated as the parameters of the directive. To use more than one line for the parameters of a directive, the backslash '\' may be used as the last character on a line to indicate that the parameters continue on the next line.

Apache distinguishes between several contexts in which a directive can be used. Each directive is only allowed within a fixed set of contexts.

3.2.1.2.1 Global Configuration

The 'Per-Server Context' applies to the global httpd.conf file (the file name can be overridden by the -f option on the httpd command line) and is divided into five sub-contexts:

1. The global context which contains directives that are applied to the default or main server.
2. (<VirtualHost>) The virtual host sections contain directives that are applied to a particular virtual server.
3. (<Directory>, <DirectoryMatch>) The directory sections contain directives that are applied to a particular directory and its subdirectories.
4. (<Files>, <FilesMatch>) The file sections contain directives that are applied to particular files.
5. (<Location>, <LocationMatch>) The URL sections contain directives that are applied to a particular URL and its sub-areas.

Directives placed in the main configuration file apply to the entire server. To change the configuration for only a part of the server, place your directives in the appropriate context. Some section types can also be nested, allowing for very fine grained configuration. Generally, all directives can appear in the global configuration file.

3.2.1.2.2 Local Configuration

The 'Per-Directory Context' applies to the local .htaccess files, which only allow configuration changes using directives of the following five sub-contexts:

1. (AuthConfig) The Authentication context contains directives that control authorization.
2. (Limits) The Limit context contains directives that control access restrictions.
3. (Options) The Option context contains directives that control specific directory features.
4. (FileInfo) The File information context contains directives that control document attributes.
5. (Indexes) The Index context contains directives that control directory indexing.

Directives placed in .htaccess files apply to the directory where you place the file, and all sub-directories. The .htaccess files follow the same syntax as the main configuration files. The server administrator further controls what directives may be placed in .htaccess files by configuring the 'AllowOverride' directive in the main configuration files.

Further information and a list of directives with allowed contexts can be found in [1] and at http://httpd.apache.org/docs/.

3.2.1.3 How Apache determines the configuration for a request

1. Determine virtual host
   The corresponding virtual host to the URI has to be found.
2. Location walk
   The configuration for the URI has to be retrieved before the URI is translated.
3. Translate Request URI (e.g.: mod_rewrite)
   The modules have the opportunity to translate the Request URI into an actual filename.
4. Directory walk beginning from root (/) directory, applying .htaccess files
   Apache reads the configuration of every section of the path and merges them.
5. File walk
   Apache gets the configuration for the files.
6. Location walk, in case Request URI has been changed

When Apache determines that a requested resource actually represents a file on the disk, it starts a process called 'directory walk'. Therefore Apache has to check through its internal list of <Directory> containers, built from the global configuration files, to find those that apply. According to the settings in the global configuration files Apache possibly searches the directories on the file system for .htaccess files.
Whenever the directory walk finds a new set of directives that apply to the request, they are merged with the settings already accumulated. The resulting collection of settings applies to the final document, assembled from all of its ancestor directories and the server's configuration files.
When searching for .htaccess files, Apache starts at the top of the file system. It then walks down the directories to the one containing the document. It processes and merges any .htaccess files it finds that the global configuration files say should be processed.

The sections are merged in the following order:

1. <Directory> (except regular expressions) and .htaccess are merged simultaneously with .htaccess overriding <Directory> sections, if allowed
2. <DirectoryMatch> and <Directory> with regular expressions
3. <Files> and <FilesMatch> merged simultaneously
4. <Location> and <LocationMatch> merged simultaneously

Each group is processed in the order that they appear in the configuration files. Only <Directory> is processed in the order ``shortest directory component to longest''. If multiple <Directory> sections apply to the same directory they are processed in the configuration file order. The configuration files are read in the order httpd.conf, srm.conf and access.conf (srm.conf and access.conf are deprecated and are kept only for backward-compatibility).
Sections inside <VirtualHost> sections are applied after the corresponding sections outside the virtual host definition. This way, virtual hosts can override the main server configuration.Finally, later sections override earlier ones.

For details see sections 4.4.4 and 4.5.

Example Configuration

httpd.conf:

######################################### 

# Section 1: Global Environment 

# Many of the values are default values, so the directives could be omitted. 

ServerType standalone 

ServerRoot "/etc/httpd" 

Listen 80 

Listen 8080 

Timeout 300 

KeepAlive On 

MaxKeepAliveRequests 100 

KeepAliveTimeout 15 

MinSpareServers 5 

MaxSpareServers 10 

StartServers 5 

MaxClients 150 

MaxRequestsPerChild 0 
 

######################################### 

# Section 2: "Main" server configuration 

ServerAdmin webmaster@foo.org 

ServerName www.foo.org 

DocumentRoot "/var/www/html"  
 

# a very restrictive default for all directories 

<Directory /> 

  Options FollowSymLinks 

  AllowOverride None 

</Directory>  
 

<Directory "/var/www/html"> 

  Options Indexes FollowSymLinks MultiViews 

  AllowOverride None 

  Order allow,deny 

  Allow from all 

</Directory>  
 

######################################### 

# Section 3: virtual hosts 

<VirtualHost www.foo.dom:80>  
 

# all hosts in the hpi.uni-potsdam.de domain are allowed access;

# all other hosts are denied access 

<Directory /> 

  Order Deny,Allow 

  Deny from all 

  Allow from hpi.uni-potsdam.de 

</Directory>  
 

# the "Location" directive will only be processed if the module

# mod_status is part of the server 

<IfModule mod_status.c> 

  <Location /server-status> 

    SetHandler server-status 

    Order Deny,Allow 

    Deny from all 

    Allow from .foo.com 

  </Location> 

</IfModule> 

</VirtualHost> 

3.2.2 Performance

3.2.2.1 Means to slow down a server

(to be completed)

(too few processes, insufficient memory, too many checks (for example: check for symbolic links), complex configuration (for example: too many .htaccess files, too many modules)

3.2.2.2 Configuration

(to be completed)

(choose proper configuration for intended usage)