Re: [Dovecot] Gotchas in switching from one server to another without impacting users?

2009-08-18 Thread Rick Romero

Quoting "Gary Chodos" :


On Fri, Aug 14, 2009 at 5:17 PM, Sahil Tandon 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



Re: [Dovecot] Gotchas in switching from one server to another without impacting users?

2009-08-17 Thread Gary Chodos
On Fri, Aug 14, 2009 at 5:17 PM, Sahil Tandon 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?


Re: [Dovecot] Gotchas in switching from one server to another without impacting users?

2009-08-14 Thread Sahil Tandon
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 


Re: [Dovecot] Gotchas in switching from one server to another without impacting users?

2009-08-14 Thread Thomas Suckow
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 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?
>
>> 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.
>


Re: [Dovecot] Gotchas in switching from one server to another without impacting users?

2009-08-13 Thread Timo Sirainen

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.


[Dovecot] Gotchas in switching from one server to another without impacting users?

2009-08-13 Thread Gary Chodos
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