On 28.11.2013, at 19.08, David Bishop dovecot@dpe.lusars.net wrote:
There are trams shuttling back and forth along this road (stopping at each station), and adding a small box (such as a weatherproofed Raspberry Pi with a wifi dongle) to transport files up and down the road is pretty simple.
But if you do it this way and you can keep a full copy of the shared mail storage on your Raspberry, that would be possible already with dsync I think. dsync supports quick incremental updates by keeping track of the previous state between the servers. This state is saved in a file, so you could keep a different state for each different dsynced server.
Bravo for a solution that doesn't require a code change and doesn't seem to require directly touching the spools! :)
Reading the man page, it looks like only mirroring for people who happen to be checking email at a given place (as well as people who have received mail and the shared mailboxes) seems like a pretty simple thing to do. Hurrah!
Thank you, this is wonderful.
And more questions...
If I'm running a virtual mail domain, the user/pass I give is for the virtual mail user, correct? And, in a virtual mail setup, do I specify "username" or "username@domain”?
Unrelated to replication and Dovecot doesn’t really care. As long as passdb/userdb works the way you want.
Is there a window beyond which synchronization becomes more difficult? For instance, if messages (or metadata updates, like "I deleted this message") get parked overnight without updating, and in the morning (9 hours later), the trams (one at a time) pull into range of wifi, there won't be confusion, right?
The dovecot.index.log is used by replicator process and IMAP CONDSTORE/QRESYNC extensions to send recently expunged messages to the sender. If there have been too many changes, all of the changes will be sent and the performance will be worse. The transaction log sizes are specified by src/lib-index/mail-transaction-log-private.h MAIL_TRANSACTION_LOG_ROTATE_MIN_SIZE MAIL_TRANSACTION_LOG_ROTATE_MAX_SIZE MAIL_TRANSACTION_LOG_ROTATE_TIME. The current defaults are thought to be mostly abuse-only workarounds and normally you shouldn’t reach them. This same tranaction log relates to replication efficiency.