by Ted Brockwood

Serving Your Web Site

In a previous article here on WDJ, I covered how to get started building Web sites with Linux. I'm glad to say it's garnered quite a bit of interest, and much of that has been directed toward the mention of the Apache Web server.
October 11, 1999

The Apache Web server, for those of you who haven't heard of it, is arguably the most popular Web server in use on the Internet today. While Microsoft contends that its Internet Information Server (IIS) is making huge gains, it's still struggling in many ways against Apache. Why?

For starters, you don't have to be running Windows to run Apache. It was first developed on the various Unix/Linux/BSD platforms, then recently ported to Win32. Internet Information Server, while a very good Web server on the NT platform, is trapped in the "Windows-only" world. While IIS has many handy features, not everyone wants to run NT for their Web server's OS.

Another reason for Apache's widespread acceptance is its overall stability. While you can slow down an Apache Web server (especially if you run tons of PERL/CGI scripts on it), you can rarely, if ever, kill one. The Apache Web server service is near bombproof.

Lastly, it's relatively fast. I say "relatively" as it's relative to what you're doing with it. If you're hosting a pretty vanilla Web site with mostly static content, Apache is a fireball. If you throw tons of CGI scripts at it, while making database calls at the same time, you're going to slow it down. Though much of the slowdown will come from your scripts themselves, and not Apache.

Are you convinced yet? Ready to take the plunge? If you are, keep reading. This article is going to cover the basics of Apache configuration on Red Hat Linux 6.0, but fear not, most of the Apache configuration features are cross platform. That means that if you make a modification to Apache on Linux, that same modification, or one extremely similar, is available on other platforms, probably using the same syntax!

Getting Your Copy of Apache

Apache is available from http://www.apache.org. While you're downloading the Apache package that's appropriate for your Operating System, be sure to grab the documentation.

If you're a Linux user, the odds are in your favor that Apache has been pre-installed. With the exception of desktop-centric Linuxes such as Caldera, it's rare that you won't have the Apache server installed. During your Linux installation, if you see an option for "Web services" make sure to select it so that Apache will be installed.

FreeBSD users have the same joy in that Apache is normally pre-installed. While it's been some time since I've used any of the BSD variants, I recall they all did come with Apache.

If you're new to the Unix/Linux/BSD world, I should warn you about something. There are two types of installation packages - source and binary. If you're new to the Unix-ish world, try to download a binary format. A binary is the fully compiled version of the application that's ready to be installed on your system.

A source package is just that, it's the source code to the application. Which means you have to compile it into an executable program all by yourself. Heaven help you if you mess up while compiling an application. If you're fortunate, you'll find your error immediately. If you're unlucky, it could be hours, days or weeks before you find out, and then you have to spend time re-compiling it again to fix your mistakes. Do yourself a favor when first learning Apache - find the binary package for your OS. You can learn the finer points of compilation later.

Installation and Testing

Since installations on various operating systems can vary, I won't really cover that here. You should, once you've installed the Apache package, be able to run this simple test successfully.

First, open up your favorite Web browser. In my example, we'll use Netscape. Once your browser is open, try to go to location "http://localhost" or "http://127.0.0.1". This should return a Web page informing you of your success (see below)

If however, you don't see this welcome, you should ensure that you've loaded the Apache Web server service after installation. On Red Hat Linux 6.0 (and most other Linuxes) you can type: "/etc/rc.d/init.d/httpd start" (without the quotes). This should cause your system to pause for a few seconds, then return an "Ok". If, however, it reports that the service is already started, or that it cannot start the service, and you aren't getting the test results shown above, it's time for you to return to the Apache documentation.

Since I've mentioned how to start the service in the preceding paragraph, it's only fair I cover stopping the service. You'll want to stop the service if you make changes to Apache's configuration that you want to ensure take effect immediately. To stop the service on Red Hat 6.0 (and, again, on most other Linuxes) type: "/etc/rc.d/init.d/httpd stop" (without any quotes). This will cause your machine to pause for a few seconds, and report "Ok" to the stop request. Until you restart the service, no requests for Web pages can be made from your machine. So be sure to restart it after a stop! While that sounds pretty obvious, I've seen people forget to do it before (I'll take some credit for forgetting to restart at least once before, well, ok, maybe twice).

Configuration

Apache uses some rather easy to understand text files for configuration. On a Red Hat system, you'll find them in /etc/httpd/conf. Quite a few Linux distributions place them in this same place, but if you can't find such a directory, do a search for "httpd.conf" and/or "access.conf". Once you find these, you've found the main config files. If you're really new to Linux, and need help finding these files, maybe you shouldn't be tinkering with your Apache configuration. Just kidding, here's how you can find them.

1. Login as root (or su as the root operator)
2. cd /
3. find -name httpd.conf

When you move into the directory containing httpd.conf, you should see three files:

1. httpd.conf - This is the overall configuration for the server.
2. access.conf - all the security settings for Apache.
3. srm.conf - contains the MIME definitions and default document names for files on the server.

