Virtual domains in a nutshell
David E. Biggar II
admin@unixhelper.org
August 2003
These instructions should be distribution inspecific - you'll have to fill in the details of what needs to be done on your own. This is an outline only.
1. DNS
This is always the first step, since the programs that need to be tweaked
after this require proper DNS responses.
Your reverse IP address will still be bound to your actual machine name, and doesn't need to be adjusted at all. It will potentially cause some small issues with some over-tight mail servers out in the world, but overall this works fine. If you absolutely need to have a reverse IP mapping, then use a dummy interface with its own IP (which you'll have to get from your ISP, even if you are your own ISP - just pick one of your own IPs).
Your forward mapping will have to point at least one name to a real IP, such as yourdomain.com -> 192.168.0.1 (use a real *public* IP, obviously). If you need more names, such as www, ftp, users and whatnot, you can use CNAME entries. The one caveat to this is some SMTP servers get really grumpy if you use a CNAME for the MX entry (typically mail.*). You can have multiple names pointing at the same public IP, so put in another A record for the MX entry's name.
Restart DNS once you have it updated, and make sure you check it both locally and on a remote machine. Note that it can take a day to propogate the DNS updates, so if it works locally but not remotely, just move on to the next step and come back here to check the remote DNS responses once it's propogated. Use things like dig -x, dig +trace, regular dig, host, and one of any DNS related information sites you can find on the 'Net. If there are any issues, address them.
2. SMTP+POP3/IMAP
This step is easier than it would first appear. Simply add your new domain
name to your chosen SMTP server's access list so it will relay for that
domain (/etc/mail/access for Sendmail, typically). If you wish, you can
then adjust the virtual name mappings so all outgoing e-mail with a certain
username will have domain.com appended to it (outward mapping). You can
also map any incoming mail for user@domain.com to any other user, even if
the "user" name doesn't match (inward mapping). You would use (in sendmail)
the /etc/mail/genericstable and /etc/mail/virtusertable for this purpose.
I highly recommend having a virus scanner in place as well. I really like using MailScanner in conjunction with F-Prot, but your mileage and taste will obviously vary. MailScanner, for example, fires up Sendmail (or your MTA (Mail Transfer Agent) of choice once it has scanned outgoing mail, and your MTA would in turn fire up MailScanner to take care of incoming mail. Pretty nifty setup, and huge kudos to the authors of MailScanner if they ever happen to read this. :)
Restart your MTA and test thoroughly, both locally and remotely, both for incoming and outgoing mail, and for POP3/IMAP if you're using those, and POP3s/IMAPs (SSL) if you're using them. Make sure you tweak your firewall if you're using names instead of IPs in your firewall script to allow appropriate connections.
3. HTTP
Here, you need a VirtualHost directive in your httpd.conf file for Apache
(as if you'd use anything other than Apache? :). You'll also need to use
the "NameVirtualHost" directive to bind your server's IP to every possible
VirtualHost entry you might have. I've found it necessary (someone please
tell me the right way to do this) to have entries for both www.domain.com
and plain domain.com seperately in order to pick them both up.
An entry might look like this:
NameVirtualHost 66.218.71.87
<VirtualHost 66.218.71.87>
ServerAdmin admin@yahoo.com
DocumentRoot /home/yahoo/html
ServerName www.yahoo.com
ServerAlias yahoo.com
ScriptAlias /cgi-bin/ "/home/yahoo/cgi/"
<Directory "/home/yahoo/cgi/">
AllowOverride None
Options None
Order allow,deny
Allow from all
</Directory>
</VirtualHost>
You'd then have another entry just like that where the ServerName was simply "yahoo.com". I know it's cheesy, and I know there must be another way, but that's the only way I'm aware of. I also recognise that the AllowOverride/Options/Allow sections in the <Directory> directive are not the best way to have them, but it works for a loose setup, and can be tightened up later. If anyone has advice on better default ways to do that, please feel free to contact me.
Restart httpd and test; again both remotely and locally. You'll have to put up a temporary page for this. Here's the template I use, just in case you are too lazy to do your own - you can copy and paste this one:
<HTML>
<HEAD>
<TITLE>Temporary Placeholder Page</TITLE>
</HEAD>
<BODY>
This is a temporary placeholder page. Please stay tuned for an update!
</BODY>
</HTML>
Well, that's all there is to virtual domains on most Linux boxes. If there is more functionality that someone wants (such as FTP, which I *never* use - I use SSH2 (openssh) instead), feel free to shout out and say so. I'll get to adding extra sections as interest, time, and extra effort comes to me.