Page 153
Page 154
This chapter guides you through the installation and configuration of the Apache Web server using Red Hat's RPM system. Red Hat includes the current version of Apache with its overall Linux product. However, if the latest version of Red Hat Linux is a few months old, a more recent version of Apache can be found in the /pub/contrib area of Red Hat's FTP server. For information about the latest version of Apache, such as what bug fixes and new features have been added, see the Apache group's Web server, http://www.apache.org, or the Apache Week Web site at http://www.apacheweek.org.
The current version of Red Hat Linux, version 4.2, includes Apache version 1.1.3. The latest stable release of Apache available at the time of this printing is 1.2.4, and 1.3 is available in beta form. Version 1.2.4 is available in RPM format on Red Hat's FTP server.
There is a lag between the release of new and beta versions of Apache and its corresponding RPM packages. Installing Apache from source code is possible on Red Hat Linux, but is beyond the scope of this chapter because the installer has to either alter the directory structure of the workstation or imitate the directory structure of a previous Apache RPM.
The Apache RPM can either be found on the Red Hat Linux installation media or on the Red Hat FTP server. It can be installed like any other RPM with the command-line rpm tool or with glint, the X Window package management utility. To install the package using rpm, execute
rpm -i latest_apache.rpm
where latest_apache.rpm is the name of the latest Apache RPM.
| TIP |
If Apache has already been installed on your system, this command will fail. To force rpm to install the latest version, use this command:rpm -i --force apache-1.2.4-5.i386.rpm |
The Apache RPM installs files in the following directories:
Page 155
Apache reads its configuration settings from three files: access.conf, httpd.conf, and srm.conf. Primarily, this organization has been developed to maintain backward compatibility with the NCSA server, but the reasoning behind it makes good sense. The configuration files reside in the conf subdirectory of the server distribution. Backup copies of the configuration files are included in the software distribution; they are named access.conf-dist, httpd.conf-dist, and srm.conf-dist, respectively.
Runtime configuration of your server is done by way of configuration directives. Directives 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...
Directives are specified one per line. Some directives only set a value such as a filename; 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 </directive>
All sections are closed with a matching section tag that looks like </directive>. You will see some of these constructs in the conf/access.conf and in your conf/httpd.conf files. Note that section tags, like any other directives, are specified one per line.
httpd.conf contains configuration directives that control how the server runs, where its logfiles are found, the user ID (UID) it runs under, the port that it listens to, and so on. You need to edit some of the default configuration values to settings that make sense in your site. I kept most of the defaults found on my httpd.conf, with the exception of the following:
| ServerAdmin | The ServerAdmin directive should be set to the address of the Webmaster managing the server. It should be a valid e-mail address or alias, such as webmaster@your.domain. |
| Setting this value to a valid address is important because this address will be returned to a visitor when a problem occurs (see Figure 9.1). |
Page 156
| User and Group | The User and Group directives set the UID and group ID (GID) that the server will use to process requests. I kept these settings as the defaults: nobody and nogroup. Verify that the names nobody and nogroup exist in your /etc/passwd and /etc/group files, respectively. (They are provided by Red Hat Linux, so they should already be defined.) If you want to use a different UID or GID, go ahead; however, be aware that the server will run with the permissions you define here. The permissions for the specified UID and GID should be limited because, in case of a security hole, 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. Instead of specifying the User and Group directives using names, you can specify them by using the UID and GID numbers. If you use numbers, be sure that the numbers |