On Thu, 25 Feb 2010 12:08:03 +1100
Adrian Overbury <adr...@inomial.com> wrote:
> I think that there's an important step here that I always use when I'm
> doing a mail migration. It could really go anywhere above the 'wait for
> a Friday night' step, really. "Reduce the TTL on the domain to
> something quite small, ie: 5 minutes." The point of this is that you'll
> get an idea rather quickly of whether or not it works and, if it
> doesn't, you'll be able to change it back without a portion of the users
> experiencing long downtimes because of DNS records pointing to the wrong
> server.
Let's see if I remember the steps I had to use a few years ago when
we took over an ISP with an aging server across town. Since the server needed
to be replaced anyway, I think I did the following:
1) Install pop3/imap proxy on new server. I used perdition for this.
I set so that users not in a database would be proxied back to the old
server, others would be proxied to 127.0.0.1 where the "real" pop3/imap
daemons were bound.
2) Set a transport in postfix to send all mail for that domain to their old
server.
3) Change DNS to insert myself in the middle of every pop3/imap/smtp/etc
transaction.
(Wait for DNS to propogate, play games, do whatever.)
Now the fun of moving the users!
I set up a per-user transport db: I think I made the default be "forward to old
server"
for the domain, and "local" transport for users specifically listed.
I set up a 'move a single user' script that would do the following (again, it's
been 9
years, so I may be forgetting something):
. Set user to 'deferred' mailer (remember i had that nifty per-user
transport!)
. rsync any .forward on old server to new server
. set .forward on old server to point to new server (the old server ran icky
sendmail,
so I had limits on trickery there.. postfix is much easier to abuse with
strange rulesets. this was so any mail that somehow made it to the old
server
would come to the new one instead of getting in their inbox.
Now at this point, all mail will funnel back to newserver where it will get into
the deferred queue.
, rsync users mailbox from old server to new server
. set perdition to send that user to new server instead of old
. set transport for that user to be 'local'.
That as I recall is all I did, well that and running the 'move a single user' a
few
thousand times, though almost always in large clusters like "all the A users".
Eventually I removed perdition and made pop3/imap answer on the real interfaces
as well as localhost as well as removing the transport map.
I think I'm missing a step in there somewhere, but damned if I remember what it
was.
The result was something like 5200 users moved and not a single user noticed.
YMMV, users with persistant IMAP connections would have problems with this
method
no doubt. POP3 users are pretty simple to move.
