Sharing Murder?

[Janne Peltonen]

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