mass.xml revision 206b5dce9e48924aa9f12ce87f14856a4cd3fb68
<?xml version='1.0' encoding='UTF-8' ?>
<!-- $LastChangedRevision$ -->
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
contributor license agreements. See the NOTICE file distributed with
this work for additional information regarding copyright ownership.
The ASF licenses this file to You under the Apache License, Version 2.0
(the "License"); you may not use this file except in compliance with
the License. You may obtain a copy of the License at
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
-->
<manualpage metafile="mass.xml.meta">
<parentdocument href="./">Virtual Hosts</parentdocument>
<title>Dynamically Configured Mass Virtual Hosting</title>
<summary>
<p>This document describes how to efficiently serve an
arbitrary number of virtual hosts with the Apache httpd webserver.
</p>
</summary>
<section id="motivation"><title>Motivation</title>
<p>The techniques described here are of interest if your
<code><VirtualHost></code> sections that are
substantially the same, for example:</p>
<example>
NameVirtualHost 111.22.33.44<br />
<VirtualHost 111.22.33.44><br />
<indent>
ServerName www.customer-1.com<br />
</indent>
</VirtualHost><br />
<VirtualHost 111.22.33.44><br />
<indent>
ServerName www.customer-2.com<br />
</indent>
</VirtualHost><br />
# blah blah blah<br />
<VirtualHost 111.22.33.44><br />
<indent>
ServerName www.customer-N.com<br />
</indent>
</VirtualHost>
</example>
<p>The basic idea is to replace all of the static
<code><VirtualHost></code> configurations with a mechanism
that works them out dynamically. This has a number of
advantages:</p>
<ol>
<li>Your configuration file is smaller, so Apache starts
more quickly and uses less memory.</li>
<li>Adding virtual hosts is simply a matter of creating the
appropriate directories in the filesystem and entries in the
DNS - you don't need to reconfigure or restart Apache.</li>
</ol>
<p>The main disadvantage is that you cannot have a different log file for
each virtual host; however, if you have many virtual hosts, doing
this can be a bad idea anyway, because of the number of file
descriptors needed. It is better to log to a pipe or a fifo, and arrange for
the process at the other end to distribute the logs to the customers.
(This can also be used to accumulate statistics, etc.).</p>
</section>
<section id="overview"><title>Overview</title>
<p>A virtual host is defined by two pieces of information: its
IP address, and the contents of the <code>Host:</code> header
in the HTTP request. The dynamic mass virtual hosting technique
used here is based on automatically inserting this information into the
pathname of the file that is used to satisfy the request. This
can be most easily done by using <module>mod_vhost_alias</module>
with Apache 2.0. Alternatively, <module>mod_rewrite</module> can be used.
Both of these modules are disabled by default; you must enable
one of them when configuring and building Apache if you want to
use this technique.</p>
<p>A couple of things need to be `faked' to make the dynamic
virtual host look like a normal one. The most important is the
server name, which is used by Apache to generate
self-referential URLs etc. It is configured with the
<code>ServerName</code> directive, and it is available to CGIs
via the <code>SERVER_NAME</code> environment variable. The
actual value used at run time is controlled by the <directive
module="core">UseCanonicalName</directive>
setting. With <code>UseCanonicalName Off</code>, the server name
is taken from the contents of the <code>Host:</code> header in the
request. With <code>UseCanonicalName DNS</code>, it is taken from a
reverse DNS lookup of the virtual host's IP address. The former
setting is used for name-based dynamic virtual hosting, and the
latter is used for IP-based hosting. If Apache cannot work out
the server name because there is no <code>Host:</code> header,
or the DNS lookup fails, then the value configured with
<code>ServerName</code> is used instead.</p>
<p>The other thing to `fake' is the document root (configured
with <code>DocumentRoot</code> and available to CGIs via the
<code>DOCUMENT_ROOT</code> environment variable). In a normal
configuration, this is used by the core module when
mapping URIs to filenames, but when the server is configured to
do dynamic virtual hosting, that job must be taken over by another
module (either <code>mod_vhost_alias</code> or
<code>mod_rewrite</code>), which has a different way of doing
the mapping. Neither of these modules is responsible for
setting the <code>DOCUMENT_ROOT</code> environment variable so
if any CGIs or SSI documents make use of it, they will get a
misleading value.</p>
</section>
<section id="simple"><title>Simple Dynamic Virtual Hosts</title>
virtual host arrangement outlined in the <a
href="#motivation">Motivation</a> section above, but in a
generic fashion using <code>mod_vhost_alias</code>.</p>
<example>
# get the server name from the Host: header<br />
UseCanonicalName Off<br />
<br />
# this log format can be split per-virtual-host based on the first field<br />
LogFormat "%V %h %l %u %t \"%r\" %s %b" vcommon<br />
<br />
# include the server name in the filenames used to satisfy requests<br />
</example>
<p>This configuration can be changed into an IP-based virtual
hosting solution by just turning <code>UseCanonicalName
Off</code> into <code>UseCanonicalName DNS</code>. The server
name that is inserted into the filename is then derived from
the IP address of the virtual host.</p>
</section>
<section id="homepages"><title>A Virtually Hosted Homepages System</title>
<p>This is an adjustment of the above system, tailored for an
ISP's homepages server. Using a slightly more complicated
configuration, we can select substrings of the server name to
use in the filename so that, for example, the documents for
directory instead of one per virtual host.</p>
<example>
# all the preliminary stuff is the same as above, then<br />
<br />
# include part of the server name in the filenames<br />
<br />
# single cgi-bin directory<br />
</example>
<p>There are examples of more complicated
<code>VirtualDocumentRoot</code> settings in the
<module>mod_vhost_alias</module> documentation.</p>
</section>
<section id="combinations"><title>Using Multiple Virtual
Hosting Systems on the Same Server</title>
<p>With more complicated setups, you can use Apache's normal
<code><VirtualHost></code> directives to control the
scope of the various virtual hosting configurations. For
example, you could have one IP address for general customers' homepages,
and another for commercial customers, with the following setup.
This can, of course, be combined with conventional
<code><VirtualHost></code> configuration sections.</p>
<example>
UseCanonicalName Off<br />
<br />
LogFormat "%V %h %l %u %t \"%r\" %s %b" vcommon<br />
<br />
<indent>
Options FollowSymLinks<br />
AllowOverride All<br />
</indent>
</Directory><br />
<br />
<indent>
Options FollowSymLinks<br />
AllowOverride None<br />
</indent>
</Directory><br />
<br />
<VirtualHost 111.22.33.44><br />
<indent>
ServerName www.commercial.isp.com<br />
<br />
<br />
</indent>
</VirtualHost><br />
<br />
<VirtualHost 111.22.33.45><br />
<indent>
ServerName www.homepages.isp.com<br />
<br />
<br />
</indent>
</VirtualHost>
</example>
<note>
<title>Note</title>
<p>If the first VirtualHost block does <em>not</em> include a
<directive module="core">ServerName</directive> directive, the reverse
DNS of the relevant IP will be used instead.
If this is not the server name you
wish to use, a bogus entry (<code>ServerName
none.example.com</code>) can be added to get around this
behaviour.</p>
</note>
</section>
<section id="ipbased"><title>More Efficient IP-Based Virtual Hosting</title>
<p>The configuration changes suggested to turn <a href="#simple">the first
example</a> into an IP-based virtual hosting setup result in
a rather inefficient setup. A new DNS lookup is required for every
request. To avoid this overhead, the filesystem can be arranged to
correspond to the IP addresses, instead of to the host names, thereby
negating the need for a DNS lookup. Logging will also have to be adjusted
to fit this system.</p>
<example>
# get the server name from the reverse DNS of the IP address<br />
UseCanonicalName DNS<br />
<br />
# include the IP address in the logs so they may be split<br />
LogFormat "%A %h %l %u %t \"%r\" %s %b" vcommon<br />
<br />
# include the IP address in the filenames<br />
</example>
</section>
Virtual Hosts Using <module>mod_rewrite</module></title>
thing as <a href="#simple">the first example</a>. The first
half is very similar to the corresponding part above, except for
some changes, required for backward compatibility and to make the
<code>mod_rewrite</code> part work properly; the second half
configures <code>mod_rewrite</code> to do the actual work.</p>
<p>There are a couple of especially tricky bits: by default,
<code>mod_rewrite</code> runs before other URI translation
modules (<code>mod_alias</code> etc.) - so if you wish to use these modules, <code>mod_rewrite</code> must be configured to accommodate
them. Also, some magic is required to do a
per-dynamic-virtual-host equivalent of
<code>ScriptAlias</code>.</p>
<example>
# get the server name from the Host: header<br />
UseCanonicalName Off<br />
<br />
# splittable logs<br />
LogFormat "%{Host}i %h %l %u %t \"%r\" %s %b" vcommon<br />
<br />
<indent>
# ExecCGI is needed here because we can't force<br />
# CGI execution in the way that ScriptAlias does<br />
Options FollowSymLinks ExecCGI<br />
</indent>
</Directory><br />
<br />
# now for the hard bit<br />
<br />
RewriteEngine On<br />
<br />
# a ServerName derived from a Host: header may be any case at all<br />
RewriteMap lowercase int:tolower<br />
<br />
## deal with normal documents first:<br />
# allow Alias /icons/ to work - repeat for other aliases<br />
RewriteCond %{REQUEST_URI} !^/icons/<br />
# allow CGIs to work<br />
RewriteCond %{REQUEST_URI} !^/cgi-bin/<br />
# do the magic<br />
<br />
## and now deal with CGIs - we have to force a handler<br />
RewriteCond %{REQUEST_URI} ^/cgi-bin/<br />
<br />
# that's it!
</example>
</section>
Homepages System Using <code>mod_rewrite</code></title>
<p>This does the same thing as <a href="#homepages">the second
example</a>.</p>
<example>
RewriteEngine on<br />
<br />
RewriteMap lowercase int:tolower<br />
<br />
# allow CGIs to work<br />
RewriteCond %{REQUEST_URI} !^/cgi-bin/<br />
<br />
# check the hostname is right so that the RewriteRule works<br />
RewriteCond ${lowercase:%{SERVER_NAME}} ^www\.[a-z-]+\.isp\.com$<br />
<br />
# concatenate the virtual host name onto the start of the URI<br />
# the [C] means do the next rewrite on the result of this one<br />
RewriteRule ^(.+) ${lowercase:%{SERVER_NAME}}$1 [C]<br />
<br />
# now create the real file name<br />
RewriteRule ^www\.([a-z-]+)\.isp\.com/(.*) /home/$1/$2<br />
<br />
# define the global CGI directory<br />
</example>
</section>
<section id="xtra-conf"><title>Using a Separate Virtual
Host Configuration File</title>
<p>This arrangement uses more advanced <module>mod_rewrite</module>
features to work out the translation from virtual host to document
root, from a separate configuration file. This provides more
flexibility, but requires more complicated configuration.</p>
this:</p>
<example>
# ...<br />
</example>
<example>
RewriteEngine on<br />
<br />
RewriteMap lowercase int:tolower<br />
<br />
# define the map file<br />
<br />
# deal with aliases as above<br />
RewriteCond %{REQUEST_URI} !^/icons/<br />
RewriteCond %{REQUEST_URI} !^/cgi-bin/<br />
RewriteCond ${lowercase:%{SERVER_NAME}} ^(.+)$<br />
# this does the file-based remap<br />
RewriteCond ${vhost:%1} ^(/.*)$<br />
<br />
RewriteCond %{REQUEST_URI} ^/cgi-bin/<br />
RewriteCond ${lowercase:%{SERVER_NAME}} ^(.+)$<br />
RewriteCond ${vhost:%1} ^(/.*)$<br />
</example>
</section>
</manualpage>