InformIT: Red Hat Linux 7 Unleashed > Runtime Server Configuration Settings

Runtime Server Configuration Settings

At this point, you have successfully installed the Apache server one way or another. It will run, but perhaps not quite the way that you want it to. This section talks about configuring the server so that it works exactly how you want it to work.

Traditionally, Apache had the runtime configurations in three files: httpd.conf, access.conf, and srm.conf. This was mainly because that's how the config files were written for NCSA, and Apache grew out of NCSA. And although there was some logic behind the original decision to split configuration options into three files, this made less and less sense over time—especially since you could put any configuration option in any file and it would work.

So, starting with Apache 1.3.4, the runtime configurations are stored in just one file—httpd.conf. The other files are still there, but they contain only a comment telling you that the files are there for purely historical reasons and that you should really put all of your configuration files in httpd.conf.

Apache reads the data from the configuration file(s) when the parent process is started (or restarted). You can also cause the Apache process to reload configuration information with the command /etc/rc.d/init.d/httpd reload. This is discussed later in the section "Starting and Stopping the Server."

You perform runtime configuration of your server with configuration directives, which are commands that set some option. You use them to tell the server about various options that you want to enable, such as the location of files important to the server configuration and operation. Configuration directives follow this syntax:

				
   directive option option...

You specify one directive per line. Some directives only set a value such as a filename, whereas others let you specify various options. Some special directives, called sections, look like HTML tags. Section directives are surrounded by angle brackets, such as <directive>. Sections usually enclose a group of directives that apply only to the directory specified in the section:

				
   <Directory somedir/in/your/tree>
				
     directive option option
				
     directive option option
</Directory>

All sections are closed with a matching section tag that looks like </directive>. Note that section tags, like any other directives, are specified one per line.

Editing `httpd.conf`

Most of the default settings in the config files are okay to keep, particularly if you have installed the server in a default location and are not doing anything unusual on your server. In general, if you don't understand what a particular directive is for, you should leave it set to the default value.

Table 12.1 lists some of the settings that you might want to change.

Table 12.1. Some Commonly Used Configuration Directives

Directive	Description
`ServerType`	This is mentioned more as a curiosity than anything else. The two server types are `standalone` and `inetd`. You will want this to be `standalone` in almost every imaginable case. Setting the `ServerType` to `inetd` will cause a new server to be spawned to handle every incoming HTTP request. That server will then die off immediately when the request has been served. This is presumably useful for testing configuration changes because the configuration files will be reloaded each time a new server process is spawned. Of course, this is extremely slow, since you have the overhead of server startup with every request.
`ServerRoot`	This directive sets the absolute path to your server directory. This directive tells the server where to find all the resources and configuration files. Many of these resources are specified in the configuration files relative to the `ServerRoot` directory.
	Your `ServerRoot` directive should be set to `/etc/httpd` if you installed the RPM and `/usr/local/apache` (or whatever directory you chose when you compiled Apache) if you installed from the source.
`Port`	The `Port` directive indicates which port you want your server to run on. By default, this is set to 80, which is the standard HTTP port number. You may want to run your server on another port, such as for running a test server that you don't want people to find by accident. Don't confuse this with real security! See the section Authentication and Access Control for more information on how to secure parts of your Web server.
`User` and `Group`	The `User` and `Group` directives should be set to the UID and group ID (GID) that the server will use to process requests. There are generally two ways to set this up. The most common way is to set user to `nobody` and group to `nobody`. The other way, which is used in Red Hat, is to set them to a user with few or no privileges. In this case, they are set to user `apache` and group `apache`. As you can imagine, this is a user defined specifically to run Apache. If you want to use a different UID or GID, you need to be aware that the server will run with the permissions of the user and group set here. This means that in the event of a security breach, whether on the server or (more likely) in your own CGI programs, those programs will run with the assigned UID. If the server runs as `root` or some other privileged user, someone can exploit the security holes and do nasty things to your site. Always think in terms of the specified user running a command like `rm -rf /`, since that would wipe all files from`your system. That should convince you that leaving this as a user with no privileges is probably a good thing.`
	Instead of specifying the `User` and `Group` directives using names, you can specify them using the UID and GID numbers. If you use numbers, be sure that the numbers you specify correspond to the user and group you want and that they are preceded by the pound (`#`) symbol.
	Here's how these directives look if specified by name: `User nobody` `Group nogroup` Here's the same specification by UID and GID: `User #-1` `Group #-1`
