Apache Server Survival Guide asg04.htm
4
Virtual Hosts
This chapter covers a powerful feature of the Apache server: virtual hosts. Virtual hosting allows a single instance of the Apache Web server to run several Web sites, each accessible by its own domain name. Apache was one of the first HTTP servers to provide support for building virtual sites. While servers from NCSA and others also provide virtual-site support, Apache provides better performance and has more features than the others.
At first glance, the main advantage of a virtual site seems mostly cosmetic: It allows many Web sites to be addressed by their own domain name on a single shared machine. However, this cosmetic advantage has several positive effects on the administration of your site and how others use it. Virtual hosts are frequently created with the intent to do the following:
- Make it easier for customers to access Web sites on leased servers. Since the lessee can use his own domain name, addresses tend to be shorter. This helps to project a professional identity to the world. Users are more likely to remember the shorter address since the domain name (hopefully) has some relevance to the corporate name.
- Reduce and maximize the computer and networking hardware. Several low-traffic sites can be housed in a single machine, thus reducing the costs of hosting the site.
- Reduce the human costs associated with system administration. Instead of managing and configuring a dedicated server for each domain, the webmaster only needs to maintain a few configuration files and a minimal number of boxes. This translates into a reduced number of systems that need to be upgraded or maintained, thus simplifying network maintenance.
Because most Web sites don't generate enough traffic to exhaust the resources of a single machine, it is desirable from an administrative point of view to allow a single server to masquerade and behave as several different machines. Instead of dedicating hardware and monetary resources to each site hosted, a few server configuration commands produce the same result: a virtual site. Because the expense required to set up a Web server can be shared between several sites, the time required to configure and manage Web sites is reduced dramatically.
Virtual hosts have the positive side effect of making Web pages portable. When a site is virtual, it’s easy to move it to a different Web server in the same network or somewhere else. It becomes a matter of transferring the site's HTML pages to a new machine and modifying the site's Domain Name System (DNS) information to point to the new server. To accommodate DNS update lapses, simply create a redirection on the old server. This allows traffic to continue flowing without a lapse, which is an important issue with sites that thrive on traffic as a way of generating business.
Historically, when you wanted a site hosted using your domain, your only viable option was to purchase (or lease) a computer and have it configured as a Web server. Incurred with these costs was the expense of managing the server. These costs, easily thousands of dollars, motivated Internet Service Provider (ISPs) to consider additional ways of supporting multiple Web sites in one host, which resulted in a few early solutions, such as the "home page" approach.
The home page approach was one early way to support multiple sites on a single Web server. This approach differentiates each site by adding extra address information, such as a user's home paqe.
The home page approach creates addresses that look like this:
http://www.isp.dom/~name
or, worse yet, uniform resource locators (URLs) that list some path to a directory on the server tree:
http://www.isp.dom/name
The home page approach is an appropriate way to serve local users' pages. But when it comes to serving corporate information that is going to be accessed more frequently and by a large number of viewers, this solution creates ugly addresses that are hard to remember, long to type, prone to user error, and not very professional looking.
Building a Virtual Site
The terms virtual host, virtual site, and multihomed server are generally used interchangeably to describe a server that supports multiple domain names. To make matters easier to understand, I find it best to limit the scope of these terms to their appropriate meanings: To create a virtual site, you need to configure a virtual host; for the virtual host to work, you may have to create a multihomed server; and obviously, there's a difference in tone. How you build a multihomed server depends on which version of Apache you are using and some other technical issues. "So what's the difference?" you ask. Semantics; but clarity here will help in describing the process.
A multihomed computer is one that can answer to multiple IP addresses. A computer that is accessible by multiple names (such as mailhost.foo.com and www.foo.com) that resolve to the same IP address is not a multihomed computer.
Aliasing a capability provided by DNS in a CNAME (canonical name) resource record or by listing multiple machine names on the /etc/hosts file after an IP address, is just a convenience for people accessing a networked resource. In general, people have a hard time remembering names, and some names such as www or ftp are typically standardized for machines that host services with the same name. Users only need to remember the domain name when those resources use traditional names, such as www.apple.com, mailhost.apple.com, or ftp.apple.com. A multihomed computer needs more than that. It must answer to two or more different IP addresses such as 1.2.3.4. IP addresses are assigned by your Internet network provider when you sign up with them.
A virtual site is a Web site that resides on a server with other Web sites. Each Web site is accessible by its own name and shares all the hardware resources with other virtual sites. Although all requests are answered by the same HTTP server process, different home pages are returned for each site depending on the name or IP address used to access the information.
Another networking issue that you will have to address before you can multihome is the DNS; DNS provides the machine name to the IP translation service. While computers like to address each other using numbers, people prefer using names. DNS translates names into numbers and numbers into names. Chances are that if you have a connection to the Internet, you are running a name server. If you are not, someone else is running it for you. If you are not running your own DNS, you'll need to coordinate with your network administrator to implement any addition or change to the DNS.
Configuring a Virtual Host
A virtual site is configured by the <VirtualHost> directive, which allows you to override several configuration directives based on the site's name or IP address. This allows you to specify a different DocumentRoot directory for each virtual site, so a single instance of the HTTP server can return different Web sites for each of the virtual sites it hosts.
Right from the beginning, the Apache server provided the necessary infrastructure to allow server-side support for virtual hosts. The only requirement was that the server needed to answer to different IP addresses. This technique, which still works reliably, requires the creation of a multihomed server. Multihomed servers have a few downsides, including a built-in limit: The number of virtual hosts that can be supported depends on how many IP addresses you have available. Each virtual host requires its own unique IP address. This requirement made it easy for an ISP to swallow up scarce IP addresses with only a few customers.
In the current incarnation of the server, the Apache group introduced a non–IP-intensive solution. Using a new extension to the HTTP protocol, which requires the browser to report the name of the server being accessed (the http://www.apple.com portion of the URL) along with the resource to retrieve, the Web server can determine who the request is for. Before, an URL such as http://www.apple.com/index.html would have the www.apple.com portion removed from the request, making it impossible for the server to determine the name of the host as known by the user. This new mechanism effectively added the infrastructure from which Apache could provide virtual site support without the need to create a multihomed computer. Non–IP-intensive virtual hosts make it possible to host an almost infinite number of virtual hosts easily, without the need to create a multihomed server.
The <VirtualHost> Directive Section
The <VirtualHost> and </VirtualHost> section tags are used to group server configuration directives that only apply to a particular virtual host. Any directive that is allowed in a virtual host context can be used. When the server receives a request directed toward a virtual host, the configuration directives enclosed between the <VirtualHost> and </VirtualHost> section tags override directives found elsewhere. <VirtualHost> sections are found in the httpd.conf file.
You specify the host to which a <VirtualHost> section applies by specifying the IP of the virtual host or a fully qualified domain name. A minimal virtual host only needs to override the DocumentRoot directive:
<VirtualHost www.company.com> DocumentRoot /www/docs/company </VirtualHost>
The <VirtualHost> declaration> for non–IP-intensive virtual hosts, based on the HTTP/1.1 feature previously described , is almost identical to the original IP-intensive version, except that you only supply a machine name that resolves to the same IP address as the real host. The server decides what to serve based on the machine name used to access the resource.
This approach only works with browsers that comply to the HTTP/1.1 specification, which is still a draft.. Hopefully this will become part of the specification and will be more widely implemented.
For IP-intensive virtual hosts, each host IP identified by the <VirtualHost> directive must be unique and, in order for it to work, the computer must be configured to accept multiple IP addresses. This configuration, unlike that of the new non-IP virtual hosts, works regardless of the browser.
The <VirtualHost> section allows configuration of a virtual host as if it were a simple single-homed server; it allows you to implement customized server configuration settings on a per-site basis. Each site can tailor the server to its own needs.
A minimal virtual host configuration only needs to make use of the DocumentRoot directive. You can further customize the virtual server with ServerName directives, which will set the name the server will use when responding to requests. You are able to include many of the directives that can be specified in the server configuration file (httpd.conf) or in the resource configuration file (srm.conf). This gives total control over the configuration and behavior of the virtual server. You can even enable logging of the transaction to different log files. The following configuration presents a more complete and typical example:
