A p a c h e  M a n u a l

Configuration, Installation and Use






Load-Time Configuration







Running Apache



Click here for the gzipped downloadable manual





(back to the top)


What is Apache?

Apache is a Web-Server. A Web-Server is basically a program running on a computer connected to some network (usually the Internet) that recieves requests for information, follows a pre-defined set of rules in-order to meet those requests, or perhaps deny them. When ever you open your default Home-Page, or any page on the Internet in fact, what you have done, or your browser has done on behalf of yourself, is contact a server running somewhere in the world, and made a request for some Web-Pages. When ever you fill in a form in a Web-Page and click to send, that information is sent to a Web-Server which knows how to deal with that information because the web-master or systems administrator has set it up to do so. This short tutorial will teach you how to set up your apache Server to do so also. This is a summary of the basics NOT a complete reference. If you need any additional information on how to use Apache you should read the manual that can be found on the Apache web site: http://httpd.apache.org/docs


(back to the top)


Getting Started

First thing you need to do is download the apache installation. This can be found at the Apache Web-Site http://httpd.apache.org. This file will be named something like this : apache_1.3.17.tar.gz

This file is an archive file. It can be decompressed using the unix command gunzip. You will need to extract the files and folders into a directory that you have access to using the tar program.

(back to the top)

Make Configure

When you have the decompressed files and folders of the apache installation you can now begin Configuration of the Installation. By doing this you affect the contents of the INSTALL script. This is where you decide what features your Apache Web-Server should support, what features should be unavailable, and what directory to install into. This is an important part of the security process for any server.

Configuration is done through the 'configure' script found in the root directory of the Apache Installation. By using the option --help, ie ./configure --help you are informed of what options are available to you, what options are associated with what features and what modules are installed by default.

Once you have decided what modules to install, use the ./configure [-option .. ....] script to create your personal installation script. If you do not use any options apache configure will use it's default settings and will warn you that it is doing that.

(back to the top)


Once you have run the configure script you can now use the installation script that will install Apache and all the modules you have selected with configure.This script is a Makefile. You run it by first invoking the command 'make', then when it is done, 'make install'. You can now go away and have a drink as this will take a little while!

(back to the top)

Checking Configuration

Ok! you have had your drink now, and the installation process is done. Assuming there were no major errors along the way, you could now go to the install directory root/bin and start apache. You could then open your browser and connect to the server. You would then get the default Web-Page for apache. If installation did NOT go correctly you will have to go back and do it again checking your configure options. Either way, the apache make will inform you on how things went at the end of installation. The config.status file found in the source root directory will have a list of which module's were installed or not if something went wrong.

It is often useful to create your own shell script to do this installation process automatically (if it is done regularly and consistantly). This is a sample of such a shell script used to install apache. SCRIPT.SH. You might also want to use another script, or include in the same script, information that installs your actual Web-Pages. In the case of a hacker-vandalism, or just a system clean out, you can have archived copies of your web-pages and scripts at another location. When ever you want to re-install from scratch you can just call your script and that also is now done automatically. Here is an example of a script that does this and sets some permissions so that pages are viewable by others (SCRIPT2.SH).



  1. gunzip apache_1.3.17.tar.gz
  2. tar -xvf apache_1.3.17.tar
  3. ./configure --help
  4. ./configure [-option1 -option2 ... ...]
  5. cat config.status
  6. make
  7. make install

(back to the top)


Load-Time Configuration



The settings of Apache largely dependant upon the contents of files found in the conf/ directory found in the Installation. Most of the configuration happens in the file httpd.conf. This file should be edited to relect system administration / security needs and the general needs of the Web-Site.


Basic Default Settings

Organising Server Time/Activities

There are many variables that you may change in httpd.conf to organise the way that apache server runs. Some of these variables are how many apache servlets (tribesment) to run at start-up, the maximum number of trubesmen to run at any one time etc. Here is are some examples of the variables and their settings.

For example: MaxRequestsPerChild is now set so each tribesman can only handle 10 requests for it commits suiicide!! This may seem strange but it is implemented so that memory is guaranteed to be freed after a certain amount of time. This is a work around for dealing with 'leaky' code!

