Virtual domain hosting with Linux: Page 2

Posted November 4, 1999

Jay Link

(Page 2 of 2)

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 </VirtualHost> 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 server

Now 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:

   #  This file contains definitions for mailserver.yourdomain.com
   VERSIONID(`@(#)mailserver.mc     1.0 (earthweb.com) 5/1/97')
   FEATURE(`virtusertable', `dbm /etc/virtusertable')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:

   #  This file contains the global definitions for earthweb.com
   VERSIONID(`@(#)earthweb.com.m4   1.0 (earthweb.com) 5/1/97')
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 < /etc/virtusertable

Be sure to replace "dbm" with "btree" or "hash" if necessary (if you did so above). This creates /etc/virtusertable.db, much in the same way that "newaliases" creates /etc/aliases.db. In fact, I recommend creating a script called "newvirtusers" that does this for you. Since the output is virtusertable.db, your original textfile (/etc/virtusertable) is left intact.

Now, add your new virtual domain to /etc/sendmail.cw. Don't forget this step or else all mail to that domain will bounce!

At this point, you can SIGHUP Sendmail, or restart the server. There won't be any more daemon changes, so if you're planning to restart the server, now's the time to do it.

FTP access

The final step is to provide your client access to his or her Web pages. What I do is create a login for that person with "adduser." Ftpd also requires that the user not appear in /etc/ftpusers file, but they must have a recognizable shell (i.e., one that appears in /etc/shells). I don't want my FTP people being able to log in to a shell account with /bin/bash, so I made up a shell for them that I also inserted into /etc/shells. This is a simple script that states that logins from their account are not allowed. If they log in through FTP, they don't see the message. If they try to telnet or dial in, they do.

Now, when the user FTPs in, they are placed in their home directory. How, then, are they to access their Web pages? Simple! Remember when you created the DocumentRoot line in httpd.conf? It looked like this:

   DocumentRoot /home/openuser
That stated that all the opensourceit.com Web pages would be found in the /home/openuser directory, which is precisely what the FTP user has access to.

And that's all there is to it!ø

Related resources

1. Sendmail home page The official home page of Sendmail, maintained by the Sendmail Consortium. Their section on Virtual Hosting is of special interest.
2. Sendmail, by Bryan Costales and Eric Allman. O'Reilly's classic reference guide.
3. The Apache Software Foundation Home of the Apache Web server and related documentation. Great stuff!
4. DNS and BIND, by Paul Albitz and Cricket Liu. Everything you ever wanted to know about DNS.

Jay Link is twenty-something and lives in Springfield, IL. He administrates InterLink BBS - an unintentionally nonprofit Internet service provider - in his fleeting spare moments as well as working various odd jobs to pay the rent.

Page 2 of 2

Previous Page
1 2

0 Comments (click to add your comment)
Comment and Contribute


(Maximum characters: 1200). You have characters left.



IT Management Daily
Don't miss an article. Subscribe to our newsletter below.

By submitting your information, you agree that datamation.com may send you Datamation offers via email, phone and text message, as well as email offers about other products and services that Datamation believes may be of interest to you. Datamation will process your information in accordance with the Quinstreet Privacy Policy.