Virtual Workshops

Part of keithjbrown.co.uk

Main Menu

• Server Environment
• MySQL
• PHP Databases
• Web Design
• Excel

Configuring Apache

Introduction

Although there are many sites around that cover aspects of Apache configuration (the official documentation for one) I have conceived this Virtual Workshop to aid the understanding of planned more specific workshops that will require some level of Apache configuration. Thus rather than assuming knowledge or sending the reader off to a different site to learn, I thought it better to develop a workshop that provides this backbone of information.

This workshop does not attempt to cover installation, but rather restricts itself to post installation editing of the httpd.conf file where all the configurations can be made and altered. It also important to note that this workshop uses the httpd.conf file from a source build of Apache 2.4x on linux, your own system the conf file may differ slightly.

Things to note before we start.

1. Configuration is controlled with a series of directives that are generally presented as the configurable element's name followed by a value or series of values.
2. All the Apache configuration directives are stored in a file called httpd.conf. This file can usually be found in a subdirectory called 'conf' wherever you have installed Apache, but may be in '/etc/httpd/conf/' if you are using Linux.
3. In order to apply any changes, the httpd.conf file must be saved and the server restarted.
4. The httpd.conf file is well commented so pay attention to what the comments say as well as my descriptions as the workshop progresses.
5. This is by no means a comprehensive guide, rather I will concentrate on areas that you are most likely to want to change rather than the configurations that can be left as the defaults. The Apache Manual is a pretty comprehensive guide to all configuration options.
6. The hash '#' character can be used at the beginning of a line to comment that line out (and by default many lines are commented out).
7. Lastly, the httpd.conf file is split into 3 main sections.

• Global Environment - this sets options that control how the server behaves in terms of processes, ports and additional modules that Apache uses, rather than anything about the server files, permissions etc.
• 'Main' server configuration - This is where the server root, log files, cgi-bin and everything else is configured.
• Virtual Hosts - Allows the configuration of virtual hosts where you can have one Apache server hosting many different web sites.

Global Environment Section

As stated above this section is concerned with the operation of the server processes. The section starts:

### Section 1: Global Environment
#
# The directives in this section affect the overall operation of Apache,
# such as the number of concurrent requests it can handle or where it
# can find its configuration files.

There then follows options that can be left as the default e.g. the ServerRoot (the base of the installation):

ServerRoot "/usr/local/apache/latest"

There are also directives concerning how many processes a server can launch to handle traffic etc and perhaps platform specific directives (i.e. specific to Netware or Windows or whatever) which may not been present if you have installed Apache from a package that has customised the httpd.conf file to some degree for you.

Listen

The first directive you may wish to change is the 'Listen' directive. This tells the server which IP address and which port to listen on for webpage requests. By default the config file will look something like this:

# Change this to Listen on specific IP addresses as shown below to 
# prevent Apache from glomming onto all bound IP addresses (0.0.0.0)
#
#Listen 12.34.56.78:80

Listen 80

This is telling the server to listen on all interfaces on port 80 (the default port for most web servers). This can be changed to a different port, say 8080:

Listen 8080

Or you could ensure that Apache only listens on one IP address (192.168.0.1):

Listen 192.168.0.1:80

As this should appear fairly straightforward, here are some situations that you may wish to make these changes.

