Virtual Hosts

The apache server can handle multiple web sites at a time

a web service provider company may have multiple different
sites to offer (see figure 6-2)
a single company may wish to partition their web site into
multiple domains (e.g., sales, accounting, management, research,
etc) (see figure 6-1)
a single organization may wish to give each user their own web
site

In any of these cases, the idea is to have the web server

create several virtual hosts
although in the last case, we just divide the file space up

We use the <VirtualHost> container for this, which allows

each host to have their own server-specific configuration
we can divide our hosts up based on IP addresses or IP aliases
<VirtualHost ipaddress>
the container looks like this:
ServerName ipalias
DocumentRoot path
</VirtualHost>

IP-Based
Assume that we want each of our servers to have a
unique IP address
in fact, we will have to set up the DNS entries so that all
of the different IP addresses resolve to the same IP
address, that of our web server
see figure 6-3

Now we place in our httpd.conf file <VirtualHost>

containers for each server
one container per server
this allows us to add more servers over time (or remove
servers) just by modifying the httpd.conf file
each virtual host will apply the overall server configuration but
you can also specify server-specific directives for each virtual
host as is needed
many of the directives we saw from chapter 5 that dealt with 1
server can be applied to any, each or some combination of servers

 Each <VirtualHost> container

will have its own unique IP
address
To the right, you see three
different servers
Notice how each server maps
to a different location under
DocumentRoot
We might create symbolic
links so that each company
can edit their own directory
from a location that they are
more familiar with
We can also set up our
various servers to respond to
different ports of the same IP
address (see the right below)

More
<VirtualHost 172.19.31.1>
ServerName www.company1.com
DocumentRoot /home/company1
</VirtualHost>
<VirtualHost 172.19.31.2>
ServerName www.company2.com
DocumentRoot /home/company2
</VirtualHost>
<VirtualHost 172.19.31.3>
ServerName www.company3.com
DocumentRoot /home/company3
</VirtualHost>
<VirtualHost 172.19.31.1:80>
ServerName www.company1.com
DocumentRoot /home/company1
</VirtualHost>
<VirtualHost 172.19.31.1:8080>
ServerName www.company2.com
DocumentRoot /home/company2
</VirtualHost>

Name-Based
If we want all of our servers
to share the same IP address,
there is only one major
difference required to the
apache server
we must add the directive
NameVirtualHost ipaddress to
our httpd.conf file where
ipaddress is the shared IP
address of all servers
this same address will be placed
in each servers <VirtualHost>
container

We will also have to ensure

that all DNS servers resolve
any of the servers aliases to
this same address

NameVirtualHost 172.19.31.1
<VirtualHost 172.19.31.1>
ServerName www.company1.com
DocumentRoot /home/company1
</VirtualHost>
<VirtualHost 172.19.31.1>
ServerName www.company2.com
DocumentRoot /company2
</VirtualHost>
<VirtualHost 172.19.31.1>
ServerName www.company3.com
DocumentRoot /home/company3
</VirtualHost>

 We can use the name-based

approach to allow multiple alias
names to map to the same server
by supplying numerous
ServerAlias directives within a
VirtualHost container
for instance, imagine that
www.company1.com wishes to
also be recognized by
company1.com,
www.company1.org,
www.company1.net and
sales.company1.com

We can also permit the * or ?

wildcard to save on the number
of entries we might want to put
into our container
however, this can easily result in
problems with respect to have
misspelled server names map to
the wrong thing

More
<VirtualHost 172.19.31.1>
ServerName www.company1.com
ServerAlias company1.com
ServerAlias www.company1.org
ServerAlias www.company1.net
ServerAlias sales.company1.com
DocumentRoot /home/company1
</VirtualHost>
Or
<VirtualHost 172.19.31.1>
ServerName www.company1.com
ServerAlias company1.com
ServerAlias *.company1.com
ServerAlias www.company1.*
DocumentRoot /home/company1
</VirtualHost>

Some Additional Comments

If we just add the previous entries into our httpd.conf file,
it does us no good unless we also ensure that DNS entries
have the same mappings
for instance, if you are at site X and issue an http request for
www.company1.org, if the DNS for site X does not map
www.company1.org to 172.19.31.1, then the http request
never makes it to our server for processing!
so we have to make sure that the DNS tables across the
Internet reflect the proper mappings
we have already set up a BIND server, so we will explore this in the
next labs

You can use both IP-based and Name-based virtual hosts

