openldap-bugs May 2009

openldap-bugs@openldap.org

42 participants
159 discussions

(ITS#6152) proxycache enhancements
by hyc＠OpenLDAP.org 28 May '09

28 May '09

Full_Name: Howard Chu Version: 2.4.16 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (80.67.104.102) Submitted by: hyc Some ideas that came out of discussions at the Ubuntu Developer Summit this week... It would be nice for pcache to detect when connectivity to the remote server has been lost. In that case, cache expiration should be stopped, and the cache contents should remain intact until connectivity is restored. Also, when connectivity is restored, pcache should explicitly refresh all the entries it currently holds, rather than allowing them to be immediately expired.

1 0

Re: (ITS#6056) Samba4 breaks OpenLDAP over ldapi
by hyc＠symas.com 28 May '09

28 May '09

Andrew Bartlett wrote: > On Tue, 2009-05-26 at 04:26 -0700, Howard Chu wrote: >> abartlet(a)samba.org wrote: >>> Full_Name: Andrew Bartlett >>> Version: CVS HEAD >>> OS: Fedora 10 >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (59.167.251.137) >>> >>> >>> Samba4's provision and 'make test' seems to create some internal situation in >>> OpenLDAP slapd where it will not accept any more connections over ldapi:/// >>> >>> This is best seen by building Samba4, and running >>> >>> TEST_LDAP=yes OPENLDAP_ROOT=/usr/local make test >>> >>> The slapd does not crash, but simply stops accepting new connections. Samba4 >>> currently then crashes due to some other bug (the LDAP backend not responding is >>> clearly untested code in Samba4). >>> >>> It isn't a Samba4 client bug, as ldapsearch also fails to respond. >>> >>> This seems very, very similar to ITS#5261 >> >> Further testing with Andrew's kvm image shows the hang only occurs when Cyrus >> SASL's libsasldb2.so plugin is present. I always remove that plugin from my >> installs, since I only use in-directory SASL secrets. That's probably why I >> wasn't seeing the reported behavior before. >> >> Also a note - it's still not clear we've been talking about the same thing up >> to this point. Even when the samba test suite hangs, I see that ldapsearch >> still works fine against slapd. At any rate, currently all of the samba4 tests >> pass for me. > > Hmm. Using that KVM image, with the libsasldb moved aside (and with it > left in place), I still get errors. > > However, there is an important difference: Where previously, once it > locked up nothing proceeded, now it proceeds - as if the failure is > temporary now. The error has changed too - instead of a failure to > connect, it is an inability to successfully read the rootDSE. > > I agree, we might be jumping at different shadows here, but your patches > did fix something... I see what you're describing now, with the kvm set with 2 CPUs. It appears to be a bug caused by the recent patch for connection_hangup() processing. Running slapd with -d15 in your test shows that a connection is closed shortly after being established and becoming readable. The bug is (probably) that we queued the reader but processed the hangup immediately, thus closing the connection before the reader executes. I'm not exactly sure why this is causing the problem on your test, since it looks like your client is closing the socket before waiting for the reply. But certainly this is the right area. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#6151) Update cosine.schema to RFC 4524
by michael＠stroeder.com 28 May '09

28 May '09

Full_Name: Michael Ströder Version: HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.163.80.206) cosine.schema is still based on obsoleted RFC 1274. It should be updated to RFC 4524.

1 0

Re: (ITS#6150) schema compliance checking tool
by michael＠stroeder.com 28 May '09

28 May '09

Pierangelo Masarati wrote: > Added to HEAD. Please test. Wow! This was fast! It simply works. I want it in 2.4.17. ;-) Ciao, Michael.

1 0

Re: (ITS#6150) schema compliance checking tool
by masarati＠aero.polimi.it 28 May '09

28 May '09

Added to HEAD. Please test. p.

1 0

(ITS#6150) schema compliance checking tool
by michael＠stroeder.com 28 May '09

28 May '09

Full_Name: Michael Ströder Version: HEAD OS: URL: Submission from: (NULL) (84.163.68.118) masarati(a)aero.polimi.it wrote: > Comes to mind that something like a schema compliance checking tool, > either off- or on-line could be useful. Sort of a "slapschema" that > checks the schema compliance of each entry (matching a filter or > within a subtree specification) in a given database. The result could contain the DNs of non-compliant entries each with the diagnostic message which would have been returned to a client adding such a non-compliant entry.

1 0

(ITS#6149) ldapsearch is not really script-friendly (patch included)
by bugreporter＠udmvt.ru 28 May '09

28 May '09

Full_Name: Alexey Version: 2.4.15 (LDAP library: OpenLDAP 20415) OS: Debian GNU/Linux URL: http://bugreport.udmvt.ru/attachment/ldapsearch-ttt.patch Submission from: (NULL) (78.85.1.13) Good day, everyone. ldapsearch have such important (mis)feature, like output format conforming to LDIF standard in some or other way. You should already know, that line length in LDIF-output is limited to 76 characters and if line is larger, it is wrapped with space-padding. Also output is sometimes base64 encoded, based on it's "printability". Printability is tested, using single-byte functions, like isgraph(), but when values is multibyte encoded with UTF-8, that sometimes produce random results. That together makes ldapsearch very script-unfriendly and here is why: to limit randomness in output's encoding, one would use -tt switch to always write field values to files and then use some simple script to parse the output and substitute file urls with their contents. But here comes to play line length limit, that will sometimes wrap urls for fields with long names (that is common for AD). Here is example: msExchHomeServerName:< file:///tmp/ldapsearch-msExchHomeServerName-ZhHdx2 msExchMailboxSecurityDescriptor:< file:///tmp/ldapsearch-msExchMailboxSecurit yDescriptor-c4gGc1 msExchUserAccountControl:< file:///tmp/ldapsearch-msExchUserAccountControl-FM UbSZ msExchMailboxGuid:< file:///tmp/ldapsearch-msExchMailboxGuid-6bLIxY End of example. That introduces extra unneeded complexity in otherwise simple script, since now it should parse LDIF, combine whole lines from broken ones, etc. Making it no longer an one-line script. Since wrapping of -tt output is nonsense, but changing that may seem unfeasible for some of you, let me suggest additional option -ttt, that does the same as -tt, but without line wrapping (perhaps, violating some standard). Patch is here, as your ITS asks: http://bugreport.udmvt.ru/attachment/ldapsearch-ttt.patch PS: manpage does not changed to reflect additional option Thanks a lot.

1 0

Re: (ITS#6056) Samba4 breaks OpenLDAP over ldapi
by abartlet＠samba.org 27 May '09

27 May '09

--=-0SnOgocYLpYqWd2pGoMe Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2009-05-26 at 04:26 -0700, Howard Chu wrote: > abartlet(a)samba.org wrote: > > Full_Name: Andrew Bartlett > > Version: CVS HEAD > > OS: Fedora 10 > > URL: ftp://ftp.openldap.org/incoming/ > > Submission from: (NULL) (59.167.251.137) > > > > > > Samba4's provision and 'make test' seems to create some internal situat= ion in > > OpenLDAP slapd where it will not accept any more connections over ldapi= :/// > > > > This is best seen by building Samba4, and running > > > > TEST_LDAP=3Dyes OPENLDAP_ROOT=3D/usr/local make test > > > > The slapd does not crash, but simply stops accepting new connections. = Samba4 > > currently then crashes due to some other bug (the LDAP backend not resp= onding is > > clearly untested code in Samba4). > > > > It isn't a Samba4 client bug, as ldapsearch also fails to respond. > > > > This seems very, very similar to ITS#5261 >=20 > Further testing with Andrew's kvm image shows the hang only occurs when C= yrus=20 > SASL's libsasldb2.so plugin is present. I always remove that plugin from = my=20 > installs, since I only use in-directory SASL secrets. That's probably why= I=20 > wasn't seeing the reported behavior before. >=20 > Also a note - it's still not clear we've been talking about the same thin= g up=20 > to this point. Even when the samba test suite hangs, I see that ldapsearc= h=20 > still works fine against slapd. At any rate, currently all of the samba4 = tests=20 > pass for me. Hmm. Using that KVM image, with the libsasldb moved aside (and with it left in place), I still get errors. =20 However, there is an important difference: Where previously, once it locked up nothing proceeded, now it proceeds - as if the failure is temporary now. The error has changed too - instead of a failure to connect, it is an inability to successfully read the rootDSE.=20 I agree, we might be jumping at different shadows here, but your patches did fix something... Andrew Bartlett --=20 Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. --=-0SnOgocYLpYqWd2pGoMe Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQBKHeuvz4A8Wyi0NrsRAoaGAJ9olpo9+ni006pt9kK5CkXJObYNCQCgorgP DswBOLRtdrlhFHibmX4XrC4= =bjw6 -----END PGP SIGNATURE----- --=-0SnOgocYLpYqWd2pGoMe--

1 0

Re: (ITS#6103) canceled operations do not respond
by h.b.furuseth＠usit.uio.no 27 May '09

27 May '09

hyc(a)symas.com writes: >Hallvard B Furuseth wrote: >> The send_ldap_response() fix is still incomplete: [Reversing the quoteed message] >> Also, this: >> rc = rs->sr_err; >> if ( rc == SLAPD_ABANDON&& op->o_cancel ) >> rc = LDAP_CANCELLED; >> will send a negative result code (SLAPD_ABANDON) if !o_cancel. > > No, it won't. That is all bypassed at the top of the function. If so, the quoted op->o_cancel test could be skipped. But an overlay could set rs->sr_err = SLAPD_ABANDON during slap_response_play(). Though that ought to mean o_abandon is set, so send_ldap_ber() will drop the message. So you're right after all that it won't be sent. >> Note, not just when the function itself sets rc = LDAP_CANCELLED, >> since syncprov can set rs->sr_err = LDAP_CANCELLED too. >> Which also suggests the assert( rs->sr_err == LDAP_REFERRAL ) when >> sr_ref != NULL is rather dubious. Maybe sr_ref should just >> be ignored when sending something else than LDAP_REFERRAL. > > Leave the assert() in place until you have proof one way or the other. Haven't tested with an example of an overlay setting SLAPD_ABANDON; could check syncprov or retcode I suppose. Faked it with nanosleep(&((struct timespec){0,2E8}), 0); /*gcc or C99 code*/ if ( op->o_abandon ) rs->sr_err = SLAPD_ABANDON; after the op->o_callback->sc_response in slap_response_play(). Then, with this slapd.conf: include servers/slapd/schema/core.schema referral ldap://elsewhere/ database frontend overlay valsort send Delete "cn=urgle" <wait 0.1 second> Abandon <previous request> lt-slapd: result.c:479: send_ldap_response: Assertion `rs->sr_err == 0x0a' failed. One more detail, looking at result.c rev 1.330 send_ldap_response(): I presume the LDAP_CONNECTIONLESS branch should also ber_printf rc rather than rs->sr_err to the response. Not sure if Cancel makes sense in cldap (and after V2 Bind which has no extended operation at that), but OpenLDAP does let through Cancel after a V2 Bind. >> When rc == LDAP_CANCELLED, the function should not send sr_matched, >> sr_text, sr_ref, and sr_ctrls. Looking at how Abandon works, it seems >> slap_cleanup_play() should still see them if they are not sent? > > Dunno what you mean. I thought that was obvious, but since it isn't maybe I should ask ldapext instead. Cancel does seem underspecified in this regard. Anyway, I meant: Either an operation gets cancelled/abandoned, or it doesn't and comletes. If these fields are set, they most likely relate to a completed operation. Nowhere SLAPD_ABANDON gets set, are the others set - possibly except with back-meta/back-ldap, I haven't looked too closely. OTOH, code setting SLAPD_ABANDON rarely _clears_ those fields, so I imagine they can convey information which would have been removed (access controls maybe?) or updated before they were sent, if the operation had completed. Clearing a critical control can be a bit doubtful, I'll grant. But for not obeying critical controls it's a choice between which error code to return - unavailableCriticalExtension, cancelled, or something else. Or some controls could mark the operation as "uncancellable" (another flag needed...) But come to think of it, an Extended Response has some of the same problem. By the above reasoning, responseName and responseValue should be dropped in a Cancelled response, as when sending protocolError to an unrecognized reqest. Might be a bit extreme. -- Hallvard

1 0

Re: (ITS#6103) canceled operations do not respond
by hyc＠symas.com 27 May '09

27 May '09

Hallvard B Furuseth wrote: > The send_ldap_response() fix is still incomplete: > > When rc == LDAP_CANCELLED, the function should not send sr_matched, > sr_text, sr_ref, and sr_ctrls. Looking at how Abandon works, it seems > slap_cleanup_play() should still see them if they are not sent? Dunno what you mean. > Note, not just when the function itself sets rc = LDAP_CANCELLED, > since syncprov can set rs->sr_err = LDAP_CANCELLED too. > Which also suggests the assert( rs->sr_err == LDAP_REFERRAL ) when > sr_ref != NULL is rather dubious. Maybe sr_ref should just > be ignored when sending something else than LDAP_REFERRAL. Leave the assert() in place until you have proof one way or the other. > Also, this: > rc = rs->sr_err; > if ( rc == SLAPD_ABANDON&& op->o_cancel ) > rc = LDAP_CANCELLED; > will send a negative result code (SLAPD_ABANDON) if !o_cancel. No, it won't. That is all bypassed at the top of the function. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs May 2009