kacperw at gmail
Feb 17, 2009, 3:10 PM
Post #6 of 7
(1931 views)
Permalink
|
|
Re: Migrating qmail from an old server to a new server
[In reply to]
|
|
On Tue, Feb 17, 2009 at 11:15 PM, Maurice Lucas - TAOS-IT
<mslucas [at] taos-it> wrote:
>> From: Kyle Wheeler [mailto:kyle-qmail [at] memoryhole]
>> On Tuesday, February 17 at 04:05 PM, quoth Asif Iqbal:
>> >> If you can't tolerate downtime, then you're going to have to handle
>> >> some sort of a migration, where both machines are up and running for
>> a
>> >> while (with different IP addresses).
>> >
>> > I like this third scenario. So I just change MX number to for the
>> > old oneto 20 and have the new one to 10 and wait until the queue
>> > cleans up on the old one and then decommision it? I am sure there
>> > is something I am missing.
>>
>> That's *close* to correct, yes. But changing the MX number won't solve
>> the issue: you don't want the old server to be a *backup* MX. The only
>> reason you're leaving it turned on is so that it can flush its queue.
>> So you can turn off qmail-smtpd entirely, just to ensure that no
>> additional messages get into the queue, even by accident.
>>
>
> So stop qmail-smtpd and the only emails which can get injected in the queue will be local emails from e.g. qmail-inject.
You haven't said anything about how mail is stored. From your listing,
the files that you describe as "I have no idea what this file does"
mention ldap amongst others, which would suggest that your users
authenticate over ldap and that mail is stored locally. Which is to
say, you need a proper migration plan. Here's a start, that you should
adapt to any special considerations in your setup:
0. Figure out all where all the "I have no idea what this file does"
comes from. looks like a bunch of custom patches!
1. set up the new qmail server to be identical in function to the old
one and migrate user accounts. TEST ALL SERVICES.
2. migrate user's mailboxes (mbox and Maildir can be done
corruption-free with several rsyncs, see below, if you use imap then
you want to preserve imap flags and such, best done with imapsync or
similar software)
3. (when your users are asleep) take down smtpd and flush the old mail
queue like the fine gentlemen before me mentioned. incoming mail will
now be in limbo. preferrably stop pop3d and imapd as well so that your
users don't mess with your migration.
4. migrate any remaining mail to the new server, now that the
mailboxes aren't being modified by incoming mail and users frobbing
their mailboxes.
5. TEST ALL SERVICES! Check that everything migrated nicely & noone
lost their mail, imap flags were preserved etc etc.
6. set up the old server to forward all its incoming mail to the new
server, essentially becoming a backup MX.
7. put the new server in as a primary mx and bob's your uncle.
8. either your users start checking their mail using the new server's
domain name or you move the corresponding domain pointers, in which
case they'll have to wait (a day or more) for DNS to propagate your
changes.
Like Kyle said, if you can't tolerate downtime, this will be a little
more tricky, as you'll have to do step 4. without doing step 3, which
means you'll have to sync live mailboxes. But hey, maybe you have some
sort of storage backend or something awesome like that and don't need
to worry about migrating mailboxes?
HTH,
0K
--
http://kacper.doesntexist.org
http://windows.dontexist.net
Employ no technique to gain supreme enlightment.
- Mar pa Chos kyi blos gros
|
