Murder confusion -- two mupdate slaves, lmtpproxyd's always connecting to master

[Michael Bacon]

I saw this recommendation elsewhere, but I don't understand why one would 
set mupdate_config: unified if I'm not, in fact, running a unified murder. 
What's the gain here?  We have dedicated front-end boxes and dedicated 
back-end boxes.  Is this just sort of a, "yeah, it's not for that, but it 
does what you want anyway" kind of things?

Thanks,
-Michael

--On November 10, 2009 12:26:22 PM -0500 Brian Awood <bawood at umich.edu> 
wrote:

>
> You can avoid the behavior in your second question by setting
> mupdate_config: unified
> in your proxies imapd.conf.  That was a long standing issue with
> murder in a large scale environment with cyrus 2.2.
>
> On Tuesday 10 November 2009 @ 11:51, Michael Bacon wrote:
>> The second one is that the code for lmtpproxyd very explicitly
>> connects to the mupdate master rather than the local slave.  I
>> can't really figure out why it would do this, but here are the two
>> relevant snippets from lmtpd.c:
>>
>> This is from service_init:
>>
>>     if (config_mupdate_server &&
>>         (config_mupdate_config ==
>> IMAP_ENUM_MUPDATE_CONFIG_STANDARD) &&
>> !config_getstring(IMAPOPT_PROXYSERVERS)) {
>>         /* proxy only -- talk directly to mupdate master */
>>         r = mupdate_connect(config_mupdate_server, NULL, &mhandle,
>> NULL); if (r) {
>>             syslog(LOG_ERR, "couldn't connect to MUPDATE server %s:
>> %s", config_mupdate_server, error_message(r)); fatal("error
>> connecting with MUPDATE server", EC_TEMPFAIL); }
>>     }
>>
>>
>> and it appears that this runs every time a message delivery is
>> attempted:
>>
>> static int mlookup(const char *name, char **server, char **aclp,
>> void *tid) {
>>     int r, type;
>>
>>     if (server) *server = NULL;
>>
>>     if (mhandle) {
>>         /* proxy only, so check the mupdate master */
>>         struct mupdate_mailboxdata *mailboxdata;
>>
>>         /* find what server we're sending this to */
>>         r = mupdate_find(mhandle, name, &mailboxdata);
>>
>> In short, it looks like, unlike proxyd and pop3proxyd, lmtpproxyd
>> never even bothers to check the local mailboxes database, and when
>> it wants an answer, feels the need to go directly to the mupdate
>> master, rather than querying the handy dandy local slave.  Is this
>> intentional?  Why can't it use the local cache?
>>
>> Thanks much,
>> Michael Bacon
>> UNC Chapel Hill
>> ----
>> 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
>
>
>