LDAP timeouts during failure conditions

[Phil Mayers]

On 29/06/11 18:48, John Dennis wrote:

> an observation). I kinda think it might be worthwhile to start with a
> clean slate, write down the requirements for the module and write it
> cleanly from scratch to match the requirements.

Maybe; but then you've got the problem of a) throwing away a lot of code 
and having to rewrite it, and having the time to rewrite it and b) 
ensuring you understand all the use-cases that people put it to, and 
either accounting for them or providing methods of doing the same.

I guess you could rename rlm_ldap to rlm_ldapold and create a new 
rlm_ldap with some "helpers" defined in policy.conf, but it seems like a 
lot of work. Additionally, given the confusion that reigns on the main 
list sometimes from old FAQs, I suspect it would cause havoc in terms of 
support.

>
>> * it doesn't touch the eDir code - I don't have a way to test it
>
> Perhaps a bit off topic for this discussion, but I always thought it was
> dubious to have special code for a specific LDAP server in FreeRADIUS. I

Examining the code, it seems that eDir needs specific LDAP controls to 
extract the cleartext password; grumble. So I suspect it needs to stay.

>
> Side comment on server models:
>
> Sorry, forgot who said this in the last couple of days, but they
> endorsed the event loop driven asynchronous model. After working for

I think that was me ;o)

> many years on a variety of servers I too have come to believe event loop
> driven architectures are superior in contrast to forking children,
> spawning threads, etc. Anything we've written recently follows the event
> loop model. It's not perfect by any means but it gets rid of a lot of
> nasty problems and IMHO the resulting code simplier and easier to

Obviously I agree, but a lot of people don't. Some people hate the way 
the callback model breaks up the flow control for anything involving 
composite operations.

It also means you need protocol implementations that will let you take 
over the networking - drive the socket receive/transmit loop yourself, 
and feed data into/out of the protocol, generating protocol PDU 
callbacks back into your app. Sadly (from my point of view), those are 
very rare.

TBH I don't think it matters that much to anyone except the developers 
what the underlying processing model is - users interact with the module 
processing, string-expansion and unlang features, not the select() loop.

On that latter topic: I do wonder if we might start running into 
problems with fd_set size limitations now that "master" supports TCP 
sockets. Eduroam sites (e.g. us) using radius-over-TLS and DNS-based 
autodiscovery could, conceivably, have many tens of TCP connections open 
at any given time. But an epoll event core is probably pretty trivial, 
given that Alan has factored the existing loop cleanly.