They may be found in the file httpd.conf. You can view them here in httpd_conf.txt which is a edited, shorter version of the same thing. Some explainations may be found in both files.


Port, Server Address Settings

These Settings may be found in the httpd_conf.txt file also. This is where you can set the Port used, and you can see what the address of the server is. They are written as :

The Port number listed is the port to which the standalone server listens. For ports < 1023, you will need httpd to be run as root initially (httpd.conf).


Setting Documents Root

This refers to the root directory that browsers will be pointed to when the ServerName is entered into the URL address. This, as many things found in httpd.conf, will probably already be correctly set by default. If not it is simply a case of changing the directorty Quoted in the DocumentRoot statement and setting the appropriate Directory Settings for that directory. The DocumentRoot statement is written as:



Setting Directory Options

This involves using the 'Directory' directive. This is used to set the viewing options for a directory. All manner of things may be specified, from what IP-Adress to allow to view, who with which password, or from which group may access, which types of files may run from this directory, can you view the Index of this directory? and lots more. We will go more into some of those other features later, but for now, we explain how the Root Directory is set-up.

<Directory "/spare0/csci399/sv24/AP_INST/htdocs">

         Options Indexes FollowSymLinks MultiViews

         AllowOverride None

         Order allow,deny

         Allow from all



The statement block (Directive) shown above are used to set the options of a directory. In this case it was used for the Root Directory.

What it all means is that for the directory /htdocs, allow the Index to be shown, Allow symbolic links to be used from this directory, and allow Multiviews.

The 'AllowOverride none' statement says not to allow any outside exception to the rule.

The 'Allow from all' statement says to allow THIS access to everyone. The 'Order allow,deny' statement means in this case if case not mentioned in the Allow or Deny statements then by default you should DENY access. If it was 'Order deny,allow' it would mean to ALLOW access by default. More information on this should be read from the Apache Web-Site http://httpd.apache.org/docs.


server-info and server-status

Turning on the server-status and server-info options is just as simple as setting Directory directives except that server-status and server-info are not Directory's, they are services provided by the Server if the module was built into Apache during set-up. So instead of using Directory directives we use the Location directive.Location Directives work like Directory directives, and turning on server-info or server-status is almost just a case of un-commenting some lines. NOTE: Comments are defined by a hash '#' at the start of a line. Here is an example of the Location Directive for server-status


<Location /server-status>

       SetHandler server-status

       Order allow,deny

       Allow from uow.edu.au

       Deny from .wolax.it.other_computer.com



What the above lines say is: set a virtual location called /server-status, set the handler for this location to be the program server-status, and allow this Virtual location to be used by ONLY those people originating from the 'uow.edu.au' domain. Again, you can view this in the file httpd.conf. Initially after you have just configured and installed Apache, these lines will be commented out. So to access server-status you would have to un-comment those lines and make sure that those people who should have access are accounted for in the Allow statements, and those who shouldn't have access might be mentioned in the Deny statement. This is necessary depending upon the Order ( see http://httpd.apache.org/docs ).

(back to the top)




Multiviews & Negotiation

When the Web-Page provides for different formats of the same information, eg, A ducument that has various language translations, the server can allow the negotiation of content with the Browser.

In This case we show the browser language Preferences set for German which carries the file extension '.de' with it.

Using this browser setting and allowing for Multiviews in Apache settings we can allow the browser to see different versions of the same file.

We might have a page that has 3 different translations accounted for. These would be named:

file.html.en                         # for english

file.html.de                         # for german

file.html.fr                           # for french

There are many other language types. These may be set in the httpd.conf file.

First, to set up support for Multiviews we must make another Directory directive which accounts for Multiviews, specific to the directory in which we want to allow this feature.

The Following lines are taken from httpd.conf.


<Directory "/spare0/csci399/sv24/AP_INST/htdocs/multiv">

           options MultiViews

           Allow from all


What this say's is: In the Directory multiv, allow from all locations, the Multiview option allowing browsers to choose their own content type in this folder.

