[Dovecot] Gotchas in switching from one server to another without impacting users?
We have to replace one mail store (foo.example.org) with another (bar.example.org). I rsync'd the maildirs from foo to bar today and the plan is to hold all delivery (in the SMTP server) on foo over the weekend, rsync again (this time it should be much faster since the large xfer already occurred today), then flush the SMTP queue on foo towards bar, direct all new deliveries to bar.example.org. Users currently access their IMAP mailboxes via imap.example.org. I plan to just 'flip the switch' at DNS so imap.example.org points to bar.example.org (instead of foo.example.org) so users don't have to change anything on their end and should not even notice this change.
Is there anything else I should think about to mitigate users noticing a change? Does the fact that the mail filenames include 'foo.example.org' in the file name (while new deliveries to bar.example.org will include that new hostname) spell trouble later on or can I ignore it? Is there a more efficient way to achieve my goal?
And finally, dovecot on foo.example.org is 1.1.7 while the new server is running 1.1.16. I don't think that should be an issue, but mentioning it just in case.
Thanks!
-- GC
On Aug 14, 2009, at 12:36 AM, Gary Chodos wrote:
We have to replace one mail store (foo.example.org) with another (bar.example.org). I rsync'd the maildirs from foo to bar today and the plan is to hold all delivery (in the SMTP server) on foo over the weekend, rsync again (this time it should be much faster since the large xfer already occurred today), then flush the SMTP queue on foo towards bar, direct all new deliveries to bar.example.org. Users currently access their IMAP mailboxes via imap.example.org. I plan to just 'flip the switch' at DNS so imap.example.org points to bar.example.org (instead of foo.example.org) so users don't have to change anything on their end and should not even notice this change.
And I guess you also thought about the DNS cache TTLs?
Is there anything else I should think about to mitigate users noticing a change?
If the maildirs are identical and no mails get lost during the move,
that should be it.
Does the fact that the mail filenames include 'foo.example.org' in the file name (while new deliveries to bar.example.org will include that new hostname) spell trouble later on or can I ignore it?
Filenames don't matter.
And finally, dovecot on foo.example.org is 1.1.7 while the new server is running 1.1.16. I don't think that should be an issue, but mentioning it just in case.
Whenever upgrading it's a good idea to go through the items marked
with "*" in NEWS file (http://dovecot.org/doc/NEWS-1.1) There aren't
many usually.
I would move the imap.* to a neverland address while doing the switch so users arn't opening email while files are being rsynced.
OR, just add a firewall rule to old server blocking imap.
I would also send a notice to uses a few days (preferably a week in a large setup) saying that email may be intermittently unavailable at 9pm on bla bla day while we perform maintenance on our servers to improve our service to you.
Have a place on your site where they can check the status of the move and it should avoid "most" phone calls.
Thomas Suckow
On Thu, Aug 13, 2009 at 9:48 PM, Timo Sirainentss@iki.fi wrote:
On Aug 14, 2009, at 12:36 AM, Gary Chodos wrote:
We have to replace one mail store (foo.example.org) with another (bar.example.org). I rsync'd the maildirs from foo to bar today and the plan is to hold all delivery (in the SMTP server) on foo over the weekend, rsync again (this time it should be much faster since the large xfer already occurred today), then flush the SMTP queue on foo towards bar, direct all new deliveries to bar.example.org. Users currently access their IMAP mailboxes via imap.example.org. I plan to just 'flip the switch' at DNS so imap.example.org points to bar.example.org (instead of foo.example.org) so users don't have to change anything on their end and should not even notice this change.
And I guess you also thought about the DNS cache TTLs?
Is there anything else I should think about to mitigate users noticing a change?
If the maildirs are identical and no mails get lost during the move, that should be it.
Does the fact that the mail filenames include 'foo.example.org' in the file name (while new deliveries to bar.example.org will include that new hostname) spell trouble later on or can I ignore it?
Filenames don't matter.
And finally, dovecot on foo.example.org is 1.1.7 while the new server is running 1.1.16. I don't think that should be an issue, but mentioning it just in case.
Whenever upgrading it's a good idea to go through the items marked with "*" in NEWS file (http://dovecot.org/doc/NEWS-1.1) There aren't many usually.
On Fri, 14 Aug 2009, Timo Sirainen wrote:
On Aug 14, 2009, at 12:36 AM, Gary Chodos wrote:
We have to replace one mail store (foo.example.org) with another (bar.example.org). I rsync'd the maildirs from foo to bar today and the plan is to hold all delivery (in the SMTP server) on foo over the weekend, rsync again (this time it should be much faster since the large xfer already occurred today), then flush the SMTP queue on foo towards bar, direct all new deliveries to bar.example.org. Users currently access their IMAP mailboxes via imap.example.org. I plan to just 'flip the switch' at DNS so imap.example.org points to bar.example.org (instead of foo.example.org) so users don't have to change anything on their end and should not even notice this change.
And I guess you also thought about the DNS cache TTLs?
The OP should also consider killing dovecot during the rsync (similar to what another member of this list suggested). Then restart with a new configuration that proxies incoming IMAP connections towards the new server in case some clients still hit the old server before full DNS propagation.
-- Sahil Tandon sahil@tandon.net
On Fri, Aug 14, 2009 at 5:17 PM, Sahil Tandonsahil@tandon.net wrote:
On Fri, 14 Aug 2009, Timo Sirainen wrote:
On Aug 14, 2009, at 12:36 AM, Gary Chodos wrote:
We have to replace one mail store (foo.example.org) with another (bar.example.org). I rsync'd the maildirs from foo to bar today and the plan is to hold all delivery (in the SMTP server) on foo over the weekend, rsync again (this time it should be much faster since the large xfer already occurred today), then flush the SMTP queue on foo towards bar, direct all new deliveries to bar.example.org. Users currently access their IMAP mailboxes via imap.example.org. I plan to just 'flip the switch' at DNS so imap.example.org points to bar.example.org (instead of foo.example.org) so users don't have to change anything on their end and should not even notice this change.
And I guess you also thought about the DNS cache TTLs?
The OP should also consider killing dovecot during the rsync (similar to what another member of this list suggested). Then restart with a new configuration that proxies incoming IMAP connections towards the new server in case some clients still hit the old server before full DNS propagation.
To make the proxy feature work I had to allow plaintext auth on 143 from old -> new server. I use firewall rules to prohibit anyone except the old server from accessing the new one on port 143. Does this pose a security issue? Is there something else I should do to prevent security holes?
Quoting "Gary Chodos" gchodos@gmail.com:
On Fri, Aug 14, 2009 at 5:17 PM, Sahil Tandonsahil@tandon.net wrote:
On Fri, 14 Aug 2009, Timo Sirainen wrote:
On Aug 14, 2009, at 12:36 AM, Gary Chodos wrote:
We have to replace one mail store (foo.example.org) with another (bar.example.org). I rsync'd the maildirs from foo to bar today and the plan is to hold all delivery (in the SMTP server) on foo over the weekend, rsync again (this time it should be much faster since the large xfer already occurred today), then flush the SMTP queue on foo towards bar, direct all new deliveries to bar.example.org. Users currently access their IMAP mailboxes via imap.example.org. I plan to just 'flip the switch' at DNS so imap.example.org points to bar.example.org (instead of foo.example.org) so users don't have to change anything on their end and should not even notice this change.
And I guess you also thought about the DNS cache TTLs?
The OP should also consider killing dovecot during the rsync
(similar to what another member of this list suggested). Then restart with a new configuration that proxies incoming IMAP connections towards the new server in case some clients still hit the old server before full DNS propagation.To make the proxy feature work I had to allow plaintext auth on 143 from old -> new server. I use firewall rules to prohibit anyone except the old server from accessing the new one on port 143. Does this pose a security issue? Is there something else I should do to prevent security holes?
I wasn't really paying attn to this thread, but I just did this. I
used ZFS snapshots this time, last time I used rsync. Both my boxes
were behind load balancers, so it was a simple IP change there and
seemless for the end-users. I also upgraded to Dovecot 1.2.
No so seamless was - For some reason, users who use AVG email scanning
with Outlook are no longer able to POP mail. The download 'freezes'.
I redirected POP from Dovecot to qmail-pop3d, had users change the
fqdn of the mail server, I wiped out existing mailboxes, I had users
try to add brand new mailboxes, I changed the pop3_uidl_format - but
nothing worked. The only solution was to disable AVGs email scanning.
Just a heads up - something is amiss.
Rick
participants (5)
-
Gary Chodos
-
Rick Romero
-
Sahil Tandon
-
Thomas Suckow
-
Timo Sirainen