Re: [vps-mail] E-mail Only Server

[Lang Zerner <lang@xxxxxxxxxxxx>]

Mike Skimin wrote:

> Have I missed anything?  This is a big client of ours and I don't want 
> to mess this up and risk losing the client.


I just did exactly this--migrated mail to a separate server--for a 
client of mine.  Following is my best recollection of what I did.  In 
these instructions, assume that newserver.example.com is the mail domain 
of the new server, and oldserver.example.com is the mail domain of the 
old server.  Note that I haven't tested any of the command-line examples 
below.  They're to convey a way to accomplish the task at hand, not to 
copy and paste.

1) su to get a root shell on both servers.  The command line examples 
below assume you use bash or sh, and that both machines are VPS v2.  To 
be sure, start a bash shell on each server after you become root:

bash

2) GO TO THE NEW SERVER

3) Create user accounts for each user on the new server.  After creating 
the users, copy lines from /etc/passwd on the old server to the new one 
to preserve the old passwords.  (Don't just copy the /etc/passwd file 
wholesale or you'll overwrite any existing system or other users.)

Note: If the old server is a VPS v1, you'll need to migrate the users 
from the old password-encryption method.  Scott Wiersdorf has developed 
a great script to do this, and it even creates the user accounts and 
sets quotas.  More info at 
http://perlcode.org/tutorials/sysadmin/pwd_migrate/ .  If you use this 
script, don't create the users manually--Scott's script skips any users 
that are already in /etc/passwd.

4) Make sure the mail domains of the new server and the old server are 
both in /etc/mail/local-host-names.  Use a text editor or enter the 
following lines, followed by Control-D:

cat >> /etc/mail/local-host-names
newserver.example.com
oldserver.example.com

Be sure you use two greater-than signs (>>) to append these lines to the 
end of /etc/mail/local-host-names.  If you use only one greater-than 
sign (>), you'll completely replace the contents of the file with the 
above two lines.

5) NOW GO TO THE OLD SERVER.

The following command line examples assume the old server is also a VPS v2.

6) Add aliases to make each user's mail go to both mailboxes (one copy 
kept on the old server, one forwarded to the new one):

bash
for user in `ls -1 /home`; do
 echo "$user: $user@xxxxxxxxxxxxxxxxxxxxx, \\$user" >> /etc/mail/aliases;
done

This ensures that user mailboxes will be kept in sync on both servers 
while the

7) Rebuild the aliases database to make the aliases stick:

cd /etc/mail
make

This is a good time to send a test message to a user  or two on the old 
server and make sure if it shows up on in the user's mailbox on both 
servers.  You really want this mirroring to be working before you continue.

8) GO BACK TO THE NEW SERVER.

9) Copy the users' mail inboxes and mail folders over, setting correct 
ownership and permissions.  The following command-line example assumes 
users keep their mail folders in ~/Mail (the standard for iManager), and 
you'll have to enter your scp password twice for each user:

for user in `ls -1 /home`; do
 scp -pC oldserver@xxxxxxxxxxxxxxxxxxxxx:/var/mail/$user /var/mail
 mkdir /home/$user/Mail
 scp -rpC oldserver@xxxxxxxxxxxxxxxxxxxxx:/home/$user/Mail\* 
/home/$user/Mail
 chown -R $user:$user /var/mail/$user /home/$user/Mail
 chmod 600 /var/mail/$user /home/$user/Mail/*
done

10) If you have any virtusers defined on the old server, copy those 
over, too:

scp -pC oldserver@xxxxxxxxxxxxxxxxxxxxx:/etc/mail/virtusertable /etc/mail
cd /etc/mail
make

Obviously, this assumes you've not defined any virtusers on the new 
server yet, since the above operation completely replaces the existing 
virtusertable file.

11) If you have aliases defined on the old server (other than the 
standard system aliases and the forwarding aliases you created in step 
6), add them to /etc/mail/aliases.  I recommend you do this manually to 
avoid overwriting the system aliases on your new server.  You might 
consider copying the old aliases file to /etc/mail/aliases.oldserver and 
comparing with diff to get an idea of what's different.

13) If you want to provide web-based email, install the same web-based 
email program on the new server.

14) Let your users know you are going to migrate to a new server.  The 
only thing they need to worry about is filing mail in folders on the 
server (as with an IMAP mail account or a web-based mail reader like 
iManager or CPX).  If they file something in a folder while the 
migration is taking place, it may get filed on the old server, then seem 
to "disappear" when they switch to the new server (which has copies of 
their mail folders as of today).  Users should stop using mail folders 
on the server until the migration is complete.

15) After all users have been notified to temporarily stop using mail 
folders, it's time to change the MX record so it points to the new 
server.  Here's a clever way I did this so that everything changed in sync:

  a) If your inbound mail server host (I'll call it mail.example.com) 
record is a CNAME,
  change it to an A record with the IP address of the new mail server.

  b) Change the MX record for example.com to refer to mail.example.com 
instead of
  the "@" null host.

  c) If you have other mail-related hosts that should move to the new 
server (such as
  pop.example.com, imap.example.com or smtp.example.com), make them CNAMEs
  pointing to mail.example.com.

When these changes propagate, not only will the MX change, but user's 
mail clients will magically start accessing the new server for all 
mail-related hosts.  As an added convenience, use mail.example.com as a 
ServerName for a virtual host where your web-based mail reader runs.

16) Give the DNS changes a day or two to propagate.

17) Shut down the web-based email reader on the old server, or change it 
to a redirect that sends folks to http://mail.example.com/ (or whatever 
URI will get them to mail on the new server).

18) Let your users know they can start using their mail folders again. 

19) Be available to handle the inevitable problems on a moment's notice.