LMTP during dsync migration
Hi all,
Another question regarding migration. While migrating a mailbox with dsync is it safe to deliver mail via LMTP to the new (target) mailbox or is it wiser to deactivate LMTP delivery to this mailbox until it's fully migrated?
And what methods could I use to stop delivery to a mailbox during migration? Our user data is stored on an LDAP server.
Cheers,
j.hofmüller http://thesix.mur.at/
On 29.7.2014 15:48, Jogi Hofmüller wrote:
Hi all,
Another question regarding migration. While migrating a mailbox with dsync is it safe to deliver mail via LMTP to the new (target) mailbox or is it wiser to deactivate LMTP delivery to this mailbox until it's fully migrated?
And what methods could I use to stop delivery to a mailbox during migration? Our user data is stored on an LDAP server.
Cheers,
Considering you're planning to use doveadm backup, you can't deliver into the new mailbox. From dsync man page:
backup - Backup mails from default mail location to location2 (or vice versa, if -R parameter is given). No changes are ever done to the source location. Any changes done in destination are discarded.
Unless I misunderstood something, this means that if you deliver messages to the new mailbox, next run of doveadm backup will remove them.
Hi Jiri, all,
Thanks for your reply.
Am 2014-07-29 16:13, schrieb Jiri Bourek:
Considering you're planning to use doveadm backup, you can't deliver into the new mailbox. From dsync man page:
Yes, this is the way we plan to migrate the mailboxes.
backup - Backup mails from default mail location to location2 (or vice versa, if -R parameter is given). No changes are ever done to the source location. Any changes done in destination are discarded.
Unless I misunderstood something, this means that if you deliver messages to the new mailbox, next run of doveadm backup will remove them.
We are not planning on multiple runs of doveadm backup. The question is what to do with LMTP _while_ the doveadm backup migration is happening?
At the time when mailbox X get's migrated, the settings used for the proxy will be removed, so user X cannot access the mailbox on the old server anymore. Given the size of some of the mailboxes chances are quite high that there will be delivery attempts _during_ the migration process. That's what I am thinking about.
Cheers,
j.hofmüller http://thesix.mur.at/
On 30.7.2014 11:27, Reindl Harald wrote:
Am 30.07.2014 11:10, schrieb Jogi Hofmüller:
We are not planning on multiple runs of doveadm backup. The question is what to do with LMTP _while_ the doveadm backup migration is happening?
just shutdown the MTA so you don't receive new mail senders will defer and deliver later
Or better - disable LMTP service in Dovecot. Incoming mail will stay on your MTA and when you're done, you just tell it to deliver everything that piled up in the queue in the meantime
Hi all,
Thanks for your replies.
Am 2014-07-30 12:02, schrieb Jiri Bourek:
On 30.7.2014 11:27, Reindl Harald wrote:
just shutdown the MTA so you don't receive new mail senders will defer and deliver later
I would like to stay away from this option since we plan on doing a transparent migration that will take a few nights. Turning MTA off every night seems a bit drastic.
Or better - disable LMTP service in Dovecot. Incoming mail will stay on your MTA and when you're done, you just tell it to deliver everything that piled up in the queue in the meantime
Better but still not perfect ;) We have users that work late and I am sure they would complain when they don't receive email during migration nights.
Still thinking ...
Cheers,
j.hofmüller http://thesix.mur.at/
Am 30.07.2014 16:39, schrieb Jogi Hofmüller:
Am 2014-07-30 12:02, schrieb Jiri Bourek:
Or better - disable LMTP service in Dovecot. Incoming mail will stay on your MTA and when you're done, you just tell it to deliver everything that piled up in the queue in the meantime
Better but still not perfect ;) We have users that work late and I am sure they would complain when they don't receive email during migration nights
normally you announce a mainantaince window for such migrations
why do you need dsync at all for such a migration?
- HOT: rsync --delete-after -tPrlpogEAX /datadir/ root@new:/datadir/
- stop services
- COLD: rsync --delete-after -tPrlpogEAX /datadir/ root@new:/datadir/
- start services on new machine
the second rsync is damned fast because it only cares about changes and in case of really large data repeat the hot run multiple times to reduce the overall differences
nobody right in his mind starts such tasks while the servers are online because if something goes wrong you can throw your mandatory backups out of the window given you can choose what data you more like to loose - the one happened by errors while migration or the one received between backup and restore
Still thinking ...
you asked "The question is what to do with LMTP _while_ the doveadm backup migration is happening?" and there is not much to think
Hi Harald, all,
Am 2014-07-30 17:36, schrieb Reindl Harald:
normally you announce a mainantaince window for such migrations
That's what we do.
why do you need dsync at all for such a migration?
Migrating from cyrus to dovecot in a transparent manner.
Cheers,
j.hofmüller http://thesix.mur.at/
On 31.7.2014 12:05, Jogi Hofmüller wrote:
Hi Harald, all,
Am 2014-07-30 17:36, schrieb Reindl Harald:
normally you announce a mainantaince window for such migrations
That's what we do.
why do you need dsync at all for such a migration?
Migrating from cyrus to dovecot in a transparent manner.
Cheers,
As far as I know you can do the warm - cold with dsync too. First you do backup on live (i.e. accessible for both imap and delivery) mailbox. This takes a long time on big mailbox, but that should not be an issue since the mailbox can be used normally.
When it's done, you disable the mailbox (again, both imap and delivery) and repeat the backup, which should be relatively fast now. When that's done, enable mailbox on new storage and you're done.
I don't think it's possible to have the mailbox available all the time during migration. Well, it's possible, but it seems like recipe for trouble.
Hi Jiri, all,
Am 2014-07-31 12:33, schrieb Jiri Bourek:
As far as I know you can do the warm - cold with dsync too. First you do backup on live (i.e. accessible for both imap and delivery) mailbox. This takes a long time on big mailbox, but that should not be an issue since the mailbox can be used normally.
That's exactly what I was trying to describe in one of my previous emails (subject: incremental mailbox syncs for quick migration). Great to hear that this solution seems viable :)
When it's done, you disable the mailbox (again, both imap and delivery) and repeat the backup, which should be relatively fast now. When that's done, enable mailbox on new storage and you're done.
Right, just as I thought.
I don't think it's possible to have the mailbox available all the time during migration. Well, it's possible, but it seems like recipe for trouble.
Agreed. Just trying to keep the downtime as short as possible.
Cheers,
j.hofmüller http://thesix.mur.at/
Hi --
On 2014-07-31 12:05, Jogi Hofmüller wrote:
Am 2014-07-30 17:36, schrieb Reindl Harald:
why do you need dsync at all for such a migration?
Migrating from cyrus to dovecot in a transparent manner.
And additionaly, if one wants to switch mailbox formats whilst migration. Dsync is great in that scenario.
I did so, migrating from a dovecot 1.2.x to 2.x server in the past. Not many users, not many mail involved. Technically I did what has been proposed already: Running an initial dsync run, running periodic differential sync until final switch. During switch I had had to shut down dovecot for a short time.
In the meantime I use something like to block users during maintainance:
passdb {
[sent to early, sorry]
On 2014-07-31 12:05, Jogi Hofmüller wrote:
Am 2014-07-30 17:36, schrieb Reindl Harald:
why do you need dsync at all for such a migration?
Migrating from cyrus to dovecot in a transparent manner.
And additionaly, if one wants to switch mailbox formats whilst migration. Dsync is great in that scenario.
I did so, migrating from a dovecot 1.2.x to 2.x server in the past. Not many users, not many mail involved. Technically I did what has been proposed already: Running an initial dsync run, running periodic differential sync until final switch. During switch I had had to shut down dovecot for a short time.
In the meantime I use something like to block users during maintainance:
# temporary blocks passdb { driver = passwd-file deny = yes args = /path/to/deny-users }
# regular passwd { driver = sql args = /path/to/dovecot-sql.conf }
/path/to/deny-users holds username to block.
But, I have to admit: that doesn't work for all of my users, I never found out why. Thst's why I finally decided for a hard shotdown of dovecot for the final switch.
Regards and good luck, Michael
Hi,
Sorry for warming up this thread, but
Am 2014-07-31 13:34, schrieb Michael Grimm:
In the meantime I use something like to block users during maintainance:
# temporary blocks passdb { driver = passwd-file deny = yes args = /path/to/deny-users }
# regular passwd { driver = sql args = /path/to/dovecot-sql.conf }
/path/to/deny-users holds username to block.
This is really cool and works perfect for imap/pop. It doesn't work for LMTP, although it acknowledges that the user has been found in the deny passdb:
Aug 21 13:01:00 klee dovecot: lmtp(pid): Connect from IP Aug 21 13:01:00 klee dovecot: auth: passwd-file(fischer,IP): User found from deny passdb Aug 21 13:01:00 klee dovecot: lmtp(pid, fischer): 2UErAGzR9VMBPQAAGyzfLQ: sieve: msgid=unspecified: stored mail into mailbox 'INBOX' Aug 21 13:01:00 klee dovecot: lmtp(pid): Disconnect from 172.16.16.205: Successful quit
Is this what is supposed to happen (since LMTP doesn't use authentication)?
Regards,
J.Hofmüller
ich zitiere wie Espenlaub.
https://twitter.com/TheGurkenkaiser/status/463444397678690304
I would like to stay away from this option since we plan on doing a transparent migration that will take a few nights. Turning MTA off every night seems a bit drastic. What I do is I implement a delivery lock in the database. I like to use exim + mysql, but I think you can probably figure something out with
On 07/30/2014 10:39 AM, Jogi Hofmüller wrote: postfix + whatever, too.
In exim-ese:
mailbox_locked: debug_print = "R: mailbox_locked for $local_part@$domain" driver = redirect allow_defer verify = false retry_use_local_part = true domains = +virtual_domains condition = ${lookup mysql{select locked from mailbox where localpart='${quote_mysql:$local_part}' and domain='${quote_mysql:$domain}' and locked=1 and active}} data = :defer: Delivery deferred, mailbox is locked
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wed, 30 Jul 2014, Jogi Hofmüller wrote:
Or better - disable LMTP service in Dovecot. Incoming mail will stay on your MTA and when you're done, you just tell it to deliver everything that piled up in the queue in the meantime
Better but still not perfect ;) We have users that work late and I am sure they would complain when they don't receive email during migration nights.
Still thinking ...
In your original post you've wrote "While migrating a mailbox". So you migrate one user after another. Also, if you want to disable LMTP for that user, you want to disable IMAP and POP3, too, for the very same reason -> or at least put them in read-only mode.
So, IMHO, your goal is to make the mail storage of one user read-only. Experiment with ACLs. Make all the mailboxes of the user read-only. After migration remove the ACLs.
Make the mail storage inaccessable during backup for just one user:
How about adding another userdb { driver = passwd-file args = /.../%s/file } as the first one, which disables the access to the one user's mail storage currently migrated. %s would be lmtp, imap, pop3 and doveadm, IMHO. Make sure, doveadm sees no user in this userdb, but the others do, e.g. symlink the appropriate files and keep /.../doveadm/file zero-length, in order to fall back to LDAP always.
In short: doveadm must know the real path, all other services a faked one.
The migration of one user would be: put user in /.../{imap,pop3,lmtp}/file # or overwrite file with user doveadm auth cache flush # make sure, user info is not cached already migrate remove user from /.../file
a) Besides the %s-way, there must be a way to have doveadm override the settings in:
userdb { driver = passwd-file args = /.../file }
in the line of: doveadm -o userdb[*]/args=/dev/null ....
[*] IMHO you can specify which userdb section is meant by a number or something like that.
b) Instead of to put/remove the user, you can overwrite the file, if there is just one user, and remove the file at the very end.
Steffen Kaiser -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux)
iQEVAwUBU9nkkHz1H7kL/d9rAQJ+VQf+Ns/nm/T95z0iq+LC7YlYZTZi7JShHLhh DOAfLZ/DEl2ca1S7ed3SzdHYJu6JLZyU6U//BcRzCCtjmrgHMURNPSlpzFDHKi0O 2kRstMoj0DfMb7r9YO1YG4EQkhWpkkie2ORtN0pubAowcucpwieOPnEcDDipp+Wo lDlxzZ1gTP+hInYGQLvB8cWF8QN2MuwNuUPXBCq3AUrOAoSRh91ALWbEJJ4TXqZE Y3SbGkkZF5cEPqtMULAm+kEd7bKjty0Drsa52LSdlcrQvje+QZmqfe6t3E60tz/I GrNzi2EPMbw5iJqHeYVupqPJWslopxDIZdSP5kboX1eNeaoEJFUGMw== =N8uo -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Thu, 31 Jul 2014, Steffen Kaiser wrote:
On Wed, 30 Jul 2014, Jogi Hofmüller wrote:
Or better - disable LMTP service in Dovecot. Incoming mail will stay on your MTA and when you're done, you just tell it to deliver everything that piled up in the queue in the meantime
Better but still not perfect ;) We have users that work late and I am sure they would complain when they don't receive email during migration nights.
Still thinking ...
In your original post you've wrote "While migrating a mailbox". So you migrate one user after another. Also, if you want to disable LMTP for that user, you want to disable IMAP and POP3, too, for the very same reason -> or at least put them in read-only mode.
So, IMHO, your goal is to make the mail storage of one user read-only. Experiment with ACLs. Make all the mailboxes of the user read-only. After migration remove the ACLs.
Make the mail storage inaccessable during backup for just one user:
How about adding another userdb { driver = passwd-file args = /.../%s/file } as the first one, which disables the access to the one user's mail storage currently migrated. %s would be lmtp, imap, pop3 and doveadm, IMHO. Make sure, doveadm sees no user in this userdb, but the others do, e.g. symlink the appropriate files and keep /.../doveadm/file zero-length, in order to fall back to LDAP always.
In short: doveadm must know the real path, all other services a faked one.
The migration of one user would be: put user in /.../{imap,pop3,lmtp}/file # or overwrite file with user doveadm auth cache flush # make sure, user info is not cached already migrate remove user from /.../file
a) Besides the %s-way, there must be a way to have doveadm override the settings in:
userdb { driver = passwd-file args = /.../file }
in the line of: doveadm -o userdb[*]/args=/dev/null ....
[*] IMHO you can specify which userdb section is meant by a number or something like that.
b) Instead of to put/remove the user, you can overwrite the file, if there is just one user, and remove the file at the very end.
Maybe, you need not no other userdb, but you can make use of %s in your LDAP userdb - filter, e.g.
user_filter = (&(objectClass=posixAccount)(uid=%u)(!(deniedService=%Ls)))
however, you must test, if Dovecot's auth caching does honor the different values of %s in this case. I mean, if doveadm queries the user data, the result will be cached, if the LMTP service queries next: does it get the result of doveadm or not. I suppose, this applies to both variants.
Steffen Kaiser -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux)
iQEVAwUBU9nsCnz1H7kL/d9rAQIO9ggAuDB4ZlbD0kaZ6GmLILyHZZGCFX/+pldL sciBDsi4i+jzhx9b+QyRZQBafl4SsbzDa+8Aima40HqfE4ixKptx/3y1k0ftcP02 ZWgs6jj8pgkY5x1s/hhhDoE5RRE2wXwNJTd9O96XiaryFxhBgMDWy2qiiUXBVILt njB5udoU1WNH9TfdYPQVAHrC7YJbMAYzCb+7jM0HxFiwpwpiw9o59h7YwDx7D5/e 8hINfOTSWcU8tVBDNhjXRP3moawEGU2gkeBcA9ql6LCekLZm9f9mqZYrcbzdkWQJ kkJHTChZ+RP+Rgf6auP+rxzpnuvzk5+gSDBtJixvCPslji6thsW+Sg== =Khy7 -----END PGP SIGNATURE-----
Dear Steffen,
Finally managed to test your suggestions ...
Am 2014-07-31 09:11, schrieb Steffen Kaiser:
On Thu, 31 Jul 2014, Steffen Kaiser wrote:
How about adding another userdb { driver = passwd-file args = /.../%s/file } as the first one, which disables the access to the one user's mail storage currently migrated. %s would be lmtp, imap, pop3 and doveadm, IMHO. Make sure, doveadm sees no user in this userdb, but the others do, e.g. symlink the appropriate files and keep /.../doveadm/file zero-length, in order to fall back to LDAP always.
I tried that now and did not get any useful results; meaning that I did not manage to block a user from using any of the services.
While imap acknowledges finding the user in said file, lmtp doesn't even bother to look there. Both services however continue to work. I tried various return values for the userdb lookup but lmtp just seems to ignore everything.
imap can be disabled easily by means of a passdb that has deny = yes set.
This is really starting to drive me mad ...
a) Besides the %s-way, there must be a way to have doveadm override the settings in:
userdb { driver = passwd-file args = /.../file }
in the line of: doveadm -o userdb[*]/args=/dev/null ....
Quite frankly I don't fully understand what you mean by this.
Maybe, you need not no other userdb, but you can make use of %s in your LDAP userdb - filter, e.g.
user_filter = (&(objectClass=posixAccount)(uid=%u)(!(deniedService=%Ls)))
Didn't try that one since I figure if passwd-file does not work why should LDAP work?
Thanks for your suggestions anyway :)
Cheers,
j.hofmüller
We are all idiots with deadlines. - Mike West
Jogi Hofmüller wrote:
We are not planning on multiple runs of doveadm backup. The question is what to do with LMTP _while_ the doveadm backup migration is happening?
At the time when mailbox X get's migrated, the settings used for the proxy will be removed, so user X cannot access the mailbox on the old server anymore. Given the size of some of the mailboxes chances are quite high that there will be delivery attempts _during_ the migration process. That's what I am thinking about.
What we did was to install a "retry" transport in addition to "lmtp" in postfix master.cf:
retry unix - - n - - error
See http://www.postfix.org/error.8.html
Before migrating each user, we instructed postfix to route the affected user to the retry transport. This puts all incoming messages for this use into the queue while the migration is running. When the migration of this user has proven to be successful, you can revert the user to the default lmtp transport.
Good luck, Daniel
On 29 Jul 2014, at 16:48, Jogi Hofmüller jogi@mur.at wrote:
Another question regarding migration. While migrating a mailbox with dsync is it safe to deliver mail via LMTP to the new (target) mailbox or is it wiser to deactivate LMTP delivery to this mailbox until it's fully migrated?
And what methods could I use to stop delivery to a mailbox during migration? Our user data is stored on an LDAP server.
Temporarily disabling mail delivery for the user being migrated is the safest choice, but it's not a requirement. You could run "doveadm sync -1" for the user and it'll merge the changes without deleting any changes. There is some problem with "doveadm sync -1" though that if it's ran multiple times (more than once) and there are large enough changes it'll start doing some stupid things (can't remember the details - either duplicates mails or just changes their UIDs unnecessarily). Running it once should be safe though.
participants (8)
-
Daniel Parthey
-
Gedalya
-
Jiri Bourek
-
Jogi Hofmüller
-
Michael Grimm
-
Reindl Harald
-
Steffen Kaiser
-
Timo Sirainen