What you will see in this example case is that when a user clicked a link to go to a file overs.html, because of a browser preference for German (de), this person recieved Gernan content. The Web page language extention is not reflected in the URL Address as you can see the address shows as ..../multiv/overs.html not as .../multiv/overs.html.de

In same way as we have set up the content negotiation of languages, you can also set up content negotiation of images, for example, the preference of .gif over .jpg, or negotiation of archive files, eg, .zip over .rar or .gz, their is no limitation.

Apache is told of a language through the AddLanguage Directive.






These are statements found in httpd.conf which tell apache about different languages:




There are file types that need to be handled by something other than the usual web-page server. The server can be told about these types through the AddHandler Directive. For instance, for our web-site to be able to use cgi scripts we should give file extentions with .cgi a cgi script handler. We do the same sort of thing with Server Side Includes also. The following lines are examples of this.

Note: This is not all we must do to get cgi scripts working. We will go more into that next.

(back to the top)


Command Gateway Interface (CGI)

CGI are a common method of processing information sent from a user over a network. This is often done via a web-page form. This tutorial is not about CGI so we will not go too far into the details of CGI programs except to give an example on a simple little program (CGI_PROGRAM) that accepts input from a form and outputs different things to the browser depending on the content of the information that was sent via the form. It was written in BASH script, but could've been done in virtually any language.

To enable any CGI on your server you might have to un-comment a Directory directive that refers to a default directory called cgi-bin. You will also have to make sure the line:     { ScriptAlias /cgi-bin/ "/SOME_LOCATION/cgi-bin/" } is not commented out.

Now you must first give it a handler ( as we done in the previous section). That is all that is needed, except of cource to give the corrent permissions on the cgi program file so that outsiders can run it!

AddHandler cgi-script .cgi

If you want to run CGI programs in a folder other than the apache default directory, you must specify what directory CGI programs are allowed to run. As before, we now use the Directory directive. This information is placed in the httpd.conf file.

<Directory "/spare0/csci399/sv24/AP_INST/htdocs/progs">

         AllowOverride None

         Options ExecCGI

         Order allow,deny

         Allow from all


It is the 'Options ExecCGI' that allows CGI programs to run in the Directory specified, in this case: .../htdocs/progs.

(back to the top)


Access Controls

The most basic access controls can appear as just as Directory directives with the Deny directive specifying what domain's aren't allowed access (just as seen with the Location directive previously). If you want a more flexible means of access control, such as a user password system, we need to do a few things first. To allow access through a user/password system we need to allow an Override for this type of access over the normal domain based control. This is done through the AllowOverride directive.

We do this on a directory by directory basis. The option for AllowOverride, in this case is the AuthConfig statement. This allows Authentication configuration within a Directory directive, or within a file that must be called '.htaccess' Within this file we can now specify Directives that control the Authentication requirements for that particular directory. Here is an example of the Directory directive specifying a directory in which the server should look for the file '.htaccess' for over-rides.

<Directory /spare0/csci399/sv24/AP_INST/htdocs/over>

          AllowOverride AuthConfig

          Options None



Inside the '.htaccess' file we find Directives specifying what groups to allow access. This is the AuthGroupFile directive which points to a file containing group names and members.

There is the AuthName directive, specifying what the 'name' of the authorization requirement is. This will appear in the login window that will pop-up in the case of an authorization requirement. As we can see from the Network Password pop-up, the Realm is called '399_sv24'. This is the AuthName.

AuthUserFile specifies where the password file, containing user name's and passwords, is located. By default it creates an encrypted file for security purposes. This means that anyone containing an entry in the passwords file can get access if quoting their login name and password at the Netword Password pop-up.

The Require directive says we equire a valid user.

Here is some of what can be found at the apache documentation web page http://httpd.apache.org/docs.

"This directive selects which authenticated users can access a directory. The allowed syntaxes are:

Require user userid [userid] ... Only the named users can access the directory.

Require group group-name [group-name] ... Only users in the named groups can access the directory.

Require valid-user All valid users can access the directory."

Read the Documentation for further information on this topic.


