7.5. Using the Apache Web Server

Apache is the most widely used web server and is a standard part of Fedora Core. One of the reasons that it has garnered a majority market share is that it is highly configurable and can therefore meet a wide range of web-serving needs. Despite the number of options available, Fedora Core ships Apache with a default configuration that is ready to meet most basic web-serving needs.

7.5.1. How Do I Do That?

Before configuring Apache, it's a good idea to make a backup copy of the original configuration file:

# cp /etc/httpd/conf/httpd.conf /etc/httpd/conf/httpd.conf-original
            

7.5.1.1. Starting Apache

Apache is not enabled by default. To start it, use the Services tool or enter this command:

# service httpd start
               

To ensure that Apache starts each time the system is booted, enable the httpd service.

Whenever the Apache configuration is changed, you must instruct Apache to reload its configuration:

# service httpd reload
               

Alternately, you can use the Restart button in the Services tool.

7.5.1.2. Testing Apache

Using a web browser on the machine running Apache, access the web location http://localhost/. You will see the test page shown in Figure 7-16.

Figure 7-16. Apache test page confirming operation of the web server

Once you can view this web page on the server, you can attempt to access the page from a remote system using the IP address of the server (such as http://192.168.100.1/), or, if DNS has been set up to allow it, the server's hostname (e.g., http://fedorabook.com/).

If you can access the web page on the server but not from a remote system, then the firewall configuration may require adjustment.

7.5.1.3. Installing your own web content

Once the web server is running, place the content you wish to serve in the directory /var/www/html. The default page for each directory is index.html; once you have created /var/www/html/index.html, the test page (Figure 7-16) will no longer appear.

Create subdirectories within /var/www/html to create any directory structure you want. These directories will be reflected in the URLs accessible through the web server. For example, you could create the directory /var/www/html/photos/:

# mkdir /var/www/html/photos

That directory will be accessible using the URI http://<hostname>/photos/.

7.5.1.4. Changing the default configuration

The default Apache configuration serves all web content from one directory: /var/www/html. To perform more advanced web serving, the default configuration needs to be modified.

Apache can be configured by using Fedora's graphical configuration tool or by editing configuration files, but you can't alternate between the two approaches. Most experienced Apache administrators prefer to directly edit the configuration file because it provides direct access to all of Apache's features and because it is more convenient when accessing a remote server. However, Fedora's graphical configuration tool is quite powerful and is a good place to start if you're not familiar with Apache setup.

7.5.1.5. Configuring Apache graphically

To configure Apache graphically, select SystemAdministrationServer SettingsHTTP (or in KDE, AdministrationServer SettingsHTTP). The httpd configuration dialog, a simple tabbed window (shown in Figure 7-17), will appear.

Figure 7-17. Graphical configuration tool for Apache httpd

Start with the Main tab and enter the server name and webmaster's email address. The server name must contain only alphanumeric characters; it will be used as a hostname and combined with the current domain name to build a fully qualified domain name ( FQDN).

The webmaster's address is displayed in server error messages and could be harvested by web spiders, so it is a good idea to use a disposable email alias and change it frequently to thwart spammers.

The Available Addresses area is used only if you wish to prevent the web server from using some network interfaces, or if you wish to use a nonstandard TCP/IP port (the default for HTTP is port 80). This is usually left at the default setting.

The Virtual Hosts tab shown in Figure 7-18 is used to configure Apache to respond to requests for multiple web sitesfor example, www.fedorabook.com and www.tylers.info. By default, a single entry is present, labeled Default Virtual Host.

Figure 7-18. Virtual host configuration

To edit an existing entry or add a new entry, use the Edit or Add buttons. In either case, the window shown on the right of Figure 7-18 will appear, with these tabs:

General Options

Enter the name of the virtual host (this information is only for your reference, so you can be as descriptive as you want), the Document Root directory that will store documents for this host, and the webmaster email address (if different from the default).

If you choose a Document Root that is not within /var/www/html and have SELinux active, you will need to change the security context of that directory (see Lab 8.2, "Using SELinux").

Page Options

When Apache receives a request for a directory (such as http://www.fedorabook.com/example/), it will search that directory for files that can serve as an index to the contents of that directory. Traditionally, the index is named index.html, but you may wish to use other names, such as index.php, home.html, or index.htm. Use the Directory Page Search List area of this tab to configure all of the possible names for the index file, in your desired order of precedence.

Apache is preconfigured with standard pages that are displayed when an error occurs. To override any of these pages and present a custom error message, highlight the page in the Error pages list and click Edit. A dialog box will appear; change the error message behavior from Default to File and enter the location of the page you wish to use (or select URL and specify the local URL of the web page). You can customize the footer displayed at the bottom of default error pages using the Default Error Page Footer control.

Logging

Apache maintains two logs per virtual host: a transfer log, which records what was sent to clients, and an error log, which records any problems encountered. By default, all virtual hosts will share one pair of logs, but to analyze statistics separately for each virtual host, you'll need to specify separate logfiles for each. To do this, change the "Log to file" name for the Transfer Log from logs/access_log to a name that includes an indication of the virtual hostname, such as logs/ fedorabook_ access_log. Do the same for the Error log, changing logs/error_log to logs/ fedorabook_ error_log. Alternately, you can consolidate logs from several servers using syslog by selecting the Use System Log option and entering the hostname or IP address of the syslog server.

The default logfile format does not contain referrer information, so you can't tell where your visitors are coming from or how they're navigating your site. To add this information, select the checkbox "Use custom logging facilities" and set the "Custom log string" to combined.

Performance

This tab should actually be named Permission, since it controls what is permitted in web directories. Click on the Edit button in the Default directory options section to edit the options for the virtual host's Document Root directory; available permission options include ExecCGI (run scripts), FollowSymLinks (follow symbolic links to files), Includes (process server-side include directives in files), IncludesNOEXEC (process server-side includes, except scripts), Indexes (use index files such as index.html when a directory is requested), MultiViews (enable content negotiation such as automatic language or image-type selection), and SymLinksIfOwnerMatch (follow symbolic links if the link and the target are owned by the same user).

To set the permissions for a particular directory, click the Add button in the lower part of the window (or, if the directory is already listed, click the Edit button). Enter the directory name in the Directory field at the bottom of the window and set the Options checkboxes for the options you wish to enable in this directory. By default, all remote computers (hosts) will have access to the content in this directory; the Allow and Deny list options can be used to permit (or deny) access only from certain hosts. The hosts can be identified by hostname (fedorabook.com), partial domain name (.com), IP address (192.168.100.1), or IP address and netmask or bit count (192.168.100.0/255.255.255.0, or the equivalent 192.168.100.0/24).

To enable the use of .htaccess files, select the checkbox labeled "Let .htaccess override directory options."

There is also a tab for SSLused for secure, encrypted web servingand a tab for Environment, which is used to pass information to web scripts, but the options on those tabs are not used for basic web serving.

Once the virtual host is configured, click OK to return to the main HTTP configuration window (Figure 7-17).

The Server and Performance Tuning tabs in the main HTTP configuration window do not normally require adjustment.

After configuring Apache, click OK to save your configuration (a confirmation dialog may appear).

7.5.1.6. Directly editing Apache's configuration file

The main Apache configuration information is stored in /etc/httpd/conf/httpd.conf. Additional configuration information is stored in the directory /etc/httpd/conf.d/. Per-module configuration files are automatically installed and removed along with Apache modules and web applications such as SquirrelMail.

httpd.conf is a regular text file and can be edited with any standard text editor. As mentioned earlier, I strongly recommended that you make a backup copy of this file before each change:

# cp /etc/httpd/conf/httpd.conf /etc/httpd/conf/httpd.conf.backup-1

httpd.conf contains a number of directives, each of which consists of a name and one or more values, listed on a single line with a space after the name and each of the values. The directive names are not case-sensitive, but some of the values are. Values must be quoted if they contain spaces.

These directives are all equivalent:

ServerRoot /etc/httpd
ServerRoot "/etc/httpd"
ServerRoot '/etc/httpd'
SERVERROOT /etc/httpd/
serverroot /etc/httpd

To add a comment line, place a pound sign at the start of the line:

# Note: /etc/httpd is the standard Fedora server root.

Comments must be on a line by themselves.

Directives are global unless they are placed in a container, which limits the scope to which the directive applies. For example, the <Directory> container causes the contained directives to be applied only to a specific directory (and its subdirectories); here, the directives apply only to the contents of /var/www/html:

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

7.5.1.6.1. Configuring the server root and document root

The ServerRoot directive sets the directory that contains all files related to the Apache serverincluding configuration files, logs, modules, and runtime informationexcept the actual content being served. By default, all relative paths specified in httpd.conf are relative to this directory. The default is /etc/httpd:

ServerRoot "/etc/httpd"

The DocumentRoot directive sets the directory for files being served. Fedora's default is /var/www/html:

ServerRoot "/var/www/html"

Changing DocumentRoot will require you to change the SELinux context of the new document root directory.

7.5.1.6.2. Configuring the server administrator, IP address and port, and server name

The directive named ServerAdministrator specifies an email address that can be used to reach the person responsible for running the web server. This address appears on certain error pages. This should be a valid address so that your web visitors can contact you if necessary, but since it can be harvested by web spiders, it is a good idea to use a disposable email address and change it regularly. The default value is root@localhost and should always be changed:

ServerAdministrator webmaster@fedorabook.com
                  

The IP address and port are configured with the Listen directive. The web server will normally listen to port 80 on all available network interfaces:

Listen 80

If necessary, you can specify an alternate port, or a specific IP address and a port:

Listen 8000
Listen 192.168.10.1:8000

The ServerName directive configures the name of the server and is necessary only if you are using a value different from the machine's fully qualified domain name:

ServerName www.fedorabook.com

7.5.1.6.3. Configuring access

Apache uses directory containers to control access to directories on your system. The root directory is configured first:

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

The Options directive is critical: it specifies what is permitted in these directories. In this case, all access to the root directory and all subdirectoriesin other words, the entire systemis prohibited except as the destination of symbolic links.

The next directory container loosens up the restrictions for /var/www/html and its subdirectories:

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

The values for the Options directive are selected from this list:

All

The default, which permits everything except for MultiViews.

ExecCGI

Permits execution of scripts.

FollowSymLinks, SymLinksIfOwnerMatch

If FollowSynLinks is specified Apache will follow symbolic links which lead to or from this directory. If SymLinksIfOwnerMatch is specified, the link and the target must be owned by the same user.

Includes, IncludesNoExec

Files may include other files, with or without the ability (Includes and IncludesNoExec, respectively) to execute those other files. Files that use this feature must have a name ending in .shtml and may include directives such as <!--#include virtual="footer.html" --> or <!--#exec cmd="/usr/bin/cal" --> to include the footer.html file or the output of the cal command, respectively.

Indexes

An index.html file usually serves as the index for a directory. If it is not present, and the Indexes option is enabled, Apache will generate an appropriate index page when required, listing the contents of the directory. If you do not wish your web visitor to know the contents of your directories, do not use this option.

MultiViews

Enables Apache to search for appropriate content based on file type, encoding, and language. For example, if the MultiViews option is in effect, Apache will select between index.html.en (English) and index.html.fr (French) files when index.html is requested, using the browser's language preference to select the most appropriate file.

Order, Allow, and Deny are directives that work together to define which remote users may access the directory. Order sets the order in which the Allow and Deny directives are used, and the value must be Allow,Deny or Deny,Allow (the default). The Allow and Deny directives accept a list of full or partial domain names, IP addresses, or IP addresses and netmask or network bit count.

For example, to enable access only from computers on your internal network, assuming your network is 12.200.X.X:

Order Allow,Deny
Allow from 12.200.0.0/16
Deny from all

On the other hand, you could enable access only from computers that are not in your internal network:

Order Deny,Allow
Deny from 12.200.0.0/255.255.0.0
Allow from all

Or you could exclude access from specific domains:

Order Deny,Allow
Deny from .gov ourcompetition.com
Allow from all

The AllowOverride directive enables the use of a hidden file, .htaccess, which may be placed in directories to override the configuration of that directory and subdirectories. Although there are several possible values for this directive, it is normally set to None (no overrides are permitted) or AuthConfig (the .htaccess file can control whether a user ID and password are required to access the content of that directory).

The next set of directory containers configure special permissions for the icon, cgi-bin, and error directories in /var/www:

<Directory "/var/www/icons">
    Options Indexes MultiViews
    AllowOverride None
    Order Allow,Deny
    Allow from all
</Directory>

<Directory "/var/www/cgi-bin">
    AllowOverride None
    Options None
    Order Allow,Deny
    Allow from all
</Directory>

<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>

These directories are not within the normal DocumentRoot and are instead made accessible through the use of Alias and ScriptAlias directives:

Alias /icons/ "/var/www/icons/"
ScriptAlias /cgi-bin/ "/var/www/cgi-bin/"
Alias /error/ "/var/www/error/"

These directives make the indicated directories appear to exist within the document tree; for example, a request for http://<hostname>/icons/text.png is fulfilled using the file /var/www/icons/text.png (instead of /var/www/html/icons/text.png). This permits /var/www/html to remain uncluttered by icons, scripts, and error messages.

Since /cgi-bin/ is aliased using a ScriptAlias directive, it is assumed that all files in that directory are actually scripts (executable programs) rather than document files, regardless of their extension. In the default configuration, this is the only directory that may contain scripts, so you only have to look in one place to check for script vulnerabilities.

7.5.1.6.4. Enabling personal web pages

To permit each user to maintain her own web directory, find the UserDir section of httpd.conf:

<IfModule mod_userdir.c>
    #
    # UserDir is disabled by default since it can confirm the presence
    # of a username on the system (depending on home directory
    # permissions).
    #
    UserDir disable

    #
    # To enable requests to /~user/ to serve the user's public_html
    # directory, remove the "UserDir disable" line above, and uncomment
    # the following line instead:
    #
    #UserDir public_html

</IfModule>

Comment out the line that reads UserDir disable and uncomment the line which reads UserDir public_html:

<IfModule mod_userdir.c>
    #
    # UserDir is disabled by default since it can confirm the presence
    # of a username on the system (depending on home directory
    # permissions).
    #
    #UserDir disable

    #
    # To enable requests to /~user/ to serve the user's public_html
    # directory, remove the "UserDir disable" line above, and uncomment
    # the following line instead:
    #
    UserDir public_html

</IfModule>

Then uncomment the container section <Directory /home/*/public_html>:

#
# Control access to UserDir directories. The following is an example
# for a site where these directories are restricted to read-only.
#
<Directory /home/*/public_html>
    AllowOverride FileInfo AuthConfig Limit
    Options MultiViews Indexes SymLinksIfOwnerMatch IncludesNoExec
    <Limit GET POST OPTIONS>
        Order allow,deny
        Allow from all
    </Limit>
    <LimitExcept GET POST OPTIONS>
        Order deny,allow
        Deny from all
    </LimitExcept>
</Directory>

Each user can then create a ~/public_html directory and place her own personal content in that directory.

If you have SELinux enabled, each user will need to execute this command to make his content accessible to Apache: $ chcon -R -t httpd_sys_content_t ~/public_html Alternately, users can make their public_html content accessible to both Apache and Samba (see Lab 8.2, "Using SELinux").

7.5.1.6.5. Using virtual hosts

Virtual hosting permits one web server to serve web pages for multiple hostnames. There are two ways of detecting which host a browser is trying to connect to: the web server can respond to multiple IP addresses and serve different content based on which IP address is used (IP-based virtual hosts), or the web server can serve the content based on the Host: header sent by the browser (name-based virtual hosts).

To configure named-based virtual hoststhe most common typeuncomment the NameVirtualHost directive in the httpd.conf file:

NameVirtualHost *:80

If you're using a port other than 80, enter it on this line.

Next, create a VirtualHost container for each virtual host. There is an example in the comments near the end of the httpd.conf file:

#<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>

Copy and uncomment these lines, substituting the correct values for these directives:

ServerAdmin

Insert the email contact for the administrator for this virtual host.

DocumentRoot

Enter the document root for this virtual host. If you're using SELinux, it is easiest to use subdirectories of /var/www/html for the virtual host document roots.

ServerName, ServerAlias

The main name of the web server and any assigned nicknames, respectively. These names must appear in the DNS entries for this host. It's a good idea to include common misspellings within your domain name, such as ww.fedorabook.com and wwww.fedorabook.com.

Your DNS configuration must include all of the hostnames used for ServerName and ServerAlias or be configured with a wildcard hostname (*).

ErrorLog, CustomLog

Set these to the name of the logfiles you wish to use for errors and for normal access, respectively. At the end of CustomLog, specify the logfile format combined so that referrer information is included in your logfile.

A completed virtual host container will look like this:

<VirtualHost *:80>
    ServerAdmin webadministrator@fedorabook.com
    DocumentRoot /var/www/html/fedorabook
    ServerName fedorabook.com
    ServerAlias www.fedorabook.com ww.fedorabook.com wwww.fedorabook.com
    ErrorLog logs/fedorabook-error_log
    CustomLog logs/fedorabook-access_log combined
</VirtualHost>

7.5.1.7. Enabling CGI scripts in every directory

Fedora's default Apache configuration permits CGI scripts only in the /cgi-bin/ script alias directory, /var/www/cgi-bin/. This makes it easy to keep an eye on all of the scripts, and many webmasters prefer this.

However, on a complex site with different web applications running, it is often desirable to group files by application, allocating one directory for each application and building a structure within that directory for the scripts, HTML, stylesheets, and multimedia files, rather than mixing the scripts for all of the applications together into a single directory.

To enable CGI scripts in every directory, uncomment the AddHandler directive for the .cgi extension in httpd.conf:

AddHandler cgi-script .cgi

Then add ExecCGI to the Options directive for the DocumentRoot:

<Directory "/var/www/html">
    ...
    Options Indexes FollowSymLinks ExecCGI
    ...
</Directory>

Apache will then treat any file with a .cgi extension as a script.

If you want individual users to be able to run scripts, do the same for the ~/public_html directories:

<Directory /home/*/public_html>
    ...
    Options MultiViews Indexes SymLinksIfOwnerMatch IncludesNoExec ExecCGI
    ...
</Directory>

CGI scripts in users' ~/public_html directories will execute with that user's permission and will therefore be able to read and write any files that the user can read and write. This can be a huge security risk because a single web script can expose any file, email, or database on your system which that user can normally access. In order to reduce the risk of a script that has been maliciously compromised, scripts that are writable by group or other users or contained in directories that are writable by group or others will not be executed by Apache, and an error message will be logged in /var/log/httpd/suexec.

7.5.1.8. Password-protecting content

Apache can be configured to password-protect content using two files: a password file and an .htaccess file.

Note that passwords are sent in unencrypted form over the network unless you use a secure (SSL) connection, so the security provided by this option is minimal.

First, configure Apache to permit the use of .htaccess files for authentication configuration. If you're using the graphical configuration tool, select the checkbox labeled "Let .htaccess files override directory options."

To configure this without using the graphical tool, add the AuthConfig keyword to the AllowOverride line in the appropriate directory container within httpd.conf:

<Directory "/var/httpd">
    ...
    AllowOverride AuthConfig
    ...
</Directory>

This option is enabled by default for ~/public_html directories.

An .htaccess file is similar to an httpd.conf file, but it is placed in the directory that you wish to protect. Here is an example:

AuthType     Basic
AuthName     "team scores"
AuthUserFile /etc/httpd/team_scores_password
Require      valid-user

The four directives in this file are required for basic password protection:

AuthType

Specifies the authentication type to be used. Basic indicates that a simple user ID/password pair will be used.

AuthName

Describes the type of data being protected by the password. Most browsers will include this text in the password dialog, as shown in Figure 7-19.

AuthUserFile

The name of the password file.

Require

Normally set to valid-user, permitting any user with a valid password to access the protected content.

Figure 7-19. Browser dialog box showing the AuthName value

For security, the password file must be located outside of the directories served by Apache. It is managed with the htpasswd command; to create the file and set the first password, use the -c option and provide the password filename and user ID as arguments:

# htpasswd -c /var/httpd/team_scores_password chris
New password: 
                     bigsecret
Re-enter new password: 
                     bigsecret
Adding password for user chris

Once the file has been created, leave out the -c option, or you'll erase existing entries:

# htpasswd /var/httpd/team_scores_password diane
New password: 
                     neverguess
Re-type new password: 
                     neverguess
Adding password for user diane

If you prefer, you can include the password at the end of command linewhich works well for scriptsby adding the -b option:

# htpasswd -b /var/httpd/team_scores_password frank TheBestPitcher
Adding password for user frank

If other users are logged in to the system, there is a small chance that they will be able to discover these passwords if you set them using the -b option because the command line is visible in the output of the ps command (although very briefly).

If you enter an existing user ID instead of a new one, the old password will be updated instead of creating a new record:

# htpasswd -b /var/httpd/team_scores_password diane new-secret
Updating password for user diane

.htaccess files have traditionally been used for access control, and they work well for ~/public_html directories because users can configure them on their own. For directories in your document root, it's just as easy to place the authentication directives in a directory container in httpd.conf:

<Directory /var/www/html/scores/>
    AuthType        Basic
    AuthName        "team scores"
    AuthUserFile    /etc/httpd/team_scores_password
    Require         valid-user
</Directory>

7.5.2. How Does It Work?

Apache is the most widely used web server software in the world. It is actively developed by the Apache Software Foundation (http://apache.org) and can be scaled from a static personal web site on a desktop-class computer to a extremely high-volume database-backed web site running on clusters of computers.

In order to meet such a wide range of needs, Apache can be configured using over 370 distinct directives. Although many different graphical configuration tools have been developed, none of them can configure all directives or handle all possible deployment scenarios for the software.

The Fedora graphical configuration tool for Apache is named system-config-httpd. The options entered into the configuration dialogs are saved in XML and then converted into a working httpd.conf by using the XSLT transformation stylesheet /usr/share/system-config-httpd/httpd.conf.xsl. You can customize that file to change the generated httpd.conf file.

The actual Apache server program is /usr/sbin/httpd. It can be started or stopped with the service command or system-config-services, which use the Fedora-specific script file /etc/rc.d/init.d/httpd; it can also be started and stopped with Apache tool /usr/sbin/apachectl, but the SELinux security context will be different.

Apache listens on the configured ports and waits for incoming connections from client software such as web browsers. Once a connection is established, the client sends a request, plus additional headers with information such as the client software version and preferred languages and encodings, followed by a blank line. The server responds with a result code, additional headers, a blank line, and then the content requested (or an error message). In its most basic form, the conversation goes something like this (the request is shown in bold; the response headers are in italic, and the rest of the listing is the body of the response):

GET /testfile.html HTTP/1.1
Host: www.fedorabook.com

HTTP/1.1 200 OK
               Date: Wed, 01 Mar 2006 02:49:54 GMT
               Server: Apache/2.2.0 (Fedora)
               Last-Modified: Mon, 27 Feb 2006 21:25:54 GMT
               ETag: "f0518-4a-5b0edc80"
               Accept-Ranges: bytes
               Content-Length: 85
               Connection: close
               Content-Type: text/html; charset=UTF-8

<html>
<head><title>Test</title></head>
<body>
<i><p>Success!</p></i>
</body>
</html>

In an elementary configuration, Apache is responsible for mapping the web namespace to the local filesystem namespace, performing access control and logging, collecting the requested resource (either by reading a file or executing code), and sending the resource to the client.

7.5.3. What About...

7.5.3.1. ...interpreting the Apache logfiles?

Logfiles come in two forms: access logs and error logs. An access log in the default common format contains entries like these (all on one line):

24.43.223.54 - - [28/Feb/2006:22:01:33 -0500] "GET / HTTP/1.1" 200 956

The fields here are the IP address of the remote host (24.43.223.54); the remote user login name (-); the authenticated username on the local system (-, because the user did not authenticate); the date, time, and time zone of the request ([28/Feb/2006:22:01:33 -0500]); the request string (GET / HTTP/1.1); the status code returned to the client (200, meaning OK); and the number of bytes sent to the client (956).

If you use the combined log format, the entries will look like this:

24.43.223.54 - - [28/Feb/2006:22:01:33 -0500] "GET / HTTP/1.1" 200 956 "http://www.fedorabook.com/index.html" "Mozilla/5.0 (X11; U; 
Linux i686; en-US; rv:1.7.12) Gecko/20060202 Fedora/1.0.7-1.2.fc4 Firefox/1.0.7"

The additional fields are the referring page, which linked to or contained the information requested (http://www.fedorabook.com/index.html), and the user agent header, which describes the client software (Firefox on a Fedora system in this case). The user agent information is interesting, but the referrer information is critical if you want to analyze where your visitors are coming from, which pages they visit first, and how they progress through your web site.

The error logfile contains entries like this:

[Tue Feb 28 22:01:33 2006] [error] [client 24.43.223.54] File does not exist: /var/www/html/favicon.ico

This indicates the date and time, the fact that this is an error, the client IP address, and the detail of the error.

7.5.3.2. ...using a more secure authentication scheme than Basic?

The problem with basic authentication is that the user ID and password travel in plain text across the network. Anyone snooping on the network can see the password.

A slightly better approach is to use digest authentication, which hashes the password before sending it across the network. This is still not nearly as secure as encrypting the connection.

To use digest authentication, use the same authentication configuration as you would for basic authentication, but substitute Digest for the AuthType:

AuthType     
                     Digest 
AuthName     "prices "
AuthUserFile /var/www/digest 
Require      valid-user

Create the password file using the htdigest command instead of htpasswd. htdigest requires one additional argument in front of the username, called the realm; copy the value from the AuthName directive and use it for the realm. Here is an example:

# htdigest -c /var/www/digest prices chris
Adding password for chris in realm prices.
New password: 
                     confidentialpassword
Re-type new password:
                      confidentialpassword
# htdigest /var/www/digest prices diane
Adding user diane in realm prices
New password: 
                     bigsecret
Re-type new password:
                      bigsecret

htdigest does not accept the -b option used with htpasswd.

7.5.4. Where Can I Learn More?

• The Apache documentation from the Apache Software Foundation is on their web site at http://httpd.apache.org/docs/2.2/ and on the web server of any Fedora system at http://<hostname>/<manual> (to disable access to the manual, remove /var/www/manual).

• The manpages for httpd, htpasswd, htdigest, and httpd_selinux.