if desired by having some VirtualHosts share the same IP
address and others have different addresses
this will require that you use NameVirtualHost for any shared
address

Continued

If you are using name-based virtual hosts, then any

http request that reaches your server will already
have had the IP address resolved
because of this, we do not have to put IP addresses in our
VirtualHost containers, but can replace them with *
the * will match any IP address
only do this with the name-based approach, if you use the IPbased approach, then each virtual host maps to a unique address

If your computer has multiple IP addresses (e.g., an

internal address and an external address)
you can place all IP addresses in the VirtualHost container
(and the NameVirtualHost directive)
NameVirtualHost 172.19.31.12
NameVirtualHost 10.11.31.12
<VirtualHost 172.19.31.12 10.11.31.12> </VirtualHost>

Include Files
Recall that not all directives need to be placed in the
httpd.conf file
in fact, for virtual hosts, you would not want this because
each servers web administrator(s) will need to edit the
configuration file for that server
if all directives were shared in one file, then you would have to
give many different people access to that one file

typically, we want to place additional directives in an

htaccess file
these are directives that apply to a particular directory
however, it is likely that the directives desired by the
administrator(s) are ones to impact the entire virtual server

therefore, we allow the administrators to place these

server-wide directives in a different file, which is then
included with the httpd.conf directives via include
directives

More

The include statement is followed by the filename

the filename typically reflects the virtual hosts name
such as include www.company1.com

If there are multiple files to be included and they are

in the same directory, we can specify the directory
instead as in include /etc/httpd/includes
as an example, each servers administrator will probably
want their own error log
while we can set the Error Log files location in
httpd.conf, we can allow each servers administrator to
override this in their own include file

Many of the directives available in the server

context are also available in the virtual host context
but not all, for instance User, Group, StartServers,
ServerLimit, etc are only available in the server context
the next slide provides a partial list of useful <VH> directives

<VirtualHost> Directives

These are some of the directives that are generally thought to be

used for server configuration but can also be used in
<VirtualHost> containers

AcceptPathInfo
AccessFileName (to override .htaccess as the default access file name)
DefaultType
<Directory>, <Files>, <Location>, <IfDefine>, <IfModule>, <Limit>
Include
Options, SetHandler
KeepAlive, KeepAliveTimeout, TimeOut, MaxKeepAliveRequests
ServerAdmin, ServerName, ServerSignature
ErrorDocument, ErrorLog, LogLevel (covered in chapter 7)

There may not be useful reasons to alter the values as established

by the server configuration such as AcceptPathName and
DefaultType
On the other hand, the virtual host may use different types of
logging and want to establish different Options and Handlers

Overriding httpd.conf Directives

Recall that the outermost context is the servers settings

we do not want our individual administrators to have access to
httpd.conf but we want to allow them to have their own
specific directives in their include files
so, in our httpd.conf file, we need to add the AllowOverride
directive to any DocumentRoot directory
for instance, in the <VirtualHost> container for company1, you will
add <Directory /home/company1> and place the AllowOverride All
directive in that container

the question is, do we want to use All in our AllowOverride

or be more specific?
AllowOverride can have
None, All, or any subset of
this list:
AuthConfig, FileInfo,
Indexes, Limit, Options

see the example to the right

<Virtualhost 172.19.31.1>
ServerName www.company1.com
DocumentRoot /home/company1
<Directory /home/company1>
AllowOverride Indexes Options
</Directory>
</VirtualHost>

Example

NameVirtualHost 172.19.31.12
<Directory /var/www/hosts>
Order allow,deny
Deny from all
Establish protection for
</Directory>
directories above any
<VirtualHost 172.19.31.12>
virtual hosts directory
ServerName www.company1.com
DocumentRoot /var/www/hosts/company1
<Directory /var/www/hosts/company1> Override any directives and
protection from the previous
AllowOverride all
directory
Allow from all
</Directory>
</VirtualHost>
<VirtualHost 172.19.31.12>
ServerName www.company2.com
DocumentRoot /var/www/hosts/company2
<Directory /var/www/hosts/company2>
AllowOverride all
Allow from all
</Directory>
</VirtualHost>

Web Site Structure

Structure Continued
The httpd.conf file will store

all of the server-wide values

set up server directories (/, document root, cgi-bin)
set up the virtual hosts
include any conf files that might be virtual host wide
these files would be located under the virtual host directories so
that the virtual host web admins have access

