issue with MIT KDC and LDAP DS
ssorce at redhat.com
Sat May 23 10:17:42 EDT 2009
On Fri, 2009-05-22 at 19:40 -0400, Ken Raeburn wrote:
> Doing things "in background" is a lot more complicated in a single-
> threaded process when the background task is defined entirely inside
> plugin. It may be a better way to do it in general, but Will's way
> probably a lot simpler with the current code base. And if the DS is
> on the same system, and running, the delay shouldn't be that large,
> and would only affect the very first request(s) received.
It depends on many factors, but it's probably ok for a first
implementation to just wait for a request.
However the driver could try to spawn a simple, very specialized thread,
just for handling the reconnection. With a big mutex around that code.
> I'd rather see it transparent to the main KDC code.
That would certainly be a good idea.
> Several ideas that have been kicked around involve
> multiple threads or processes, and would allow, say, the LDAP
> implementation to manage its own parallelism and background tasks
> without requiring hooks in the main KDC code. If that sort of big
> restructuring project can be done, great! I'd love to see it happen.
What need to happen to have it done ?
> I'd add that it would be nice if a KDC connected to an LDAP server
> could detect that the server went down, too, and automatically try
> reconnecting, without needing to be prodded by Kerberos traffic to
> notice. I'm not familiar enough with the LDAP APIs to know if
If you have a main loop you can get the same sort of notification you
get when any socket is close from the other side. (A reconnection thread
could easily do that)
Simo Sorce * Red Hat, Inc * New York
More information about the krbdev