Datamation content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
|
Internet service providers (ISPs) have discovered an additional, quite lucrative revenue stream to providing connectivity: hosting “virtual domains.” But in fact, hosting a virtual domain is a fairly simple DIY (do it yourself) and usually entails nothing more than configuring a few files. Here you will learn everything you need to know to set up and host a new virtual domain yourself. You will need: While it is certainly possible to use other server programs such as qmail to accomplish these same goals, I’ll limit my discussion to what I have listed above. Not only do these programs have widespread usage, they’re what I’ve chosen to use for my own server. What is a virtual domain?You’ve undoubtedly become familiar with the concept of the Internet domain; earthweb.com and yahoo.com are two everyday examples. In fact, you probably typed in a domain name to reach this Web site. But what differentiates a “real” domain with one that’s “virtual”? In the old days, each individual “dot-com” needed to have its own server, and all domains were “real.” This limitation was dictated by HTTP 1.0, the first version of the Web protocol. However, possibilities were expanded with the release of the following version, HTTP 1.1. For the first time, a single computer could host multiple (or virtual) domains. Hosting multiple domains on one machine is both convenient and economical. Many Web sites have low enough traffic that they don’t require their own dedicated server. Does it not make sense, then, to combine several sites onto one machine? Of course. That’s precisely what virtual hosting allows you to do. Without any further ado, here’s what you need to do to host a virtual domain:
For the purposes of this article, I’m going to pretend I’ve been hired to host www.opensourceit.com. Here’s an in-depth look at what I need to do to make it happen. Domain registrationThe first step in hosting a domain, real or virtual, is to register it with InterNIC, or rather Network Solutions, or another company authorized as a registrar (for a list, see here). The cost is $70.00 for the first two years and then $35.00 per each following year. In addition to the .com, .net, and .org “top-level” domains, there are individual country-coded domains such as .uk. If you need to use one of these, you’ll find a list of every available country code and their respective contact information at the IANA (Internet Assigned Numbers Authority). Regardless of what top-level domain you decide to put your domain under, you’ll need to provide the registrars with the IP addresses of the machines that will be handling DNS lookups for your new domain. If the domain you’ll be hosting isn’t new (i.e., if it’s a transfer from another hosting company), you’ll need to submit the transfer request in much the same way as you’d request a new domain. Fortunately, transfers are free. DNSDNS, or the Domain Name System, matches domain names (such as opensourceit.com) with IP addresses (209.10.73.152). This process is managed in part by InterNIC, which maintains the gigantic database of .com, .net, and .org domains. If you type “whois opensourceit.com” (without quotes) on the command line, you’ll see the information that InterNIC maintains on opensourceit.com. (Being a smart person, you can probably extrapolate that you can get the registry information on any .com, .net, or .org domain by typing “whois Domain servers in listed order: NS5.EARTHWEB.COM 209.10.73.140 NS1.EARTHWEB.COM 206.152.10.2 This is what we care about! It states that DNS requests for opensourceit.com should be directed to ns5.earthweb.com (209.10.73.140), and, failing that, should be redirected instead to ns1.earthweb.com (206.152.10.2), the backup. There could be several backups listed, but the minimum is one, as we have here. Now, what happens when ns5.earthweb.com gets a DNS request? We can presume that ns5 has a copy of “named” running. Named, which is part of the BIND package, is what handles these requests. Named is normally started at boot time. You probably have an entry for it in one of your /etc/rc.d files. Mine is in /etc/rc.d/rc.inet2 and looks like this:
NET="/usr/sbin"
# Start the NAMED/BIND name server.
if [ -f ${NET}/named ]; then
echo -n " named"
${NET}/named
fi
The first thing named needs to do on startup is, like many other daemons, read its configuration file. In this case, it’s /etc/named.boot. There’s usually a “directory” line that tells named where it can find the DNS files. It looks like this: directory /var/named This simply states that all the DNS files will be in the /var/named directory. The directory could be /abc/123; it makes no difference as long as that’s where the files are. Then, there will be an entry for each domain that you host. They look like this: primary opensourceit.com named.opensourceit.com This tells named that the DNS file for opensourceit.com (assuming I hosted that) is called “named.opensourceit.com”, and that we will be the primary host. Again, the file could be called “spaghetti” if you wanted it to be. All that matters is that the actual file name matches up with what you have listed in named.boot. Now that we’ve told named where the DNS files are, let’s have a look at the contents of /var/named/named.opensourceit.com:
$ORIGIN com.
opensourceit IN SOA opensourceit.com. root.earthweb.com. (
100
360000
3600
3600000
3600
)
IN NS ns5.earthweb.com.
IN NS ns1.earthweb.com.
IN MX 0 mail.earthweb.com.
$ORIGIN opensourceit.com.
www IN A 209.10.73.152
@ IN A 209.10.73.152
Now, it’d take a book to explain what all this means (and, in fact, several good ones have been written), but you can basically just copy this as a template and exchange your information with what I have here. With that in mind, here’s a brief explanation: In a DNS file, all names not ending with a period are appended with your domain name. This appending name (your domain name) is called the “origin”, and presumably, in this case, it’d be “earthweb.com”. We don’t want that, so we override it with: $ORIGIN com. Now the “opensourceit” on the next line will be read as “opensourceit.com”. SOA means “Start of Authority” and basically means that the important stuff starts here. Note that “root.earthweb.com” is the e-mail address of the domain’s administrator; the “@” is replaced with a period as is proper DNS file syntax. The “IN NS” lines reflect what we have listed with InterNIC: IN NS ns5.earthweb.com. IN NS ns1.earthweb.com. “IN NS” stands for INternet Name Server. Then, the “MX” (mail exchange) line tells DNS where to direct e-mail. The 0 means that mail.earthweb.com is the primary mail server; a low number has a higher priority. IN MX 0 mail.earthweb.com. Finally, we change the $ORIGIN variable to be the full domain name, and we say that www.opensourceit.com is the same thing as plain ol’ opensourceit.com. The IP numbers are the right ones for opensourceit.com. $ORIGIN opensourceit.com. www IN A 209.10.73.152 @ IN A 209.10.73.152 Many people find DNS confusing but it generally suffices to swap the names you need with those found in a template like I have here. Once you’ve added your “primary” line to named.boot and created named.opensourceit.com, you’ll need to restart named by sending it a SIGHUP: kill -HUP 76 ? S 0:16 /usr/sbin/named you’d type: kill -HUP 76 Alternately, you could wait until you’re done with everything and then restart your server. A cautionary tale: When I first attempted to get named going on my own machines, I had a heck of a time. I wanted to transfer DNS control from my upstream provider but nothing I did seemed to work. No matter how I configured my files (and everyone tells you differently), it never got going correctly. Finally, close to desperation, I realized my fault: I had a bad binary! After a quick upgrade of named, I was up and running. Web serverThis part is fairly easy. You’ll just need to edit your httpd.conf, which on my system is /http/conf/httpd.conf. At the end, there’s a place to put virtual domain entries. Here’s what they look like: # So, in this case, here’s how your entry might look:
Starting from the top, we have the IP address of the hosting machine (same as before, with DNS) located within the VirtualHost brackets. This is followed by the admin’s e-mail address, ServerAdmin. Then, there’s the DocumentRoot, the directory where the actual Web pages can be found. I’ve specified this as the /home/openuser directory, but once again, this is entirely arbitrary. Do whatever meets your needs. Next, the DirectoryIndex is the first Web page brought up when someone visits the site. I’ve chosen “index.html” (as is standard), but it could be anything. Do be sure that this page actually exists, though, even if it’s blank. Otherwise, you’ll get an error when you restart Apache. Then there’s the ServerName (www.opensourceit.com) and ServerAlias lines. These may take a little explaining. |
|
ServerName is what Apache is “listening” for. In this case, it’s www.opensourceit.com, so Apache will ignore requests for any other variation, including simply “opensourceit.com” (minus the leading “www.”). (You get around this by using ServerAlias.) ServerName is also what’s displayed by the Web client as Web pages are retrieved. ServerAlias, on the other hand, allows you to add variations to the ServerName. I’ve got opensourceit.com and *.opensourceit.com, which then allows just about any sort of opensourceit.com address. Whether the client requests opensourceit.com, www.opensourceit.com, xxx.opensourceit.com, or anything else, Apache will dish up the pages. ErrorLog is, predictably, where errors are recorded, for example, when clients request non-existent pages. TransferLog records all successful Web requests. Note that while you can specify a different file for each virtual host, you probably shouldn’t. Not only will this slow down operations, you’ll run into problems when you start adding a lot of virtual hosts because a process can only have so many files open (usually 64) at any given time. (There is a way around this, though. See Apache.org’s documentation for details.) My recommendation is to just use the same log and error files for every virtual host. This may not be pretty, but hey, it works. Finally, add the line. After you’ve made this addition to httpd.conf, restart Apache with a SIGHUP as before – or wait and restart the entire server. E-mail serverNow we get to Sendmail. You may need to download a new version of Sendmail, unpack it, and move to the src directory to compile but once you’ve set it up the first time, future virtual hosts will be a breeze. Basically, we want e-mail bound for opensourceit.com to go there and not to us (the hosting company). If we simply added a Cw line to our /etc/sendmail.cf file, all opensourceit.com mail would come here (to us). Also, we want to have ALL opensourceit.com mail going somewhere – even mail addressed to non-existent users. This way, no mail will bounce. You create the Makefile by typing “Build” or “makesendmail” (it makes no difference – they’re both links to the same executable) from Sendmail’s src directory. Then, “makesendmail install” installs the binaries. See the README files if you need extra help. Read the cf/README file to learn how to create a .mc file in the cf/cf directory. Our mailserver.mc file might look like this: divert(-1)dnl # # This file contains definitions for mailserver.yourdomain.com # divert(0)dnl VERSIONID(`@(#)mailserver.mc 1.0 (earthweb.com) 5/1/97') OSTYPE(linux)dnl DOMAIN(earthweb.com)dnl FEATURE(`virtusertable', `dbm /etc/virtusertable')dnl MAILER(local)dnl MAILER(smtp)dnl Note the “virtusertable” definitions. This is what we’re interested in for virtual hosting, and I’ll describe it in detail below. It’s similar to the /etc/aliases file. For now, choose a database format. The default is “dbm” but you may also choose “btree” or “hash.” The “hash” format is used if you compiled Sendmail with NEWDB instead of NDBM (the default). Then, there’ll also be the cf/domain/earthweb.com.m4 file: divert(-1)dnl # # This file contains the global definitions for earthweb.com # divert(0)dnl VERSIONID(`@(#)earthweb.com.m4 1.0 (earthweb.com) 5/1/97') FEATURE(`use_cw_file')dnl The use_cw_file line means that all Cw definitions will be in their own external file (/etc/sendmail.cw) instead of in sendmail.cf. Finally, the following three commands are keyed in to generate the sendmail.cf file: cd sendmail-VERSION/cf/cf m4 ../m4/cf.m4 mailserver.mc > obj/mailserver.cf cp obj/mailserver.cf /etc/sendmail.cf Now we’re ready to roll! Let’s create the virtusertable. As I said, the virtusertable is similar to /etc/aliases. It takes the incoming mail for a virtual host and routes it to the correct destination. As the Sendmail people put it, it “maps virtual addresses into real addresses.” Virtual addresses appear on the left, and the actual recipients are on the right, separated by whitespace (spaces or tabs). The file itself is a textfile. You can call it anything; I suggest “virtusertable”! Here are some examples: rmcginty@opensourceit.com rmcginty bob@opensourceit.com robert@hotmail.com @opensourceit.com support Since we’re actually earthweb.com, all mail will come to us by default. But since we compiled virtusertable support into Sendmail, the diversions listed above will take effect. First of all, all mail sent to rmcginty@opensourceit.com will now be sent to the local rmcginty (rmcginty@earthweb.com). Bob’s mail will be redirected to Hotmail, and everything else will go to support@earthweb.com. Make sense? Finally, you can make the following construction: @opensourceit.com %1@perl.com This will route all mail originally sent to opensourceit.com to the same user at perl.com. To compile the virtusertable (and it won’t be useful prior to compilation), type: makemap dbm /etc/virtusertable |