At last we strike a topic that doesn't immediately involve the modification of httpd.conf !

If we want to have Authentication via user/password identification, we need to have a passwords file, that i have called .htpasswords. We put the .ht at the start of the name always because then we can control the access to sensitive files with a 'Files' directive specifying files starting with .ht. For example,

<Files ~ "^\.ht">

          Order allow,deny

          Deny from all


We use a program found in the 'bin' directory of the installation called htpasswd. By just typing the name of this program alone with no options we get a list of options available and what they are used for. It is good to create a password file that encrypts it's user names and passwords.

Once we have our password file, and it is placed in a directory that is protected from access from everybody except key admin personel, we then continue our modification of httpd.conf.

(back to the top)


Server-Side Includes

To enable Server-Side Includes, we need to do a few small adjustments to the httpd.conf file. First we need to specify which directory to allow Server-Side Includes to run from, we do this, as always, with a Directory directive, giving the 'Includes' Option as:

<Directory /spare0/csci399/sv24/AP_INST/htdocs/over>

          Options Includes


Then, if we are using the extension '.shtml' we should use the AddType directive to tell the Apache server about this file type as:

AddType text/html .shtml

Lastly we need to give a handler to .shtml files so that Apache knows to do something special when it works with this file type. This is done exactly as in previous examples of CGI, except the handler is not the 'cgi-script' handler.

AddHandler server-parsed .shtml

The only thing left to do now is write your Server-Side Includes script. This is not a manual on server side includes so we will not go into that topic except to give a few examples. The example given here does two things.

The first is for implements a simple counter that can count the number of vistors to that page. To implement it, we write a couple of small scripts that implement a simple counter program. All the Server-Side Includes does here is execute the scripts and output the result.

The second part of the Server-Side Includes outputs the last time a specified file was last modified.

Because we were making a counter and last accessed page, we use the Server-Side Include's function flastmod to tell us the last time our counter file was last modified. In other words, when was the last access to the page that contains the Server-Side Includes script.

The Counter scripts are count.sh and getcount.sh were written by me. They work together in a way, both working with a file called '.count' which holds the actual value of the count. This is just a very simple example. There are many ways to implement a counting program.

(back to the top)


Running Apache


Now that you have installed and configured Apache, you can now get it running. This is a simple thing. Just invoke the name of the apache control program apachectl with the start option, as:

apachectl start

If you have it already running, but you have made some further modifications to the 'httpd.conf' file you can either stop it and start again, as:

apachectl stop

apachectl start

Or you may just use the restart option as:

apachectl restart

You may view the help for apachectl by just simple invoking the name with no options, as:


You then are given a list of available options and what they do.

Another useful option 'configtest' tests the syntax of your httpd.conf file, and tells you where the problem is if the syntax is incorrect.

apachectl configtest

(back to the top)



To assist in your maintenance of Apache we can use the server-status and server-info outputs. These links for server-status and server-info, as mentioned previously in this manual show you examples of the types of useful information this service can provide at demand. server-status is particularly useful for viewing how much demaind isput upon your system at any time. As in the case of our example, you can see that this server was put under no demand at all, only processing 1 client (me) with a very small 5 idle servlets waiting. A commercial server would have many more servlets running and not so many idle at times.

Certain files that Apache produces, such as access_log or error_log can also be very interesting and useful when keeping an eye on your system, and those attempting to access it. These files show you some example content of what you might expect to find in this files (although they will often be much much larger).

If you take a look at both files, access_log and error_log, at the time of  '22:05:12'  you will see what is happening at that time. Which in this case is someone trying many times to access a page that they don't have access to. They are guessing the log-in password, or user-name or both, and have failed and been denied (note the error code 401 in the access_log).

These files can be found in the logs/ directory and are a useful service for security and maintenance purposes.





Here end the Manual for Apache (UNIX). It is hoped that this has been useful for someone starting out with Apache. To assist your development, here is a link to a sample Web-Site. This Web-Site features material shown in this manual, including working Server-Side Includes and CGI. Have fun Configuring Your Apache Server!


(back to the top)



WebMaster:   Sean Van Buggenum