issue with MIT KDC and LDAP DS

[Simo Sorce]

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
> a  
> plugin.  It may be a better way to do it in general, but Will's way
> is  
> 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
> database  
> 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
> that's  
> practical.

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.

-- 
Simo Sorce * Red Hat, Inc * New York