`ServerAdmin`	The `ServerAdmin` directive should be set to the address of the Webmaster managing the server. It should be a valid email address or alias, such as `webmaster@gnulix.org`. Setting this value to a valid address is important because this address will be returned to a visitor when a problem occurs on the server.
`ServerName`	The `ServerName` directive sets the hostname the server will return. Set it to a fully qualified domain name (`FQDN`). For example, set it to `www.your.domain` rather than simply `www`. This is particularly important if this machine will be accessible from the Internet rather than just on your local network. You really do not need to set this unless you want a different name returned than the machine's canonical name. If this value is not set, the server will figure out the name by itself and set it to its canonical name. However, you might want the server to return a friendlier address, such as `www.your.domain` . Whatever you do, `ServerName` should be a real Domain Name System (DNS) name for your network. If you are administering your own DNS, remember to add an alias for your host. If someone else manages the DNS for you, ask that person to set this name for you.
`DocumentRoot`	Set this directive to the absolute path of your document tree, which is the top directory from which Apache will serve files. By default, it is set to `/var/www/html` or, if you built the source code yourself, `/usr/local/apache/htdocs` (if you did not choose another directory when you compiled Apache). Prior to version 1.3.4, this directive appears in `srm.conf`.
`UserDir`	This directive defines the directory relative to a local user's home directory where that user can put public HTML documents. It's relative because each user will have his or her own HTML directory. The default setting for this directive is `public_html`. So, each user will be able to create a directory called `public_html` under his or her home directory, and HTML documents placed in that directory will be available as `http://servername/~` `username` , where `username` is the username of the particular user. Prior to version 1.3.4, this directive appears in `srm.conf`.
`DirectoryIndex`	The `DirectoryIndex` directive indicates which file should be served as the index for a directory, such as which file should be served if the URL http://gnulix.org/SomeDirectory/ is requested. It is often useful to put a list of files here so that, in the event that `index.html` (the default values) is not found, another file can be served instead. The most useful application of this is to have a CGI program run as the default action in a directory. If you also have users who make their Web pages on Windows, you might want to add `index.htm` as well. In this case, the directive would look like `DirectoryIndex index.html index.cgi index.htm`. Prior to version 1.3.4, this directive appears in `srm.conf` .

`.htaccess` Files

Almost any directive that appears in the configuration files can appear in an .htaccess file. This file, specified in the AccessFileName directive in httpd.conf (or srm.conf prior to version 1.3.4) sets configurations on a per-directory basis. As the system administrator, you can specify both the name of this file and which of the server configurations may be overridden by the contents of this file. This is especially useful for sites where there are multiple content providers and you want to control what these people can do with their space.

To limit what .htaccess files can override, you need to use the AllowOverride directive. This can be set globally or per directory. To configure which options are available by default, you need to use the Options directive.

For example, in your httpd.conf file, you will see the following:

# Each directory to which Apache has access can be configured with respect
# to which services and features are allowed and/or disabled in that
# directory (and its subdirectories).
#
# First, we configure the "default" to be a very restrictive set of
# permissions.
#
<Directory />
    Options FollowSymLinks
    AllowOverride None
</Directory>

`Options` Directives

Options can be None, All, or any combination of Indexes, Includes, FollowSymLinks, ExecCGI, or MultiViews. MultiViews is not included in All and must be specified explicitly. These options are explained in Table 12.2.

Table 12.2. Switches Used by the `Options` Directive

Switch	Description
`None`	None of the available options are enabled for this directory.
`All`	All of the available options, except for `MultiViews`, are enabled for this directory.
`Indexes`	In the absence of an `index.html` file or another `DirectoryIndex` file, a listing of the files in the directory will be generated as an HTML page for display to the user.
`Includes`	Server-Side Includes (SSIs) are permitted in this directory. This can also be written as `IncludesNoExec` if you want to allow includes, but don't want to allow the `exec` option in these includes. For security reasons, this is usually a good idea in directories over which you do not have complete control, such as `UserDir` directories.
`FollowSymLinks`	Allows access to directories that are symbolically linked to a document directory. This is usually a bad idea, and you should not set this globally for the whole server. You might want to set this for individual directories, but only if you have a really good reason to do so. This option is a potential security risk because it allows Web users to escape from the document directory, and it could potentially allow them access to portions of your filesystem where you really don't want people poking around.
`ExecCGI`	CGI programs are permitted in this directory, even if it is not a `ScriptAlias`-ed directory.
`MultiViews`	This is part of the `mod_negotiation` module. When the document that the client requests is not found, the server tries to figure out which document best suits the client's requirements. See `http://localhost/manuals/mod/mod_negotiation.html` for your local copy of the Apache documentation.

`AllowOverrides` Directives

The AllowOverrides directives specify which options .htaccess files can override. You can set this per directory. For example, you can have different standards about what can be overridden in the main document root and in UserDir directories.

This capability is particularly useful for user directories, where the user does not have access to the main server configuration files.

AllowOverrides can be set to All or any combination of Options, FileInfo, AuthConfig, and Limit. These options are explained in Table 12.3.

Table 12.3. Switches Used by the `AllowOverrides` Directive

Switch	Description
`Options`	The `.htaccess` file can add options not listed in the `Options` directive for this directory.
`FileInfo`	The `.htaccess` file can include directives for modifying document type information.
`AuthConfig`	The `.htaccess` file may contain authorization directives.
`Limit`	The `.htaccess` file may contain `allow`, `deny`, and `order` directives.