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.