Now that you've found them, let's start with the main file, httpd.conf. Open it with any plain text editor. If you're on the Linux platform, try using the Pico editor. Whatever you open this with, make sure you save it as plain text - any special character formatting will make your Apache setup problematic. Generally, you only have to worry about non-text format problems on the Win32 (Win 95/98/NT) platform, as most other OSs will only write back to the file in plain text.

httpd.conf

The httpd.conf file holds the general configuration for your Apache server. If you have problems running Apache, odds are that there's something wrong in this file. While the whole file is very important, I'm just going to cover the "meat" of it, that is, settings you definitely should work on once you've installed Apache.

Servertype:

This is important for performance. You have two options here: inetd and standalone. With an inetd configuration, Apache is loaded on-demand. Your system waits for incoming Web page requests, and upon receiving one, fires up Apache. This is good for small, low-access sites, but can be murder if you have lots of traffic as the server keeps launching for every connection. Try inetd if you're just running the server on your local workstation as a test platform for new pages before moving them to your main server.

If you're going to be running a heavily-hit server, set it for standalone. Standalone Apache servers are always running, waiting to take incoming requests. This responds more quickly to requests, and doesn't bog down the server waiting for new requests. As the server is always in an "on" state, it will consume a little more memory than an inetd configuration, but this difference should be negligible.

HostNameLookups:

If you're going to be logging traffic on your server, feel free to turn this on but I have to warn you that this will slow down your server, sometimes rather heavily. Every time a request is made to the Apache server, it's going to do a lookup to match the incoming IP address to a hostname. Just imagine the overhead of running 1,000 lookups every few minutes and you'll see what I mean. If you are using a log analyzer that can perform its own lookups, turn this setting off. As a general rule, most users tend to leave HostNameLookups set to off.

ServerName

Apache assumes that your server's name on the network will be the same as that used on the Internet. If it's not going to be, then you can use this setting to change it to what users on the Internet will see.

For example, say the Web serving machine is called "bogo.manglor.com" on your network. Users on the Internet, however, are going to connect to it by going to "mojo.manglor.com". Then you would want to set the ServerName to "mojo.manglor.com" so incoming requests are properly routed.

Performance Settings

There are multiple performance settings you can activate in Apache. Each of these is designed to prevent slow user connections from hogging up all your server's resources. They can also be used to prevent things like Web spiders from hogging up all your resources.

Some of the Settings

Timeout

This is your general timeout setting, in seconds, before Apache kills the requests.

KeepAlive

KeepAlive is a function that allows a client to maintain a persistent connection. These can be a pain as someone may make thousands of requests through one connection, thus hogging all of your resources and making none available to other users. I'd recommend KeepAlive stay set to "On", but you use some of its other settings to tighten it down.

MaxKeepAliveRequests

Here is one way to tighten down KeepAlive. This function limits the number of available KeepAlive sessions. You can set it to 0, which means no KeepAlive connections if you wish, but that's the same as just turning KeepAlive "off". It is by default set to 100, which should be adequate to maintain performance for you and your users.

KeepAliveTimeout

As noted in the comments in httpd.conf, this is the time, in seconds, Apache will wait before launching the next KeepAlive request.

Server Pooling

Server pools are another way to maintain performance for your site visitors. At its simplest, a server pool setting is used by Apache to determine how many server processes it needs to run to handle incoming requests. Apache does this dynamically, although if you wish you may set a range for it.

SpareServers

There are two configurable settings here, a minimum and a maximum number of spare servers. These spare servers are used to handle traffic spikes, such as when one browser makes multiple requests all at once. SpareServers work as a sort of overflow handler, keeping Apache running smoothly, and visitors happy. In general, the defaults are good enough for most sites.

StartServers

This is the number of server processes Apache will launch when started. If you expect massive traffic, you can up this number. In theory , you really shouldn't need to change it, since Apache will dynamically add new servers as needed.

MaxClients

This is an incredibly important setting. This limits the number of clients that may ever be connected to your server simultaneously. Decrease this number at your own risk. One of the best reasons for using the MaxClients setting is to keep an out-of-control server from overwhelming the operating system's resources and taking everything down. Once the MaxClients number is reached, no new accesses can occur.

MaxRequestsPerChild

Another important setting, especially if you're running on an Operating System that is known to have memory leakage problems (Solaris is noted in the documentation as having a leak problem). This setting will limit the number of requests, or actions performed, by a client's connection. When this number is reached, the client connection ("child process") is flushed clean then reconnected. Users will not see anything happening, but you'll see it, since your server will not be killed by memory leakages.

What's Next

In the next segment of this series, we'll take a quick look at access.conf, especially using it to protect your server from being accessed by certain domains, and we'll look at actually adding content to your server. Finally, we'll cover creating user directories and virtual domains, which will allow your users to have their own Web pages, and even subdomains such as "mike.mydomain.org" and "suzie.mydomain.org".

Ted Brockwood is the Information Services Manager for a real estate listing service in Oregon. His experience covers Java, Linux, UNIX, NT, Win95/98, Win3.x, and DOS.