[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Graceful way to move user's mail from one host to another?

adam et al.,

[ sorry for the delay... this has been posted a month ago ]

this is how we were doing it before we had the cyrus murder setup in
place (which makes moving of spools from one host to another rather
painless) -- note that none of this was actually thought out or
implemented by myself but by other, better ones who came before me ;)

* Adam Rosi-Kessel <adam@rosi-kessel.org> [2006-03-03 16:07]:
> In the past when I've done this, I've always done an awkward one-by-one
> move, where first I rsync the user's home directory over, then I move the
> messages from the user's mail spool into a file in their home directory and
> immediately put a .forward file in place, re-rsync the home directory, then
> on the target system, I go and copy all the messages from the spool file in
> their home directory back into the real spool file in /var/mail. (In cases
> where I'm also changing DNS, I then implement the DNS change, and the
> .forward file on the first host takes care of messages delivered to the old
> IP address until the DNS change propagates).

since we only have virtual users all relevant data (mail) is stored
somewhere below /var/spool/imap so we don't have to mess with $HOME
*and* $MAIL

we create some CNAME DNS record (e.g. relocation.example.org) that
points to the old box (boxA) and change the "mailhost" (which is
completely dependent on how you're doing your mail routing; all MTAs
should have some kind of lookup table to allow for individual routing
info) of all users who should be moved to boxB to that DNS entry.
  as soon as all involved mail/mx servers have updated their routing
info we 'rsync --delete' all data to the boxB.
as has been pointed out none of this should disrupt any services for
anyone so this could be done before the actual migration starts.

there's another DNS entry (e.g. connectionrefused.example.org) that
sits on a logical interface with no deamon listening on that
interface. so when we start migration we change the CNAME of
spoolmigration to point to connectionrefused.example.org and reload

all open sessions (esp. IMAP) to the old boxA should be killed to
ensure consistency in the spools before rsync'ing again (which is now
rather fast because we're just syncing a few deltas, depending on how
long ago the complete rsync was). no new connections are possible at
this point and incoming mail for these accounts gets queued.
(it's up to you to ensure this. don't forget about webmail, ssh logins
or other ways of direct or hardcoded access to the spools or
spoolhosts in your setup).

then we do all that's necessary to ensure the spools on boxB are in
place properly (for cyrus this ususally means creating mailboxes,
copying over sieve files and subscriptions, setting IMAP quotas, etc).

finally we change the "relocation" DNS entry to point to boxB and
reload name servers. all routing entries for the accounts just moved
are changed to point to boxB as well.

after making sure everything is working fine you may remove the old
spools from boxA. YMMV.


peter.schober@univie.ac.at - vienna university computer center
Universitaetsstrasse 7, A-1010 Wien, Austria/Europe
Tel. +43-1-4277-14155, Fax. +43-1-4277-9140

Reply to: