Apache Server Survival Guide asg02.htm

Previous Page TOC Next Page

2


Installing and Configuring the Apache Server


This chapter guides you through the installation and configuration of Apache using a basic setup. You will find the latest stable server software, as well as the latest beta releases of the Apache source distribution, on the Apache group's Web server ( http://www.apache.org). A copy of the latest release available at the time this book was written (Apache 1.1.1) is included on the CD-ROM that accompanies this book.

If you don't have access to a compiler, you can still install Apache provided that you can find a precompiled version of the server that works with your hardware and operating system. I have included the precompiled servers I found at the Apache group's Web server, including AUX 3.1, BSDI 1.1 and 2.0, FREEBSD 2.1, HPUX 9.07, IRIX 5.3, Linux, NETBSD 1.1, SOLARIS 2.4, SunOS 4.1.3, and UNIXWARE 1.1.2., and others.

Fig. 2.1 The Apache home page. Notice this site is mirrored around the world.


The Apache site provides links to various mirror sites from which you can download the software. Choose the one that is geographically closest to you from the various sites listed on the Apache home page.

To install Apache in its default location at /usr/local/etc/httpd, you may need to be the superuser. You'll need to know the root password of the machine in which you are installing Apache. If you don't know how to become root, please contact your local system administrator. Put the distribution archive in the /tmp directory. A sequence of commands to do the installation from /tmp might look like this: 


mkdirs /usr/local/etc (your system may use 'mkdir -p /usr/local/etc' instead)

cd /usr/local/etc

mv /tmp/apache_1.1.1.tar.gz /usr/local/etc

gzcat apache_1.1.1.tar.gz | tar -xf -

mv apache_1.1.1 httpd

If your system does not support gzcat, you may need to do a gunzip -c instead.

Note that depending on the version you are installing, you will be left with a directory called apache_x.x.x. Now you should have a tree under httpd that contains the complete distribution of Apache. This directory tree contains configuration templates and other resources that the server needs for its operation. Be sure not to move or rename any of the files and directories, unless you know what you are doing.

Installing a Precompiled Server


Apache has been compiled for many platforms, and chances are that a prebuilt copy of the server exists for your setup. If you are interested in compiling the source, you might want to skip to the section in this chapter titled, "Installing from the Source" because it offers information on how to build the Apache HTTP server.

Installing a precompiled server is very similar to installing a source-only distribution. The only difference is that a compiled httpd binary already exists in the server's src directory. The compiled binary of the Apache server is called httpd. On binary distributions, the binary is usually labeled httpd-architecture, where architecture is the name of the OS you are installing. For Linux, the httpd binary is called httpd-linux.

Although it is perfectly fine to keep the binary in the src directory, I like to install the binary at the top of the distribution tree. In this example, that is /usr/local/etc/httpd/httpd. Sometimes, the binary distribution has not been stripped. Stripping removes extra symbol information that the linker left from the compilation linking process. Removing this extra information using strip usually makes the binary about 30 to 40 percent smaller. I also like to protect the executable from any user trying to alter it. An easy way to do this is by changing the owner and group of the executable to root and the group to wheel. Then remove all write privileges to the binary from everyone but the owner. To chown and chmod a file (change owner and change mode) to root, you need to do this as the superuser. The following installation steps might look something like this:

  1. 1. cd /usr/local/etc/httpd

  2. 2. cp src/httpd-linux httpd

  3. 3. strip httpd

  4. 4. chown root.wheel httpd

  5. 5. chmod 755 httpd

If you are installing a precompiled server, you can skip to the section titled, "Runtime Server Configuration Settings."

Installing from the Source


Installing from the source is a little more time-consuming, but it will force you to get familiar with the source distribution of the Apache server. It will also give you the opportunity to customize the modules that are built into Apache. Many of these modules provide functionality that will make your server more powerful. All the files you will need to edit to build the binary are in the src directory. Building from the source is a three-step process:

  1. 1. Edit the one-time configuration file, src/Configuration.

  2. 2. Run the Configure script.

  3. 3. Run make.


Editing the Configuration File


Before you can compile the software, you need to edit the configuration file and set some compile-time options that address the peculiarities of your operating system (and, in some cases, the hardware on which you are going to be running the server). Apache supports the concept of modules that extend and enhance the functionality of the server. However, in order for some of these modules to work, they have to be enabled in the configuration file. The configuration file can be found in /usr/local/etc/httpd/src. To make a copy of the configuration file, type in the following: 


cd /usr/local/etc/httpd/src

cp Configuration.tmpl Configuration

Using your favorite editor, read and edit the configuration file you just created. A listing of the default configuration files is included at the end of this chapter for your reading enjoyment.

I kept all the default settings with the exception of changing the compiler and compilation options to match my hardware and operating system. This is executed by removing the comments (the # signs) from the AUX_CFLAGS and AUX_LIBS defines found on the configuration file. Remember to comment out (put in a #) in front of other settings that may not apply to your system configuration.

Running the Configure Script


After you edit the configuration file, you need to run the Configure script. The Configure script is a Bourne shell script that uses the configuration file you edited (src/Configuration) to generate a new Makefile and modules.c to match the options you set in the compilation configuration file. To do this, type the following into your terminal program: 


cd /usr/local/etc/httpd/src

./Configure

Configure allows you to specify a configuration file on the command line by using the -file flag:
Configure -file NEXTSTEP.configuration
Using alternate config file NEXTSTEP.configuration
This feature is useful if you need to maintain various different configurations for several different machines.

Running make


If Configure proceeded normally, you should be able to build the server binary at this point. To build the binary, type this on your terminal: 


make

After a few minutes, depending on the speed of your hardware, you will have a compiled version of the Web server. It is called httpd and is on the /usr/local/etc/apache/src directory. The current version of the Apache source code does not have an install target for make, so you'll have to copy and strip the executable by hand: 


cp httpd ../httpd

cd ..

strip httpd

chown root.wheel httpd

chmod 755 httpd

Runtime Server Configuration Settings


Apache reads its configuration settings from three files: access.conf, httpd.conf, and srm.conf. Primarily, this has been done to maintain backward compatibility with the NCSA server, but the reasoning behind this organization makes good sense. The configuration files reside in the conf subdirectory of the server distribution. Sample configuration files are included in the software distribution; they are named access.conf-dist, httpd.conf-dist, and srm.conf-dist, respectively. You will need to create copies of these files without the -dist portion: 


cd /usr/local/etc/httpd/conf

cp httpd.conf-dist httpd.conf

cp access.conf-dist access.conf

cp srm.conf-dist srm.conf

After you've made your local copies, you are ready to configure a basic server.

Runtime configuration of your server is done by way of configuration directives. Directives are commands that set some option; 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. There are special directives, called sections, that 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 directive, are specified one per line.

Editing httpd.conf


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

Figure 2.2. One of the error messages the server returns if there's an error. Note that the ServerAdmin was set to alberto@accesslink.com.
ServerAdmim 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 to a valid address is important because this address will be returned to a visitor when there's a problem.
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 to the defaults: nobody and nogroup. Please verify that the names nobody and nogroup exist in your /etc/passwd and /etc/group files, respectively. 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 very low because, in case of a security hole, whether on the server or (more likely) on your own CGI programs, those programs will run with the assigned UID. If the server runs as root or some other privileged user, someone may exploit the security holes and do nasty things to your site. Instead of specifying the User and Group directives using a name, you can specify them by using the UID and GID numbers. If you use numbers, be sure that the numbers you specify correspond to the user and group you want, and that they are preceded by the pound (#) symbol.

Here's how these directives would look if specified by name: 


User nobody

Group nogroup

Here's the same specification, but by UID and GID: 


User #-1

Group #-1

ServerName The ServerName directive sets the hostname the server will return. Set it to a fully qualified domain name (fqdn). If not set, the server will try figure it out by itself and set to its canonical name. However, you may want the server to return a friendlier address such as www.your.domain. Whatever you do, ServerName should be a real Domain Name System (DNS) name for your network. If you are administering your own DNS, remember to add a CNAME alias for your host. If someone else manages the DNS for you, ask her to do this for you. Your ServerName entry should look like this: ServerName www.your.domain

If you would like to install a Web server for test purposes on a standalone machine, you can do so by specifying a ServerName of localhost. You can then access the server as http://www.localhost from within the standalone machine. This may be a useful thing to do for trying out new configurations or Internet Web servers.
ServerRoot This directive sets the absolute path to your server directory (where your httpd binary is located). This directive tells the server where to find all the resources and configuration files. Many of these resources are specified in the configuration files relative of the ServerRoot directory. If you installed your server using my examples, your ServerRoot directive will read: ServerRoot /usr/local/etc/httpd

Editing srm.conf


The srm.conf file is the resource configuration file. It controls settings related to the location of your Web document tree, the CGI program directories, and other resource configuration issues that affect your Web site. I kept most of the defaults found on my srm.conf. The most important directives on this configuration file are
DocumentRoot Set this directive to the absolute path of your document tree. Your document tree is the top directory from which Apache will serve files. By default it is set to /usr/local/etc/httpd/htdocs.

You may also want to set the UserDir directive to disabled. The UserDir directive defines the directory relative of a local user's home directory where they will put public HTML documents. It's relative because each user will have a public_HTML directory. Although this may give users at your site the freedom to create and maintain their own home pages, many users may not be aware of this fact, resulting in the possibility of their creating a public_html directory that contains private files. Additionally, depending on the kind of users in your system and the server configuration, this may create potential security problems. It would make it possible for a user to publish your entire filesystem by creating a symbolic link to a directory outside of a Web document tree. By doing this, anyone would be able to read and navigate your filesystem freely.

Chapter 16, "Web Server Security Issues," discusses alternatives for providing this functionality that I feel are better from a security and maintenance standpoint.

A copy of the boilerplate conf/srm.conf file has been included at the end of this chapter.

Editing access.conf


I kept all the defaults found in my access.conf file. access.conf is the global access control file; it configures the type of access users have to your site and the documents you make available, as well as security issues defining the extent to which users may alter the security settings you may have defined. The default configuration provides unrestricted access to documents in your DocumentRoot.

If you want to provide a more restrictive site, you may want to verify that all <Directory path> sections match the directories they list in your installation. The Directory sections specify a set of options, usually involving security issues, on a per-directory basis. In particular, you may want to remove the Indexes option that follows the Options directive on the section that looks like this: 


<Directory /usr/local/etc/httpd/cgi-bin>

Options Indexes FollowSymLinks

</Directory>

The Indexes option allows for server-generated directory listings. You probably don't want anyone peeking at the contents of your cgi-bin directories.

Options that you implement on your global ACT can be overridden by the use of an .htaccess file. You can disable all .htaccess overrides by setting the directive AllowOverride to None, which is by default set to allow all overrides: 


AllowOverride None

I discuss access control and security in Chapter 15, "Access Control and User Authentication."

Configuring an inetd Server


Normally, Apache runs in standalone mode or daemon mode. How it is run by the system depends on how it is configured by the ServerType directive in conf/httpd.conf.

A standalone server offers superior performance over inetd-run servers because usually there will be a server process ready to serve a request. When run under inetd (the Internet daemon), a new server is started every time a request is received on the HTTP port. There is a considerable amount of overhead in starting a new server process with each new request.

The default setting for ServerType is standalone; unless you have an extremely light traffic site, you should stick with this setting. inetd servers are good for information you want available, but to which you don't want to dedicate a computer.


inetd servers are great for testing configuration settings because the server rereads all its settings every time there's a request. On standalone servers, you need to manually restart the server before it sees any changes you made to the configuration files.

To run a server from inetd, you'll need to modify conf/httpd.conf once more and change the ServerType directive from standalone to inetd: 


ServerType inetd

The Port directive has no effect on an inetd server. A standalone server uses this configuration information to learn which port it should be listening to. Because inetd does the binding between the port and the software, this setting has no effect on an inetd configuration.

Configuring inetd


inetd is the "Internet superserver." It gets started when the machines boots by /etc/rc. Once launched, inetd listens for connections on Internet socket ports. When it finds a connection, it starts up the program responsible for managing that port. When the request is served and the program exits, inetd continues to listen for additional requests on that port.

To make Apache work from inetd, you need to edit /etc/inetd.conf and /etc/services. Configuring an inetd server requires a bit more system configuration than a standalone server.

First, you need to edit your /etc/services file. The /etc/services database contains information about all known services available on the Internet. Each service is represented by single line listing the following information:

      Official service name

      Port number

      Protocol name

      Aliases by which the service is known

Each entry is separated by a tab or spaces. An entry describing httpd will look like this: 


http portnumber/tcp httpd httpd

UNIX ports range from 0 to 65,535; however, the first 1,024 ports are reserved. A reserved port means that only processes owned by the superuser will be able to bind to them; if you want to run the server at port 80 (the default for httpd), httpd will need to be started by the superuser.

Set portnumber to the port number on which you want to run the server. Typically this will be port 80 for a standalone server. inetd servers run better at port 8080, so your entry will look like this: 


http 8080/tcp httpd httpd

If you are running NetInfo, you can type this line into a temporary file, such as /tmp/services, and then run 


niload services . < /tmp/services

Next, you need to edit /etc/inetd.conf to configure inetd to listen for httpd requests. Each line in inetd.conf contains the following information:

      Service name

      Socket type

      Protocol

      Wait/no wait

      User the server program will run as

      Server program

      Server program arguments

My completed entry looks like this: 


httpd stream tcp nowait nobody /usr/local/etc/httpd/httpd httpd -f /usr/ local/etc/httpd/conf/httpd.conf











The previous example will start the server as nobody. Typically, you will want a standalone server to be started by the root user so that the server is able to bind to port 80, the standard HTTP port, and be able to change the UID and GID of its children processes. When the standalone server starts up, it forks children processes. These children processes run with a UID of nobody and a GID of nogroup unless you specified a different setting with the User and Group directives. The children processes are the ones that handle HTTP requests. The main process, owned by root, has as its duty the creation and destruction of its children processes. This makes the standard, standalone server secure.


If you specify the root UID in this example with the intention of running the inetd server on port 80, the process handling the request is owned by root. This may create security problems; unlike a standalone server, the inetd server doesn't fork any children processes, so it handles requests with the UID and GID of the process owner.










After adding the httpd entry to /etc/inetd.conf, you'll need to restart inetd. You can easily do this by finding out the inetd process number with ps and sending it a HANGUP signal:









# kill -HUP InetdProcessID



Replace the InetdProcessID with the process number listed by the ps command. If the PID listed was 86, you would type kill -HUP 86.





inetd will restart, rereading its configuration file that will instruct it to listen for request for port 8080.
















Running the Web Server for the First Time






Before you can run the server for the first time, you need to create an HTML document. The standard Apache distribution includes such a file, but I have created another which is more useful and I am sure that you'll use time and again. Using your favorite text editor, create a file called index.html inside the htdocs directory with this content:







<HTML>

<HEAD>

<TITLE>Apache Server Survival Guide</TITLE>

</HEAD>

<BODY BGCOLOR="#ffffff" LINK="#000080"
VLINK="#000080">

<H1><CENTER>Apache Server Survival
Guide </CENTER></H1>

<H2><CENTER>Congratulations! Your Apache server
was successfully installed.</CENTER></H2>

<H3>Here are some interesting sites that host information about

the Apache server: </H3>

<UL>

<LI>The official homepage for the

<A HREF="http://www.apache.org">Apache Group</A>

<LI>The official homepage for

<A HREF="http://www.us.apache-ssl.com">Community
Connexion</A>

developers of Stronghold: Apache-SSL-US (A Netscape compatible

SSL server based on Apache)

<LI>The official homepage for 

<A HREF="http://www.algroup.co.uk/Apache-SSL">Apache-SSL</A>

(A Netscape compatible SSL server based on Apache - only available

to users outside of the United States).

<LI><A HREF="http://www.zyzzyva.com/server/module_registry/">

Apache Module Registry</A>, the place where you can find information

about 3<SUP>rd</SUP> party Apache modules

and other development stuff.

<LI><A HREF="http://www.apacheweek.com">The Apache Week Home</A>,

here you will find an essential weekly guide

dedicated to Apache server nformation.

<LI><A HREF="http://www.ukweb.com">UK Web's
Apache Support Center</A>

<LI><A HREF="http://www.fastcgi.com">The FastCGI
Website</A>

</UL>

<P>

<STRONG>Deja News a very handy USENET news search
engine:</STRONG>

<FORM ACTION="http://search.dejanews.com/dnquery.xp"
METHOD=POST>

<P>

<CENTER>

<STRONG>Quick Search For:</STRONG> <INPUT
NAME="query" VALUE="Apache"
SIZE="37">

<INPUT TYPE="submit"
VALUE="Search!"><INPUT NAME="defaultOp"
VALUE="AND" TYPE="hidden">

<INPUT NAME="svcclass" VALUE="dncurrent"
TYPE="hidden">

<INPUT NAME="maxhits" VALUE="20"
TYPE="hidden">

</CENTER>

</FORM>

</BODY>

</HTML>




Put this file in your htdocs directory. At this point you are ready to test the server.





[ic:CD-ROM]The machine-readable text for the file you just created is included in server/setup/index.html, and it should be placed in DocumentRoot/index.html.















Starting Up a Standalone Server






If you are running a standalone server, you'll need to start httpd manually. This is how you do it:









# /usr/local/etc/httpd/httpd -f /usr/local/etc/httpd/conf/httpd.conf



Please note that I started the standalone server from the root account, indicated by the pound sign (#) at the beginning of the line. Standalone servers need to be started by root so two important things happen:





    


  • If your standalone server uses the default HTTP port (port 80), only the superuser can bind to Internet ports that are lower than 1025.


    


    


  • Only processes owned by root can change their UID and GID as specified by the User and Group directives. If you start the server under another UID, it will run with the permissions of the user starting the process.


    


    
















Starting Up an inetd Server






As you probably guessed, you don't need to start an inetd server. inetd will start httpd every time a request is received in the port assigned to the server. inetd servers make good development platform because configuration settings are reread every time you send a request.















Starting and Stopping the Server






The Apache server, httpd, has a few command-line options you can use to set some defaults specifying where httpd will read its configuration directives. The Apache httpd executable understands the following options:









httpd [-d ServerRoot] [-f ConfigurationFile] [-x] [-v] [-?]



The -d option overrides the location of the ServerRoot directory. It sets the initial value of the ServerRoot variable (the directory where the Apache server is installed) to whatever path you specify. This default is usually read from the ServerRoot directive in httpd.conf:





The -f flag specifies the location of the main configuration file, conf/httpd.conf. Reads and executes the configuration commands found on ConfigurationFile on startup. If the ConfigurationFile is not an absolute path (doesn't begin with a /), its location is assumed to be relative of the path specified in the ServerRoot directive in httpd.conf. By default, this value is set to ServerRoot/conf/httpd.conf.





The -x option is used by the developers of Apache as a debugging aid and should not be used under normal server operation. It runs a single server process that does not create any children.





The -v option prints the development version of the Apache server and terminates the process.





The -? option prints the following usage information for the server:






Usage: httpd [-d directory] [-f file] [-v]

-d directory : specify an alternate initial ServerRoot

-f file : specify an alternate ServerConfigFile














The start Script






I have developed a small start script that launches the server with all the command-line settings I use. This script saves me a little typing when I'm trying things that require me to start and stop the server.





You can create this script by just typing it into a file (one per script). When you are done entering it, to turn it into executable, type:






cd WhereEverYouEnterThem

chmod 755 start stop restart



You may want to store the script in a place where it is convenient, such as /usr/local/bin. Here's the listing for the start script:






#!/bin/sh

/usr/local/etc/httpd/httpd -f /usr/local/etc/httpd/conf/httpd.conf













The stop Script






The server is designed to stop gracefully when its sent a TERM (terminate) signal. Because when the server starts it spawns several children processes, it becomes a little more difficult to terminate. Apache automatically kills any children processes when the main process is killed. Luckily, the developers of Apache put the process ID of the main process in a file where you can easily obtain the ID of the process. My stop script makes use of the PidFile (/usr/local/etc/httpd/logs/PidFile) file.





This is the listing to the stop script:






#!/bin/sh

#Stop Apache Script

kill 'cat /usr/local/etc/httpd/logs/httpd..pid'














The restart Script






The server is designed to restart if it receives a -HUP (hangup) signal. On receiving this type of signal, the server stops and immediately restarts, rereading its configuration files.





Here's the listing for the restart script:






#!/bin/sh

#Restart Apache Script

kill -HUP 'cat /usr/local/etc/httpd/logs/httpd.pid'



This is a very convenient script that automates the process. Any time you modify any of the configuration files, you need to restart the server to enable the changes. htrestart makes this easy to do.















Auto-Starting the Web Server at Boot Time






You may be interested in automating the startup process of the server whenever you boot your machine. Doing so is very easy. On your /etc/rc.local file, add an entry like this:






#

# Run httpd server automatically

#

echo 'starting httpd server'

if [ -f /etc/rc.httpd ]; then

 sh /etc/rc.httpd

fi



Create a new file, /etc/rc.httpd, with the following contents:






#!/bin/sh -u

#

cd /usr/local/etc/httpd/

./httpd -d /usr/local/etc/httpd/ -f conf/httpd.conf



Although you can put the commands in /etc/rc.httpd in your /etc/rc.local, I find it convenient to be able to disable the server from loading by renaming the /etc/rc.httpd. When the computer boots, if /etc/rc finds a file named /etc/rc.httpd, it will execute the commands it finds there.
















Testing the Newly Installed Server






If your configuration files were edited properly, you should be able to point your Web browser to the machine running the server and see the page you created earlier, confirming that your server is running. Figure 2.2 shows what your screen should look like.





 Figure 2.3. The startup page you created as rendered by Microsoft Internet Explorer version 3.0.














If you are running the server in a nonstandard port, such as 8080, you'll need to specify the port number as part of the URL:


httpd://yourhost.yourdomain.com:port










If there was a problem with the server or a configuration, Apache is pretty good about giving you an indication about the problem. If Apache could not find some of the configuration files, it should give you a message like this:







httpd: could not open document config file /usr/local/etc/httpd/conf/httpd.conf

fopen: No such file or directory




Check for typos or incorrect path information on your command line or in the configuration files. Typically this problem appears if you have customized your installation to a different directory. Apache has compiled-in defaults that preset the location of ServerRoot. If you specify a relative path, the server prefixes the compiled-in ServerRoot instead.





Other problems may have dump values such as






httpd: could not bind to port

bind: Address already in use



If you get this message, more than likely there's another process using the port number you have defined. Other port binding problems can show up if you specify a reserved port number (one whose address is smaller than 1025). Only root processes can bind to reserved ports. The solution is to start the server as root so that the server can bind properly to the specified port (if you have followed our instructions, your server although started by root, runs as nobody).





If the server doesn't respond, check to see if it is running. Use the ps program to see what's going on:





    


      


      ps -guax | grep httpd (on BSD-type systems)


      





    


      


      ps -ef | grep httpd (on SVR4-type systems)


      





Don't get worried if you see several httpd processes running. Apache's server model runs several simultaneous processes coordinated by the parent process (the one owned by root).





Sometimes Apache returns enough information that will help you track a problem to a bad configuration setting. Other times, you'll have to hunt for the error. The first thing to check are the logs/error_log and logs/access_log files for more information. While you're at it, you may want to check for any core files in the ServerRoot. If some problem is crashing Apache (I've never had one that dumped core), it's likely that it left a trace there.
















Configuration File Listings






For your convenience, here's a listing of the various configuration files I talked about in this chapter.















src/Configuration File






After you configure and build your server, you won't have to edit this file. At least not until you enable additional modules. You will then have to add them here, and repeat the configuration and binary building process again.







Listing 2.2. The Configuration.tmpl File







# Config file for the Apache httpd.

# Configuration.tmpl is the template for Configuration. Configuration should

# be edited to select system type. Configuration.tmpl should only be changed

# when a new system or module is added, or an existing one modified.

# There are three types of lines here:

# '#' comments, distinguished by having a '#' as the first non-blank character

#

# Lines which set a Make option --- these are simply copied into the Makefile

#

# Module selection lines, distinguished by having 'Module' at the front.

# These list the configured modules, in priority order (highest priority

# first). They're down at the bottom.

# First, ordinary compile-time configuration.

# What to call the compiler: For normal machines with ANSI compilers

# CC= cc

# For Suns or other non-ANSI platforms. Please make sure your gcc is

# 2.0 or later, as 1.40 seems to create bad code for the Sun 4.

CC= gcc

# CFLAGS, compile flags.

# -DMINIMAL_DNS is now obsolete. Use httpd.conf settings of

# HostnameLookups on

# or

# HostnameLookups off

#

# If you want to have more secure hostname resolution at the cost of some 

# performance, use -DMAXIMUM_DNS.

# If you want setting the xbit of a file to cause it to be treated as

# server-included HTML (unless it is a CGI script), say -DXBITHACK. Note

# that this is a run-time option, per-directory, either way (via the XBITHACK

# command); this option only sets the default.

# If you find that your OS can't cope with mmap (compiles OKAY but refuses

# to run and moans "httpd: Could not mmap memory" .. or similar) try

# disabling use of shared memory for process management (scoreboard with

# -DNO_MMAP

# Status Instrumentation

# In order for the status module to obtain full statistics Apache must

# be modified to keep track of various information. This is not

# turned on by default. In order to enable full status details add -DSTATUS 

# to the end of the CFLAGS line below.

# Using SOCKS

# Apache can be compiled to work over a SOCKS firewall by 

# adding the following string to your CFLAGS define:

#

# -Dconnect=Rconnect -Dselect=Rselect -Dgethostbyname=Rgethostbyname

#

# and by adding the following to the EXTRA_LIBS define:

#

# -L/usr/local/lib -lsocks

#

# making sure that -L points to wherever you've put libsocks.a.

# [Some other former Apache compile-time options are now treated differently;

# the virtual host code is always present; DBM auth is an optional module, and

# may be configured out by changing the module config below, though it still

# defaults in. Note that this config file does not include DBM auth by

# default --- configure it in below if you need it].

CFLAGS= -O2

# Place here any flags you may need upon linking, such as a flag to

# prevent dynamic linking (if desired)

LFLAGS= 

# Place here any extra libraries you may need to link to. 

# -lndbm is commonly required for DBM auth, if that is configured in.

EXTRA_LIBS=

# AUX_CFLAGS are system-specific control flags.

# NOTE: IF YOU DO NOT CHOOSE ONE OF THESE, EDIT httpd.h AND CHOOSE

# SETTINGS FOR THE SYSTEM FLAGS. IF YOU DON'T, BAD THINGS WILL HAPPEN.

# For SunOS 4

#AUX_CFLAGS= -DSUNOS4

# For Solaris 2.

#AUX_CFLAGS= -DSOLARIS2

#AUX_LIBS= -lsocket -lnsl

# For SGI IRIX. Use the AUX_LIBS line if you're using NIS and want

# user-supported directories

#AUX_CFLAGS= -DIRIX

#AUX_LIBS= -lsun

# For HP-UX n.b. if you use the paid-for HP CC compiler, use flag -Ae

#AUX_CFLAGS= -DHPUX

# For AIX

#AUX_CFLAGS= -DAIX -U__STR__

# For Ultrix

#AUX_CFLAGS= -DULTRIX

# For DEC OSF/1

#AUX_CFLAGS= -DOSF1

# For NeXT

#AUX_CFLAGS= -DNEXT

# For Sequent

#AUX_CFLAGS= -DSEQUENT

# For Linux -m486 ONLY IF YOU HAVE 486 BINARY SUPPORT IN KERNEL

#AUX_CFLAGS= -DLINUX

# For A/UX

#AUX_CFLAGS= -DAUX -D_POSIX_SOURCE

#AUX_LIBS= -lposix -lbsd -s

# For SCO ODT 3

# libcrypt_i available from sosco.sco.com, files /SLS/lng225b.Z and

# /SLS/lng225b.ltr.Z

# the -Oe option causes cc to die compiling mod_imap (using 3.0.0a of the dev sys)

#CFLAGS= -Oacgiltz

#AUX_CFLAGS= -DSCO

#AUX_LIBS= -lPW -lsocket -lmalloc -lcrypt_i

# For SCO OpenServer Release 5

# -K noinline is needed to work around an optimiser bug which appears in

# http_bprintf.c

#AUX_CFLAGS= -DSCO5

#AUX_LIBS=-lsocket -lmalloc -lprot

#BROKEN_BPRINTF_FLAGS=-K noinline

# For SVR4

# Some SVR4 implementations will require SO_LINGER option to be set in order

# to guarantee buffer flushes. Dell, Esix, and UnixWare are a few of these.

# Use -DNEED_LINGER in addition to other AUX_CFLAGS for these.

#AUX_CFLAGS= -DSVR4

#AUX_LIBS= -lsocket -lnsl -lc

# For UnixWare 2.x, no longer just SVR4 (sigh) - use cc, not gcc

# AUX_LIBS= -lsocket -lnsl -lcrypt

# For Amdahl UTS 2.1

# -Xa enables ANSI mode, -eft is expanded types

#AUX_CFLAGS= -Xa -eft -DUTS21

#AUX_LIBS= -lsocket -lbsd -la

# For HP/Apollo Domain/OS

#AUX_CFLAGS= -DAPOLLO

# For NetBSD/FreeBSD/BSDI 2.x

# -m486 only if you are running on Intel 486/586

#AUX_CFLAGS= -m486

# BSDI doesn't need -lcrypt

#AUX_LIBS= -lcrypt

# For QNX

#AUX_CFLAGS= -DQNX

#AUX_LFLAGS= -N 0x20000

# For LynxOS

#AUX_CFLAGS= -DLYNXOS

#EXTRA_LIBS=-lbsd -ldes -lc_p

# For DG/UX 5.4

#AUX_CFLAGS= -DDGUX

#AUX_LIBS=

# For EMX OS/2 port

#AUX_CFLAGS= -Zbsd-signals -Zbin-files

#-DNO_KILLPG -DNEED_STRCASECMP -DNO_SETSID

#-g

#AUX_LIBS= -lsocket -llibufc -lgdbm -lbsd

###########################################

# Module configuration

#

# Modules are listed in reverse priority order --- the ones that come

# later can override the behavior of those that come earlier. This

# can have visible effects; for instance, if UserDir followed Alias,

# you couldn't alias out a particular user's home directory.

# The configuration below is what we consider a decent default 

# configuration. If you want the functionality provided by a particular

# module, remove the "#" sign at the beginning of the line. But remember, 

# the more modules you compile into the server, the larger the executable

# is and the more memory it will take, so if you are unlikely to use the

# functionality of a particular module you might wish to leave it out.

## Basic modules (i.e., generally useful stuff that works everyplace):

## You should probably not comment out any of these unless you know what it

## does and you know you won't need it.

Module mime_module mod_mime.o

Module access_module mod_access.o

Module auth_module mod_auth.o

Module negotiation_module mod_negotiation.o

Module includes_module mod_include.o

Module dir_module mod_dir.o

Module cgi_module mod_cgi.o

Module userdir_module mod_userdir.o

Module alias_module mod_alias.o

Module env_module mod_env.o

Module common_log_module mod_log_common.o

## The asis module implemented ".asis" file types, which allow the embedding

## of HTTP headers at the beginning of the document. mod_imap handles internal 

## imagemaps (no more cgi-bin/imagemap/!). mod_actions is used to specify 

## CGI scripts which act as "handlers" for particular files, for example to

## automatically convert every GIF to another file type.

Module asis_module mod_asis.o

Module imap_module mod_imap.o

Module action_module mod_actions.o

## Optional modules for NCSA user-agent/referer logging compatibility

## We recommend, however, that you migrate to the configurable logging

## module, below.

# Module agent_log_module mod_log_agent.o

# Module referer_log_module mod_log_referer.o

## This is a *replacement* for mod_log_common which supports a

## LogFormat directive which allows you to specify what goes into 

## the TransferLog (if you want Referer, etc.) source code for docs.

##

## If you play with this, remember to drop the standard

## mod_log_common --- a server with both will work, but you'll get

## very confused trying to figure out what's going on...

# Module config_log_module mod_log_config.o

## cern_meta mimicks the behavior of the CERN web server with regards to 

## metainformation files. 

# Module cern_meta_module mod_cern_meta.o

## The status module allows the server to display current details about 

## how well it is performing and what it is doing. Consider also enabling 

## -DSTATUS (see the CFLAGS section near the start of the file) to allow

## full status information. Check conf/access.conf on how to enable this.

# Module status_module mod_status.o

## The Info module displays configuration information for the server and 

## all included modules. It's very useful for debugging.

# Module info_module mod_info.o

## Optional authentication modules. 

##

## The anon_auth module allows for anonymous-FTP-style username/ 

## password authentication.

# Module anon_auth_module mod_auth_anon.o

## db_auth and dbm_auth work with Berkeley DB files - make sure there

## is support for DBM files on your system. You may need to grab the GNU

## "gdbm" package if not.

# Module db_auth_module mod_auth_db.o

# Module dbm_auth_module mod_auth_dbm.o

## msql_auth checks against an MSQL database. You must have MSQL installed

## and an "msql.h" available for this to even compile. Additionally,

## you may need to add a couple entries to the CFLAGS line, like

##

## -lmsql -L/usr/local/lib -L/usr/local/Minerva/lib

##

## This depends on your installation of MSQL.

# Module msql_auth_module mod_auth_msql.o

## "digest" implements HTTP Digest Authentication rather than the less 

## secure Basic Auth used by the other modules.

# Module digest_module mod_digest.o

## Outright experiments --- mod_dld defines commands which

## allows other modules to be loaded in at runtime, and mod_cookies

## uses Netscape cookies to automatically construct and log accurate

## click-trails from Netscape cookies, for Netscape-using clients who

## aren't coming in via proxy. 

# Module dld_module mod_dld.o

# Module cookies_module mod_cookies.o

## Finally, the proxy module. It's not as complete as it could

## be yet, so use at your own risk.

# Module proxy_module mod_proxy.o














The Server Configuration File: conf/httpd.conf







# This is the main server configuration file. See URL http://www.apache.org/

# for instructions.

# Do NOT simply read the instructions in here without understanding

# what they do, if you are unsure consult the online docs. You have been

# warned. 

# Originally by Rob McCool

# ServerType is either inetd, or standalone.

ServerType standalone

# If you are running from inetd, go to "ServerAdmin".

# Port: The port the standalone listens to. For ports < 1023, you will

# need httpd to be run as root initially.

Port 80

# HostnameLookups: Log the names of clients or just their IP numbers

# e.g. www.apache.org (on) or 204.62.129.132 (off)

HostnameLookups on

# If you wish httpd to run as a different user or group, you must run

# httpd as root initially and it will switch. 

# User/Group: The name (or #number) of the user/group to run httpd as.

# On SCO (ODT 3) use User nouser and Group nogroup

User nobody

Group #-1

# ServerAdmin: Your address, where problems with the server should be

# e-mailed.

ServerAdmin you@your.address

# ServerRoot: The directory the server's config, error, and log files

# are kept in

ServerRoot /usr/local/etc/httpd

# BindAddress: You can support virtual hosts with this option. This option

# is used to tell the server which IP address to listen to. It can either

# contain "*", an IP address, or a fully qualified Internet domain name.

# See also the VirtualHost directive.

#BindAddress *

# ErrorLog: The location of the error log file. If this does not start

# with /, ServerRoot is prepended to it.

ErrorLog logs/error_log

# TransferLog: The location of the transfer log file. If this does not

# start with /, ServerRoot is prepended to it.

TransferLog logs/access_log

# PidFile: The file the server should log its pid to

PidFile logs/httpd.pid

# ScoreBoardFile: File used to store internal server process information

ScoreBoardFile logs/apache_status

# ServerName allows you to set a host name which is sent back to clients for

# your server if it's different than the one the program would get (i.e. use

# "www" instead of the host's real name).

#

# Note: You cannot just invent host names and hope they work. The name you 

# define here must be a valid DNS name for your host. If you don't understand

# this, ask your network administrator.

#ServerName new.host.name

# CacheNegotiatedDocs: By default, Apache sends Pragma: no-cache with each

# document that was negotiated on the basis of content. This asks proxy

# servers not to cache the document. Uncommenting the following line disables

# this behavior, and proxies will be allowed to cache the documents.

#CacheNegotiatedDocs

# Timeout: The number of seconds before receives and sends time out

# n.b. the compiled default is 1200 (20 minutes !)

Timeout 400

# KeepAlive: The number of Keep-Alive persistent requests to accept

# per connection. Set to 0 to deactivate Keep-Alive support

KeepAlive 5

# KeepAliveTimeout: Number of seconds to wait for the next request

KeepAliveTimeout 15

# Server-pool size regulation. Rather than making you guess how many

# server processes you need, Apache dynamically adapts to the load it

# sees --- that is, it tries to maintain enough server processes to

# handle the current load, plus a few spare servers to handle transient

# load spikes (e.g., multiple simultaneous requests from a single

# Netscape browser).

# It does this by periodically checking how many servers are waiting

# for a request. If there are fewer than MinSpareServers, it creates

# a new spare. If there are more than MaxSpareServers, some of the

# spares die off. These values are probably OK for most sites ---

MinSpareServers 5

MaxSpareServers 10

# Number of servers to start --- should be a reasonable ballpark figure.

StartServers 5

# Limit on total number of servers running, i.e., limit on the number

# of clients who can simultaneously connect --- if this limit is ever

# reached, clients will be LOCKED OUT, so it should NOT BE SET TOO LOW.

# It is intended mainly as a brake to keep a runaway server from taking

# Unix with it as it spirals down...

MaxClients 150

# MaxRequestsPerChild: the number of requests each child process is

# allowed to process before the child dies.

# The child will exit so as to avoid problems after prolonged use when

# Apache (and maybe the libraries it uses) leak. On most systems, this

# isn't really needed, but a few (such as Solaris) do have notable leaks

# in the libraries.

MaxRequestsPerChild 30

# Proxy Server directives. Uncomment the following line to

# enable the proxy server:

#ProxyRequests On

# To enable the cache as well, edit and uncomment the following lines:

#CacheRoot /usr/local/etc/httpd/proxy

#CacheSize 5

#CacheGcInterval 4

#CacheMaxExpire 24

#CacheLastModifiedFactor 0.1

#CacheDefaultExpire 1

#NoCache adomain.com anotherdomain.edu joes.garage.com

# Listen: Allows you to bind Apache to specific IP addresses and/or

# ports, in addition to the default. See also the VirtualHost command

#Listen 3000

#Listen 12.34.56.78:80

# VirtualHost: Allows the daemon to respond to requests for more than one

# server address, if your server machine is configured to accept IP packets

# for multiple addresses. This can be accomplished with the ifconfig 

# alias flag, or through kernel patches like VIF.

# Any httpd.conf or srm.conf directive may go into a VirtualHost command.

# See alto the BindAddress entry.

 

#<VirtualHost host.foo.com>

#ServerAdmin webmaster@host.foo.com

#DocumentRoot /www/docs/host.foo.com

#ServerName host.foo.com

#ErrorLog logs/host.foo.com-error_log

#TransferLog logs/host.foo.com-access_log

#</VirtualHost>













The Resource Configuration File: conf/srm.conf







# With this document, you define the name space that users see of your http

# server. This file also defines server settings which affect how requests are

# serviced, and how results should be formatted. 

 

# See the tutorials at http://www.apache.org/ for

# more information.

# Originally by Rob McCool; Adapted for Apache

# DocumentRoot: The directory out of which you will serve your

# documents. By default, all requests are taken from this directory, but

# symbolic links and aliases may be used to point to other locations.

DocumentRoot /usr/local/etc/httpd/htdocs

# UserDir: The name of the directory which is appended onto a user's home

# directory if a ~user request is recieved.

UserDir public_html

# DirectoryIndex: Name of the file or files to use as a pre-written HTML

# directory index. Separate multiple entries with spaces.

DirectoryIndex index.html

# FancyIndexing is whether you want fancy directory indexing or standard

FancyIndexing on

# AddIcon tells the server which icon to show for different files or filename

# extensions

AddIconByEncoding (CMP,/icons/compressed.gif) x-compress x-gzip

AddIconByType (TXT,/icons/text.gif) text/*

AddIconByType (IMG,/icons/image2.gif) image/*

AddIconByType (SND,/icons/sound2.gif) audio/*

AddIconByType (VID,/icons/movie.gif) video/*

AddIcon /icons/binary.gif .bin .exe

AddIcon /icons/binhex.gif .hqx

AddIcon /icons/tar.gif .tar

AddIcon /icons/world2.gif .wrl .wrl.gz .vrml .vrm .iv

AddIcon /icons/compressed.gif .Z .z .tgz .gz .zip

AddIcon /icons/a.gif .ps .ai .eps

AddIcon /icons/layout.gif .html .shtml .htm .pdf

AddIcon /icons/text.gif .txt

AddIcon /icons/c.gif .c

AddIcon /icons/p.gif .pl .py

AddIcon /icons/f.gif .for

AddIcon /icons/dvi.gif .dvi

AddIcon /icons/uuencoded.gif .uu

AddIcon /icons/script.gif .conf .sh .shar .csh .ksh .tcl

AddIcon /icons/tex.gif .tex

AddIcon /icons/bomb.gif core

AddIcon /icons/back.gif ..

AddIcon /icons/hand.right.gif README

AddIcon /icons/folder.gif ^^DIRECTORY^^

AddIcon /icons/blank.gif ^^BLANKICON^^

# DefaultIcon is which icon to show for files which do not have an icon

# explicitly set.

DefaultIcon /icons/unknown.gif

# AddDescription allows you to place a short description after a file in

# server-generated indexes.

# Format: AddDescription "description" filename

# ReadmeName is the name of the README file the server will look for by

# default. Format: ReadmeName name

#

# The server will first look for name.html, include it if found, and it will

# then look for name and include it as plaintext if found.

#

# HeaderName is the name of a file which should be prepended to

# directory indexes. 

ReadmeName README

HeaderName HEADER

# IndexIgnore is a set of filenames which directory indexing should ignore

# Format: IndexIgnore name1 name2...

IndexIgnore */.??* *~ *# */HEADER* */README* */RCS

# AccessFileName: The name of the file to look for in each directory

# for access control information.

AccessFileName .htaccess

# DefaultType is the default MIME type for documents which the server

# cannot find the type of from filename extensions.

DefaultType text/plain

# AddEncoding allows you to have certain browsers (Mosaic/X 2.1+) uncompress

# information on the fly. Note: Not all browsers support this.

AddEncoding x-compress Z

AddEncoding x-gzip gz

# AddLanguage allows you to specify the language of a document. You can

# then use content negotiation to give a browser a file in a language

# it can understand. Note that the suffix does not have to be the same

# as the language keyword --- those with documents in Polish (whose

# net-standard language code is pl) may wish to use "AddLanguage pl .po" 

# to avoid the ambiguity with the common suffix for perl scripts.

AddLanguage en .en

AddLanguage fr .fr

AddLanguage de .de

AddLanguage da .da

AddLanguage el .el

AddLanguage it .it

# LanguagePriority allows you to give precedence to some languages

# in case of a tie during content negotiation.

# Just list the languages in decreasing order of preference.

LanguagePriority en fr de

# Redirect allows you to tell clients about documents which used to exist in

# your server's namespace, but do not anymore. This allows you to tell the

# clients where to look for the relocated document.

# Format: Redirect fakename url

# Aliases: Add here as many aliases as you need (with no limit). The format is 

# Alias fakename realname

#Alias /icons/ /usr/local/etc/httpd/icons/

# ScriptAlias: This controls which directories contain server scripts.

# Format: ScriptAlias fakename realname

#ScriptAlias /cgi-bin/ /usr/local/etc/httpd/cgi-bin/

# If you want to use server side includes, or CGI outside

# ScriptAliased directories, uncomment the following lines.

# AddType allows you to tweak mime.types without actually editing it, or to

# make certain files to be certain types.

# Format: AddType type/subtype ext1

# AddHandler allows you to map certain file extensions to "handlers",

# actions unrelated to filetype. These can be either built into the server

# or added with the Action command (see below)

# Format: AddHandler action-name ext1

# To use CGI scripts:

#AddHandler cgi-script .cgi

# To use server-parsed HTML files

#AddType text/html .shtml

#AddHandler server-parsed .shtml

# Uncomment the following line to enable Apache's send-asis HTTP file

# feature

#AddHandler send-as-is asis

# If you wish to use server-parsed imagemap files, use

#AddHandler imap-file map

# To enable type maps, you might want to use

#AddHandler type-map var

# Action lets you define media types that will execute a script whenever

# a matching file is called. This eliminates the need for repeated URL

# pathnames for oft-used CGI file processors.

# Format: Action media/type /cgi-script/location

# Format: Action handler-name /cgi-script/location

# For example to add a footer (footer.html in your document root) to

# files with extension .foot (e.g. foo.html.foot), you could use:

#AddHandler foot-action foot

#Action foot-action /cgi-bin/footer

# Or to do this for all HTML files, for example, use:

#Action text/html /cgi-bin/footer

# MetaDir: specifies the name of the directory in which Apache can find

# meta information files. These files contain additional HTTP headers

# to include when sending the document

#MetaDir .web

# MetaSuffix: specifies the file name suffix for the file containing the

# meta information.

#MetaSuffix .meta

# Customizable error response (Apache style)

# these come in three flavors

#

# 1) plain text

#ErrorDocument 500 "The server made a boo boo.

# n.b. the (") marks it as text, it does not get output

#

# 2) local redirects

#ErrorDocument 404 /missing.html

# to redirect to local url /missing.html

#ErrorDocument 404 /cgi-bin/missing_handler.pl

# n.b. can redirect to a script or a document using server-side-includes.

#

# 3) external redirects

#ErrorDocument 402 http://other.server.com/subscription_info.html

#













The Global Access Configuration File: conf/access.conf







# access.conf: Global access configuration

# Online docs at http://www.apache.org/

# This file defines server settings which affect which types of services

# are allowed, and in what circumstances. 

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

# Originally by Rob McCool

# This should be changed to whatever you set DocumentRoot to.

<Directory /usr/local/etc/httpd/htdocs>

# This may also be "None", "All", or any combination of "Indexes",

# "Includes", "FollowSymLinks", "ExecCGI", or "MultiViews".

# Note that "MultiViews" must be named *explicitly* --- "Options All"

# doesn't give it to you (or at least, not yet).

Options Indexes FollowSymLinks

# This controls which options the .htaccess files in directories can

# override. Can also be "All", or any combination of "Options", "FileInfo", 

# "AuthConfig", and "Limit"

AllowOverride None

# Controls who can get stuff from this server.

order allow,deny

allow from all

</Directory>

# /usr/local/etc/httpd/cgi-bin should be changed to whatever your ScriptAliased

# CGI directory exists, if you have that configured.

<Directory /usr/local/etc/httpd/cgi-bin>

AllowOverride None

Options None

</Directory>

# Allow server status reports, with the URL of http://servername/status

# Change the ".nowhere.com" to match your domain to enable.

#<Location /status>

#SetHandler server-status

#order deny,allow

#deny from all

#allow from .nowhere.com

#</Location>

# You may place any other directories or locations you wish to have

# access information for after this one.














Summary






Congratulations! If you have reached this point, you should have a properly configured Apache server running. You can now continue to Chapter 3, "Organizing Your Web Site," where you will learn the tricks for putting together an effective site.





Apache server is easy to build and configure. Although there are no GUI-based tools available for the configuration (not yet anyway), configuration is not particularly difficult. A nice editor is all that is needed. Netscape servers, once they have a basic configuration, prompt the Administrator to finish configuration details with a browser. See Chapter 8, "Apache Configuration Overview," for additional information on basic configuration.




Previous Page

Page Top

TOC

Next Page