This article is also available as a TechRepublic download.

One of Apache's most underused features is its ability to host virtual sites. Being able to host more than one site allows for one machine to host all of your Web needs. Here's how you make it work.

What do virtual sites do?

How do virtual sites work? Let's say you host a small company site that allows its users to browse products or services; on that server, you want to offer your employees Web mail access.

Assume your site is www.yourcompany.com. A Web mail setup that allows your employees to go to www.yourcompany.com/webmail could easily be created, but why not set up webmail.yourcompany.com with the same access? It's quicker to type and easier to remember. You could also set up sales.yourcompany.com or editorial.yourcompany.com, for example, all on a single IP address. That's what virtual sites are for.

Name vs. IP

There are two types of virtual hosting: name-based and IP-based. IP-based virtual hosting uses an IP address to determine which virtual host to send the connection to. This scheme requires each host to have a separate IP address, which isn't a problem if you're working on a small network. If your network is larger, IP addresses could quickly grow scarce. Name-based virtual hosting uses a hostname to determine where the connection must be sent. Using name-based virtual hosting allows many different hosts to share the same IP address. I suggest name-based virtual hosting for anyone unless:

  • You have a short supply of IP addresses.

    You have to support obsolete clients (such clients will not send the correct Host: header information).

  • You have to use SSL (name-based cannot be used with secure servers

  • Your OS or networking hardware can not differentiate between hosts unless they are on different IP addresses.

Otherwise, you are able to move forward with name-based virtual hosting.

First steps to setting up virtual hosts

Virtual hosts can be defined and configured in Apache's config file. This config file can be found in Fedora Core by default in /etc/httpd/conf/httpd.conf, but the location of this file may vary on other distributions. For example, in Ubuntu, the Apache configuration file is in the /etc/apache2/ directory. If you're having trouble finding this file, you can locate it with the command locate httpd.conf. Once you've located your configuration file, open it with your favorite editor (such as Pico) and search for the NameVirtualHost entry.

HINT: If you use the Pico editor, you can find the entry by running the grep -n NameVirtualHost command to see exactly where the line is. Once you know the exact line number, you can open the file in Pico, scroll down a bit, and hit ctrl-c to see exactly which line you are on. If the line is not in your conf file, add it.

Now, make sure the entry is uncommented and looks like the following:

NameVirtualHost *

This will use whatever IP address to which you assign your server to point to all the hosts configured in the httpd.conf virtual hosts configuration. (The NameVirtualHost * configuration only works with Apache 1.3.13 and greater.) You can also configure a specific IP address for the server in place of the asterisk (*).

The following example will require you to have the document root located in /var/www/ (as it is in Apache2) and the new Web mail will be installed in /var/www/Web mail. If your locations vary, change the example accordingly before adding them to httpd.conf.

To get it up and running quickly, add these lines below NameVirtualHost *:

<VirtualHost *>
ServerName www.yourcompany.com
DocumentRoot /www/yourcompany
</VirtualHost>

<VirtualHost *>
ServerName Web mail.yourcompany.com
DocumentRoot /www/Web mail
</VirtualHost>

where www.yourcompany.comis the FQDN of your company. Do not leave a trailing / at the end of the DocumentRoot directive.

There are many more advanced configurations for virtual hosting. You can add the following configurations:

  • Logging

    By default, Apache will record all messages to the access_log and error_log files located in /var/log/httpd. However, if you want each virtual site to have separate logs, add these directives to the virtual host section (assume you’re adding log files for your virtual Web mail):

    ErrorLog /var/log/httpd/Web mail-error_log common
    CustomLog /var/log/httpd/Web mail-access_log common

    So, if you want your Web mail site to record messages to Web mail-access_log and Web mail-error_log, then your VirtualHost section for the Web mail site will look like this:

    <VirtualHost *:80>
    ServerName Web mail.yourdomain.com
    DocumentRoot /www/Web mail
    ErrorLog /var/log/httpd/Web mail-error_log common
    CustomLog /var/log/httpd/Web mail-access_log common
    </VirtualHost>

  • Error Pages

    You can set Apache to serve a custom page when a visitor gets a 404 (not found) or 500 (internal server error) or any other error code, for that matter. For instance, you can redirect any visitor who receives a 404 error to the main index file, or to a 404 file you created. To accomplish this, add the following directives to the virtual host block, just like in the above example:

    ErrorDocument 404 /index.htm
    ErrorDocument 500 /index.htm

    The error page could be anything. But remember, the location starts with the directory set in DocumentRoot in httpd.conf. For instance, if your DocumentRoot is /var/www/html and the error page is in /var/www/html/messages/404.htm, then you'll have to append /messages/404.htm to the ErrorDocument directive.

  • Server Aliases

    If you want to use your virtual host for more than one domain name, you can use the ServerAlias directive inside the virtual host block in order to link the two domains together. In the httpd.conf file, enter:

    ServerAlias yourcompany.com yoursecondcompany.com

    Take this a step further by using the wildcard to point all requests to yourcompany.com:

    ServerAlias yourcompany.com *

    One caveat: You cannot simply make up host names and put them in the ServerAlias or ServerName directives. All host names must be correctly mapped in your DNS server configuration so those names will properly map to the right server.

Something old, something new

Earlier, I mentioned clients who do not have to send the required data for name-based virtual hosts.? If you're one of the lucky few to be running such clients, fear not; there is a work-around using the ServerPatch directive. Always send these clients pages from the first virtual host listed for the primary name-based virtual host.

Here is the sample configuration for subdomain solution:

NameVirtualHost 192.168.1.42

<VirtualHost 192.168.1.42>

ServerName www.domain.yourcompany.com

ServerPath /domain

DocumentRoot /web/domain

RewriteEngine On

</VirtualHost>

The above configuration means that any request for any URL beginning with /domain will be served from the virtual host www.domain.yourcompany.com. These pages can be accessed as http://www.domain.yourcompany.com/domain/ for all clients. Of course any client sending the proper Host: header will also be able to access www.domain.yourcompany.com.We have also added the RewriteEngine directive to ensure that clients who send the proper Host:header information will be able to use both iterations of the URL.

To make this work within your primary hosts page, put a link to www.domain.yourcompany.comand then, in the virtual hosts pages, use only relative links such as <a href="shop.html"> or <a href="../images/image.jpg">. You can also use the domain preface with links like: <a href="/domain/images/image.jpg">.

NOTE: Relative links are links that specify the name of the file to be linked to only as it is related to the current document. So if the current document, pictures.html resides in /var/wwwand points to the image image.jpg that resides in /var/www/images, the only necessary link is <a href="/images/image.jpg”>. Or if the pictures.html file is already in the /var/www/images directory, the links would only need to look like <a href=”image.jpg”>

Don’t forget

Once you have your entire configuration complete, remember to restart the Apache daemon. Otherwise, the changes won't take effect. If you have problems, don't forget your error and log files; they will tell you everything you need to know about what has gone wrong.

Apache is one of the most powerful, flexible tools in the open source world. The capabilities of Apache are near that of proprietary servers; additionally, there are many things Apache can do that proprietary systems cannot. The virtual hosting feature is only a small example of the power of Apache.