• If you have to different web servers running on the same machine (perhaps Apache AND Microsoft's IIS for testing different hosting environments) you would need to have these running on different ports.
• It may be the case that you have two network interface cards in the machine (perhaps an internal network card and an external card that links to the Internet), but you only want Apache to listen for web traffic on the internal card only to serve Intranet pages.
• You may wish Apache to listen on two ports (perhaps implementing a proxy server on the second port).

Dynamic Shared Object (DSO) Support

The next section that should interest us is 'Dynamic Shared Object (DSO) Support' which allows us add additional modules to Apache to increase the server's functionality. Without getting too technical, some modules can be 'embedded' into the Apache program and other times they can be loaded dynamically from an external file. This section allows us to tell Apache which of these additional 'external' modules to load using the Loadmodule directive.

LoadModule  module_name      path/to/module

Typically the path is from the base of the Apache installation as specified in the ServerRoot directive. A full path to the module can be specified however can be the full path (especially on windows). So to give an example you probably want to use the PHP module.

LoadModule php4_module modules/libphp4.so

Or on windows (which uses a .dll file)

LoadModule php4_module c:/apache/php/sapi/php4Apache.dll

There are other directives that can go into this section but these are the main ones that you are likely to have to change.

'Main' server configuration

This section is where all of the server options that control the behaviour of the server are set. This includes where to look for files, where to log 'hits', what to do with files of a certain type etc. The first few directives are straight forward and usually well documented by the comments in the httpd.conf file.

Sets the user and group that the server will run as (and thus restricts the permissions that the server has over the server machine). It is fairly standard to create a 'nobody' user and group:

User  nobody
Group nobody

On certain platforms (such as windows) you don't need to specify the user/group and thus it may be omitted. Next is a simple directive to set the e-mail address of the server administrator...

ServerAdmin webmaster@keithjbrown.co.uk

...the server name (this should be commented out if you are using multiple virtual hosts)...

ServerName www.apachevirtualworkshop.com

...and a directive telling Apache whether to force the use of the ServerName (set above), so that if any client successfully connects to the server by not using the full ServerName (perhaps using a shorter machine hostname or IP Address) this will automatically be changed to be the 'correct' hostname. The default is...

UseCanonicalName Off

...and it is perfectly OK not to turn this feature on. Next is usually the DocumentRoot directive that sets the directory in which we will store all the web site files (note there is no trailing slash):

DocumentRoot "/usr/local/apache/htdocs"

Or on Windows:

DocumentRoot "c:\Apache\htdocs"

In order to carry on and look at the next section, it is best to take a step backwards and take a look at the overall directive before examining how it is typically implemented.

<Directory> Directive

For any directory that you plan to allow Apache to serve files from you must set certain options. These are directives are specific to that directory (and any sub-directories) only and within a 'container' <Directory> directive which is open and closed like so:

<Directory  /path/to/directory/>
	directive 1
	directive 2
	....
</Directory>

The common directives that are used within a <Directory> include options for the type of includes or script executions allowed, whether an .htaccess file is permitted and access controls.

The first directive is the Option directive which has the following potential values.

Value	Which allows...
ExecCGI	...the execution of scripts.
FollowSymLinks	...a symbolic link to be followed to another directory or file.
Includes	...Server Side Includes (SSI).
IncludesNOEXEC	...Server Side Includes except that the 'exec' elements wont work.
Indexes	...an index of a the directory to be displayed if no default file is found.
MultiViews	...different versions of the same resource (e.g. different language versions).
SymLinksIfOwnerMatch	...symbolic links to be followed, but only of the owner if the symlink is the same as the target directory or file.
All	...all the options (with the exception of multiviews).

Next there is the AllowOverride directive. The specifies which (if any) directives can be included in an .htaccess file. For those that don't know, an .htaccess file can be placed in any directory and can contain additional directives that are not globally applied in the httpd.conf file.

Value	Which allows...
AuthConfig	...authorization directives that control access based on users/passwords etc
FileInfo	...directives controlling document types such as ErrorDocument or Redirect which relate to the types of files being served.
Indexes	...directives controlling directory indexing such as DirectoryIndex (see below) or FancyIndexing.
Limit	...directives controlling host access using Allow and Deny (see below).
Options	...the use of the options directive discussed above.

For reasons of brevity not all the permissible directives will be discussed happen we upon them while continuing through the httpd.conf file, but they are likely to be incorporated into a future .htaccess virtual workshop or can be investigated in the Apache Manual. The final common directives that are found in the within the <Directory> directive are those which control access based on the host name.

Allow from IP or hostname
  
Deny from IP or hostname

And as well as these two directives there is the Order directive which tells Apache the order in which to apply these directives. If Allow is specified first...

Order Allow,Deny

...the server will first check to see if access is allowed according to any Allow directives and if so allow the request to be served. If not then any Deny directives are checked and if a rule is found then then the request is blocked and the appropriate error page (403 - access denied) returned by the server. If neither directive is matched in this order then Deny is assumed and once again access is denied. In the other order....

Order Deny,Allow

...Deny directives are evaluated first, then Allow directives and if there is no match then Allow is the default state.

Implementing a <Directory> Directive

With this newly acquired knowledge of the <Directory> directive let's examine how this is used in the httpd.conf file to allow access to our files. To begin with a very restrictive <Directory> directive is given that covers the entire filesystem:

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

This restricts the options for all all directories on a system to following symlinks and denying any overriding of the main httpd.conf file by a .htaccess file. Next the DocumentRoot directory is given the directives that allow pages to be served.

Note: It is likely that in your httpd.conf file the directives will be interspersed with comments and so will not appear exactly as shown.

<Directory "/usr/local/apache/htdocs">
	Options Indexes FollowSymLinks Includes
	AllowOverride None 
	Order allow,deny
	Allow from all
</Directory>

This particular default settings are too restrictive for my tastes as I like to use .htaccess files to set certain directives, so use the AllowOverride directive to enable .htaccess use.

<Directory "/usr/local/apache/htdocs">
	Options Indexes FollowSymLinks Includes
	AllowOverride AuthConfig FileInfo Indexes Limit
	Order allow,deny
	Allow from all
</Directory>

I never usually add options to the AllowOverride directive as those are probably best restricted to the httpd.conf file. Before finishing with this small section it is worth noting that there are some 'container' directives that work in a similar way. These are <Files> and <Location>.

<Files> matches the file types, for example to match all .gif images:

 <Files "*.gif">
	Directive 1
	Directive 2
	....
</Files>

<Location> matches the URL or URL path rather than the physical directory structure. So a URL of www.Apachevirtualworkshop.com/lessons would allow us to perform a match based on the URL '/lessons'.

 <Location "/lessons">
	Directive 1
	Directive 2
	....
</Location>

Note: Not all of the directives that can by placed within <Directory> can by used by <Files> or <Location>.

All three of these directives also have 'Match' counterparts - <DirectoryMatch>, <LocationMatch> and <FilesMatch> - that use a form of regular expression to create conditions, but again for reasons of brevity I'll skip past these and continue going through the httpd.conf file.

Also Note: The directives that are discussed in the rest of this 'Main' section are outside any <Directory> container and thus are applied globally to all directories. You can also choose to put most of these within a <Directory> directive to apply local setting to specific directories.

More 'Quick' Directives

Next there is usually a bit about setting up user directories for a multi-user environment, but again we will skip that bit. The next important directive is DirectoryIndex. This controls the names of files that can act as a 'default' file to be displayed when a directory is requested. For example if you request the URL 'www.Apachevirtualworkshop/newfiles/' then there is no actual file requested (rather a directory) and the server looks at the DirectoryIndex directive to see which files can be displayed by 'default'. Obviously if there is no file in the directory that matches the names of those in DirectoryIndex, then an index of files is displayed. The default configuration is:

DirectoryIndex index.html index.html.var

But I like to add much more options than that including the .shtml extension (for SSIs), .php and 'default.xxx' files as I got taught on a server that used that as default (about 1996 - see footnote) and it's has stuck. While you could put all these on one line, I tend to split the directive into two instances of DirectoryIndex on two lines.

DirectoryIndex default.shtml default.htm default.html default.php
DirectoryIndex index.shtml index.html index.htm index.php index.html.var 

Also note that the order you place these in determines which will be served if there are 2 or more matching files in a directory that are present, so that in the above example, default.shtml takes precedence over everything else, then default.htm, then default.html etc etc.

Then there is usually directives controlling the access file (.htaccess) and making sure that these configuration files cannot by viewed by a client, also we have some directives that control MIME types and these can be left alone with default settings. The next directive you may wish to change is HostnameLookups, which translates the IP address of the requesting machine to a fully qualified hostname. This hostname can subsequently be used in SSIs, scripts and is logged in the log files. Although turning this on does put an added resource burden on the server, I think it is worth doing and thus tend to enable this directive.

HostnameLookups On

Next let's skip down to the section on logs.

Configuring Log Files

To begin with let's look at the error log file. First you have to set the type of errors that you want to record using the LogLevel directive. The options for this directive are in order (with the highest first).

Option	Description
emerg	Emergencies - system is unusable.
alert	Action must be taken immediately
crit	Critical Conditions.
error	Error conditions.
warn	Warning conditions.
notice	Normal but significant condition.
info	Informational.
debug	Debug-level messages

It is worth noting that any level above that which you specify is also logged. So if the 'error' type is specified then errors of emerg, alert and crit are also logged. The default level is set to warn...

LogLevel warn

... and that is usually sufficient but if you are having any problems that aren't obvious (or you wish to optimise the server performance) setting a lower level would be a good idea. Since the level is set, the file in which to store errors can now be specified.

ErrorLog logs/error_log

This will store the errors in a log file within a logs directory below the ServerRoot directory. However you can specify a full path. for example on some Linux systems the logs from different applications are stored in the same area (perhaps /var/log/) thus you could specify that all the Apache logs get stored in one directory (httpd)...

ErrorLog /var/log/httpd/error_log

...or on windows:

ErrorLog c:\logs\error_log

The next log will control where all the hits on the server are stored for our later analysis. Apache allows us to control what is recorded through the use of several format strings, but has also established several combinations of these strings called Log Formats that are fairly standard and understood by log analysis programs.

Basically the format string is a percentage sign followed by character (note: uppercase and lowercase letters are two distinct characters) that denotes a specific piece of data to be recorded. A full list of these format strings is available as part of the Apache manual, what follows are some of the most commonly used in Log Formats.

Format String	Description
%h	The remote host of the machine requesting a server resource. This will be an IP address or if HostnameLookups has been enabled (as a successful lookup performed) then the hostname will be recorded.
%l	If the IndentityCheck directive is enabled then Apache will ask the requesting machine for the name of the user on that machine that requested the page. In reality the software that Apache tries to contact (identd) isn't being used on most machines and the additionally the overhead of an extra request back and forth slows things down. Thus this is normally disabled and a '-' appears in the logs where the username would appear.
%u	This is a local user. If you have set up a passworded area of your website, then the username of a logged in user will be recorded when they requesting pages. If no user is logged in another '-' will appear in the logs.
%t	The time of the request.
%r	First line of the request (see more below).
%s	Status. This is the status code of the request (for example 200 for success and 404 for not found). Specifying '%>s' with the addition of an angular bracket means the LAST request status is reported. This is useful if you have redirected any pages.
%b	Bytes Sent. Basically the size of the page.
%{header}i	The records different HTTP header values. (see below).

Again without getting too technical a little background explanation of how browsers and servers work is going to be required for some of these format strings to truly make sense. When a client requests a resource from a web server it does so using the HTTP protocol (this is why URLs are prefixed with 'http://'). This request takes via a collection of 'headers' (i.e. no body) sent to the web server by a browser and the web server will return a page (the body) but also more information in similar 'headers' as well. Below follows a brief example of what a web browser sends and receives (captured using Mozilla's LiveHTTPHeaders).

First the browsers sends a request to the webserver for the Virtual Workshops homepage following a link on this very page.

GET /vworks/ HTTP/1.1
Host: www.keithjbrown.co.uk
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; 
en-US; rv:1.4) Gecko/20030624
Accept: text/xml,application/xml,application/xhtml+xml,text/html;
q=0.9,text/plain; q=0.8,video/x-mng,image/png,image/jpeg,
image/gif;q=0.2,*/*;q=0.1
Accept-Language: en-gb,en-us;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://www.keithjbrown.co.uk/vworks/unix/apache.shtml

And what is next is that returned in the headers by Apache (just to show you - we're not interested in what Apache sends back).

HTTP/1.x 200 OK
Date: Tue, 22 Jul 2003 00:47:04 GMT
Server: Apache/2.0.43 (Unix) mod_ssl/2.0.43 OpenSSL/0.9.6g DAV/2 PHP/4.3.1
Accept-Ranges: bytes
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html; charset=ISO-8859-1

What is really interesting to us at this point is the request that the browser sends to out Apache server. If we examine the first line:

GET /vworks/ HTTP/1.1

This is the information that gets recorded by '%r' format string. If we look at the other lines, they consist of Name: Value pairs. We can record these values in the logs by using '%{header}i'. So we can record the 'User-Agent' (browser) that requested the page like so %{User-Agent}i . In this case Mozilla 1.4:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624

Or we can record the referer (this page) from where a hyperlink was followed %{Referer}i:

http://www.keithjbrown.co.uk/vworks/unix/apache.shtml

Hopefully, that has made clear the format strings, and now we will look at four Log Formats that Apache uses and people are familiar with. It is worth noting that:

• Format strings are interspersed with other characters (including spaces) that apply formatting to the logs. Specifically the use of the quotation mark characters. These quotes are escaped with a preceding backslash so that Apache doesn't think they surrounding a value.
• Log formats are defined using the LogFormat directive, a list of the format strings (and other characters) and finally the name of the Log Format.

The first LogFormat is the 'Common' LogFormat.

LogFormat "%h %l %u %t \"%r\" %>s %b" common

So that's HOST IDENT USER TIME FIRST_LINE STATUS SIZE. An example of what this would look like (from my own logs) is:

clt81-123.carolina.rr.com - - [22/Jul/2003:02:14:23 +0100] "GET /vworks/mysql/ HTTP/1.1" 200 10253

The second is a referer log format:

LogFormat "%{Referer}i -> %U" referer

Which records the referring URL (in this case a Google search) and the URL requested from your site ('%U'):

http://www.google.com/search?hl=en&ie=UTF-8&oe=UTF-8&q=keith+brown+virtual+workshops&btnG=Google+Search -> /vworks/mysql/

The third is the fairly straightforward agent log format:

LogFormat "%{User-agent}i" agent

Which, as we saw above, records the name of the browser used (in this case Mozilla Firebird 0.6).

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4b) Gecko/20030516 Mozilla Firebird/0.6

The final LogFormat combines all three log formats above into the imaginatively entitled 'Combined' format.

LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined

This produces the following.....

clt81-123.carolina.rr.com - - [22/Jul/2003:02:14:23 +0100] "GET /vworks/mysql/ HTTP/1.1" 200 10253 "http://www.google.com/search?hl=en&ie=UTF-8&oe=UTF-8&q=keith+brown+virtual+workshops&btnG=Google+Search" "Mozilla/5.0     (Windows; U; Windows NT 5.1; en-US; rv:1.4b) Gecko/20030516 Mozilla Firebird/0.6"

I use the Combined Log Format as it tells you the most information. I guess I could have just said that and moved on, but I think it is important to actually understand what you are recording in the logs. Anyway the final thing to do is to use the CustomLog directive to specify where to write the log entries and specify which log format to use.

CustomLog logs/access.log combined

Alias and ScriptAlias

The next 'important' bits are the Alias and ScriptAlias directives. These map a URL path to a directory outside the defined DocumentRoot and the only difference between the two is that ScriptAlias also conveys that the target directory contains scripts to the run through the CGI of the server.

By default the httpd.conf file contains examples of this working. These include an Alias to a directory filled with icons, a Alias to a local copy of the manual and a ScriptAlias to a cgi-bin. I guess the reasons for these Alias directives are to ensure that the icons and manual directories are not accidentally deleted when working day-to-day within the DocumentRoot, whereas it is important to have the cgi-bin (where scripts will be run from) in a more secure location than the DocumentRoot. Lets look at these in turn starting with icons.

On my server Apache has been installed is the directory "/usr/local/apache/latest/" and there is a subdirectory called icons (as well as manual and cgi-bin) to which we want to map the URL '/icons/' to. First we use the Alias directive specifying the URL then the physical location of the directory.

Alias /icons/ "/usr/local/apache/latest/icons/"

Then as this is outside our DocumentRoot we also need a new <Directory> directive to allow access to the icons directory.

<Directory "/usr/local/apache/latest/icons">
   Options Indexes MultiViews
   AllowOverride None
   Order allow,deny
   Allow from all
</Directory>

This works in exactly the same way for the manual pages.

Alias /manual "/usr/local/apache/latest/manual"

<Directory "/usr/local/apache/latest/manual">
   Options Indexes FollowSymLinks MultiViews IncludesNoExec
   AddOutputFilter Includes html
   AllowOverride None
   Order allow,deny
   Allow from all
</Directory>

The cgi-bin is slightly different as the <Directory> directive is very restrictive:

ScriptAlias /cgi-bin/ "/usr/local/apache/latest/cgi-bin/"

<Directory "/usr/local/apache/latest/cgi-bin">
    AllowOverride None
    Options None
    Order allow,deny
    Allow from all
</Directory>

Note: There are no options set on this directory that allow execution of scripts (ExecCGI), the ability to run scripts from this directory is set by the ScriptAlias directive alone.

After this section in most httpd.conf files there follows a lot of directives and configurations that can largely be left alone. This includes setting icons to associated with file types, language settings, potential to customise error pages etc etc. There is one bit buried amongst all that which is like to need attention and that is the AddType directive.

AddType and AddOutputFilter

If we stop and think about the different types of files that a web server (HTML, CSS, PHP, etc) they are really just text files but with different extensions. We do however want these text files to be identified in different ways. CSS files must be a particular mime type to validate and we need PHP files to use the PHP module for example.

There are two main directives to look at here, AddType and AddOutputFilter. AddType is used to define the mime type of a certain extension, whereas AddOutputFilter is used to tell Apache to do some sort of data processing before returning a request to a client. Once more without getting too involved in technicalities, there are two types of processing an Apache module can do (handle or filter). With modules such as PHP or mod_perl any special server-side processing is 'handled' by running the appropriate module. Apache knows which files to process in this manner by the file types we define. In other instances a module will use a filter (to manipulate the data as it passes through the server), and needs an explicit directive to define which files get processed as file type alone is not sufficient. Amongst many predefined examples of this in the default httpd.conf file, there are two directives (commented out) that enable Server Side Includes for files using a .shtml extension. You should uncomment these lines:

AddType text/html .shtml
AddOutputFilter INCLUDES .shtml

AddType defines .shtml files as text/html mime types and AddOutputFilter tells Apache to filter any output through mod_include. We also need to add another AddType directive that defines the PHP file type and thus tell Apache to use the PHP handler module for .php files.

AddType application/x-httpd-php .php

Of course you can add your own custom handlers etc once you become an Apache wizard, but this should suffice for this beginners tutorial.

What Else?

For reasons of brevity, and with the novice in mind, there are many directives in this section that I have skipped past because the default settings are good enough. There are also other directives which I think are useful (authentication directives and redirects etc) that I would normally have included, but I think would be better discussed as part of a planned .htaccess workshop. Thus the only section we have yet to examine is the 'Virtual Hosts' section of the httpd.conf.

Virtual Hosts Section

One of the most important features of Apache is the ability to host more that one website domain on the same machine, achieved by configuring 'Virtual Hosts' section of the httpd.conf file. There are two methods of defining a virtual host, one based on IP address (where each host as a separate IP address) or name-based (where one IP address is shared between different hosts and the host header is used to direct the traffic to the correct site).

IP Based Virtual Hosts

It is important that each IP address that you intend to use has been declared using the Listen directive, of course if you have chosen to listen for all traffic on port 80 this will be done automatically. To illustrate this section imagine that we have two sites with the following domain name - IP address mappings.

www.Apachevirtualworkshop.com 	- 192.168.0.1
www.learnaboutvhosts.com		- 192.168.0.2

Next we use the <VirtualHost> directive to specify a container for each IP address.

<VirtualHost 192.168.0.1>

</VirtualHost>

<VirtualHost 192.168.0.2>
  
</VirtualHost>

We can now place all the normal directives from the 'Main' section about within these 'containers'. For example:

<VirtualHost 192.168.0.1>
  	ServerAdmin webmaster@keithjbrown.co.uk
	ServerName www.Apachevirtualworkshop.com
	DocumentRoot "/websites/apachevirtualworkshop"
	
	<Directory "/websites/apachevirtualworkshop">
		Options Indexes FollowSymLinks Includes
		AllowOverride AuthConfig FileInfo Indexes Limit
		Order allow,deny
		Allow from all
	</Directory>
	
	ErrorLog /logs/apachevirtualworkshop/error_log
	CustomLog /logs/apachevirtualworkshop/access.log combined

</VirtualHost>

<VirtualHost 192.168.0.2>
    ServerAdmin webmaster@keithjbrown.co.uk
	ServerName www.learnaboutvhosts.com
	DocumentRoot "/websites/learnaboutvhosts"
	
	<Directory "/websites/learnaboutvhosts">
		Options Indexes FollowSymLinks Includes
		AllowOverride AuthConfig FileInfo Indexes Limit
		Order allow,deny
		Allow from all
	</Directory>
	
	ErrorLog /logs/learnaboutvhosts/error_log
	CustomLog /logs/learnaboutvhosts/access.log combined

</VirtualHost>

Name Based Virtual Hosts

As name based virtual hosts share an IP address things are slightly different when defining these virtual hosts. In this example both domains have the same IP address.

www.Apachevirtualworkshop.com 	- 192.168.0.1
www.namebasedvhosts.com			- 192.168.0.1

In order to allow Apache to implement name based virtual hosts you have to define the IP address that the sites use.

NameVirtualHost 192.168.0.1

The default is to listen on all devices (which can just be uncommented).

NameVirtualHost *

We still use the IP address (or wildcard) in the <VirtualHost> directive, but the ServerName becomes very important for this to work.

<VirtualHost *>
	ServerName www.Apachevirtualworkshop.com
	Other directives etc.....
</VirtualHost>

<VirtualHost *>
	ServerName www.namebasedvhosts.com	
	Other directives etc....
</VirtualHost>

It is worth noting that when this is functioning if no matching host is given by the client in the host header the first defined virtual host will be served. So if you were just to type in the IP address then the www.Apachevirtualworkshop.com would be served.

Which one to use?

In general it's fine to use name based virtual hosts, but in some circumstances security and functionality can be enhanced by a website having it's own IP address. A common fear is that sharing an IP address between sites may mean that if one site misbehaves and incurs some sort of IP based punishment (some search engines may stop crawling the site) then the other hosts are effected too. This is very rare and if you take an interest in the sites you are hosting then it is also unlikely to happen.

Conculsion

This has been a brief guide to Apache configuration and will act as a basis for future workshops that will attempt to address some webmaster issues in more depth. Planned workshops include how to use .htaccess files and how to implement a log rotation and analysis strategy. Thus it should be obvious that there is a whole lot more that can be done with Apache than the configurations discussed above.

Footnote

On reading this Virtual Workshop George McMurdo (who administered the first web server I used to host pages) e-mailed me to say that his choice for default.htm being used as the default page for a directory (as in the DirectoryIndex directive above) was a deliberate decision. Although the web server software of the time (Purveyor) used default.htm he continues to teach using this method as:

"Default is a value used by the computer if no other value is provided, and as DirectoryIndex is defining the page to display when only a directory is requested (and so no other page/value is 'provided'), default.htm is (IMHO) the correct choice, in computing terms. "

...thanks George.

Lastest 10 Threads - view all

---

Post a Comment or Question

Name

Email

URL (optional)

Title of Comment

Comment
HTML Allowed:
a,code,strong,em

I would like to be e-mailed any response to my comment.

In this section

• Using SSH
• Setting Up a Server
• Configuring Apache
• Managing Log Files

Related Reading

• Apache Manual

Related Books

Related Ads