Certification Objective 7.01: Apache

 < Day Day Up > 

Apache is by far the most popular Web server today. Based on the HTTP daemon (httpd), it provides simple and secure access to all types of content, based on the regular HTTP protocol, as well as its secure cousin, HTTPS.

Apache is based on the server code developed by the National Center for Supercomputing Applications (NCSA). It included so many 'patches' it became known as 'a patchy' server. The Apache Web server continues to advance the art of the Web and provides one of the most stable, secure, robust, and reliable Web servers available. This server is under constant development by the Apache Software Foundation (www.apache.org).

While there are numerous other Web servers available, Apache is the only one described in the current curricula for RH133 and RH300. One alternative Web server is Tux, which you can configure separately. You can also configure it to work with Apache to optimize service for certain types of Web sites.

Apache is a service; basic Apache clients are Web browsers. Therefore, only those concerned with the RHCE should read this section. This provides the briefest of overviews on Apache. For more information, read the documentation online at httpd.apache.org/docs-2.0/, or Apache Server 2.0: The Complete Reference by Ryan Bloom (Mcgraw-Hill/Osborne, 2002).

Exam Watch 

If you're studying for the exam using Red Hat Linux 9, the version numbers of Apache RPM packages are slightly different. However, if you're careful, the results should be the same (as per the Red Hat Exam Prep guide, we're configuring the service for basic operation). There are defaults in some of the Red Hat Linux 9 versions of the Apache configuration files that you'll have to change or comment out in order to follow the discussion in this section.

Apache 2.0

Red Hat Enterprise Linux includes the latest major release of Apache. The version included with RHEL 3 is httpd-2.0.46-25.ent. While there are major differences with Apache version 1.3.x if you're a Web administrator or developer, the differences with respect to the RHCE exam are fairly straightforward. It supports the configuration for regular (HTTP) and secure (HTTPS) web services. Both are specified as requirements in the Red Hat Exam Prep guide.

  • New packages If you're installing Apache from the Red Hat Installation RPMs, all the package names have changed. As you'll see in the following section, most start with httpd. Strangely enough, the username associated with Apache services is now apache.

  • Modular directive files Basic directives, such as those based on Perl, PHP, or the Secure Socket Layer, are now configured separately in the /etc/httpd/conf.d directory.

  • Revised variables Some variables have changed in the httpd.conf configuration file. For example, Apache listens for computers that are looking for Web pages on port 80. You can now change that port with the Listen variable.

  • Virtual hosts Apache configuration is now normally based on virtual hosts, which allows you to host multiple Web sites on the same Apache server, using a single IP address.

You may see some of these characteristics if you use Apache 1.3.x; some of these features have been 'backported' from Apache version 2.0.x.


The RPM packages required by Apache are included in the Web Server package group. As you'd have to install a total of 33 RPM packages, it's probably more efficient to install these packages using the Red Hat Package Management utility. If you selected the Web Server package group with its defaults when you installed RHEL 3, you can continue to the next section.

Exam Watch 

If you know which of the 33 RPM packages you want to install, it may be slightly faster to install the Apache packages with the rpm command. However, if you use the Package Management utility, you can do other things while Apache is being installed.

Unless you have the Installation CDs available, you should start the Package Management utility, pointing to the networked source for the RHEL 3 installation files. If it's mounted on the /mnt/inst directory, you'd use the following command from a Linux GUI command line interface:

# redhat-config-packages --tree=/mnt/inst

For more information on this command, see Chapter 4.

Once the Package Management utility is open, select the Web Server package group. It's easiest to accept the defaults. As shown in Figure 7-1, when you select this package group, you'll be installing 27 RPM packages. In Red Hat Linux 9, there are fewer RPMs in the Web Server package group; the defaults still suffice.

click to expand
Figure 7-1: Installing from the Package Management utility

Starting on Reboot

Once Apache is installed, you'll want to make sure it starts the next time you boot Linux. If it doesn't start when the person who grades your Red Hat exam reboots your computer, you may not get credit for your work on the Apache service.

The most straightforward way to make sure Apache starts the next time you boot Linux is with the chkconfig command. You'll need to set it to start in at least runlevels 3 and 5, with a command such as:

# chkconfig --level 35 httpd on

To see if the chkconfig command worked, use the --list switch:

# chkconfig --list httpd

Normally to start services, it's best to use the associated script in the /etc/rc.d/init.d directory. There is an httpd script in that directory. However, Apache often starts and stops more gracefully with the following commands:

# apachectl stop # apachectl start

Once you've got Apache running, start a Web browser and enter a URL of http://localhost. If Apache installation is successful, you should see the screen in Figure 7-2.

click to expand
Figure 7-2: The default Apache Web page

When you read the screen, you will see that RHEL 3 looks for Web page files in the /var/www/html directory. You can verify this with the DocumentRoot variable in the main Apache configuration file. If you want to create a custom error page, you can set it in the /etc/httpd/conf.d/welcome.conf file.

Exercise 7-1: Installing the Apache Server

start example

In this exercise, you'll be installing all of the packages generally associated with the Apache server. Then you'll test and activate the result so that the Apache daemon, httpd, is active the next time you reboot Linux.

  1. Open the GUI in your computer. If you aren't already in a graphical login manager, you can do so with the startx command.

  2. Open a command line interface in the GUI. In the default GNOME desktop, right-click on the desktop and click New Terminal in the pop-up menu that appears. (In KDE, the Open Terminal command works as well.)

  3. Mount to the source of RHEL 3 installation files. Refer to Chapter 2 for more information. For the purpose of this exercise, we'll assume that you're mounting on the local /mnt/entr directory.

  4. Start the Red Hat Package Management utility. Make sure it reads from the RHEL 3 installation files with the following command:

    # redhat-config-packages --tree=/mnt/entr
  5. Locate the Web Server package group. Select it if required.

  6. Click Update. When you see the Completed System Preparation window, you may notice that there are more packages on the list than you selected in the Web server package group. Click Continue.

  7. When you see the Update Complete window, click OK. Click Quit to exit the Package Management utility.

  8. Back in the command line window, run the following command to see if Apache is already configured to start in any runlevels:

    # chkconfig --list httpd
  9. Now, use the following command to make sure Apache starts in runlevels 3 and 5 the next time you boot Linux:

    # chkconfig --level 35 httpd on
  10. Start the Apache service with the following command:

    # /etc/rc.d/init.d/httpd start
  11. Start a Web browser such as Mozilla or Konqueror. Navigate to http://localhost. You should see the default Apache Web page for Red Hat Enterprise Linux.

  12. Close your Web browser.

end example

The Apache Configuration Files

There are two key configuration files for the Apache Web server: httpd.conf in the /etc/httpd/conf directory and ssl.conf in the /etc/httpd/conf.d directory. The default version of these files create a generic Web server service you can further customize and optimize, as desired. There are other configuration files, as shown in Figure 7-3, in two directories: /etc/httpd/conf and /etc/httpd/conf.d.

click to expand
Figure 7-3: Apache configuration files

On The Job 

Previous versions of Apache, 1.3.x and below, required two other Apache configuration files in the same directory, access.conf and srm.conf. Even though these files were essentially blank in later versions of Apache 1.3.x, they were still required. These files are no longer required in any way in Apache 2.x.

The generic configuration file is httpd.conf. If you're required to configure a Secure Web server on the RHCE exam, you'll also need to configure the ssl.conf configuration file.

Basic Apache Configuration for a Simple Web Server

As described earlier, Apache looks for Web pages in the directory specified by the DocumentRoot variable. In the default httpd.conf file, this variable points to the /var/www/html directory.

In other words, all you need to get your Web server up and running is to transfer Web pages to the /var/www/html directory. The default DirectoryIndex variable looks for an index.html Web page file in this directory. You can test this for yourself by copying the default Mozilla home page file, index.html, from the /usr/share/doc/HTML directory.

If you have an iptables firewall on your computer, you'll need to disable it at least for TCP/IP port 80. Chapter 10 describes this process in detail.

The base location of configuration and log files are determined by the ServerRoot variable. The default value from httpd.conf is:

ServerRoot "/etc/httpd"

You'll note that the main configuration files are stored in the conf and conf.d subdirectories of the ServerRoot. If you run the ls -l /etc/httpd command, you'll find that Red Hat links /etc/httpd/logs to the directory with the actual log files, /var/log/httpd.

Analyzing the Default Apache Configuration

Apache comes with a well-commented set of default configuration files. In this section, we'll look at the key commands in the httpd.conf configuration file, in the /etc/httpd/conf directory. Browse through this file in your favorite text editor or with a command such as less. Before we begin our analysis, keep two things in mind:

  • If you configure Apache with the Red Hat HTTP tool (redhat-config-httpd), it overwrites any changes that you may have made with a text editor.

  • The main Apache configuration file incorporates the files in the /etc/httpd/conf.d directory with the following directive:

    Include conf.d/*.conf

There are a couple of basic constructs in httpd.conf. First, directories, files, and modules are configured in containers. The beginning of the container starts with the name of the directory, file, or module to be configured, contained in directional brackets (< >). Examples of this include:

<Directory "/var/www/icons"> <Files ~ "^\.ht"> <IfModule mod_mime_magic.c>

The end of the container starts with a forward slash. For the above examples, the end of the container would be:

</Directory> </Files> </IfModule>

Next, Apache includes a substantial number of directives, which are commands that Apache can understand that have some resemblance to English. For example, the ExecCGI directive allows executable CGI scripts.

Apache Security

You can modify the httpd.conf configuration file to secure the entire server or manage security on a directory-by-directory basis. Directory controls secure access by the server, as well as users who connect to the Web sites on the server. To explore the basics of Apache security, start with the first default active line in httpd.conf:

ServerTokens OS

This line looks deceptively simple; it limits what readers see about your Web server when you browse to a nonexistent page. If you don't use this command, outsiders can see if you've loaded modules such as Perl, Python, and PHP. Sharing this knowledge can make your system more vulnerable. You can restrict access to the root directory on your Web server, as shown below:

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

This configures a very restrictive set of permissions. The Options FollowSymLinks line supports the use of symbolic links for Web pages. The AllowOverride None line disables any .htaccess files. Otherwise, .htaccess can allow others to administer your server, starting from your computer's root directory.

You can improve this further by limiting access to all but desired users, such as those within your company, by adding the following commands to the <Directory /> container:

     Order deny,allow      Deny from all

The next excerpt limits access to /var/www/html, which corresponds to the default DocumentRoot variable:

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

You'll note that the Options directive has changed; the Indexes setting allows readers to see a list of files on your Web server if there is no index.html file in the DocumentRoot directory. The Order and Allow lines shown here allow all users to access the Web pages on this server.

Finally, the Listen directive defines the IP address and TCP/IP port for this server. For example, the default shown here means that this server will work with every computer that requests a Web page from any of the IP addresses for your computer on the standard TCP/IP port, 80.


If you have more than one IP address on your computer, you can use this directive to limit this Web server to one specific IP address. For example, if you've set up an intranet on this Web server, you could use the IP address that connects to your private network here.

If you're also setting up secure Web services, there's a second Listen directive in the ssl.conf file in the /etc/httpd/conf.d directory. The data from this file is automatically incorporated into your Apache configuration. It includes the following directive, which points to the default secure HTTP (HTTPS) port for TCP/IP, 443:

Exam Watch 

The Red Hat Exam Prep guide suggests that you need to be ready to configure a regular HTTP and a secure HTTPS Web server.

Virtual Hosts

Another useful feature of Apache 2.0 is its ability to manage Web sites using a single IP address. You can do so by creating multiple virtual hosts on the same Web server. You can configure virtual hosts for regular Web sites in the main Apache configuration file /etc/httpd/conf/httpd.conf. In that way, you can link multiple domain names such as www.example.com and www.mommabears.com to the same IP address on the same Apache server.

On The Job 

The www.example.com domain name cannot be registered and is officially reserved by the Internet society for documentation.

Exam Watch 

If you're required to create a virtual host for a secure Web site, you'll need a second NameVirtualHost directive for the HTTPS port, 443. These settings are already available in /etc/httpd/conf.d/ssl.conf.

You can also create multiple secure Web sites which conform to the HTTPS protocol, by configuring virtual hosts in the /etc/httpd/conf.d/ssl.conf configuration file. While the details vary, the basic directives that you'd use in this file are the same.

Section 3 of the default httpd.conf includes sample commands which you might use to create one or more virtual hosts. To activate the Virtual Host feature, you'll want to activate this line. If you're using a name-based host, leave the asterisk after this directive. Otherwise, set the IP address for your interface.

#NameVirtualHost *:80

It's often more reliable to substitute the IP address, as it avoids the delays sometimes associated with name resolution through a DNS server.

You should already know that TCP/IP port 80 is the default for serving Web pages. If you want to direct all requests to IP address on port 80, you can substitute <VirtualHost> for the first line shown below:

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

Don't forget to uncomment the commands shown by removing the # in front of each line. As you can see, it includes a number of directives from the main part of the configuration file. Here are the highlights of this container:

  • You'll want to substitute the Web server IP address and TCP/IP port for the asterisk (*) in the <Virtual Host *> command. The standard HTTP port is 80; the standard HTTPS port is 443.

  • Error messages are sent to the e-mail address defined by ServerAdmin.

  • The Web pages can be stored in the DocumentRoot directory.

  • Clients can call this Web site through the ServerName.

  • The ErrorLog and CustomLog files use the relative log directory-relative to the ServerRoot. In other words, you can find these files in the /etc/httpd/logs directory. As noted earlier, this directory is linked to /var/logs/httpd.

Substitute the IP addresses, domain names, directories, and e-mail addresses of your choice. Create the DocumentRoot directory if required. You can test the syntax of what you've done with the following command:

# httpd -t

and Apache will verify your configuration or identify specific problems. When you run this command on the default configuration, you'll get the following message:

httpd: Could not determine the server's fully  qualified domain name, using for ServerName Syntax OK 

This message is nothing to worry about during initial testing; it just notes that you haven't set a fully qualified domain name for the overall Web server through the ServerName directive.

Secure Virtual Hosts

If you're configuring a secure Web server, which conforms to the HTTPS protocol, Red Hat provides a different configuration file for this purpose: ssl.conf in the /etc/httpd/conf.d directory. If you don't see this file, you need to install the mod_ssl RPM. Before you begin editing this file, make sure the following Listen directive is active:


Later in this file, pay attention to the <VirtualHost _default_:443> container. You'll need to make sure that all of the directives between this line and the </VirtualHost> line at the end of the file are included in some way. If you accidentally leave out some of these commands, you'll end up with a nonworking Web server. You can replace _default_ in the VirtualHost container with the IP address of your local secure server.

Follow the same guidelines as described for the regular virtual host. Ideally, you should configure a DocumentRoot in a different directory. You'll also need to add an index.html file to this directory. One possible DocumentRoot directive is:

DocumentRoot /www/secure/dummy-host.example.com

You'll also need to add a ServerName directive, pointing to the secure HTTP port, 443. For the previously noted Virtual Host domain, that would lead to the following directive:

ServerName dummy-host.example.com:443

A Basic Web Page

You may need to create some index.html files. You could use Apache's default Web page. You can change this or any other Web page with a text- or HTML-specific editor. If you need to create a simple Web page during the exam, you don't have to use HTML tags. The Red Hat exams aren't intended to test your knowledge of HTML code.

Alternatively, you may be able to create a basic index.html page on the RHCE exam, as a simple text file. For example, you might save the following line in the text editor of your choice as index.html. You could then copy it to the appropriate DocumentRoot directory.

This is a simple Web page

Checking Syntax

You can also check the work that you've done to create virtual hosts with the following command:

# httpd -S

Assuming there were no problems, you should be able to start your Web server and connect to your local service with a browser request. (This command does not work in Red Hat Linux 9.)

The beauty of VirtualHost containers is that you can repeat the process. With name-based virtual hosting, you can set up as many Web sites on your Apache server as your computer can handle. All you require is one IP address. When you set up your new VirtualHost container, make sure to revise at least the ServerName, the locations of the log files, and the DocumentRoot.

Exam Watch 

Be prepared to create multiple Web sites on an Apache Web server using virtual hosts. If you're required to do so on your exam, create a separate VirtualHost container for this purpose.

Host-Based Security

You can add the Order, allow, and deny directives to regulate access based on hostnames or IP addresses. This basic command reads the deny directive first:

Order deny,allow

You can deny or allow from various forms of hostnames or IP addresses. For example, the following directive denies access from all computers in the osborne.com domain:

Deny from osborne.com

It's preferable to use IP addresses, so communication with a DNS server does not slow down your Web server. The following example directives use a single IP address; alternatively, you can set up the subnet in partial, netmask, and CIDR (Classless InterDomain Routing) notation:

Deny from Allow from 192.168.30 Deny from Allow from 

User-Based Security

You can limit access to your Web sites to authorized users with passwords. As I'll describe shortly, these passwords can be different from the regular password database on your Linux computer.

If you want to configure User-based security for the virtual Web site described earlier, you'll need to set up a <Directory> container for the directory specified by the DocumentRoot. In this case, it's /www/docs/dummy-host.example.com. You'll want several commands in the <Directory> container:

  • To set up basic authentication, you'll need an AuthType Basic command.

  • To describe the site to requesting users, you can include an AuthName 'some comment' command.

  • To refer to a Web server password database named /etc/httpd/webpass, you'll need a AuthUserFile /etc/httpd/webpass command.

  • To limit the site to a single user named engineer1, you could add a Require user engineer1 command.

  • Alternatively, to limit the site to a group as defined in /etc/httpd/webgroup, you'd add the AuthGroupFile /etc/httpd/webgroups command. You'll also need a Require group Design command, where Design is the name of the group specified in webgroups.

Here's an example of code that I've added after the <Virtual Host> container:

<Directory "/www/docs/dummy-host.example.com">      AuthType Basic      AuthName "Internal Use Only"      AuthUserFile /etc/httpd/webpass      Require user michael </Directory>

When properly configured, the next time you try accessing the dummy-host.example.com Web site in the Mozilla browser, you're prompted for a username and password, as shown in Figure 7-4.

click to expand
Figure 7-4: A secured Web site

Configuring Web Passwords

To configure passwords for a Web site on your server, you need to create a separate database of usernames and passwords. As the useradd and passwd command is used for regular users, the htpasswd command is used to set up usernames and passwords for your Web server.

For example, if you want to create a database file named webpass in the /etc/httpd directory, you'd start with the following command:

# htpasswd -c /etc/httpd/webpass engineer1

The -c switch creates the specified file, and the first user is engineer1. You're prompted to enter a password for engineer1. Users in the webpass database do not have to have a regular account on your Linux computer.

Once you've created the database file, you can add to it without the -c switch; for example, the following command prompts you for a password for drafter1 before adding it to your webpass database:

# htpasswd /etc/httpd/webpass drafter1

To set up access for more than one user, you'll also need a group file. For the example described in the previous section, you can set up a webgroup file in the same directory with the following line of users:

Design: engineer1 drafter1 lead1

Web Access to Home Directories

One useful option through Apache is access to users' home directories. If you change the following directive from UserDir disable to:

UserDir public_html

anyone will have access to Web pages that a user puts in his or her ~/public_html directory. For example, if you have a user named michael, he can create a /home/michael/public_html directory, and add the Web pages of his choice.

However, this requires a bit of a security compromise; you need to make michael's home directory executable for all users. This is also known as 701 permissions, which you can configure with the following command:

# chmod 701 /home/michael

Control Through .htaccess

There is a way to override inherited permissions in any subdirectory. If you're willing to set the following command in the <Directory> containers of your choice:

AllowOverride Options

you can configure .htaccess files to override previously set permissions. In this way, you can customize permissions on different virtual hosts. For example, you can configure an intranet site limited to your employees and an Internet site for general access on the same Apache server.

You can store an .htaccess file in every Web directory. While you can configure all types of Apache directives in this file, the Red Hat Exam Prep guide suggests that all you need to do is configure host-based and user-based security for the service.

Options and .htaccess

There are many ways to activate the Options directive. The simplest two are Options None and Options All. They would do the following:


For no custom options in force


Allows all options except MultiViews

You can also set finer options with keywords. Some examples include:


Permits Web pages to run CGI scripts


Permits symbolic links to directories outside of DocumentRoot


Allows server-side includes


Permits FTP-style directory indexing

The Indexes directive controls directory indexing, which is the name for file lists that are generated automatically by Apache.

Executable Files in Apache

You have many different ways to set up Apache resources. Some might be available in different languages, different media types, or more. When you set up multiple resources, Apache can choose depending on the browser-supplied preferences for media type, languages, character set, and encoding.

You can use the ScriptAlias variable for directories with executable CGI files. An Alias variable essentially links one file or directory to another. The ScriptAlias variable links the default cgi-bin directory to /var/www/cgi-bin. You can set up CGI scripts in a different directory and change the reference accordingly.

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

This excerpt from the default /etc/httpd/conf/httpd.conf file first identifies the directory with server scripts. The user apache is allowed to run these scripts. Permissions for others are adjusted through the <Directory /var/www/cgi-bin> container. The AllowOverride None command prevents regular users from changing permissions/settings in that directory. Otherwise, smarter users could read the CGI files in your directory, potentially compromising the security of your Web server. The Options None line prevents other users from running CGI scripts in the given directory. The Order allow,deny command sets up authorization checks; Allow from all lets all users run scripts in this directory.

The Alias /manual '/var/www/manual' command allows clients to read documentation stored in the /var/www/manual directory. If the name of your Web site is www.example.com, the alias allows clients to read the documentation by navigating to www.example.com/manual.

The Alias /icons/ '/var/www/icons' command identifies a directory for icons on your Web site. If the name of your Web site is www.example.com, you can set up the icons in HTML code on your page in the www.example.com/icons directory. You can then store the icons on your computer in the /var/www/icons directory.

Finally, you can add access control for any other directories available via your Web interface. Just wrap the directory you wish to control in a <Directory /path/to/dir>. . . </Directory> container and set the access restrictions you need. The command shown below applies the Deny directive first:

<Directory /path/to/your/directory/goes/here/>     Options Indexes FollowSymLinks     Order deny,allow     Deny from .evil.crackers.net     Allow from .yourdomain.net </Directory>

Apache Log Files

As described earlier, the log files in httpd.conf are configured in the /etc/httpd/logs directory. It's linked to /var/logs/httpd. Access to your Web server is logged in the access_log file; errors are recorded in the error_log file. If you want more detail about your Web site for tuning or statistical reasons, you can have the Web server generate more information, generate separate log files for each virtual Web site, and create new log files at different frequencies (such as daily, weekly, or monthly).

There are standard log file formats. For more information, take a look at the LogFormat directive as shown in Figure 7-5. Four different formats are shown: combined, common, the referrer (the Web page with the link used to get to your site), and the agent (the user's Web browser). The first two LogFormat lines include a number of percent signs followed by lowercase letters. These variables determine what goes into the log.

click to expand
Figure 7-5: Customized Apache logs

You then use the CustomLog directive to select a location for the log file (for example, logs/access_log) and which log file format you wish to use (for example, common). For more information on log files and formats, refer to httpd.apache.org/docs-2.0/logs.html.

On The Job 

Some Web hit log analyzers have specific requirements for log file formats. For example, the popular Open Source tool awstats (advanced Web Stats) requires the combined log format. It will fail to run if you leave the default common format. Awstats is a great tool for graphically displaying site activity. You can download it from a site such as www.sourceforge.net.

Apache Troubleshooting

When you install the right Apache packages, the default configuration normally creates a running system. But if you're setting up a real Web site, you probably want more than just the test page. Before you start changing the configuration, back up the httpd.conf Apache configuration file. If something goes wrong, you can then always start over. Some Apache errors fall into the following categories:

  • Error message about an inability to bind to an address Another network process may already be using the default http port (80). Alternatively, your computer is running httpd as a normal user (not the user apache) with a port below 1024.

  • Network addressing or routing errors Double-check your network settings. For information on configuring your computer for networking, see Chapter 4.

  • Apache isn't running Check the error message when you use the apachectl command to start or restart the Apache server. Check the error_log in the /var/log/httpd directory.

  • Apache isn't running after a reboot Run chkconfig --list httpd. Make sure Apache (httpd) is set to start at runlevels 3 and 5 during the boot process with the following command:

    # chkconfig --level 35 httpd on
  • You need to stop Apache Send the parent process a TERM signal, based on its PID. By default, this is located in /var/run/httpd.pid. You kill Apache with a command such as:

    #kill -TERM `cat /var/run/httpd.pid`

Alternatively, you can use the apachectl stop command.

Exercise 7-2: Updating a Home Page

start example

In this exercise, you'll update the home page associated with your Web site on the Apache server. You can use these techniques to copy the actual HTML formatted pages that you'll need for your Web site.

  1. Start the Apache Web server with the default configuration.

  2. Copy an HTML file such as /var/www/error/noindex.html to /var/www/html/index.html.

  3. Edit the file /var/www/html/index.html.

  4. Change the title of the page to reflect your personal or corporate name.

  5. Use a Web browser such as Mozilla to connect to localhost (or

end example

On The Job 

Apache administration is a necessary skill for any Linux system administrator. You should develop the ability to install, configure, and troubleshoot Apache quickly. You should also be able to set up and customize virtual Web sites, which will make you a more effective Webmaster. You can test your skills using the exercise that follows.

Exercise 7-3: Set Up a Virtual Web Server

start example

In this exercise, you'll set up a Web server, with a virtual Web site. You can use this technique with different directories to set up additional Web sites on the same Apache server.

  1. Back up your httpd.conf file.

  2. Add a virtual Web site for the fictional company SnoBard, called www.snobard.net.

  3. Create a DocumentRoot directory called /snobard. (Don't forget to create this directory on your system as well.)

  4. Open the /snobard/index.html file in your text editor. Add a simple line in text format such as:

    This is the placeholder for the SnoBard Web site.
  5. Save this file.

  6. Open the browser of your choice. Test access the configured Web site (www.snobard.com) and the Web site on the localhost computer.

end example

The Red Hat httpd Configuration Tool

Red Hat has recently introduced its own graphical configuration tool for Apache, redhat-config-httpd, which you can install from the RPM of the same name. Before using this tool, back up your current /etc/httpd/conf/httpd.conf configuration file. Any changes that you make with this tool overwrite this file.

You will find that redhat-config-httpd is a straightforward tool, with four different tabs that can help you configure the httpd.conf configuration file. You can also open this tool in the GUI with the Main Menu | System Settings | Server Settings | HTTP command. However, you cannot use it to edit the ssl.conf configuration file, and therefore should not use it to create a secure (HTTPS) Web server.

However, it may be useful to practice creating virtual hosts with this utility, so I've described the tabs shown in Figure 7-6 here:

click to expand
Figure 7-6: The Apache configuration tool, Main tab

  • Main The Main tab allows you to set basic parameters for your Apache server, including the ServerName, the Webmaster e-mail address, and the Listen variable.

  • Virtual Hosts The Virtual Hosts tab permits you to set the properties for different Web sites that you host on your Apache server. This includes the DocumentRoot, basic HTML filenames and locations, SSL support, basic log file configuration, CGI script variables, and default directories.

  • Server The Server tab enables you to set the basic lock and PID files, as well as the user and group associated with the httpd service. In most cases, you should not have to change these settings.

  • Performance Tuning The Performance Tuning tab allows you to set basic connection parameters.

Even if you do master this tool for configuring a regular Web server, you'll still need to manually edit the ssl.conf file to create a secure Web server. And I believe that it's easier to learn and faster to edit the Apache configuration file, /etc/httpd/conf/httpd.conf, directly in a text editor. Remember, time may be of the essence when you take the RHCE exam.

 < Day Day Up > 

RCHE Red Hat Certified Engineer Linux Study Guide[c] Exam (Rh302)
RCHE Red Hat Certified Engineer Linux Study Guide[c] Exam (Rh302)
ISBN: 71765654
Year: 2003
Pages: 194

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net