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 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)dnlNote 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')dnlThe 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.cfNow 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:
firstname.lastname@example.org rmcginty email@example.com firstname.lastname@example.org @opensourceit.com supportSince 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 email@example.com will now be sent to the local rmcginty (firstname.lastname@example.org). Bob's mail will be redirected to Hotmail, and everything else will go to email@example.com. Make sense?
Finally, you can make the following construction:
@opensourceit.com %firstname.lastname@example.orgThis 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 accessThe 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/openuserThat 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 resources1. 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.