Name-Based Virtual Hosting
|Note:||Webmin can be used for virtual hosting most easily with the Virtualmin hosting control panel. It automates all of the following tasks, as well as many others commonly needed in a virtual hosting environment, such as setting up email, name service, and databases. Virtualmin is available for free download in Webmin module form from Webmin's home page, as well as an easy to install script from the Virtualmin download page at Virtualmin.com.|
In the real world, it is rare to only operate one website on a machine. For all but the most demanding websites, it would be a waste of resources to do so, because a single modest computer can serve hundreds or thousands of web requests every minute without much effort. It would also be a waste of the finite IP space on the Internet, as there is a fixed number of IP addresses available and large swaths of them are already in use. To solve both problems Apache provides a feature known as name-based virtual hosts. With name-based virtual hosts, you may serve hundreds or thousands of websites, each with their own domain name, from a single machine running on a single IP!
|Note:||The terms virtual host and virtual server are generally interchangeable for our purposes. The terminology is constantly shifting, however, and you may hear the terms used differently in different contexts. In our case, the terms have the same meaning, but the term virtual host may be used to indicate a concept, while the term virtual server will generally be used to indicate a specific configuration detail.|
In this short tutorial we will convert our existing default server into a virtual server, and create a new server that can be hosted alongside our first website on a different domain name. With the mention of domain names, you may have realized we won't be able to test our new virtual servers until domain name service has been configured. Luckily, there is a short tutorial for that as well in the BIND chapter to which you can refer when you are ready to try out your new virtual hosts.
Converting a Default Server to a Virtual Server
The first step to using virtual servers in a generic, and thus easily scalable and flexible manner, is to convert our already configured default server to a virtual server. Though this isn't strictly necessary to make this change, it is common practice to instead provide an appropriate error page, or a page of links to all of the virtual hosts on the machine using a traditional URL syntax for web clients that are incompatible with name-based hosts (however extremely rare such clients may be). Because the default server will be used in the event no virtual servers match, it could also be left as-is, with all other hosts being configured using the virtual hosts mechanism.
To create a new virtual server, fill in the form at the bottom of the primary Apache Webserver module page. You may leave the address and port empty and select the Any option for the address, unless your server has many IP addresses and you only want this virtual host to respond on one of them or you want this virtual host to respond on one ore more non-standard ports. For our example setup, we'll just leave them empty.
The Document Root can be any directory on your system to which the Apache process has read access, however there are some conventions that you can follow in order to make your server more immediately comprehensible to subsequent administrators. If all of the virtual servers on your system are to be under the control of your company, and you will be administering all of them yourself, it is wise to place all of the document roots into subdirectories of whatever the default server document roots parent directory is. For example, on my system the default document root is /var/www/html, so it makes good sense for my virtual server document roots to reside in subdirectories of /var/www. The more common convention, however, is used in environments where many users will be maintaining many websites, and none of the users should have access to the other users website directories directly. In this case, the normal practice is to place the document root into the users home directory, in a sub-directory called htdocs or www.
Finally, fill in the server name, which is the domain name on which you'd like this server to answer (Figure 7.9, 'Creating a new virtual host'). If you don't happen to own a domain that can be used for experimenting, you can simply make one up. We'll be configuring our own local domain name server later on, so there are no rules about how you have to name it. You could call it google.com, or whitehouse.gov, or just george, if you wanted to. However, since it is likely you intend to put the server online for production use at some point in the future, you'll likely just name it whatever domain name it will be at that point. In my case, I'd call it swelltech.com.
Figure 7.9. Creating a new virtual host
Creating a new virtual host
Click Create. Now move your content from your default server document root directory into your new document root. In my case it is /var/www/swelltech.com. After applying the changes to your server, your Apache configuration should be finished, though we'll tackle a few more small issues before calling it done.
|Note:||To test your new virtual server, you can't simply browse to your IP as you did in the previous tutorial. The browser request must contain the domain name for the virtual host in the URL. There are a couple of ways to achieve this. The first is to configure a local name server to temporarily provide name service for your new domain, the second is to setup your system hosts file to point to the appropriate IP for the domain name. The easiest is obviously to add it to your hosts file. You can do this in Webmin, if your client machine is a UNIX machine running Webmin, using the Networking:Network Configuration:Host addresses module. On a Windows client machine, you'll need to edit the hosts file manually. It is located in c:\windows\hosts on Win98 and Me, c:\winnt\system32\drivers\etc\hosts on WinNT, 2000, and XP Pro, and c:\windows\system32\drivers\etc\hosts on XP Home. The more interesting and educational method is to configure BIND to serve your new address, and then configure your client to get name service from the newly configured BIND. This is documented later in the BIND chapter, feel free to skip ahead and work through that tutorial now. I'll wait for you here...|
Adding Other Virtual Server Names
Perhaps you noticed when we configured the above virtual server, it was named simply swelltech.com. Did you wonder why I didn't call it www.swelltech.com instead? The reason is simple: I'd like for users to be able to browse to either address and get the same website. So I named the virtual server swelltech.com, and now a new server alias can be added to cause it to answer on both names. To add a new virtual server name to an existing virtual server, click on the icon for the virtual server on the main Apache Webserver module page. Then click the Networking and Addresses icon. Now fill in all of the other domain names on which you'd like your website to appear. Note that these names must each have their own DNS record for users to be able to use them, just like the original swelltech.com name. Every additional host name in the domain is a new address, so www.swelltech.com and mail.swelltech.com have to have their own name record in the name server even if they are on the same machine.