Howard Chu wrote:
Ralf Haferkamp wrote:
Hi,
On Thursday 14 October 2010 02:02:17 Howard Chu wrote:
hyc@OpenLDAP.org wrote:
Update of /repo/OpenLDAP/pkg/ldap/libraries/libldap
Modified Files: sasl.c 1.82 -> 1.83
Log Message: More for prev commit. What about ldap_pvt_sasl_getmechs() ?
CVS Web URLs: http://www.openldap.org/devel/cvsweb.cgi/libraries/libldap/
http://www.openldap.org/devel/cvsweb.cgi/libraries/libldap/sasl .cChanges are generally available on cvs.openldap.org (and CVSweb) within 30 minutes of being committed.
Please review and comment, thanks.
It seems that SASL/GSSAPI binds broke somehow. At least for me ldapsearch from current HEAD hangs in ldap_int_select(). I have 2.4.23 on the server side. Here is the end of ldapsearch's debug output:
Thanks, I suspected that might happen. I only tested DIGEST-MD5 and EXTERNAL so far. Will look into it shortly.
All working for me now.
Looking at it again, it strikes me that perhaps this restructuring was an exercise in futility. The ldap_host_connected_to() function can block doing a DNS lookup, and also the GSSAPI mechanism can block while obtaining a service ticket. (In addition to any blocking during ldap_pvt_sasl_getmechs()...) As such, it would need a lot more work to make it fully asynchronous. We could create the infrastructure needed to make ldap_host_connected_to() and ldap_pvt_sasl_getmechs() fully asynch, but we have no such control over the SASL mechanisms.
Still dunno what to do with this. Is it better than nothing?