Apache Guide: Setting Up Virtual Hosts

Monday Jul 17th 2000 by Rich Bowen
Share:

Need to make a single DSL connection look like a colocation facility? Then you'll want to look at setting up virtual hosts -- Web sites with different names that all run on the same server hardware. Rich Bowen explains three different methods of setting up virtual hosts on your Apache server.

What's a Virtual Host?

As suggested in the paragraph above, virtual hosts are Web sites with different names that all run on the same server hardware. The idea is that Apache knows which site you are trying to get, even though they are all on the same server, and gives you content from the right one.

It's this trick that lets me run several Web sites on my home machine, from a variety of different domain names, and several names within one domain, so that my one little machine behind my DSL link looks like a room full of servers. Neat trick.

Reasons for Using Virtual Hosts

Well, you probably already have some ideas in mind. But here's how I generally use virtual hosts. I work for a Web-design company, and when we're developing a customer site, we set up a virtual host specially for that company. These are usually name-based, since these are faster to set up (one step shorter), and are almost always internal only. That is, the names are put into our internal DNS, so that internal hosts can see the Web sites, but external browsers see only the boring, featureless external page on our development server.

The advantages to doing this are numerous. It lets us set the directory structure on the site the same way that it will be on the real server when we are done with development. It lets us keep fines completely separate from one "server" and another, so that there is no confusion as to what is on which site. And, from the developers' perspective, it lets them set up completely different sites in DreamWeaver, rather than just different subdirectories on the same site.

And, of course, you don't have to have a new server for each site, no matter how many customer projects you're working on at one time. Which is the biggest reason for using virtual hosts in any scenario.

Name-based vs IP-based Virtual Hosting

Virtual hosts can be specified one of two ways. These are configuration differences on the server, and are not visible to the client--that is, there is no way that the user can tell what sort of virtual host they are using. Or even that they are using a virtual host, for that matter.

The two types are IP-based virtual hosting and name-based virtual hosting. In a nutshell, the difference is that IP-based virtual hosts have a different IP address for each virtual host, while name-based virtual hosts have the same IP address, but use different names for each one. There are reasons for each. There's not much difference in implementation.

IP-based Virtual Hosting

In IP-based virtual hosting, you are running more than one web site on the same server machine, but each web site has its own IP address. In order to do this, you have to first tell your operating system about the multiple IP addresses. Most modern operating systems let you give your machine as many IP addresses as you want. The specific details of how you give your machine multiple IP addresses varies from OS to OS, and I'm not going to go into that right now. If you don't know how to accomplish this on your OS, you might want to consult your local guru. It's typically not very difficult. Or, you may just want to skip down to the section on name-based virtual hosts.

On older operating systems, it was sometimes even necessary to have one NIC (network interface card) per IP address, but that is almost never the case any more.

Once you have given your machine multiple IP addresses, you will need to put each IP in your DNS, so that it will resolve to the names that you want to give those addresses. Again, I'm not going to go into the details of setting up DNS records. You should contact the person that is responsible for your DNS server to get these records put in place.

Now, the part that directly relates to Apache. Assuming that you have all the IP addresses on your machine, and each IP address has a DNS record for it, you'll put the following information in your Apache httpd.conf configuration file.

For this discussion, I'll assume that you have 3 IP addresses, and that you've given them the names name1.mydomain.com, name2.mydomain.com, and name3.mydomain.com. You can, however, given them names from entirely different domains, such as www.mydomain.com and www.myotherdomain.com.

The addition to your httpd.conf file will look like:


        <VirtualHost name1.mydomain.com>
        DocumentRoot /usr/local/apache/name1_www
        ServerName name1.mydomain.com
        ErrorLog /usr/local/apache/logs/name1_logs/error_log
        TransferLog /usr/local/apache/logs/name1_logs/access_log
        </VirtualHost>
        <VirtualHost name2.mydomain.com>
        ServerAdmin webmaster@name2.mydomain.com
        DocumentRoot /usr/local/apache/name2_www
        ServerName name2.mydomain.com
        ServerAlias name2
        </VirtualHost>
        <VirtualHost name3.mydomain.com>
        DocumentRoot /usr/local/apache/name3_www
        ServerName name3.mydomain.com
        ScriptAlias /use/local/apache/name3_cgi
        </VirtualHost>

Notice that you don't need to configure everything for each virtual host. Whatever you don't specify, it will inherit from the main server configuration. For example, you'll notice that on the second virtual host, I did not specify a location for the server logs. This virtual host will log to the main server log files.

Notice also that in the third section, I specify a CGI directory. All the other sections will default to using the cgi directory specified in the main server configuration, when a URL is accessed containing /cgi-bin/, because it has not been specified in the virtual host configuration section.

