Advanced.Linux.Networking..Roderick.Smith [Electronic resources] نسخه متنی

Handling
Virtual Domains

You can use Apache to serve Web pages for a
single site, such as http://www.threeroomco.com , as
described earlier in this chapter. Suppose, though, that you want to host two
or more sites on one computer. Is this possible? Yes! In fact, Web hosting
services use this feature extensively, to host dozens, hundreds, or more Web
sites from a single Web server. The bulk of the configuration for handling
these virtual domains is the same as for a
simpler Apache configuration, but there are some special details to which you
must attend.

Why Use a Virtual Domain?

A virtual domain allows a Web server to
respond differently depending upon the name with which it's addressed. (This
requires you to point several different hostnames to the Web server computer in
DNS records for one or more domains.) There are several possible uses for such
a configuration, including the following:

If you're changing your domain name (or the Web
server's name within a single domain), you can have Apache display a message to
that effect on the old name, then redirect to the new name. In time, most of
the sites and bookmarks that link to the old name should be updated.

If two closely related companies, or even
departments within a single company, want to share a single Web server, you can
configure it to respond to appropriate names for each. In some cases
(particularly departments within a single company), using subdirectories may
make more sense than using distinct server names, though. Physically proximal
small businesses might want to use this approach to reduce their Internet
expenses.

An individual, members of a family, or roommates
might register separate domain names and host them all on a single computer. This
approach is most useful to individuals who have broadband Internet access with
ISPs that permit running personal servers.

You can go into the Web hosting business, and
set up a Web server to handle a large number of third-party Web sites. If this
is your goal, you'll need far more expertise than can be delivered by a single
Linux networking book, though.

As a general rule, the capacity of Apache to
handle domain hosting tasks is certainly most useful to large organizations and
ISPs that might want or need to handle multiple domains. Smaller-scale uses can
certainly be important for those who happen to be in appropriate situations,
though.

Virtual Domain Configuration Options

There are two common methods of handling
virtual domain hosting. One assigns different document root directories based
on the requested domain name, and the other allows you to set up a collection
of (possibly differing) options for each virtual domain.

Using VirtualDocumentRoot

One key virtual domain configuration option
is VirtualDocumentRoot . This directive lets you specify a directory name to be used as the
root of a request to the server, dependent upon the name used. To that end, you
can include several variables in the directory name you give to VirtualDocumentRoot , as outlined in href="http:// /JVXSL.asp?x=1&mode=section&sortKey=insertDate&sortOrder=desc&view=&xmlid=0-201-77423-2/ch20lev1sec7&open=true&title=New%20This%20Week&catid=&s=1&b=1&f=1&t=1&c=1&u=1#ch20table01#ch20table01"> Table 20.1 .

For instance, consider the following
directive:

VirtualDocumentRoot /home/httpd/%0
This results in the server using
subdirectories of /home/httpd named after the entire hostname by which the server is referenced. If
a call comes in for http://www.threeroomco.com/indexl ,
the server looks for a file called /home/httpd/www.threeroomco.com/indexl . This approach is very useful if you want to host many sites,
although it can create a large number of subdirectories directly under the base
directory ( /home/httpd in this example). If you know you'll be serving domains of a given
length, you might prefer something that further breaks up the directory
structure, like this:

VirtualDocumentRoot /home/httpd/%-1/%-2
In a configuration like this, a call to
retrieve http://www.threeroomco.com/indexl causes Apache to look for /home/httpd/com/threeroomco/indexl . Alternatively, you might want to alphabetize your virtual site
directories with a configuration like this:

VirtualDocumentRoot /home/httpd/%-2.1/%0
With this configuration, a URL of http://www.threeroomco.com/indexl causes Apache to return /home/httpd/t/www.threeroomco.com/indexl , if it exists. The %-2.1 variable returns the first ( .1 ) character
of the next-to-last ( -2 ) component of the hostname, so the directories are stored in
subdirectories by their domain names' first letters.

No matter what your precise VirtualDocumentRoot directive, you should set UseCanonicalName to Off , thus:

UseCanonicalName Off
When UseCanonicalName is set
to On , as is the default with most configurations, Apache uses what it
believes its hostname to be when doing relative references within Web sites. For
instance, if the indexl page includes a call to load productsl , Apache
will try to retrieve productsl from its canonical name. With a virtual domain, this lookup will
fail. Setting UseCanonicalName to Off changes Apache's behavior to use the hostname associated with the
virtual domain instead.

Using <VirtualHost>

Another approach to virtual hosting is to explicitly
define each virtual host. You do this by using two special directives:

NameVirtualHost This directive goes in the main Apache configuration file, and
informs Apache that you want to configure virtual hosts. The value of this
directive is normally either a single asterisk ( * ), in which case you
must define virtual hosts for all the server's definitions, or an IP address
associated with one interface, in which case the main server configuration
handles all requests except those that come on
the specified interface, and those are handled by the virtual host definitions.

<VirtualHost> This directive begins a specific virtual host definition block. It
takes a value that should be identical to the value given to NameVirtualHost . The directive block ends with a </VirtualHost> directive. Between these two are directives to specify the hosting directory
and otherwise customize the virtual host. You can include many of the same
directives within this block that you might use in a configuration that doesn't
use virtual hosts.

Two directives that you're likely to include
within the <VirtualHosts> block are ServerName (to set the name to which the block applies) and DocumentRoot . You
can also customize other features, such as enabling CGI. As an example,
consider the following lines, which set up a server to handle two virtual Web
sites:

NameVirtualHost * <VirtualHost *>

ServerName www.threeroomco.com DocumentRoot /home/httpd/threeroomco/html ScriptAlias /cgi-bin/ "/home/httpd/threeroomco/cgi-bin/"

</VirtualHost>

<VirtualHost *>

ServerName www.pangaea.edu DocumentRoot /home/httpd/pangaea-u/html </VirtualHost>

When a server so configured is accessed via
the www.threeroomco.com name, it serves files stored in /home/httpd/threeroomco/html as static files, and enables CGI scripts in /home/httpd/threeroomco/cgi-bin . When the server receives a request addressed to www.pangaea.edu , on the other hand, it serves the files from /home/httpd/pangaea-u/html . This latter configuration doesn't support CGI scripts. If a
request comes in using another name or the raw IP address, the first
configuration takes precedence, so such requests go through the www.threeroomco.com configuration in this example.

Compared to VirtualDocumentRoot , <VirtualHost> configurations make it easy to customize virtual hosts in unique
ways, or to place their files in arbitrary directories. The advantage of the VirtualDocumentRoot approach is that you don't need to reconfigure the server to add a
new domain; you need only create a new directory. In practice, most sites use
the <VirtualHost> approach, but you can pick whichever is more appropriate for your
purposes.