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
