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 laterI 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 meantimeBetter 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/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 213 bytes Desc: OpenPGP digital signature URL: <http://dovecot.org/pipermail/dovecot/attachments/20140730/4310be33/attachment-0001.sig>
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 > nightsnormally 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 at new:/datadir/ * stop services * COLD: rsync --delete-after -tPrlpogEAX /datadir/ root at 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 246 bytes Desc: OpenPGP digital signature URL: <http://dovecot.org/pipermail/dovecot/attachments/20140730/fa7a797b/attachment.sig>
On 07/30/2014 10:39 AM, Jogi Hofm?ller wrote:> 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 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. 1) 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. 2) 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. > > 1) 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. > > 2) 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-----