Part 3 of the series where we focus on DNS and mail.
Author’s Note: OK, so the first thing I learned on seeing these articles actually posted on afp548.com is that I need to make sure that the settings are not just in the graphics but also in the text, since graphics and screenshots don’t get posted on that site. The full article with images is on my website at here.
For Stage II, the goal is to set up the infrastructure for the example.org domain to provide a home base for the open source project. External contributors will get replacement accounts in the example.org domain, and their old example.com domain accounts will be forwarded. We also need to set up the DMZ server so that it acts as a forwarder for DNS requests from the internal server, to cut off the last direct connection between the internal server and the outside world. In addition, the example.org project will get its own separate website, rather than just having a piece of the example.com website.
Part of this is external, part of it is internal.
Internal DNS configuration
In the DNS service on server.example.com, create a new zone called example.org, whose name server is called “server” with IP address 192.168.1.2.
Add another machine called “dmzserver” with IP address 192.168.2.2. Aliases: www, mail, imap, and set it to be the mail server for the example.org zone.
The reverse DNS lookup for 192.168.2.2 will still point to dmzserver.example.com.
External DNS configuration
This needs to happen at your ISP or registrar.
- Aliases: www, mail, imap
- MX for example.org.
The net result is that all of the dmzserver.example.org host entries point to the same machine, whether from inside the network or from outside the network.
Mail Service Reconfiguration
Shut down the mail service
This is to ensure that no e-mail is lost while this transfer process is going on. Outside mail servers should try to send in e-mail, recognize that the server is down, and re-try after a reasonable interval (generally 15 or 30 minutes). Turn off the Mail service using Server Admin on both server.example.com and dmzserver.example.com.
Move IMAP mail storage to dmzserver
In order to ensure that none of the outside contributors lose any e-mail, we will need to move their existing imap mail stores to the dmzserver. The easiest way to do this is to use the command line tool tar, which among other things preserves ownership and permissions if invoked as root.
You will need to move only some of the folders within /var/spool/imap, in particular the folders for contributor1 and contributor2, only. From the command line on server.example.com, execute the following commands:
cd /var/spool/imap/ sudo tar zcf /tmp/contributors.tgz users/contributor1 users/contributor2
Copy the file /tmp/contributors.tgz to dmzserver.example.com and un-tar it into the same relative location:
cd /var/spool/imap/ sudo tar zxf /tmp/contributors.tgz
Open Workgroup Manager and select the accounts for the external contributors to the example.org project. Change their mail server to dmzserver.example.org.
Lastly, tell Cyrus to re-index the mail files on the dmzserver by using the command:
sudo -u cyrusimap /usr/bin/cyrus/bin/reconstruct
Postfix can host domains other than the local domain. In this case, we’ll set dmzserver.example.com to host the example.org domain as well as the dmzserver.example.com domain. Open Server Admin and connect to dmzserver.pretendco.com. Select the Mail service and click on the Settings tab, then click on the Advanced tab, then select the Hosting sub-tab. Add the example.org domain to the list of Locally Hosted Domains. This tells Postfix to deliver all mail addressed to the @example.org domain to the local mail agent, Cyrus IMAP, rather than looking up the MX record and passing the mail on to the destination.
The last part of the Postfix configuration is to make sure that mail sent to the external contributors in the example.com domain ends up in the example.org domain. To do this, we need to edit the /etc/postfix/main.cf and /etc/postfix/aliases files on server.pretendco.com.
In the main.cf file, make sure the alias_maps parameter includes the hash:/etc/postfix/aliases settings. The line should read something like:
alias_maps = hash:/etc/postfix/aliases
In the aliases file, put the entries:
Next, run the postmap command on the aliases file so that the file /etc/postfix/aliases.db file is updated.
sudo postmap /etc/postfix/aliases
Lastly, use Server Admin to set the Mail service on server.example.com to relay all mail through dmzserver.example.com.
But what to do if we want to have the same e-mail username for both domains, e.g. [email protected] and [email protected]? We can handle this through Workgroup Manager. Set up two users with different short names, e.g. infoexamplecom and infoexampleorg. As additional short names, add [email protected] and [email protected], respectively. Set up the mail service for each user (either as a normal mail box or as a forwarder), and it should just work.
Don’t forget to turn the Mail service back on.
Web Server Reconfiguration
We had been running the website for the example.org open source project from the /opensource subdirectory of the main example.com webserver. However, we would like to give the example.org project its own website. Fortunately, Mac OS X Server makes it easy to do.
In Server Admin, connect to dmzserver.example.com and click on the Web service. Click on the Sites tab and duplicate the example.com website. (Make sure that the default site — which has a domain name of “*” — is disabled or deleted.) Change all of the references from example.com to example.org. Also, change the location of the document root of the example.org website to be some place other than the same place as the example.com website. Then have your web designer create the new website in the new location.
One good way to organize a website’s underlying directories is to create a structure that looks like:
/WebServer/ example.com/ conf/ httpd_extra.conf Documents/ index.html logs/ access_log error_log example.org/ conf/ http_extra.conf Documents/ index.html logs/ access_log error_log
This isolates all of the parts of a website into one directory, including any additional config files, the HTML and image files for the site, and the logs.
The last thing we need to do is set up an HTTP redirect so that visitors to the old example.org project location at /opensource will be sent over to the new example.org website. Create a new plain text file called /WebServer/example.com/conf/httpd_extra.conf. This file should contain three lines:
Redirect /opensource http://example.org/
To pull this configuration file into the Apache web server system, you will need to add the line:
near the end of the website configuration file for the example.com website. It will be named something like /etc/httpd/sites/0001_any_80_example.com.conf. (The number at the front of the filename may vary.) Insert the additional line just before the line that closes the VirtualHost block.
There’s only one minor networking change. Instead of redirecting port 993 to 192.168.1.2, redirect port 993 to 192.168.2.2. This cuts off the last inbound connection from outside directly to the internal server. This does mean that inside users can no longer check their e-mail from the outside world without using VPN or some sort of tunneling service, but that’s what we want anyway.
At this point there are no longer any connections directly from the outside to the internal server. Nor is the internal server making any connections directly to the outside. This makes your server much safer, as anyone trying to break in will need to crack the defenses of the dmzserver before they can attempt to attack the internal server.
The example.org domain is up and running (albeit without mailing lists yet), and external contributors now have official email addresses in the example.org domain. Their old @example.com addresses still work, so people who haven’t updated their address books won’t have their mail bounce. Here’s what the final situation looks like: