We have illustrated a number of facilities in the Apache 2.2 web server which can be used to create a web server serving multiple web sites.
The configuration file we have built as we go along is syntactically valid, but reflects its didactic origins. Our final act will be to tidy it up.
The first thing typically done is to move all the LoadModule commands to a block near the start of the file. That allows us to use all their commands in whatever order we want further down the file.
The next thing we would do is to reorder the commands to exploit this freedom. In our case the only major shuffle will be to put the IndexIgnore statement next to the FilesMatch block that cover the same files. We have also added some magic to make the Apache manual available under /manual/, moved some of the "deny by default" rules to the top of the file, and indented the content of the various blocks for readability.
Listen 80
User wwwrun
Group www
# Load the modules needed for this file
LoadModule mime_module /usr/lib/apache2/mod_mime.so
LoadModule dir_module /usr/lib/apache2/mod_dir.so
LoadModule autoindex_module /usr/lib/apache2/mod_autoindex.so
LoadModule alias_module /usr/lib/apache2/mod_alias.so
LoadModule log_config_module /usr/lib/apache2/mod_log_config.so
LoadModule userdir_module /usr/lib/apache2/mod_userdir.so
LoadModule authz_host_module /usr/lib/apache2/mod_authz_host.so
LoadModule authz_user_module /usr/lib/apache2/mod_authz_user.so
LoadModule auth_basic_module /usr/lib/apache2/mod_auth_basic.so
LoadModule authn_file_module /usr/lib/apache2/mod_authn_file.so
LoadModule authz_groupfile_module /usr/lib/apache2/mod_authz_groupfile.so
LoadModule ucam_webauth_module /usr/lib/apache2/mod_ucam_webauth.so
LoadModule setenvif_module /usr/lib/apache2/mod_setenvif.so
LoadModule negotiation_module /usr/lib/apache2/mod_negotiation.so
# Deny-by-default
<Directory />
Order Allow,Deny
Deny from all
Options None
AllowOverride None
</Directory>
<Directory /srv/www>
Order allow,deny
Allow from all
Options FollowSymlinks Indexes
AllowOverride All
</Directory>
# Set up MIME content type recognition
TypesConfig /etc/mime.types
# Set up default documents for directory queries
DirectoryIndex index.html index.htm
# Enable automatic indexing of directories
Options +Indexes
IndexOptions FancyIndexing
HeaderName HEADER.html
# Suppress indexing and access to backup and working files
IndexIgnore "#*#" "*~" ".*" "configuration"
<FilesMatch (^#.*#$|.*~$|^\..*|^configuration$)>
Order allow,deny
Deny from All
</FilesMatch>
# Set up access to standard icons
Alias /icons/ /usr/share/apache2/icons/
<Directory /usr/share/apache2/icons/>
Order Allow,Deny
Allow from all
Options Indexes
</Directory>
# Set up icons and associated alt text
AddIconByType /icons/layout.gif text/html
AddAltByType "HTML file" text/html
AddIconByType /icons/text.gif text/plain
AddAltByType "Plain text" text/plain
AddIconByType /icons/generic.gif text/*
AddAltByType "Text" text/*
AddIconByType /icons/image2.gif image/*
AddAltByType "Static image" image/*
AddIconByType /icons/sound1.gif audio/*
AddAltByType "Audio" audio/*
AddIconByType /icons/movie.gif video/*
AddAltByType "Video" video/*
AddIconByType /icons/ps.gif application/postscript
AddAltByType "PostScript" application/postscript
AddIconByType /icons/pdf.gif application/pdf
AddAltByType "PDF" application/pdf
DefaultIcon /icons/ball.gray.gif
AddIcon /icons/dir.gif "^^DIRECTORY^^"
AddAlt "Directory" "^^DIRECTORY^^"
AddIcon /icons/back.gif ".."
AddAlt "Up" ".."
# Display file listings as a table
IndexOptions HTMLTable
# Set the error logging level to "info": informational messages.
# The default is "warn": warnings.
LogLevel info
# Specify the error log file - error.log in place of error_log
ErrorLog /var/log/apache2/error.log
LogFormat "%h %l %u %t \"%r\" %>s %b" clf
# We want hosts' names rather than address in the logs
HostnameLookups On
# Users' own web pages
<Directory /home/*/public_html>
Order Allow,Deny
Allow from all
Options Indexes
</Directory>
UserDir public_html
# Delegate control via "configuration" files
AccessFileName configuration
IndexIgnore configuration
<Directory /srv/www/>
AllowOverride All
</Directory>
# Raven authentication config
AACookieKey "now is the time for all good chickens to be counted"
AAKeyDir /etc/apache2/webauth_keys
<Directory /srv/www/WWW/bestiary>
Order Allow,Deny
Allow from cam.ac.uk
AuthType Ucam-WebAuth
AuthGroupFile /etc/apache2/access/group
Require group managers
Satisfy any
</Directory>
# Access to the Apache manual
AliasMatch ^/manual(?:/(?:de|en|es|fr|ja|ko|ru))?(/.*)?$ \
"/usr/share/apache2/manual$1"
<Directory "/usr/share/apache2/manual">
Options Indexes
AllowOverride None
Order allow,deny
Allow from all
<Files *.html>
SetHandler type-map
</Files>
SetEnvIf Request_URI ^/manual/(de|en|es|fr|ja|ko|ru)/ prefer-language=$1
RedirectMatch 301 ^/manual(?:/(de|en|es|fr|ja|ko|ru)){2,}(/.*)?$ \
/manual/$1$2
</Directory>
# Set up name-based virtual hosting on all interfaces.
NameVirtualHost *
<VirtualHost *>
ServerName www.dept.cam.ac.uk
DocumentRoot /srv/www/WWW
CustomLog /var/log/apache2/www.log clf
</VirtualHost>
<VirtualHost *>
ServerName prg.dept.cam.ac.uk
DocumentRoot /srv/www/PRG
CustomLog /var/log/apache2/prg.log clf
</VirtualHost>What's next? Having completed this course you are now in a position to follow up by adding modules that provide for extra facilities. The computing service has two follow-on courses from this one that build on this foundation.
Follow-on web server courses
This course introduces the use of the HTTPS (secure http) protocol used to protect communication between web browsers and web servers. This additional security is particularly appropriate when sensitive information is being transmitted (passwords, credit card numbers, personal details, etc) or when the identity of an end-user needs to be established securely.
The course is presented from the point of view of a web server administrator who wishes to configure servers to support such communication. It provides an overview of the https protocol and of related cryptographic components, including public key and symmetric key encryption, message digests and digital certificates as they relate to HTTPS. It also describes how to obtain certificates for web servers, and demonstrates the configuration of an Apache server to use HTTPS.
The Common Gateway Interface (CGI) underlies much of the modern web. It provides the most popular way by which web servers can respond to browser requests by invoking programs and using the resulting output as their response. CGI programs can make decisions based on information contained in browser requests, and so can be used for various tasks, including dynamic page generation, processing fill-in forms, interfacing to databases, implementing 'shopping carts', etc.
This two-afternoon course covers the CGI itself, various aspects of HTML and HTTP that are directly relevant to CGI programmers, and general CGI programming issues including security. CGI programs can be written in a variety of languages, and their use is supported by most web servers. This course uses the Perl scripting language to develop examples for use with an Apache web server running under Linux. However the vast majority of the material covered is applicable to other languages and servers, and should be readily understandable by anyone with programming experience. Some of the examples may be suitable for general use.
In addition, there are a whole range of other features that are available in Apache "out of the box" that may be of use in some circumstances.
Additional Apache features
There are a huge range of configuration commands for customising Apache's performance. While the default settings of all these are fine for a small personal site they will probably need adjusting for anything bigger.
Apache can take advantage of facilities in HTTP to allow it to automatically serve different content to different users. This is handled by an automatic process of negotiation and can include varying languages, character encodings and content types.
All the error messages produced by Apache can be customised.
Apache can automatically rewrite URLs. This can be particularly useful for ensuring that old URLs continue to work following site reorganisation.
Various facilities exist to control the HTTP headers that are sent with documents, including control of document expiry, automatically adding cookies, etc.
Documents can be automatically modified as they are served to include other files, dynamic information such as the date, etc.
Apache can be configured as an HTTP proxy, optionally also providing caching facilities.
Additional modules allow the Apache server itself to be monitored in real time.