 |  |
| |
On site.twocopy (see Section 4.3, later in this chapter) we run two different versions of Apache, each serving a different host. As we have said, you might want to do this to optimize the two versions in different ways. However, it is more common to run a number of virtual Apache servers that steer incoming requests on different URLs (usually with the same IP address) to different sets of documents. These might well be home pages for members of your organization or your clients.
In the first edition of this book, we showed how to do this for Apache 1.2 and HTTP 1.0. The result was rather clumsy, with a main host and a virtual host, but it coped with HTTP 1.0 clients. However, the setup can now be done much more neatly with the NameVirtualHost directive. The possible combinations of IP-based and name-based hosts can become quite complex. A full explanation with examples and the underlying theology can be found at http://www.apache.org/docs/vhosts, but several of the possible permutations are unlikely to be very useful in practice.
This is by far the preferred method of managing virtual hosts, taking advantage of the ability of HTTP 1.1-compliant browsers (or at least browsers that support the Host header . . . pretty much all of them at this point) to send the name of the site they want to access. At .../site.virtual/Name-based we have www.butterthlies.com and sales. butterthlies.com on 192.168.123.2. Of course, these sites must have their names registered in DNS (or, if you are dummying the setup as we did, included in /etc/hosts). The Config file is as follows:
User webuser Group webgroup NameVirtualHost 192.168.123.2 <VirtualHost www.butterthlies.com> ServerName www.butterthlies.com ServerAdmin sales@butterthlies.com DocumentRoot /usr/www/APACHE3/APACHE3/site.virtual/htdocs/customers ErrorLog /usr/www/APACHE3/APACHE3/site.virtual/Name-based/logs/error_log TransferLog /usr/www/APACHE3/APACHE3/site.virtual/Name-based/logs/access_log </VirtualHost> <VirtualHost sales.butterthlies.com> ServerName sales.butterthlies.com ServerAdmin sales@butterthlies.com DocumentRoot /usr/www/APACHE3/APACHE3/site.virtual/htdocs/salesmen ServerName sales.butterthlies.com ErrorLog /usr/www/APACHE3/APACHE3/site.virtual/Name-based/logs/error_log TransferLog /usr/www/APACHE3/APACHE3/site.virtual/Name-based/logs/access_log </VirtualHost>
The key directive is NameVirtualHost, which tells Apache that requests to that IP number will be subdivided by name. It might seem that the ServerName directives play a crucial part, but here they just provide a name for Apache to return to the client. The <VirtualHost> sections are now identified by the name of the site we want them to serve. If this directive were left out, Apache would issue a helpful warning that www.butterthlies.com and sales.butterthlies.com were overlapping (i.e., rival interpretations of the same IP number) and that perhaps we needed a NameVirtualHost directive, which indeed we would.
The virtual sites can all share log files, as shown in the given Config file, or they can use separate ones.
NameVirtualHost allows you to specify the IP addresses of your name-based virtual hosts.
NameVirtualHost address[:port] Server config
Optionally, you can add a port number. The IP address has to match with the IP address at the top of a <VirtualHost> block, which must include a ServerName directive followed by the registered name. The effect is that when Apache receives a request addressed to a named host, it scans the <VirtualHost> blocks having the same IP number that was declared with a NameVirtualHost directive to find one that includes the requested ServerName. Conversely, if you have not used NameVirtualHost, Apache looks for a <VirtualHost> block with the correct IP address and uses the ServerName in the reply. This prevents people from getting to hosts blocked by the firewall by using the IP of an open host and the name of a blocked one.
In the authors' experience, most of the Web still uses IP-based hosting, because although almost all clients use browsers that support HTTP 1.1, there is still a tiny portion that doesn't, and who wants to lose business unnecessarily? However, the Internet is running out of IP addresses, and people are gradually moving to name-based hosting.
This is how to configure Apache to do IP-based virtual hosting. The Config file is as follows:
User webuser Group webgroup # we don't need a NameVirtualHost directive <VirtualHost 192.168.123.2> ServerName www.butterthlies.com ServerAdmin sales@butterthlies.com DocumentRoot /usr/www/APACHE3/APACHE3/site.virtual/htdocs/customers ErrorLog /usr/www/APACHE3/APACHE3/site.virtual/IP-based/logs/error_log TransferLog /usr/www/APACHE3/APACHE3/site.virtual/IP-based/logs/access_log </VirtualHost> <VirtualHost 192.168.123.3> ServerName sales-IP.butterthlies.com ServerAdmin sales@butterthlies.com DocumentRoot /usr/www/APACHE3/APACHE3/site.virtual/htdocs/salesmen ErrorLog /usr/www/APACHE3/APACHE3/www/APACHE3/APACHE3/site.virtual/IP-based/logs/ error_log TransferLog /usr/www/APACHE3/APACHE3/site.virtual/IP-based/logs/access_log </VirtualHost>
We don't need a NameVirtualHost directive, but we do need ServerName directives in each of the VirtualHost blocks. This setup responds nicely to requests to http://www.butterthlies.com and http://sales-IP.butterthlies.com. The way our machine was configured, it also served up the customers' page to a request on http://sales.butterthlies.com — which is to be expected since they share a common IP number. This method applies to sites that use SSL — see Chapter 11 for more details. However, the basic issue derives from the fact that certificate processing takes place before the server sees the Host header.
You can, of course, mix the two techniques. <VirtualHost> blocks that have been NameVirtualHost edwill respond to requests to named servers; others will respond to requests to the appropriate IP numbers. This will also be important when we look at Apache SSL (see Chapter 11):
User webuser Group webgroup NameVirtualHost 192.168.123.2 <VirtualHost www.butterthlies.com> ServerAdmin sales@butterthlies.com DocumentRoot /usr/www/APACHE3/APACHE3/site.virtual/htdocs/customers ErrorLog /usr/www/APACHE3/APACHE3/site.virtual/IP-based/logs/error_log TransferLog /usr/www/APACHE3/APACHE3/site.virtual/IP-based/logs/access_log </VirtualHost> <VirtualHost sales.butterthlies.com> ServerAdmin sales@butterthlies.com DocumentRoot /usr/www/APACHE3/APACHE3/site.virtual/htdocs/salesmen ServerName sales.butterthlies.com ErrorLog /usr/www/APACHE3/APACHE3/site.virtual/IP-based/logs/error_log TransferLog /usr/www/APACHE3/APACHE3/site.virtual/IP-based/logs/access_log </VirtualHost> <VirtualHost 192.168.123.3> ServerAdmin sales@butterthlies.com DocumentRoot /usr/www/APACHE3/APACHE3/site.virtual/htdocs/salesmen ServerName sales-IP.butterthlies.com ErrorLog /usr/www/APACHE3/APACHE3/site.virtual/IP-based/logs/error_log TransferLog /usr/www/APACHE3/APACHE3/site.virtual/IP-based/logs/access_log </VirtualHost>
The two named sites are dealt with by the NameVirtualHost directive, whereas requests to sales-IP.butterthlies.com, which we have set up to be192.168.123.3, are dealt with by the third <VirtualHost> block. It is important that the IP-numbered VirtualHost block comes last in the file so that a call to it falls through the named blocks.
This is a handy technique if you want to put a web site up for access — perhaps for testing — by outsiders, but you don't want to make the named domain available. Visitors surf to the IP number and enter your private site. The ordinary visitor is very unlikely to do this: she will surf to the named URL. Of course, you would only use this technique for sites that were not secret or compromising and could withstand inspection by strangers.
Port-based virtual hosting follows on from IP-based hosting. The main advantage of this technique is that it makes it possible for a webmaster to test a lot of sites using only one IP address/hostname or, in a pinch, host a large number of sites without using name-based hosts and without using lots of IP numbers. Unfortunately, most ordinary users don't like their web server having a funny port number, but this can also be very useful for testing or staging sites.
User webuser Group webgroup Listen 80 Listen 8080 <VirtualHost 192.168.123.2:80> ServerName www.butterthlies.com ServerAdmin sales@butterthlies.com DocumentRoot /usr/www/APACHE3/APACHE3/site.virtual/htdocs/customers ErrorLog /usr/www/APACHE3/APACHE3/site.virtual/IP-based/logs/error_log TransferLog /usr/www/APACHE3/APACHE3/site.virtual/IP-based/logs/access_log </VirtualHost> <VirtualHost 192.168.123.2:8080> ServerName sales-IP.butterthlies.com ServerAdmin sales@butterthlies.com DocumentRoot /usr/www/APACHE3/APACHE3/site.virtual/htdocs/salesmen ServerName sales.butterthlies.com ErrorLog /usr/www/APACHE3/APACHE3/site.virtual/IP-based/logs/error_log TransferLog /usr/www/APACHE3/APACHE3/site.virtual/IP-based/logs/access_log </VirtualHost>
The Listen directives tell Apache to watch ports 80 and 8080. If you set Apache going and access http://www.butterthlies.com, you arrive on port 80, the default, and see the customers' site; if you access http://www.butterthlies.com:8080, you get the salespeople's site. If you forget the port and go to http://sales.butterthlies.com, you arrive on the customers' site, because the two share an IP address in our dummied DNS.
|  | |
| 4. Virtual Hosts |  | 4.3. Two Copies of Apache |
Copyright © 2003 O'Reilly & Associates. All rights reserved.