below On 9/12/2007 8:54 AM, Nik Conwell wrote: > > On Sep 11, 2007, at 3:00 PM, Paul M Fleming wrote: > >> I had the same problems. if you google for this you'll find a >> discussion regarding how SASL context expires should be handled. >> Heimdal allows expired contexts to be used after expiration. MIT does >> not. > > > Thanks. I had seen your posting http://cyrusimap.web.cmu.edu/archive/ > message.php?mailbox=archive.info-cyrus&msg=38716 but saw no responses > so I wanted to bring it up again. > > I just did some more googling on sasl gssapi context expire and that > turned up some more good stuff. Thanks. > >> 2&3) My opinion is this behavior is broken in SASL unfortunately I'm >> not sure if it can be "fixed" without major changes to the SASL >> library. I know the openldap list discussed work arounds to deal with >> an expired context. Lowering the client timeout levels in imap can >> also help but you still get deadlocks between front and back ends >> which users notice a a client connection lock up. I did not attempt >> to change the code for SASL or IMAP, but handling a "context expired" >> event as a fatal error makes sense when running MIT kerberos. My >> guess is CMU doesn't have this issue because they use Heimdal. >> >> My solution was to change the keys involved in murder to have a >> 25hour max life and change the KDC to allow 25h tickets. Then instead >> of a period event in cyrus.conf use an at event to renew the ticket >> at 2:00AM when users are less likely to notice. The Cyrus timeouts >> kick in before start of business and most clients (Netscape, >> Thunderbird,etc) reconnect automatically and the user doesn't notice >> a thing, but you still have to deal with the log messages. This >> solution solved the deadlock issues for my clients. > > > Interesting about the cyrus timeouts. The clients I'm seeing this > problem with (pine and Outlook) are typically checking for mail every > couple of minutes and so the session never times out. the client to front-end connection won't timeout but once the FE-BE connection times out due to a context expiration the connection to the client will also be closed. > > Just curious - why didn't you decide to go with some other auth scheme > instead? (Having passwords embedded in config files doesn't appeal to > me though.) laziness - our RPM version of SASL has sasldb support disabled because we use kerberos. It was easier to "fix" the context expiration issue via a reconfig than to recompile and retest my entire murder cluster not to mention my openldap & sendmail installs which also use SASL. I'm also using a custom AUTH mech for cyrus that uses regular expressions to match kerberos prinipals so that would have required work too.. plus I really dislike passwords in config files. > > For the list in general - what are you all using for the Murder > authentication? Heimdal? Certs? Passwords in configs? > > -nik > > ---- 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
