Your Daily Source for Apache News and Information |
Breaking News | Preferences | Contribute | Triggers | Link Us | Search | About |
|
By Virtual hosts let you run more than one Web site on the same server. In this article, I'll show you how to set up your server to run virtual hosts. 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 HostsWell, 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 HostingVirtual 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 HostingIn 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 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 The addition to your <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 [email protected] 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 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 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 HostsOf 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 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 DaemonsThere'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 /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 Could not bind to port 80: Port already in use. SummaryVirtual 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 columnsPlease 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 And please let me know what you think of my columns, at that same address. Many thanks for reading down this far! |
|
|
About Triggers | Media Kit | Security | Triggers | Login |
All times are recorded in UTC. Linux is a trademark of Linus Torvalds. Powered by Linux 2.4, Apache 1.3, and PHP 4 Legal Notices, Licensing, Reprints, & Permissions, Privacy Policy. |