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 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/index.html , the server looks for a file called /home/httpd/www.threeroomco.com/index.html . 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:

Table 20.1. Variables Used to Specify Hostname-Specific Home Directories

Variable	Description
%%	A single % in the directory name
%p	The port number on which the server runs
% N . M	Select parts of a name, as separated by periods. N is a number that refers to the period-separated component, with being the entire name, 1 being the first component, 2 being the second component, -1 being the last component, -2 being the next -to-last component, and so on. M is similar to N , but it refers to the characters within the name component. (You can omit M if you want to use an entire hostname component rather than a single character.)

 VirtualDocumentRoot /home/httpd/%-1/%-2 

In a configuration like this, a call to retrieve http://www.threeroomco.com/index.html causes Apache to look for /home/httpd/com/threeroomco/index.html . 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/index.html causes Apache to return /home/httpd/t/www.threeroomco.com/index.html , 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 index.html page includes a call to load products.html , Apache will try to retrieve products.html 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.