You can find the Apache RPM on the Fedora Core installation media, on the Fedora FTP server, or at one of its many mirror sites. Check the fedora.redhat.com site as often as possible to download updates as they become available. Updated RPM files usually contain important bug and security fixes. When an updated version is released, install it as quickly as possible to keep your system secure.

After you have obtained an Apache RPM, you can install it with the command-line rpm tool by typing the following:

rpm -Uvh latest_apache.rpm

where latest_apache.rpm is the name of the latest Apache RPM. For more information on installing packages with RPM, refer to Chapter 7.

The Apache RPM installs files in the following directories:

When Apache is being run, it also creates the file httpd.pid, containing the process ID of Apache’s parent process in the /var/run/ directory.

There are several ways to obtain the source code for Apache. The Fedora Project provides SRPMs containing the source of Apache, which includes patches to make it work better with the Fedora Core distribution. The most up-to-date, stable binary version for Fedora can be installed via RPM packages using the up2date command or by installing a source RPM from Fedora’s source repository (browse to http://fedora.redhat.com and then click the Download link). When you install one of these SRPMs, a tar archive containing the Apache source is created in /usr/src/redhat/SOURCES/.

You can also download the source directly from http://www.apache.org/. The latest version at the time of this writing (2.0.50) is a 6MB compressed tape archive, and the latest pre-2.0 version of Apache is 1.3.31. Although many sites continue to use the older version (for script and other compatibility reasons), many new sites are migrating to or starting out using the latest stable version.

After you have the tar file, you must unroll it in a temporary directory, such as /tmp. Unrolling this tar file creates a directory called apache_version_number, where version_number is the version you’ve downloaded (for example, apache_1.3.21).

There are two ways to compile the source—the old, familiar way (at least, to those of us who have been using Apache for many years) by editing makefile templates, and the new, easy way using a configure script. You’ll first see how to build Apache from source the easy way. The configure script offers a way to have the source software automatically configured according to your system. However, manually editing the configuration files before building and installing Apache provides more control over where the software is installed and which capabilities or features are built in to Apache.

# ./configure --prefix=/preferred/directory/

# service httpd start

# /etc/rc.d/init.d/httpd start

# links http://localhost/

apache:x:48:48:Apache:/var/www:/sbin/nologin

You can start Apache from the command line of a text-based console or X terminal window, and you must have root permission to do so. The server daemon, httpd, recognizes several command-line options you can use to set some defaults, such as specifying where httpd reads its configuration directives. The Apache httpd executable also understands other options that enable you to selectively use parts of its configuration file, specify a different location of the actual server and supporting files, use a different configuration file (perhaps for testing), and save startup errors to a specific log. The -v option causes Apache to print its development version and quit. The -V option shows all the settings that were in effect when the server was compiled.

The -h option prints the following usage information for the server (assuming that you’re running the command as root):

# httpd -h
Usage: httpd [-D name] [-d directory] [-f file]
             [-C "directive"] [-c "directive"]
             [-k start|restart|graceful|stop]
             [-v] [-V] [-h] [-l] [-L] [-t]
Options:
  -D name           : define a name for use in <IfDefine name> directives
  -d directory      : specify an alternate initial ServerRoot
  -f file           : specify an alternate ServerConfigFile
  -C "directive"    : process directive before reading config files
  -c "directive"    : process directive after reading config files
  -e level          : show startup errors of level (see LogLevel)
  -E file           : log startup errors to file
  -v                : show version number
  -V                : show compile settings
  -h                : list available command line options (this page)
  -l                : list compiled in modules
  -L                : list available configuration directives
  -t -D DUMP_VHOSTS : show parsed settings (currently only vhost settings)
  -t                : run syntax check for config files

Other options include listing Apache’s static modules, or special, built-in independent parts of the server, along with options that can be used with the modules. These options are called configuration directives and are commands that control how a static module works. Note that Apache also includes nearly 50 dynamic modules, or software portions of the server that can be optionally loaded and used while the server is running.

The -t option is used to check your configuration files. It’s a good idea to run this check before restarting your server, especially if you’ve made changes to your configuration files. Such tests are important because a configuration file error can result in your server shutting down when you try to restart it.

Fedora uses the scripts in the /etc/rc.d/init.d directory to control the startup and shutdown of various services, including the Apache web server. The main script installed for the Apache web server is /etc/rc.d/init.d/httpd, although the actual work is done by the apachectl shell script included with Apache.

You can use the /etc/rc.d/init.d/httpd script and the following options to control the web server:

For example, to check on the status of your server, use the command

# /etc/rc.d/init.d/httpd status

This prints the following for me:

httpd (pid 15997 1791 1790 1789 1788 1787 1786 1785 1784 1781) is running...

This indicates that the web server is running; in fact, 10 instances of the server are currently running in this configuration.

In addition to the previous options, the httpd script also offers these features:

Instead of directly calling the /etc/rc.d/init.d/httpd script, you can use Red Hat’s service command to start, stop, and restart Apache. The service command is used with the name of a service (listed under /etc/rc.d/init.d) and an optional keyword:

# service <name_of_script> <option>

For example, you can use service with httpd and any option discussed in the previous section, like so:

# service httpd restart

This restarts Apache if it’s running or starts the server if it isn’t running.

The chkconfig command provides a command-line–based interface to Fedora’s service scripts. The command can be used to list and control which software services are started, restarted, and stopped for a specific system state (such as when booting up, restarting, or shutting down) and runlevel (such as single-user mode, networking with multitasking, or graphical login with X).

For example, to view your system’s current settings, take a look at Fedora’s default runlevel as defined in the system initialization table /etc/inittab using the grep command:

# grep id: /etc/inittab
id:3:initdefault:

This example shows that this Fedora system boots to a text-based login without running X11. You can then use the chkconfig command to look at the behavior of Apache for that runlevel:

# chkconfig --list | grep httpd
httpd           0:off 1:off 2:off 3:off 4:off 5:off 6:off

Here you can see that Apache is turned off for runlevels 3 and 5 (the only two practical runlevels in a default Fedora system, although you could create a custom runlevel 4 for Apache). Use --level, httpd, and the control keyword on to set Apache to automatically start when booting to runlevel 3:

# chkconfig --level 3 httpd on

You can then again use chkconfig to verify this setting:

# chkconfig --list | grep httpd
httpd           0:off   1:off   2:off   3:on   4:off   5:off   6:off

To have Apache also start when your system is booted to a graphical login using X, again use level, httpd, and the control keyword on, but this time, specify runlevel 5 like so:

# chkconfig --level 5 httpd on

Again, to verify your system settings, use

# chkconfig --list | grep httpd
httpd           0:off   1:off   2:off   3:on   4:off   5:on   6:off

Use the off keyword to stop Apache from starting at a particular runlevel.

You can also use a graphical version of the chkconfig command named system-config-services during an X session to set when Apache is started or stopped and at which runlevel. To start system-config-services, select the Services on the Server Settings menu from your desktop panel’s System Settings menu, or type the command in a terminal window like so:

$ system-config-services &

After you press Enter, you’re prompted for the root password (because you shouldn’t be running X as root).

This client is a graphical runlevel editor. To have Apache start when using runlevel 3, first use the Edit Runlevel menu to select runlevel 3 and then scroll through the list of services to find httpd. If you click the httpd check box, as shown in Figure 21.1, and then click the toolbar’s Save button, Apache is started at that runlevel the next time the system starts or reboots.

Figure 21.1. Use the system-config-services client to set when Apache is started or stopped on your Fedora system.

You can also use the Service Configuration client to instantly control a service. Use the Edit Runlevel menu to select the current runlevel in use; highlight httpd; and then click the Start, Stop, or Restart toolbar button.

You perform runtime configuration of your server with configuration directives, which are commands that set options for the httpd daemon. The directives are used to tell the server about various options you want to enable, such as the location of files important to the server configuration and operation. Apache supports nearly 300 configuration directives using the following syntax:

directive option option...

Each directive is specified on a single line. See the following sections for some sample directives and how to use them. Some directives set only a value such as a filename, whereas others enable you to 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 this: </directive>. Note that section tags, like any other directives, are specified one per line.

Most of the default settings in the config file are okay to keep, particularly if you’ve installed the server in a default location and aren’t 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.

The following sections describe some of the configuration file settings you might want to change concerning operation of your server.

User apache
Group apache

User #48
Group #48

Apache version 2.0 and greater now uses a new internal architecture supporting multiprocessing modules (MPMs). These modules are used by the server for a variety of tasks, such as network and process management, and are compiled into Apache. MPMs enable Apache to work much better on a wider variety of computer platforms, and they can help improve server stability, compatibility, and scalability.

Apache can use only one MPM at any time. These modules are different from the base set included with Apache (see the “Apache Modules” section later in this chapter), but are used to implement settings, limits, or other server actions. Each module in turn supports numerous additional settings, called directives, which further refine server operation.

The internal MPM modules relevant for Linux include

MPM enables Apache to be used on equipment with fewer resources yet still handle massive numbers of hits and provide stable service. The worker module provides directives to control how many simultaneous connections your server can handle.

Apache also supports special configuration files, known as .htaccess files. Almost any directive that appears in httpd.conf 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 (usually in a user directory) basis. As the system administrator, you can specify both the name of this file and which of the server configurations can be overridden by the contents of this file. This is especially useful for sites in which there are multiple content providers and you want to control what these people can do with their space.

To limit which server configurations the .htaccess files can override, use the AllowOverride directive. AllowOverride can be set globally or per directory. For example, in your httpd.conf file, you could use 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>

One of the simplest ways to limit access to website material is to restrict access to a specific group of users, based on IP addresses or hostnames. Apache uses the allow and deny directives to accomplish this.

Both directives take an address expression as a parameter. The following list provides the possible values and use of the address expression:

If you have the choice, it’s preferable to base your access control on IP addresses rather than hostnames. Doing so results in faster performance because no name lookup is necessary—the IP address of the client is included with each request.

You also can use allow and deny to provide or deny access to website material based on the presence or absence of a specific environment variable. For example, the following statement denies access to a request with a context that contains an environment variable named NOACCESS:

deny from env=NOACCESS

The default behavior of Apache is to apply all the deny directives first and then check the allow directives. If you want to change this order, you can use the order statement. Apache might interpret this statement in three different ways:

Consider this example. Suppose that you want to allow only persons from within your own domain to access the server-status resource on your web. If your domain were named gnulix.org, you could add these lines to your configuration file:

<Location /server-status>
    SetHandler server-status
    Order deny,allow
    Deny from all
    Allow from gnulix.org
</Location>

Authentication is the process of ensuring that visitors really are who they claim to be. You can configure Apache to allow access to specific areas of web content only to clients who can authenticate their identity. There are several methods of authentication in Apache; Basic Authentication is the most common (and the method discussed in this chapter).

Under Basic Authentication, Apache requires a user to supply a username and a password to access the protected resources. Apache then verifies that the user is allowed to access the resource in question. If the username is acceptable, Apache verifies the password. If the password also checks out, the user is authorized and Apache serves the request.

HTTP is a stateless protocol; each request sent to the server and each response are handled individually, and not in an intelligent fashion. Therefore, the authentication information must be included with each request. That means each request to a password-protected area is larger and therefore somewhat slower. To avoid unnecessary system use and delays, protect only those areas of your website that absolutely need protection.

To use Basic Authentication, you need a file that lists which users are allowed to access the resources. This file is composed of a plain text list containing name and password pairs. It looks very much like the /etc/passwd user file of your Linux system.

To create a user file for Apache, use the htpasswd command. This is included with the Apache package. If you installed using the RPMs, it is in /usr/bin. Running htpasswd without any options produces the following output:

Usage:
       htpasswd [-cmdps] passwordfile username
       htpasswd -b[cmdps] passwordfile username password

       htpasswd -n[mdps] username
       htpasswd -nb[mdps] username password
 -c Create a new file.
 -n Don't update file; display results on stdout.
 -m Force MD5 encryption of the password.
 -d Force CRYPT encryption of the password (default).
 -p Do not encrypt the password (plaintext).
 -s Force SHA encryption of the password.
 -b Use the password from the command line rather than prompting for it.
 -D Delete the specified user.
On Windows, TPF and NetWare systems the '-m' flag is used by default.
On all other systems, the '-p' flag will probably not work.

As you can see, it isn’t a very difficult command to use. For example, to create a new user file named gnulixusers with a user named wsb, you need to do something like this:

# htpasswd -c gnulixusers wsb

You would then be prompted for a password for the user. To add more users, you would repeat the same procedure, only omitting the -c flag.

You can also create user group files. The format of these files is similar to that of /etc/groups. On each line, enter the group name, followed by a colon, and then list all users, with each user separated by spaces. For example, an entry in a user group file might look like this:

gnulixusers: wsb pgj jp ajje nadia rkr hak

Now that you know how to create a user file, it’s time to look at how Apache might use this to protect web resources.

To point Apache to the user file, use the AuthUserFile directive. AuthUserFile takes the file path to the user file as its parameter. If the file path isn’t absolute—that is, beginning with a /—it’s assumed that the path is relative to the ServerRoot. Using the AuthGroupFile directive, you can specify a group file in the same manner.

Next, use the AuthType directive to set the type of authentication to be used for this resource. Here, the type is set to Basic.

Now you need to decide to which realm the resource belongs. Realms are used to group different resources that share the same users for authorization. A realm can consist of just about any string. The realm is shown in the Authentication dialog box on the user’s web browser. Therefore, you should set the realm string to something informative. The realm is defined with the AuthName directive.

Finally, state which type of user is authorized to use the resource. You do this with the require directive. The three ways to use this directive are as follows:

Returning to the server-status example you saw earlier, instead of letting users access the server-status resource based on hostname, you can require the users to be authenticated to access the resource. You can do so with the following entry in the configuration file:

<Location /server-status>
    SetHandler server-status
    AuthType Basic
    AuthName "Server status"
    AuthUserFile "gnulixusers"
    Require valid-user
</Location>

If you have host-based as well as user-based access protection on a resource, the default behavior of Apache is to require the requester to satisfy both controls. But assume that you want to mix host-based and user-based protection and allow access to a resource if either method succeeds. You can do so using the satisfy directive. You can set the satisfy directive to All (this is the default) or Any. When set to All, all access control methods must be satisfied before the resource is served. If satisfy is set to Any, the resource is served if any access condition is met.

Here’s another access control example, again using the previous server-status example. This time, you combine access methods so that all users from the Gnulix domain are allowed access and those from outside the domain must identify themselves before gaining access. You can do so with the following:

<Location /server-status>
    SetHandler server-status
    Order deny,allow
    Deny from all
    Allow from gnulix.org
    AuthType Basic
    AuthName "Server status"
    AuthUserFile "gnulixusers"
    Require valid-user
    Satisfy Any
</Location>

There are more ways to protect material on your web server, but the methods discussed here should get you started and are probably be more than adequate for most circumstances. Look to Apache’s online documentation for more examples of how to secure areas of your site.

mod_access controls access to areas on your web server based on IP addresses, hostnames, or environment variables. For example, you might want to allow anyone from within your own domain to access certain areas of your web. Refer to the “File System Authentication and Access Control” section earlier in this chapter for more information.

mod_alias manipulates the URLs of incoming HTTP requests, such as redirecting a client request to another URL. It also can map a part of the file system into your web hierarchy. For example,

Alias /images/ /home/wsb/graphics/

fetches contents from the /home/wsb/graphics directory for any URL that starts with /images/. This is done without the client knowing anything about it. If you use a redirection, the client is instructed to go to another URL to find the requested content. More advanced URL manipulation can be accomplished with mod_rewrite.

mod_asis is used to specify, in fine detail, all the information to be included in a response. This completely bypasses any headers Apache might have otherwise added to the response. All files with an .asis extension are sent straight to the client without any changes.

As a short example of the use of mod_asis, assume that you’ve moved content from one location to another on your site. Now you must inform people who try to access this resource that it has moved, as well as automatically redirect them to the new location. To provide this information and redirection, you can add the following code to a file with an .asis extension:

Status: 301 No more old stuff!
Location: http://gnulix.org/newstuff/
Content-type: text/html

<HTML>
 <HEAD>
  <TITLE>We've moved...</TITLE>
 </HEAD>
 <BODY>
   <P>We've moved the old stuff and now you'll find it at:</P>
   <A HREF="http://gnulix.org/newstuff/">New stuff</A>!.
 </BODY>
</HTML>

mod_auth uses a simple user authentication scheme, referred to as Basic Authentication, which is based on storing usernames and encrypted passwords in a text file. This file looks very much like UNIX’s /etc/passwd file and is created with the htpasswd command. Refer to the “File System Authentication and Access Control” section earlier in this chapter for more information about this subject.

The mod_auth_anon module provides anonymous authentication similar to that of anonymous FTP. The module enables you to define user IDs of those who are to be handled as guest users. When such a user tries to log on, he is prompted to enter his email address as his password. You can have Apache check the password to ensure that it’s a (more or less) proper email address. Basically, it ensures that the password contains an @ character and at least one . character.

mod_auth_dbm uses Berkeley DB files instead of text for user authentication files.

An extension of the basic mod_auth module, instead of sending the user information in plain text, mod_auth_digest is sent via the MD5 Digest Authentication process. This authentication scheme is defined in RFC 2617. Compared to using Basic Authentication, this is a much more secure way of sending user data over the Internet. Unfortunately, not all web browsers support this authentication scheme.

To create password files for use with mod_auth_dbm, you must use the htdigest utility. It has more or less the same functionality as the htpasswd utility. See the man page of htdigest for further information.

The mod_autoindex module dynamically creates a file list for directory indexing. The list is rendered in a user-friendly manner similar to those lists provided by FTP’s built-in ls command.

mod_cgi allows execution of CGI programs on your server. CGI programs are executable files residing in the /var/www/cgi-bin directory and are used to dynamically generate data (usually HTML) for the remote browser when requested.

The mod_dir module is used to determine which files are returned automatically when a user tries to access a directory. The default is index.html. If you have users who create web pages on Windows systems, you should also include index.htm, like this:

DirectoryIndex index.html index.htm

mod_env controls how environment variables are passed to CGI and SSI scripts.

mod_expires is used to add an expiration date to content on your site by adding an Expires header to the HTTP response. Web browsers or cache servers won’t cache expired content.

mod_headers is used to manipulate the HTTP headers of your server’s responses. You can replace, add, merge, or delete headers as you see fit. The module supplies a Header directive for this. Ordering of the Header directive is important. A set followed by an unset for the same HTTP header removes the header altogether. You can place Header directives almost anywhere within your configuration files. These directives are processed in the following order:

mod_include enables the use of server-side includes on your server. See the “Dynamic Content” section later in the chapter for more information about how to use SSI.

mod_info provides comprehensive information about your server’s configuration. For example, it displays all the installed modules, as well as all the directives used in its configuration files.

mod_log_config defines how your log files should look. See the “Logging” section for further information about this subject.

The mod_mime module tries to determine the MIME type of files from their extensions.

The mod_mime_magic module tries to determine the MIME type of files by examining portions of their content.

Using the mod_negotiation module, you can select one of several document versions that best suits the client’s capabilities. There are several options to select which criteria to use in the negotiation process. You can, for example, choose among different languages, graphics file formats, and compression methods.

mod_proxy implements proxy and caching capabilities for an Apache server. It can proxy and cache FTP, CONNECT, HTTP/0.9, and HTTP/1.0 requests. This isn’t an ideal solution for sites that have a large number of users and therefore have high proxy and cache requirements. However, it’s more than adequate for a small number of users.

mod_rewrite is the Swiss army knife of URL manipulation. It enables you to perform any imaginable manipulation of URLs using powerful regular expressions. It provides rewrites, redirection, proxying, and so on. There’s very little that you can’t accomplish using this module.

mod_setenvif allows manipulation of environment variables. Using small snippets of text-matching code known as regular expressions, you can conditionally change the content of environment variables. The order in which SetEnvIf directives appear in the configuration files is important. Each SetEnvIf directive can reset an earlier SetEnvIf directive when used on the same environment variable. Be sure to keep that in mind when using the directives from this module.

mod_speling is used to enable correction of minor typos in URLs. If no file matches the requested URL, this module builds a list of the files in the requested directory and extracts those files that are the closest matches. It tries to correct only one spelling mistake.

You can use mod_status to create a web page containing a plethora of information about a running Apache server. The page contains information about the internal status as well as statistics about the running Apache processes. This can be a great aid when you’re trying to configure your server for maximum performance. It’s also a good indicator of when something’s amiss with your Apache server.

mod_ssl provides Secure Sockets Layer (version 2 and 3) and transport layer security (version 1) support for Apache. At least 30 directives exist that deal with options for encryption and client authorization and that can be used with this module.

mod_unique_id generates a unique request identifier for every incoming request. This ID is put into the UNIQUE_ID environment variable.

The mod_userdir module enables mapping of a subdirectory in each user’s home directory into your web tree. The module provides several ways to accomplish this.

mod_usertrack is used to generate a cookie for each user session. This can be used to track the user’s click stream within your web tree. You must enable a custom log that logs this cookie into a log file.

mod_vhost_alias supports dynamically configured mass virtual hosting, which is useful for Internet service providers (ISPs) with many virtual hosts. However, for the average user, Apache’s ordinary virtual hosting support should be more than sufficient.

There are two ways to host virtual hosts on an Apache server. You can have one IP address with multiple CNAMEs, or you can have multiple IP addresses with one name per address. Apache has different sets of directives to handle each of these options. (You learn more about virtual hosting in Apache in the next section of this chapter.)

Again, the available options and features for Apache modules are too numerous to describe completely in this chapter. You can find complete information about the Apache modules in the online documentation for the server included with Fedora or at the Apache Software Foundation’s website.

After you’ve configured your Linux machine with multiple IP addresses, setting up Apache to serve them as different websites is simple. You need only put a VirtualHost directive in your httpd.conf file for each of the addresses you want to make an independent website:

<VirtualHost 212.85.67.67>
ServerName gnulix.org
DocumentRoot /home/virtual/gnulix/public_html
TransferLog /home/virtual/gnulix/logs/access_log
ErrorLog /home/virtual/gnulix/logs/error_log
</VirtualHost>

Use the IP address, rather than the hostname, in the VirtualHost tag.

You can specify any configuration directives within the <VirtualHost> tags. For example, you might want to set AllowOverrides directives differently for virtual hosts than you do for your main server. Any directives that aren’t specified default to the settings for the main server.

Name-based virtual hosts enable you to run more than one host on the same IP address. You must add the names to your DNS as CNAMEs of the machine in question. When an HTTP client (web browser) requests a document from your server, it sends with the request a variable indicating the server name from which it’s requesting the document. Based on this variable, the server determines from which of the virtual hosts it should serve content.

Name-based virtual hosts require just one step more than IP address-based virtual hosts. You must first indicate which IP address has the multiple DNS names on it. This is done with the NameVirtualHost directive:

NameVirtualHost 212.85.67.67

You must then have a section for each name on that address, setting the configuration for that name. As with IP-based virtual hosts, you need to set only those configurations that must be different for the host. You must set the ServerName directive because it’s the only thing that distinguishes one host from another:

<VirtualHost 212.85.67.67>
ServerName bugserver.gnulix.org
ServerAlias bugserver
DocumentRoot /home/bugserver/htdocs
ScriptAlias /home/bugserver/cgi-bin
TransferLog /home/bugserver/logs/access_log
</VirtualHost>

<VirtualHost 212.85.67.67>
ServerName pts.gnulix.org
ServerAlias pts
DocumentRoot /home/pts/htdocs
ScriptAlias /home/pts/cgi-bin
TransferLog /home/pts/logs/access_log
ErrorLog /home/pts/logs/error_log
</VirtualHost>

ServerAlias bugserver

For more information about VirtualHost, refer to the help system on http://localhost/_manual.

By default, you can put any CGI program on your server in the directory defined by the ScriptAlias directive. CGI programs can be written in any language. The most popular languages for CGI programming are Perl and C. Chapter 30, “Using Perl,” provides more information about using the Perl scripting language.

These programs must be executable by the default Apache user, which means you must change the mode of the files to 555 so that the Apache user can execute them. By default, Apache runs in Fedora as a user named apache:

chmod 555 program.cgi

To execute CGI programs outside the ScriptAlias directory, you must enable the ExecCGI option for that directory. This is done in either your httpd.conf file or in an .htaccess file in the directory.

To test whether you have CGI configured correctly, try the CGI program in Listing 21.1. This program is written in Perl and displays the values of the HTTP environment variables.

#!/usr/bin/perl -w

print <<EOF;
"Content-type: text/html"

<HTML>
 <HEAD>
  <TITLE>Simple CGI program</TITLE>
 </HEAD>
 <BODY>
EOF
for (keys %ENV) {
    print " $_ = $ENV{$_}<BR>
";
}
    print <<EOF;
     </BODY>
    </HTML>
EOF

If you’re going to write CGI programs in Perl, take some time to study the CGI modules that come bundled with Perl. An extensive Perl module library, which contains many modules designed to be used when writing CGIs, is accessible at http://www.cpan.org/.

If you are using many CGIs written in Perl, examine the mod_perl module. It embeds a Perl interpreter within the Apache server. Using this module results in faster execution times for your CGIs because you don’t need to start a new Perl interpreter for each request. You’ll find information about using mod_perl under the /usr/share/doc/_mod_perl-1.99_12/docs/ directory if you install it from this book’s DVD.

Server-side includes are directives written directly into an HTML page, which the server parses when the page is served to the web client. SSIs can be used to include other files, output from programs, or environment variables.

You can enable SSI with the XBitHack directive. XBitHack can be set to a value of on or off and can be set in either your configuration file or .htaccess files. If the XBitHack directive is on, it indicates that all files with the user-execute bit set should be parsed for SSI directives. This has two main advantages. One is that you don’t need to rename a file and change all links to that file simply because you want to add a little dynamic content to it. The other reason is more cosmetic: Users looking at your web content can’t tell by looking at the filename that you’re generating a page dynamically, so your wizardry is just a tiny bit more impressive.

Another positive side effect of using XBitHack is that it enables you to control how clients should cache your page. Pages containing SSI statements do not usually contain a Last-modified HTTP header. Therefore, they won’t be cached by proxies or web browsers. If you enable XBitHack, the group-execute bit for files controls whether a Last-modified header should be generated. It is set to the same value as the last modified time of the file. Be sure to use this only on files that really are supposed to be cached.

Another way to enable SSI is to indicate that files with a certain filename extension (typically .shtml) are to be parsed by the server when they’re served. This is accomplished with the following lines in your httpd.conf file:

# To use server-parsed HTML files
#
#AddType text/html .shtml
#AddHandler server-parsed .shtml

If you uncomment the AddType and AddHandler lines, you tell the server to parse all .shtml files for SSI directives. In addition to these directives, the following directive must be specified for directories in which you want to permit SSI:

Options Includes

This can be set in the server configuration file or in an .htaccess file.

SSI directives look rather like HTML comment tags. The syntax is as follows:

<!--#element attribute=value attribute=value ... -->

The element can be one of several directives, including

The following sections describe each of these directives and their uses.

<!--#printenv -->

<!--#set var="animal" value="cow" -->

Using the variables set with the set directive and the various environment and include variables, a limited flow control syntax can be used to generate a certain amount of dynamic content on server-parsed pages.

The syntax of the if/else functions is as follows:

<!--#if expr="test_condition" -->
<!--#elif expr="test_condition" -->
<!--#else -->
<!--#endif -->

expr can be a string, which is considered true if nonempty, or a variety of comparisons between two strings. Available comparison operators are =, !=, <, <=, >, and >=. If the second string has the format /string/, the strings are compared with regular expressions. Multiple comparisons can be strung together with && (AND) and || (OR). Any text appearing between the if/elif/else directives are displayed on the resulting page. An example of such a flow structure follows:

<!--#set var="agent" value="$HTTP_USER_AGENT" -->
<!--#if expr="$agent = /Mozilla/" -->
Mozilla!
<!--#else -->
Something else!
<!--#endif -->

This code displays Mozilla! if you’re using a browser that passes Mozilla as part of its USER_AGENT string, and it displays Something else! otherwise.

In the Virtual Hosts tab, you can configure the properties of each virtual host. The Name list box contains a list of all virtual hosts operating in Apache. Edit a virtual host by opening the Virtual Hosts Properties dialog box, shown in Figure 21.3. You do this by highlighting the name of a virtual host in the Name list box of the Virtual Hosts tab and clicking the Edit button at the right of the tab. Use the General Options item in the Virtual Hosts Properties dialog box to configure basic virtual host settings.

Figure 21.3. system-config-httpd’s Virtual Host Properties dialog box gives you access to numerous options for configuring the properties of an Apache virtual host.

Click the Site Configuration listing in the General Options list of this dialog box to set defaults, such as which files are loaded by default when no files are specified (the default is index.*) in the URL.

The SSL listing in the General Options pane gives you access to settings used to enable or disable SSL, specify certificate settings, and define the SSL log filename and location. Select the Logging listing to access options for configuring where the error messages are logged, as well as where the transfer log file is kept and how much information is put in it.

Use the Environment Variables options to configure settings for the env_mod module, used to pass environment directives to CGI programs. The Directories section configures the directory options (such as whether CGI programs are allowed to run) as well as the order entries mentioned in the httpd.conf section.

The Server tab, shown in Figure 21.4, enables you to configure things such as where the lock file and the PID file are kept. In both cases, you should use the defaults. You can also configure the directory where any potential core dumps will be placed.

Figure 21.4. system-config-httpd’s Server configuration tab.

Finally, you can set which user and group Apache is to run as. As mentioned in a previous note, for security reasons, you should run Apache as the user named apache and as a member of the group apache.

Use the options in the Performance Tuning tab to configure Apache to provide peak performance in your system. Options in this tab set the maximum number of connections, connection timeouts, and number of requests per connection. When setting this number, keep in mind that for each connection to your server, another instance of the HTTPD program might be run, depending on how Apache is built. Each instance takes resources such as CPU time and memory. You can also configure details about each connection such as how long, in seconds, before a connection times out and how many requests each connection can make to the server. More tips on tuning Apache can be found in Chapter 35, “Performance Tuning.”

Despite the Netcraft numbers shown previously in Table 21.1, there is evidence that the Sun Java System Web Server (formerly known as the iPlanet Web Server, and subsequently Sun ONE Web Server) might be even more popular than Apache in strictly corporate arenas. Netcraft has rated Sun Java System Web Server number one in market share among Fortune 100 websites.

The server got its start as the Netscape Enterprise Server—one of the first powerful web servers ever to hit the market. Sun Java System Web Server comes in many flavors, and all of them are big. In addition to the enterprise-level web server that can be run on Red Hat, the software features application, messaging, calendar, and directory servers—just to name a few.

Sun Java System Web Server is great for handling big web needs, and it comes with an appropriately big price tag: $1,495 (U.S.) per CPU. It’s definitely not something to run the school website—unless your school happens to be a major state university with several regional campuses. For more information on Sun Java System Web Server, you can visit its website (http://wwws.sun.com/software/products/web_srvr/home_web_srvr.html).

If you’re looking for something a little more secure than Apache but still don’t want to lose the Apache functionality, you can purchase Stronghold from Red Hat Software. Although not a web server as such, Stronghold is a server add-on that provides 128-bit cryptography and security certificates to the Apache web server (which is included in your purchase of Stronghold). Stronghold supports SSL and TLS security standards, as well as many of the certificate standards on the market today.

The price for this kind of security is not particularly cheap. The software, which can be previewed at http://www.redhat.com/software/stronghold/, was advertised in 2004 at $995 (U.S.) per year.

Zope is another open source web server. Although it is still relatively young and might not have as much flexibility as Apache, it is making strong inroads in the web server market.

What makes Zope different from Apache is the fact that it is managed through a completely web-based graphic interface. This has broad appeal for those who are not enthused about a command-line–only interface.

Zope is a product of the Zope Corporation (formerly Digital Creations), the same firm that made the Python programming language. And, like all things open source, it is free. Information on Zope can be found at both http://www.zope.com/ (for the commercial version) and http://www.zope.org/ (for the open source version).

Fedora sites can also use the Zeus Web Server from Zeus Technology. This server offers a scalable SSL implementation, security settings across multiple websites, and an online administration server. The current price is $1,700 for a host platform with up to two CPUs, but load balancing via the Zeus Load Balancer costs $12,000 for each pair of load-balancing computers.

You can get more information about the Zeus Web Server at http://www.zeus.com/products/zws/.