Simplify Your Life with Apache Virtual Hosts
by Russell Dyer07/24/2003
Web designers and systems administrators sometimes don't consider
reconfiguring Apache to solve some of their web problems. Sometimes with
the help of a few directives, web designing can be easier and server costs
can be reduced. The VirtualHost directive is one of these
helpful but often overlooked features. It can be used for running several
domains on a single server with one or many static IP addresses. I can
think of at least two scenarios in which this could be useful. One made
web designing easier for me. The other cut my server costs
significantly.
Scenario One
Consider a web developer who works from home on a Linux machine. He
installed Apache on his computer to make it easier to check his work
before uploading web pages and scripts to the live site. Now here's the
rub: with his browser, he requests a local copy of the main page of Client
A (http://127.0.0.1/client_a/index.html), which is located in
the /var/www/html/client_a directory on his computer. On the
index page he has added a link to a CGI script that he just wrote in Perl
(of which he's quite proud) that searches the client's site. The link is
to search.cgi, which is located in Client A's
cgi-bin directory (/var/www/cgi-bin/client_a) on
his computer. You probably see the problem already, but for good form,
I'll finish.
The developer tests the link on his local workstation and all is well.
Feeling pleased, he uploads both index.html and
search.cgi to the client's site. When he tries them out
online, though, the new link fails with an error message. The file
/cgi-bin/client_a/search.cgi does not exist. The file does
exist, of course; it is the directory /cgi-bin/client_a that
does not exist. The developer has correctly placed
search.cgi in the client's directory,
/var/www/cgi-bin (which Apache knows is the alias of calls to
/cgi-bin). It's just that the client's file tree is
different from the local one.
Common Solutions
This scenario won't manifest itself if the web developer only has one
client because all of the files would be in the main directories. Since
he has several clients, he needs separate directories for each, otherwise,
it would be madness to keep track of which files belong to which client.
Also, he would want to name generic, albeit customized files similarly
(for example, index.html). To deal with linking problems,
most developers use relative paths. However, if a link comes from a file
several subdirectories down, relative paths can be cumbersome (e.g.,
../../../cgi-bin/search.cgi), especially if he occasionally
relocates or renames files and directories.
Another solution would be to work online with the original files. This is not recommended as he would not be able to test the files before saving them. Another bad idea would be to change the links right before or right after uploading them to conform to the client's server. This is particularly tedious and prone to broken links. The best solution is to reconfigure Apache for virtual hosts (vhosts) so that links will work regardless of whether a file is local or remote.
Scenario Two
Consider a systems administrator with a web server either located
physically at her office or rented from a web hosting company (probably a
virtual server with root access). Her boss announces one day that she
wants the admin to setup a web site for a small subsidiary that is to have
its own domain name. The standard impulse would be to set up another
server. The admin would either have to buy a new server and another
static IP address or rent a second virtual server. Neither is necessary.
The VirtualHost directive can easily solve her problem. Both
sites can be handled by the one server and one static IP address without
much reconfiguring of Apache.
The Process
Before digging into Apache directives, let's consider the typical steps
for processing a request to Apache for a document on a virtual host, as
shown in Figure 1. When Apache is started, it scans the configuration
file (/etc/httpd/conf/httpd.conf) to determine its settings.
It generates a table of the server's IP addresses with a hash (known as a
vhost address set) containing the associated domain names. With
the Apache daemon (httpd) running and listening at the
appropriate ports (usually just 80), it's ready to receive requests from
clients.
Figure 1 — how Apache processes vhost requests
When a browser goes looking for a document that a user has requested,
it first has a domain name server translate the domain name entered to an
IP address. The browser then sends the user's request to the IP address.
As of HTTP
1.1, the browser must also send to the web server the domain name that
the user entered; it's no longer to be implied. This requirement makes
virtual hosting possible. If Apache has no vhosts, it will use
the main server's DocumentRoot directory (often set to
/var/www/html). However, if Apache has been configured for
vhosts, it will compare the client's request to the
ServerName of each vhost with the same IP address
and port that the request came in on. The accompanying vhost
directives of the first ServerName that matches the client's
request will be applied.
Within a vhost block--between <VirtualHost>
and </VirtualHost> tags in
httpd.conf--many directives may be given, but only two are
typically required: the ServerName and the
DocumentRoot directives. The ServerName
directive provides the domain name. The DocumentRoot
directive sets the root directory for the domain. If Apache finds a
vhost with a ServerName that matches a client
request, it will look in the root directory specified by the
DocumentRoot directive for files. If it finds what was
requested, it will send copies to the client.
Pages: 1, 2 |
