Articles October 7, 2006 at 11:19 pm

How to Split a Server (Part 3 of 4)

Part 3 of the series where we focus on DNS and mail.

You can find Part 1 and Part 2 of this series which were published eariler.

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.

DNS Configuration

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.

image
image

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.

dmzserver.example.org.

  • 1.2.3.4
  • 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.

image

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 configuration

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.

image

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:

	[email protected]: [email protected]
	[email protected]: [email protected]

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.

image
image

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.

image
image
image
image
image

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:

	Include /WebServer/example.com/conf/httpd_extra.conf

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.

Network Configuration

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.

Conclusion

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:

image

Leave a reply

You must be logged in to post a comment.