painful mupdate syncs between front-ends and database server

[Michael Bacon]

--On October 19, 2009 9:37:57 PM -0400 Wesley Craig <wes at umich.edu> wrote:
> How are your frontend mupdate processes authenticating to your mupdate
> master?  And what version of Kerberos are you using (anticipating the
> answer to your first question)?  I suspect that you're getting a GSSAPI
> expired context.

We were originally doing GSSAPI, but ran into catastrophic performance with 
the auth_krb module.  I think this relates to Sun's terrible, horrible, no 
good, very bad implementation of krb5 (it appears to have gone downhill 
with the arrival of the cryptoadm framework), but at the time I didn't have 
time to fight with it, so we ditched it in favor of PLAIN with a very long 
password.

> lmtpd on your proxies is talking directly to the mupdate master?  It's
> possible for lmtpd on your proxies to only check the local mailboxes.db.

I'm a little confused as to why this is happening too.  Initially, when we 
configured inbound mail, we were relying on the lmtpproxyd's to return 
"User unknown" messages, and just telling sendmail to let it all in.  Bad 
idea -- I quickly put a valid user database back into place, because that 
was absolutely destroying the mupdate server, with all of the kicks it was 
generating.   At this point, we really shouldn't be having any bad users 
coming into the system, but because of various things (like user tables 
that aren't 100% up to date), we still get the occasional ones, but I don't 
think that's what's killing us.  At this point, I'm not 100% sure on how to 
quantify exactly what's making connections to the mupdate master and what's 
not, so I could be very off on what's going on.

Michael Bacon
UNC Chapel Hill