On Wed, Nov 29, 2006 at 11:46:46AM -0500, Wesley Craig wrote: > On 29 Nov 2006, at 10:46, Janne Peltonen wrote: > >The part '... all "replicated" servers can serve the same mailboxes > >from a > >shared filesystem' attracted my attention. Is this the LB that is > >reported not > >to work with current murder/replication? Or is this something else? > In the "replicated" mupdate_config, each backend (nothing to do with > replication) is meant to serve data from a common mail spool, while > maintaining a "replicated" copy of mailboxes.db. The changes to > implement this IMAP_ENUM_MUPDATE_CONFIG_REPLICATED are isolated to > imap/mupdate-client.c, effectively to just remove references to the > backend server. So, this configuration would remove the various > locking problems surrounding mailboxes.db, since each backend would > be maintaining a separate copy. Any concerns related to locking in > the mail spool would still be relevant, tho that locking is typically > less esoteric. You'd need to have an mupdate master as well. Now /this/ is an interesting feature. Does away with the need to share the config dir... I think. LMTP delivery should work (with MUPDATE), the same with duplicate delivery suppression. Mm. Comparing this solution to sharing the configdir: +no file locking issues, that is: +no contention to mailboxes +can use any database format +can use duplicate delivery suppression +officially supported, so won't stop working with future versions -must use mupdate master -> SPOF? not if the mupdate master is an active-passive cluster -how synchronous will the metadata be? So if I'm correct, to achieve a true single server image, you don't actually have to sync anything but the mailboxes list... sieve, delivery, dupl suppression etc. should "just work". Nice. --Janne ---- Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
