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. 1) indefinitely long means the default lifetime of your KDC or the individual keys involved. The default also depends on your version of MIT kerberos. Older versions by default request 10 hour tickets regardless of the max lifetime set in the KDC config files or the principals themselves. 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. On 9/11/2007 1:29 PM, Nik Conwell wrote: > My frontends authenticate to the backends using GSSAPI. Every 5 > hours the frontends do a kinit to get a TGT to talk to the backend > and all is good. > > However, if the frontend imap (proxyd) is proxying a session for more > than 10 hours I get: > > imaps[3207]: GSSAPI Error: The context has expired (No error) > > This seems to happen in cmd_idle() (probably spends most of its time > there). The frontend is in cmd_idle() having just received something > from the user client to terminate the IDLE. The frontend writes DONE > \r\n to the backend but the write gets the context has expired error > but it isn't checking for errors returns on the prot_printf(). The > frontend then does a pipe_until_tag() waiting for the backend. > Meanwhile the backend has seen nothing and so is still waiting for > the frontend to terminate the idle. Hung. > > So, my questions are: > > 1) Should somebody (SASL?) be requesting an indefinitely long > context? gss_init_sec_context has an arg of the duration of the > context. My linux build (Thanks Simon) has 0 for the time_req which > is evidently defaulting to 10 hours. It could take GSS_C_INDEFINITE > but it's not apparent that this wouldn't just end up being the life > of the ticket (10 hours, 21 hours?). I'm game to try this if it's > not stupid. > > 2) Should somebody (SASL? frontend proxy?) be creating new contexts > automatically when the old ones expire? > > 3) Should cmd_idle() be just handling the error on the write to the > backend and passing that back up to the client who will reconnect again? > > > BTW - my imapd is CVS:1.509. I browsed the changelog for newer stuff > but didn't see anything relevant. > > Thanks for any info. > -nik > > Nik Conwell > Information Technology > Boston University > > ---- > 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 ---- 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