set up initial Options and Deny/Allow permissions

permit overriding

Each virtual host will have

an Include file that contains virtual host-wide directives
(optional)
.htaccess files that will contain specific directives,
<Directory> containers and if necessary, <Files> and
<Location> containers

Continued

Server-wide directives will include

Listen, TCP directives

Deny/Allow for specific directories
under document root, -Indexes, +FollowSymLinks, +Includes,
-ExecCGI

Lets assume that dept1 will only permit specific users, then the
include file or .htaccess file for dept1 will need
LoadModule for the proper authentication
for the dept1 directory, authentication directives and a password file
(probably stored in that directory)

Let us further assume that dept2 will permit CGI execution, so

its Include file or .htaccess file will need
Options +ExecCGI
either its own cgi-bin directory, or the ability to place cgi code in
/var/cgi-bin and links

Finally, assume that the web administrator for company2 will

allow Indexes but not symbolic links, then the company2
.htaccess file will need
Options +Includes -FollowSymLinks

Virtual Host Performance and Status

The only real drawback to using virtual hosts is that
the more hosts you have, the worse the servers
performance will be
running 10 servers instead of 1 will probably result in 10
times the number of requests to service and thus the server
will be 10 times more busy
running 10 servers instead of 1 will probably require 10
times the amount of disk usage
an ISP that wishes to provide web server services will have to
take this into account when purchasing server hardware

To determine the status of the various servers, use

httpd S which will list
IP address and port (if different from the default server)
name of the server
location of DocumentRoot for the given server
we will examine status information in more detail in chapter 7

Other Performance Impacts

The flexibility of overriding directives sounds great,
as does the ability to place directives in include files
and htaccess files
however, directives are not just read once
for any http request, each htaccess file is read and the
overrides must be compared to any new directives
the more you override directives, the more you place specific
directives in htaccess files, and the more you separate server
directives from virtual host directives, you are creating more
work for your apache server

Is there some way to control this but still provide

flexibility?
you might want to limit the number of virtual hosts that
you are running on your apache server

Another Concern: Log Files

Aside from having performance problems by hosting
too many servers, you may also run out of log files
Unix/Linux limits the number of descriptors available to
any process to 64 (usually), file names are one example of
a descriptor but Apache tends to use 10-20 descriptors
internally
consider if each virtual server uses three log files, one for
successful accesses, one for errors, and one to log redirections
then there would be only be enough descriptors for perhaps 17
virtual hosts, possibly far fewer

One solution is to force all servers to use the same

log file(s)
but to include the hosts name in the log file
your customers may not like this as they may want to keep the
log information confidential

Another solution is to force each virtual host to use a

single log file

Configuring Many Similar VHs

Imagine that you have dozens of VHs that you
want to configure using <VH> containers
all of the containers will be nearly identical except for
the VirtualHost ServerName and DocumentRoot
it would be a hassle to enter the dozens of containers, or
even copy and paste them

the mod_vhost_alias module allows you to specify the

server names and it will create the <VH> containers
for you
it will fill in DocumentRoot names for each VH using
VirtualDocumentRoot /usr/local/apache2/htdocs/vhosts/%0
each host name (or host IP address) is filled in for %0
you can also use %1 or %2 for the names first part or second
part or %-1 or %-2 for last part or penultimate part or some
combination as in %1/%-1

Per User Directories

What happens when you use the URL
www.nku.edu/~foxr?
what does the ~foxr mean?
in Linux, ~foxr means user foxrs home directory
this is known as a user directory

How do we set up user directories in general

by permitting user directories, rather than directories
under DocumentRoot, users can edit their web sites from
their own home directories

These are known as per user directories (part of the

mod_userdir module, which is part of Apaches core)
to establish one, you add the directive UserDir dirname
dirname is the name of the directory underneath each users home
directory where their web pages will be found
this typically defaults to public_html

More

We could put the user directories outside of their home

directories, for instance in /var/web by using UserDir
/var/web/*/public_html, but this defeats the idea of users
have easy access to their web directories
The UserDir directive allows you to include the argument
disabled or enabled
the enabled/disabled options are used to control whether a
specific user has their own user directory
you can place as many individual users in a list as you want, or
leave it blank (to indicate all users)
for instance, imagine that you want all regular users to have a
user directory of public_html but you do not want root or apache
to
UserDir enabled
UserDir disabled root apache

-- the default user dir is public_html

-- so we dont need to specify it here