openldap-bugs September 2010

openldap-bugs@openldap.org

26 participants
109 discussions

Re: (ITS#6641) Syncrepl failure with 'overlay unique'
by hyc＠symas.com 07 Sep '10

07 Sep '10

andrew.findlay(a)skills-1st.co.uk wrote: > Full_Name: Andrew Findlay > Version: 2.4.23 > OS: SLES 10.3 x86_64 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (88.97.25.132) > > > The attribute uniqueness overlay can cause syncrepl to jam up. > Consider this case: > The obvious answer is for syncrepl to bypass all data checks, as the supplier > server should have already enforced them. The problem with that is that clients > could see data that breaks the rules if they query while syncrepl is running > (unless the refresh phase is handled as a single transaction and thus isolated > from clients until it is complete). We've talked about doing this isolation in the first refresh upon slapd startup. That might still be a good idea. Doing it on every refresh seems far more problematic, because without some type of multi-version concurrency control, that means making the server non-responsive until the refresh completes. -- -- 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#6641) Syncrepl failure with 'overlay unique'
by andrew.findlay＠skills-1st.co.uk 07 Sep '10

07 Sep '10

Full_Name: Andrew Findlay Version: 2.4.23 OS: SLES 10.3 x86_64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (88.97.25.132) The attribute uniqueness overlay can cause syncrepl to jam up. Consider this case: 1) Configure a mirrormode pair with identical configs, including 'unique_attributes uid' 2) Start one server and add some data, including an entry containing a UID value. 3) Start the second server, let it synchronise, then stop it again. 4) On the first server, delete the entry and add a new one with a different DN that has the same UID value. 5) Start the second server. Look in the logs, and you will see something like this: Sep 7 11:33:03 jupiter slapd[19407]: @(#) $OpenLDAP: slapd 2.4.23 (Sep 6 2010 19:55:47) $ andrew@jupiter:/usr/local/src/openldap-2.4.23/servers/slapd Sep 7 11:33:03 jupiter slapd[19408]: slapd starting Sep 7 11:33:04 jupiter slapd[19408]: conn=1000 fd=23 ACCEPT from IP=127.0.0.1:33611 (IP=0.0.0.0:389) Sep 7 11:33:04 jupiter slapd[19408]: conn=1000 op=0 BIND dn="" method=128 Sep 7 11:33:04 jupiter slapd[19408]: conn=1000 op=0 RESULT tag=97 err=0 text= Sep 7 11:33:04 jupiter slapd[19408]: conn=1000 op=1 SRCH base="" scope=0 deref=0 filter="(objectClass=*)" Sep 7 11:33:04 jupiter slapd[19408]: conn=1000 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text= Sep 7 11:33:04 jupiter slapd[19408]: conn=1000 op=2 UNBIND Sep 7 11:33:04 jupiter slapd[19408]: conn=1000 fd=23 closed Sep 7 11:33:04 jupiter slapd[19408]: null_callback : error code 0x13 Sep 7 11:33:04 jupiter slapd[19408]: syncrepl_entry: rid=001 be_add uniqueIdentifier=list.6b9432f9,dc=routing,dc=mail,dc=apps,dc=nis,dc=brunel,dc=ac,dc=uk failed (19) Sep 7 11:33:04 jupiter slapd[19408]: do_syncrepl: rid=001 rc 19 retrying (9 retries left) Sep 7 11:34:04 jupiter slapd[19408]: null_callback : error code 0x13 Sep 7 11:34:04 jupiter slapd[19408]: syncrepl_entry: rid=001 be_add uniqueIdentifier=list.6b9432f9,dc=routing,dc=mail,dc=apps,dc=nis,dc=brunel,dc=ac,dc=uk failed (19) Sep 7 11:34:04 jupiter slapd[19408]: do_syncrepl: rid=001 rc 19 retrying (9 retries left) Sep 7 11:35:05 jupiter slapd[19408]: null_callback : error code 0x13 Sep 7 11:35:05 jupiter slapd[19408]: syncrepl_entry: rid=001 be_add uniqueIdentifier=list.6b9432f9,dc=routing,dc=mail,dc=apps,dc=nis,dc=brunel,dc=ac,dc=uk failed (19) Sep 7 11:35:05 jupiter slapd[19408]: do_syncrepl: rid=001 rc 19 retrying (9 retries left) The problem is that syncrepl is trying to add the new entry before deleting the old one, and the uniqueness constraint on UID is preventing it from doing so. It is likely that other constraints on data will have the same effect. See for example this thread: http://www.openldap.org/lists/openldap-software/201001/msg00038.html The obvious answer is for syncrepl to bypass all data checks, as the supplier server should have already enforced them. The problem with that is that clients could see data that breaks the rules if they query while syncrepl is running (unless the refresh phase is handled as a single transaction and thus isolated from clients until it is complete). Andrew

1 0

(ITS#6640) pcache must always free callback
by masarati＠aero.polimi.it 06 Sep '10

06 Sep '10

Full_Name: Pierangelo Masarati Version: irrelevant OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (129.72.165.221) Submitted by: ando pcache_op_cleanup should always free callback malloc'ed by pcache_op_search when done; caught with valgrind (need -DSLAP_NO_SL_MALLOC); see ITS#6629

1 0

Re: (ITS#6598) EXOP to return number of children of a (sub)tree
by masarati＠aero.polimi.it 06 Sep '10

06 Sep '10

> masarati(a)aero.polimi.it wrote: >>> If you want to be able to distinguish results based on scope then it >>> makes >>> more sense to just define a Search control. Like No-op - count the >>> entries >>> that would be returned, instead of returning them. (And bypassing the >>> sizelimit too, but probably not bypassing timelimit.) >> >> I'm drafting the code to implement this no-op search. > > Maybe sizelimit should not be by-passed in all cases. > How about letting the client choose which limits are by-passed? Michael, your idea sounds interesting. In the current implementation sizelimits are technically bypassed during the internal search. Since the operation returns only a (possibly successful) searchResultDone, it seems appropriate to return success when sizelimit would be violated, because from the client's perspective no sizelimit could be exceeded since no entry is being returned. The fact that the actual search would be exceeded is reflected in the additional response code in the control response's value. Could you be more precise about what you mean? One or two use cases or a not-so-formal specification would suffice. Thanks, p.

1 0

Re: objectClass index from slapd.conf is not working
by tim stone 06 Sep '10

06 Sep '10

Hello, the line "index objectClass eq" is the first index in my config and placed there before first filling the database. But I tried to rebuild this index with slapindex too and I also set up the hole database with slapcat/slapadd on a new testsystem. Every time the same behavior. kindly regards, Tim 2010/9/2 tim stone <timstone10001(a)googlemail.com> > > Hello Michael, > > the line > > "index objectClass eq" > > is the first index in my config and placed there before first filling the database. But I tried to rebuild this index with slapindex too and I also set up the hole database with slapcat/slapadd on a new testsystem. Every time the same behavior. > > kindly regards, Tim > > 2010/9/2 Michael Ströder <michael(a)stroeder.com> >> >> tim stone wrote: >> > >> > I've a strange behavior while using index objectClass for searching. >> >> Did you change the objectClass index *after* populating your database? >> >> http://www.openldap.org/faq/data/cache/136.html >> >> Ciao, Michael. >

2 1

Re: (ITS#6598) EXOP to return number of children of a (sub)tree
by michael＠stroeder.com 06 Sep '10

06 Sep '10

masarati(a)aero.polimi.it wrote: >> If you want to be able to distinguish results based on scope then it makes >> more sense to just define a Search control. Like No-op - count the entries >> that would be returned, instead of returning them. (And bypassing the >> sizelimit too, but probably not bypassing timelimit.) > > I'm drafting the code to implement this no-op search. Maybe sizelimit should not be by-passed in all cases. How about letting the client choose which limits are by-passed? Ciao, Michael.

1 0

Re: (ITS#6638) ldapseach segfault on OSX
by masarati＠aero.polimi.it 05 Sep '10

05 Sep '10

Should now be fixed in HEAD; platform independent, on Linux was not failing but memory was being used incorrectly. ldapsearch-specific, no issue in client library. Please test. Thanks, p.

1 0

Re: (ITS#6638) ldapseach segfault on OSX
by masarati＠aero.polimi.it 05 Sep '10

05 Sep '10

> --On Sunday, September 05, 2010 9:19 PM +0200 masarati(a)aero.polimi.it > wrote: > > >>> /opt/zimbra/openldap/bin/ldapsearch -LLL -D ... -w ... -H >>> ldap://...:3268 >>> -x -E >>> deref=member:mail "(CN=test)" mail > >>From the ITS. Only thing I removed was binddn, password, and hostname. > Note that the same search against OpenLDAP also segfaults, so it is not a > server side issue. It is clearly a client-side issue: the core dump appears while cooking the control's value. Your backtrace shows a failure on strlen() being passed an invalid string. The string appears invalid to gdb as well, as it fails to show the contents of the string's pointer. Using valgrind with Linux I notice a memory allocation error. Checking... p.

1 0

Re: (ITS#6638) ldapseach segfault on OSX
by quanah＠zimbra.com 05 Sep '10

05 Sep '10

--On Sunday, September 05, 2010 9:19 PM +0200 masarati(a)aero.polimi.it wrote: >> /opt/zimbra/openldap/bin/ldapsearch -LLL -D ... -w ... -H ldap://...:3268 >> -x -E >> deref=member:mail "(CN=test)" mail >From the ITS. Only thing I removed was binddn, password, and hostname. Note that the same search against OpenLDAP also segfaults, so it is not a server side issue. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6638) ldapseach segfault on OSX
by masarati＠aero.polimi.it 05 Sep '10

05 Sep '10

> Full_Name: Quanah Gibson-Mount > Version: 2.4.23 > OS: Mac OSX 10.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.45.108) > > > When querying AD from a mac, we found that we can segfault ldapsearch. > This > segfault does not happen when running the same query from linux. Here is > the > backtrace: > > (gdb) thr apply all bt full > > Thread 1 (core thread 0): > #0 0x00007fff80697180 in strlen () > No symbol table info available. > #1 0x000000010008ae22 in ber_put_string (ber=0x100401480, > str=0x686372616573 > <Address 0x686372616573 out of bounds>, tag=18446744073709551615) at > encode.c:273 Something seems to be wrong with the parsing of the deref control in ldapsearch.c; can you provide the command-line? Thanks, p. > No locals. > #2 0x000000010008be20 in ber_printf (ber=0x100401480, fmt=0x10005f5e4 > "s{") at > encode.c:575 > ap = {{ > gp_offset = 24, > fp_offset = 48, > overflow_arg_area = 0x7fff5fbfeb00, > reg_save_area = 0x7fff5fbfea40 > }} > s = 0x686372616573 <Address 0x686372616573 out of bounds> > ss = (char **) 0x0 > bv = (struct berval *) 0x0 > bvp = (struct berval **) 0x7fff8069dc3b > rc = 0 > i = 584234 > len = 140734799800880 > #3 0x00000001000586d8 in ldap_create_deref_control_value (ld=0x100401130, > ds=0x100400130, value=0x100016a20) at deref.c:68 > j = 1 > ber = (BerElement *) 0x100401480 > tag = 18 > i = 1 > __func__ = "\000\000\000\000\000\000\000Critical extension is una" > #4 0x0000000100003a28 in main (argc=13, argv=0x7fff5fbff4f8) at > ldapsearch.c:1090 > i = 0 > filtpattern = 0x7fff5fbff739 "(CN=SE-EMEA-OEM)" > attrs = (char **) 0x7fff5fbff558 > line = '\0' <repeats 504 times>, > "ï¿œï¿œï¿œ_ï¿œ\000\000ï¿œï¿œ_ï¿œ\000\000\006\003ï¿œï¿œï¿œ\000\000\000ï¿œ_ï¿œ\000\000ï¿œ&ï¿œ_ï¿œ", > '\0' <repeats 18 times>, > "ï¿œï¿œï¿œ_ï¿œ\000\000\020ï¿œ_ï¿œ\000\000ï¿œï¿œ_ï¿œ\000\000ï¿œ\005ï¿œ_ï¿œ\000\000ï¿œï¿œ~L\000\000\000\000=ï¿œ\002\000ï¿œ\000\000ï¿œ\000\000\000Ì¹ï¿œT\035ï¿œ_ï¿œï¿œdYhMï¿œ6T{ï¿œbjï¿œ\033\020v:ï¿œ*ï¿œb7\003a/ï¿œMï¿œï¿œï¿œï¿œï¿œï¿œ8ï¿œLï¿œï¿œXï¿œ\025Cï¿œÔ¶&Úxï¿œ6cï¿œOï¿œï¿œDpb*\030\tdï¿œï¿œï¿œ^biï¿œ}ï¿œï¿œ&ï¿œyï¿œfï¿œq"... > fp = (FILE *) 0x0 > rc = 0 > rc1 = 0 > i = 0 > first = 0 > ld = (LDAP *) 0x100401130 > seber = (BerElement *) 0x0 > vrber = (BerElement *) 0x0 > syncber = (BerElement *) 0x0 > syncbvalp = (struct berval *) 0x0 > err = 0 > > > Search was: > > /opt/zimbra/openldap/bin/ldapsearch -LLL -D ... -w ... -H ldap://...:3268 > -x -E > deref=member:mail "(CN=test)" mail > > Segmentation fault (core dumped) > > >

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs September 2010