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.c
Changes are generally available on cvs.openldap.org (and CVSweb) within 30 minutes of being committed.
Please review and comment, thanks.
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:
-----------------8<----------------------------------- res_errno: 14, res_error: <SASL(0): successful result: >, res_matched: <> ldap_free_request (origid 3, msgid 3) ldap_int_sasl_bind: <null> ldap_parse_sasl_bind_result ber_scanf fmt ({eAA) ber: ber_dump: buf=0x624ee0 ptr=0x624ee3 end=0x624f2a len=71 0000: 61 45 0a 01 0e 04 00 04 1c 53 41 53 4c 28 30 29 aE.......SASL(0) 0010: 3a 20 73 75 63 63 65 73 73 66 75 6c 20 72 65 73 : successful res 0020: 75 6c 74 3a 20 87 20 05 04 05 ff 00 0c 00 00 00 ult: . ......... 0030: 00 00 00 05 5c ee 23 07 01 00 00 c3 56 03 6d 56 .....#.....V.mV 0040: 24 c6 ab e5 96 61 1c $....a. ber_scanf fmt (O) ber: ber_dump: buf=0x624ee0 ptr=0x624f08 end=0x624f2a len=34 0000: 87 20 05 04 05 ff 00 0c 00 00 00 00 00 00 05 5c . .............\ 0010: ee 23 07 01 00 00 c3 56 03 6d 56 24 c6 ab e5 96 .#.....V.mV$.... 0020: 61 1c a. ldap_parse_result ber_scanf fmt ({iAA) ber: ber_dump: buf=0x624ee0 ptr=0x624ee3 end=0x624f2a len=71 0000: 61 45 0a 01 0e 04 00 04 1c 53 41 53 4c 28 30 29 aE.......SASL(0) 0010: 3a 20 73 75 63 63 65 73 73 66 75 6c 20 72 65 73 : successful res 0020: 75 6c 74 3a 20 87 20 05 04 05 ff 00 0c 00 00 00 ult: . ......... 0030: 00 00 00 05 5c ee 23 07 01 00 00 c3 56 03 6d 56 .....#.....V.mV 0040: 24 c6 ab e5 96 61 1c $....a. ber_scanf fmt (x) ber: ber_dump: buf=0x624ee0 ptr=0x624f08 end=0x624f2a len=34 0000: 87 20 05 04 05 ff 00 0c 00 00 00 00 00 00 05 5c . .............\ 0010: ee 23 07 01 00 00 c3 56 03 6d 56 24 c6 ab e5 96 .#.....V.mV$.... 0020: 61 1c a. ber_scanf fmt (}) ber: ber_dump: buf=0x624ee0 ptr=0x624f2a end=0x624f2a len=0
sasl_client_step: 0 SASL username: ldap/bronsted.g17.lan@G17.LAN SASL SSF: 56 ldap_pvt_sasl_generic_install SASL data security layer installed. ldap_msgfree ldap_result ld 0x6166c0 msgid 3 wait4msg ld 0x6166c0 msgid 3 (infinite timeout) wait4msg continue ld 0x6166c0 msgid 3 all 1 ** ld 0x6166c0 Connections: * host: nibbler.g17.lan port: 389 (default) refcnt: 1 status: Connected last used: Fri Oct 15 11:51:43 2010
** ld 0x6166c0 Outstanding Requests: Empty ld 0x6166c0 request count 0 (abandoned 0) ** ld 0x6166c0 Response Queue: Empty ld 0x6166c0 response count 0 ldap_chkResponseList ld 0x6166c0 msgid 3 all 1 ldap_chkResponseList returns ld 0x6166c0 NULL ldap_int_select -----------------8<-----------------------------------
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.
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.
-----------------8<----------------------------------- res_errno: 14, res_error:<SASL(0): successful result:>, res_matched:<> ldap_free_request (origid 3, msgid 3) ldap_int_sasl_bind:<null> ldap_parse_sasl_bind_result ber_scanf fmt ({eAA) ber: ber_dump: buf=0x624ee0 ptr=0x624ee3 end=0x624f2a len=71 0000: 61 45 0a 01 0e 04 00 04 1c 53 41 53 4c 28 30 29 aE.......SASL(0) 0010: 3a 20 73 75 63 63 65 73 73 66 75 6c 20 72 65 73 : successful res 0020: 75 6c 74 3a 20 87 20 05 04 05 ff 00 0c 00 00 00 ult: . ......... 0030: 00 00 00 05 5c ee 23 07 01 00 00 c3 56 03 6d 56 .....#.....V.mV 0040: 24 c6 ab e5 96 61 1c $....a. ber_scanf fmt (O) ber: ber_dump: buf=0x624ee0 ptr=0x624f08 end=0x624f2a len=34 0000: 87 20 05 04 05 ff 00 0c 00 00 00 00 00 00 05 5c . .............\ 0010: ee 23 07 01 00 00 c3 56 03 6d 56 24 c6 ab e5 96 .#.....V.mV$.... 0020: 61 1c a. ldap_parse_result ber_scanf fmt ({iAA) ber: ber_dump: buf=0x624ee0 ptr=0x624ee3 end=0x624f2a len=71 0000: 61 45 0a 01 0e 04 00 04 1c 53 41 53 4c 28 30 29 aE.......SASL(0) 0010: 3a 20 73 75 63 63 65 73 73 66 75 6c 20 72 65 73 : successful res 0020: 75 6c 74 3a 20 87 20 05 04 05 ff 00 0c 00 00 00 ult: . ......... 0030: 00 00 00 05 5c ee 23 07 01 00 00 c3 56 03 6d 56 .....#.....V.mV 0040: 24 c6 ab e5 96 61 1c $....a. ber_scanf fmt (x) ber: ber_dump: buf=0x624ee0 ptr=0x624f08 end=0x624f2a len=34 0000: 87 20 05 04 05 ff 00 0c 00 00 00 00 00 00 05 5c . .............\ 0010: ee 23 07 01 00 00 c3 56 03 6d 56 24 c6 ab e5 96 .#.....V.mV$.... 0020: 61 1c a. ber_scanf fmt (}) ber: ber_dump: buf=0x624ee0 ptr=0x624f2a end=0x624f2a len=0
sasl_client_step: 0 SASL username: ldap/bronsted.g17.lan@G17.LAN SASL SSF: 56 ldap_pvt_sasl_generic_install SASL data security layer installed. ldap_msgfree ldap_result ld 0x6166c0 msgid 3 wait4msg ld 0x6166c0 msgid 3 (infinite timeout) wait4msg continue ld 0x6166c0 msgid 3 all 1 ** ld 0x6166c0 Connections:
- host: nibbler.g17.lan port: 389 (default) refcnt: 1 status: Connected last used: Fri Oct 15 11:51:43 2010
** ld 0x6166c0 Outstanding Requests: Empty ld 0x6166c0 request count 0 (abandoned 0) ** ld 0x6166c0 Response Queue: Empty ld 0x6166c0 response count 0 ldap_chkResponseList ld 0x6166c0 msgid 3 all 1 ldap_chkResponseList returns ld 0x6166c0 NULL ldap_int_select -----------------8<-----------------------------------
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?
On Friday 15 October 2010 14:02:27 Howard Chu wrote:
Howard Chu wrote:
Ralf Haferkamp wrote:
[..]
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.
Same here. Thanks.
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?
I'd think so, yes. AFAIK we do have similar issues with StartTLS as well, don't we. Ok, ldap_start_tls() seems to completely async, but one needs to call ldap_install_tls() after that, and that again might block somewhere in the underlying openssl/gnutls/moznss libraries.
Ralf
-
Howard Chu -
Ralf Haferkamp