Almost any configuration directive is valid inside a VirtualHost section. In the server documentation, you'll notice that each directive says where it is valid, and it should be pretty clear whether or not you can put a particular directive in one of these sections.

Remember to test your new configuration files before restarting your server:

       /usr/local/apache/bin/apachectl configtest

Another handy tip, which also applies to name-based virtual hosts, is to use the ServerAlias directive. When accessing a server internally, on your LAN, you'll often want to use the server's short name, eg "name2", rather than the full name "name2.mydomain.com." Using the ServerAlias ensures that you don't get an unexpected page when trying to use that short name. Apache has no way to know that "name2" and "name2.mydomain.com" are actually the same Web site.

Once you restart your server to reload the configuration file, Apache will figure out, based on the URL that you typed in, which web site you are trying to access, and will serve you the right page based on that information. Even though they are all on the same physical machine. Pretty cool, huh?

Name-Based Virtual Hosts

Of course, sometimes, you don't have the luxury of giving your machine multiple IP addresses. IP addresses are in shorter and shorter supply, and frequently, such as if you have an DSL connection as I do, you only have one. In this case, name-based virtual hosting is for you.

You don't have to give your machine multiple IP addresses, but you will still have to contact the person that is responsible for your DNS server, and have them put more than one DNS record in for your machine. These extra records are called C-records, or CNames. (The main record pointing at a machine is called the AName, or A-record.) You can have as many CNames as you like pointing to a particular machine.

Once you have your DNS configured to send traffic to you for all these names, you'll need to do the following in your server configuration file:


        NameVirtualHost 192.168.1.1
        <VirtualHost 192.168.1.1>
        ServerName name1.mydomain.com
        DocumentRoot /usr/local/apache/name1docs
        ServerAlias name1
        </VirtualHost>
        <VirtualHost 192.168.1.1>
        ServerName name2.mydomain.com
        DocumentRoot /usr/local/apache/name2docs
        ServerAlias name2
        </VirtualHost>
        <VirtualHost 192.168.1.1>
        ServerName name3.mydomain.com
        DocumentRoot /usr/local/apache/name3docs
        ServerAlias name3
        </VirtualHost>

Once again, as in the IP-based virtual hosts, you can put any directive you want in these sections. I've kept them all pretty simple.

There are several things to note here.

First, you must specify, with the NameVirtualHost directive, what IP address should be responding to virtual host requests. You can use IP-based and name-based virtual hosting in conjunction - that is, you can do both on the same server at the same time. So you must specify which addresses you're using for this. I'll frequently set up virtual hosts on the internal and external interface of a server (intranet servers and internet servers, that is) and so you must specify both addresses:

        NameVirtualHost 192.168.1.1
        NameVirtualHost 208.32.54.7

Furthermore, you can run virtual hosts on different ports, as well as different addresses, if you really want to complicate things:

        NameVirtualHost 192.168.1.1:80
        NameVirtualHost 192.168.1.1:90

Just make sure that all the names make it into DNS, or you might end up serving a page that you were not intending to.

The magic for the virtual host stuff is that the browser tells the server what server it is requesting content from. There are still some older browsers in use that don't do this correctly, and so they might get content from the "default" server on your machine. This is almost never a real consideration, since any browser produced in the last five years (perhaps even before that--I tend to lose track of time these days) has this ability. There are work-arounds in Apache so that it will work for even these browsers, but I'll let you research that on your own, if you really want to. Start at http://www.apache.org/docs/manual/vhosts/index.html and go from there.

Running Multiple Daemons

There's actually a third alternative. You can run completely separate server daemons on your server machine and have each one serving a separate Web site. The downside of this is that each one must run on a different port, since you can't have multiple services listening on the same port at the same time.

You can get a server to run with a particular configuration file with the -f command-line option:


        /usr/local/apache/bin/apache -f /usr/local/apache/conf/name2_httpd.conf

This lets you start as many server daemons as your machine can stand, each one running a different server configuration. Make sure, of course, that each configuration file has a Port directive pointing at a different port, or every one after the first one will fail to start, giving you an error message like:

       Could not bind to port 80: Port already in use. 

Summary

Virtual hosts let you run multiple Web sites on the same physical server machine. The advantages of this are numerous, and can be summed up for your boss as "we don't have to buy another machine for the 18 other Web sites you want to run."

Future columns

Please let me know if there are other topics that you'd like for me to talk about in future columns. You can send your suggestions to me at ApacheToday@rcbowen.com And please let me know what you think of my columns, at that same address. Many thanks for reading down this far!

Share:
Home
Mobile Site | Full Site
Copyright 2017 © QuinStreet Inc. All Rights Reserved