On 06/29/2011 12:59 PM, Phil Mayers wrote: Glad to see someone tackling the LDAP code. This comment is beyond the connection issue, but from working with rlm_ldap in the past it seemed to me the implementation was a bit "crufty", probably the result of incremental evolution by multiple parties over time (no criticism, just 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. Now here is the silly egregious part of this comment I have to apologize for, while I could technically do the work or contribute to it (I work in a group dedicated to identity/authentication solutions based on LDAP, Kerberos & PKI) I am so swamped with work at the moment I couldn't volunteer, sorry :-(
* 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 wonder if it should be removed and just stick with the standardized LDAP API. If there was a strong argument for server specific logic perhaps LDAP should follow the SQL model with a generic LDAP module and driver specific sub-modules. 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 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 understand, which means less bugs. It's too big a change for FreeRADIUS but I thought I would at least endorse the previous comment. -- John Dennis <jdennis@redhat.com> Looking to carve out IT costs? www.redhat.com/carveoutcosts/