openldap-bugs

openldap-bugs@openldap.org

1 participants
20966 discussions

Re: (ITS#6553) Test043 oddities under Windows
by masarati＠aero.polimi.it 24 May '10

24 May '10

> On May 23, 2010, at 9:57 AM, masarati(a)aero.polimi.it wrote: > >> Isn't ldif-filter supposed to deal with this? Probably, test043 needs >> to >> sort entries (-s bdb=a,hdb=a). > > Yes, Thanks. > > Here is a patch: Works for me, but I can't check using windows. I'd commit it, pending verification. Thanks, p. > Index: test043-delta-syncrepl > =================================================================== > RCS file: /var/CVSROOT/ldap24/tests/scripts/test043-delta-syncrepl,v > retrieving revision 1.1.1.5 > diff -r1.1.1.5 test043-delta-syncrepl > 342c342 > < $LDIFFILTER < $MASTEROUT | grep -iv "^auditcontext:" > $MASTERFLT > --- >> $LDIFFILTER -s bdb=a,hdb=a < $MASTEROUT | grep -iv "^auditcontext:" > >> $MASTERF > LT > 344c344 > < $LDIFFILTER < $SLAVEOUT | grep -iv "^auditcontext:" > $SLAVEFLT > --- >> $LDIFFILTER -s bdb=a,hdb=a < $SLAVEOUT | grep -iv "^auditcontext:" > >> $SLAVEFLT > > >> >> p. >> >>> Full_Name: Matt Hardin >>> Version: 2.4.22 >>> OS: Windows 7 >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (74.38.117.141) >>> >>> >>> test043 fails under Windows because the contextCSN attribute for the >>> entry >>> dc=example,dc=com are returned in different places within the entry for >>> the >>> producer and consumer. To wit: >>> >>> server1.flt- >>> >>> dn: dc=example,dc=com >>> dc: example >>> objectClass: organization >>> objectClass: domainRelatedObject >>> objectClass: dcObject >>> l: Anytown, Michigan >>> st: Michigan >>> o: Example, Inc. >>> o: EX >>> o: Ex. >>> description: The Example, Inc. at Anytown >>> postalAddress: Example, Inc. $ 535 W. William St. $ Anytown, MI 48109 $ >>> US >>> telephoneNumber: +1 313 555 1817 >>> associatedDomain: example.com >>> structuralObjectClass: organization >>> entryUUID: 1602452e-3d10-4fb1-9d55-efb8c08ac643 >>> creatorsName: cn=Manager,dc=example,dc=com >>> createTimestamp: 20100518161938Z >>> entryCSN: 20100518161938.140191Z#000000#000#000000 >>> modifiersName: cn=Manager,dc=example,dc=com >>> modifyTimestamp: 20100518161938Z >>> entryDN: dc=example,dc=com >>> subschemaSubentry: cn=Subschema >>> contextCSN: 20100518162026.443250Z#000000#000#000000 >>> hasSubordinates: TRUE >>> >>> >>> >>> server2.flt- >>> >>> dn: dc=example,dc=com >>> dc: example >>> objectClass: organization >>> objectClass: domainRelatedObject >>> objectClass: dcObject >>> l: Anytown, Michigan >>> st: Michigan >>> o: Example, Inc. >>> o: EX >>> o: Ex. >>> description: The Example, Inc. at Anytown >>> postalAddress: Example, Inc. $ 535 W. William St. $ Anytown, MI 48109 $ >>> US >>> telephoneNumber: +1 313 555 1817 >>> associatedDomain: example.com >>> structuralObjectClass: organization >>> entryUUID: 1602452e-3d10-4fb1-9d55-efb8c08ac643 >>> creatorsName: cn=Manager,dc=example,dc=com >>> createTimestamp: 20100518161938Z >>> entryCSN: 20100518161938.140191Z#000000#000#000000 >>> modifiersName: cn=Manager,dc=example,dc=com >>> modifyTimestamp: 20100518161938Z >>> contextCSN: 20100518162026.443250Z#000000#000#000000 >>> entryDN: dc=example,dc=com >>> subschemaSubentry: cn=Subschema >>> hasSubordinates: TRUE >>> >>> >>> While this is not a problem in operation, and is not specifically a bug >>> according to the RFCs, test043 nonetheless fails because it expects an >>> exact >>> match in the ordering between the producer and consumer. It's not clear >>> whether >>> the desired fix is in slapd or in the test itself. >>> >>> This test does not fail on any other platforms with which we are >>> currently >>> working (HP-UX, Linux, Solaris, AIX), nor does it appear to be related >>> to >>> ITS#6549, which is now fixed (thanks Ando!). >>> >>> >>> >>> >> >> > > >

1 0

Re: (ITS#6553) Test043 oddities under Windows
by mhardin＠symas.com 24 May '10

24 May '10

On May 23, 2010, at 9:57 AM, masarati(a)aero.polimi.it wrote: > Isn't ldif-filter supposed to deal with this? Probably, test043 needs = to > sort entries (-s bdb=3Da,hdb=3Da). Yes, Thanks. Here is a patch: Index: test043-delta-syncrepl =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /var/CVSROOT/ldap24/tests/scripts/test043-delta-syncrepl,v retrieving revision 1.1.1.5 diff -r1.1.1.5 test043-delta-syncrepl 342c342 < $LDIFFILTER < $MASTEROUT | grep -iv "^auditcontext:" > $MASTERFLT --- > $LDIFFILTER -s bdb=3Da,hdb=3Da < $MASTEROUT | grep -iv = "^auditcontext:" > $MASTERF LT 344c344 < $LDIFFILTER < $SLAVEOUT | grep -iv "^auditcontext:" > $SLAVEFLT --- > $LDIFFILTER -s bdb=3Da,hdb=3Da < $SLAVEOUT | grep -iv "^auditcontext:" = > $SLAVEFLT >=20 > p. >=20 >> Full_Name: Matt Hardin >> Version: 2.4.22 >> OS: Windows 7 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (74.38.117.141) >>=20 >>=20 >> test043 fails under Windows because the contextCSN attribute for the = entry >> dc=3Dexample,dc=3Dcom are returned in different places within the = entry for >> the >> producer and consumer. To wit: >>=20 >> server1.flt- >>=20 >> dn: dc=3Dexample,dc=3Dcom >> dc: example >> objectClass: organization >> objectClass: domainRelatedObject >> objectClass: dcObject >> l: Anytown, Michigan >> st: Michigan >> o: Example, Inc. >> o: EX >> o: Ex. >> description: The Example, Inc. at Anytown >> postalAddress: Example, Inc. $ 535 W. William St. $ Anytown, MI 48109 = $ US >> telephoneNumber: +1 313 555 1817 >> associatedDomain: example.com >> structuralObjectClass: organization >> entryUUID: 1602452e-3d10-4fb1-9d55-efb8c08ac643 >> creatorsName: cn=3DManager,dc=3Dexample,dc=3Dcom >> createTimestamp: 20100518161938Z >> entryCSN: 20100518161938.140191Z#000000#000#000000 >> modifiersName: cn=3DManager,dc=3Dexample,dc=3Dcom >> modifyTimestamp: 20100518161938Z >> entryDN: dc=3Dexample,dc=3Dcom >> subschemaSubentry: cn=3DSubschema >> contextCSN: 20100518162026.443250Z#000000#000#000000 >> hasSubordinates: TRUE >>=20 >>=20 >>=20 >> server2.flt- >>=20 >> dn: dc=3Dexample,dc=3Dcom >> dc: example >> objectClass: organization >> objectClass: domainRelatedObject >> objectClass: dcObject >> l: Anytown, Michigan >> st: Michigan >> o: Example, Inc. >> o: EX >> o: Ex. >> description: The Example, Inc. at Anytown >> postalAddress: Example, Inc. $ 535 W. William St. $ Anytown, MI 48109 = $ US >> telephoneNumber: +1 313 555 1817 >> associatedDomain: example.com >> structuralObjectClass: organization >> entryUUID: 1602452e-3d10-4fb1-9d55-efb8c08ac643 >> creatorsName: cn=3DManager,dc=3Dexample,dc=3Dcom >> createTimestamp: 20100518161938Z >> entryCSN: 20100518161938.140191Z#000000#000#000000 >> modifiersName: cn=3DManager,dc=3Dexample,dc=3Dcom >> modifyTimestamp: 20100518161938Z >> contextCSN: 20100518162026.443250Z#000000#000#000000 >> entryDN: dc=3Dexample,dc=3Dcom >> subschemaSubentry: cn=3DSubschema >> hasSubordinates: TRUE >>=20 >>=20 >> While this is not a problem in operation, and is not specifically a = bug >> according to the RFCs, test043 nonetheless fails because it expects = an >> exact >> match in the ordering between the producer and consumer. It's not = clear >> whether >> the desired fix is in slapd or in the test itself. >>=20 >> This test does not fail on any other platforms with which we are = currently >> working (HP-UX, Linux, Solaris, AIX), nor does it appear to be = related to >> ITS#6549, which is now fixed (thanks Ando!). >>=20 >>=20 >>=20 >>=20 >=20 >=20

1 0

Re: (ITS#6560) Samba4 OpenLDAP backend
by masarati＠aero.polimi.it 24 May '10

24 May '10

> Full_Name: Nitin Bhadauria > Version: OpenLDAP 2.X-Devel > OS: Ubuntu 10.04 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (119.82.72.226) > > > I am try to configure Samba4 with OpenLDAP and while setup provision... > > Using Following doc: > > http://wiki.samba.org/index.php/Samba4/LDAP_Backend/OpenLDAP > > I got this error in messages logs. > > May 24 06:12:08 ubuntu kernel: [171547.545660] slapd[8141]: segfault at > 7ffffffb > ip 004b7e91 sp bffd8148 error 4 in libc-2.11.1.so[448000+153000] > May 24 06:15:51 ubuntu slapd[8159]: rdnval: repaired=0 Please read this <http://www.openldap.org/faq/data/cache/56.html> and act accordingly. p.

1 0

Re: (ITS#6559) About Referrals and BIND
by quanah＠zimbra.com 24 May '10

24 May '10

--On Monday, May 24, 2010 3:39 AM +0000 jet(a)hf.webex.com wrote: > Full_Name: Jet Du > Version: openldap-2.4.21 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (61.191.27.34) > > > Because there are some typo in some description of (ITS#6558). So, I > submit a new ITS as below. > > There are two openLDAP Directory. > > 10.224.39.165 openLDAP has suffix dc=cisco,dc=com > 10.224.39.172 openLDAP has suffix dc=webex,dc=com > > In 10.224.39.172 OpenLDAP, I configure referral in slapd.conf like below: > referral ldap://10.224.39.165:389/ > > Connect 10.224.39.172 to BIND entry existing in 10.224.39.165. Code like > following: > lc.connect("10.224.39.172", 389); > lc.bind(LDAPConnection.LDAP_V3, > "uid=xxx(a)hf.cisco.com,ou=People,dc=cisco,dc=com", > "pass".getBytes("UTF8")); > > But, I can not BIND successfully. Exception like below: > Connect ERRORLDAPException: Invalid Credentials (49) Invalid > Credentials LDAPException: Matched DN: ...... > > How to do BIND based on Referral? Thanks ... Two things: (a) Don't submit a new ITS because you typoed on the previous one. Just follow up to it. (b) Don't submit ITSes for software usage questions. Use the openldap-technical(a)openldap.org software list. The ITS system is for reporting bugs found in the software. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6560) Samba4 OpenLDAP backend
by bhadauria.nitin＠gmail.com 24 May '10

24 May '10

Full_Name: Nitin Bhadauria Version: OpenLDAP 2.X-Devel OS: Ubuntu 10.04 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (119.82.72.226) I am try to configure Samba4 with OpenLDAP and while setup provision... Using Following doc: http://wiki.samba.org/index.php/Samba4/LDAP_Backend/OpenLDAP I got this error in messages logs. May 24 06:12:08 ubuntu kernel: [171547.545660] slapd[8141]: segfault at 7ffffffb ip 004b7e91 sp bffd8148 error 4 in libc-2.11.1.so[448000+153000] May 24 06:15:51 ubuntu slapd[8159]: rdnval: repaired=0

1 0

(ITS#6559) About Referrals and BIND
by jet＠hf.webex.com 23 May '10

23 May '10

Full_Name: Jet Du Version: openldap-2.4.21 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (61.191.27.34) Because ther are some typo in some description of (ITS#6558). So, I submit a new ITS as below. There are two openLDAP Directory. 10.224.39.165 openLDAP has suffix dc=cisco,dc=com 10.224.39.172 openLDAP has suffix dc=webex,dc=com In 10.224.39.172 OpenLDAP, I configure referral in slapd.conf like below: referral ldap://10.224.39.165:389/ Connect 10.224.39.172 to BIND entry existing in 10.224.39.165. Code like following: lc.connect("10.224.39.172", 389); lc.bind(LDAPConnection.LDAP_V3, "uid=xxx(a)hf.cisco.com,ou=People,dc=cisco,dc=com", "pass".getBytes("UTF8")); But, I can not BIND successfully. Exception like below: Connect ERRORLDAPException: Invalid Credentials (49) Invalid Credentials LDAPException: Matched DN: ...... How to do BIND based on Referral? Thanks ...

1 0

(ITS#6558) About Referrals and BIND
by jet＠hf.webex.com 23 May '10

23 May '10

Full_Name: Jet Du Version: openldap-2.4.21 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (61.191.27.34) There are two openLDAP Directory. 10.224.39.165 openLDAP has suffix dc=cisco,dc=webex 10.224.39.172 openLDAP has suffix dc=webex,dc=webex In 10.224.39.172 OpenLDAP, I configure referral in slapd.conf like below: referral ldap://10.224.39.165:389/ Connect 10.224.39.172 to BIND entry existing in 10.224.39.165. Code like following: lc.connect("10.224.39.172", 389); lc.bind(LDAPConnection.LDAP_V3, "uid=xxx(a)hf.cisco.com,ou=People,dc=cisco,dc=com", "pass".getBytes("UTF8")); But, I can not BIND successfully. Exception like below: Connect ERRORLDAPException: Invalid Credentials (49) Invalid Credentials LDAPException: Matched DN: ...... How to do BIND based on Referral? Thanks ...

1 0

Re: (ITS#6553) Test043 oddities under Windows
by masarati＠aero.polimi.it 23 May '10

23 May '10

Isn't ldif-filter supposed to deal with this? Probably, test043 needs to sort entries (-s bdb=a,hdb=a). p. > Full_Name: Matt Hardin > Version: 2.4.22 > OS: Windows 7 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (74.38.117.141) > > > test043 fails under Windows because the contextCSN attribute for the entry > dc=example,dc=com are returned in different places within the entry for > the > producer and consumer. To wit: > > server1.flt- > > dn: dc=example,dc=com > dc: example > objectClass: organization > objectClass: domainRelatedObject > objectClass: dcObject > l: Anytown, Michigan > st: Michigan > o: Example, Inc. > o: EX > o: Ex. > description: The Example, Inc. at Anytown > postalAddress: Example, Inc. $ 535 W. William St. $ Anytown, MI 48109 $ US > telephoneNumber: +1 313 555 1817 > associatedDomain: example.com > structuralObjectClass: organization > entryUUID: 1602452e-3d10-4fb1-9d55-efb8c08ac643 > creatorsName: cn=Manager,dc=example,dc=com > createTimestamp: 20100518161938Z > entryCSN: 20100518161938.140191Z#000000#000#000000 > modifiersName: cn=Manager,dc=example,dc=com > modifyTimestamp: 20100518161938Z > entryDN: dc=example,dc=com > subschemaSubentry: cn=Subschema > contextCSN: 20100518162026.443250Z#000000#000#000000 > hasSubordinates: TRUE > > > > server2.flt- > > dn: dc=example,dc=com > dc: example > objectClass: organization > objectClass: domainRelatedObject > objectClass: dcObject > l: Anytown, Michigan > st: Michigan > o: Example, Inc. > o: EX > o: Ex. > description: The Example, Inc. at Anytown > postalAddress: Example, Inc. $ 535 W. William St. $ Anytown, MI 48109 $ US > telephoneNumber: +1 313 555 1817 > associatedDomain: example.com > structuralObjectClass: organization > entryUUID: 1602452e-3d10-4fb1-9d55-efb8c08ac643 > creatorsName: cn=Manager,dc=example,dc=com > createTimestamp: 20100518161938Z > entryCSN: 20100518161938.140191Z#000000#000#000000 > modifiersName: cn=Manager,dc=example,dc=com > modifyTimestamp: 20100518161938Z > contextCSN: 20100518162026.443250Z#000000#000#000000 > entryDN: dc=example,dc=com > subschemaSubentry: cn=Subschema > hasSubordinates: TRUE > > > While this is not a problem in operation, and is not specifically a bug > according to the RFCs, test043 nonetheless fails because it expects an > exact > match in the ordering between the producer and consumer. It's not clear > whether > the desired fix is in slapd or in the test itself. > > This test does not fail on any other platforms with which we are currently > working (HP-UX, Linux, Solaris, AIX), nor does it appear to be related to > ITS#6549, which is now fixed (thanks Ando!). > > > >

1 0

(ITS#6556) test031 core dumps after applying first filter
by dieter＠dkluenter.de 23 May '10

23 May '10

Full_Name: Dieter Kluenter Version: HEAD OS: openSuSE URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.142.11.71) I have enabled slapd-modules/comp_match and properly installed all relevant files to tests/data/comp_libs. When running test031, slapd segfaults: Running ./scripts/test031-component-filter for bdb... running defines.sh Running slapadd to build slapd database... Running slapindex to index slapd database... Starting slapd on TCP/IP port 9011... Testing slapd searching... Testing Component Filter Match RFC3687 Certificate searching: f=(userCertificate:componentFilterMatch:=item:{ component "toBeSigned.serialNumber", rule allComponen tsMatch, value 0 }) ... f=(userCertificate:componentFilterMatch:=item:{ component "toBeSigned.version", rule allComponentsMat ch, value 2 }) ... ./scripts/test031-component-filter: Zeile 105: 5312 Speicherzugriffsfehler (Speicherabzug geschrieben) $SLA PD -f $ADDCONF -h $URI1 -d $LVL $TIMING > $LOG1 2>&1 ldapsearch failed (255)! ./scripts/test031-component-filter: Zeile 110: kill: (5312) - Kein passender Prozess gefunden (gdb) core-file core Core was generated by `/home/dieter/build/openldap/servers/slapd/.libs/lt-slapd -s0 -f /home/dieter/bu'. Program terminated with signal 11, Segmentation fault. (gdb) file /home/dieter/build/openldap/servers/slapd/.libs/lt-slapd Reading symbols from /home/dieter/build/openldap/servers/slapd/.libs/lt-slapd...done. (gdb) where #0 0x080e6525 in slap_sl_free (ptr=0x87ba173, ctx=0x89aa3c0) at sl_malloc.c:492 #1 0x080a0f5b in ch_free (ptr=0x87ba173) at ch_malloc.c:137 #2 0x080e3e3a in mra_free (op=0x89adc80, mra=0x87ba218, freeit=1) at mra.c:43 #3 0x08085621 in filter_free_x (op=0x89adc80, f=0x87ba258, freeme=1) at filter.c:556 #4 0x0808373e in do_search (op=0x89adc80, rs=0xb71190c4) at search.c:230 #5 0x080805f9 in connection_operation (ctx=0xb7119198, arg_v=0x89adc80) at connection.c:1109 #6 0x08080b18 in connection_read_thread (ctx=0xb7119198, argv=0x11) at connection.c:1245 #7 0xb7f963b7 in ?? () #8 0xb7cf86e5 in ?? () (gdb) bt full #0 0x080e6525 in slap_sl_free (ptr=0x87ba173, ctx=0x89aa3c0) at sl_malloc.c:492 sh = 0x89aa3c0 size = 543520108 p = 0x87ba16f nextp = 0x28e116db tmpp = 0xb7119198 __PRETTY_FUNCTION__ = "slap_sl_free" #1 0x080a0f5b in ch_free (ptr=0x87ba173) at ch_malloc.c:137 ctx = 0x89aa3c0 #2 0x080e3e3a in mra_free (op=0x89adc80, mra=0x87ba218, freeit=1) at mra.c:43 No locals. #3 0x08085621 in filter_free_x (op=0x89adc80, f=0x87ba258, freeme=1) at filter.c:556 p = 0x8214680 next = 0x89adcac #4 0x0808373e in do_search (op=0x89adc80, rs=0xb71190c4) at search.c:230 base = {bv_len = 17, bv_val = 0x89aff28 "dc=example,dc=com"} siz = 0 off = 0 i = 0 #5 0x080805f9 in connection_operation (ctx=0xb7119198, arg_v=0x89adc80) at connection.c:1109 rc = 80 cancel = 0 op = 0x89adc80 rs = {sr_type = REP_RESULT, sr_tag = 101, sr_msgid = 2, sr_err = 0, sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x0, sr_un = {sru_search = {r_entry = 0x0, r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 2, r_v2ref = 0x0}, sru_sasl = {r_sasldata = 0x0}, sru_extended = {r_rspoid = 0x0, r_rspdata = 0x0}}, sr_flags = 0} tag = 99 opidx = SLAP_OP_SEARCH conn = 0x8433e04 memctx = 0x89aa3c0 memctx_null = 0x0 memsiz = 1048576 __PRETTY_FUNCTION__ = "connection_operation" #6 0x08080b18 in connection_read_thread (ctx=0xb7119198, argv=0x11) at connection.c:1245 ---Type <return> to continue, or q <return> to quit--- rc = 0 cri = {op = 0x89adc80, func = 0, arg = 0x0, ctx = 0xb7119198, nullop = 0} s = 17 #7 0xb7f963b7 in ?? () No symbol table info available. #8 0xb7cf86e5 in ?? () No symbol table info available. (gdb) -Dieter

1 0

Re: (ITS#6555) Syncprov (refreshAndPersist) loses deletes
by hyc＠symas.com 21 May '10

21 May '10

ralf(a)OpenLDAP.org wrote: > Am Freitag 21 Mai 2010 05:52:31 schrieb Howard Chu: >> Ralf Haferkamp wrote: >>> A fix is now in syncprov.c r1.312. Would be great if someone could >>> review it if it makes sense. Testing results look good so far. >> >> Not sure why this makes the difference. After all, mincsn will be set >> to the consumer's cookie, and any writes that occur during the >> refresh phase will naturally have an entryCSN greater than mincsn and >> still be queued. > That doesn't seem to be true for deletes of entries that have an entryCSN > less than the value from the cookie. What I did to reproduce the problem > was: > > 1. load provider with about 100 entries > 2. start consumer wait for it to get synced. > 3. stop consumer > 4. load more entries in to the provider (in my test case about 1000) > 5. restart consumer (the consumer will start a ldapsync session with a > cookie) > 6. use ldapdelete to delete in an entry for the initial 100 entries. > (those that have an entryCSN< csn provide in the cookie). This ldap > delete as to happened during the refresh part of the ldapsync session > (when the 1000 new entries are sent) > 7. watch it fail > > What happens is that when syncprov_op_mod() calls syncprov_matchops() it > tests the to be deleted entry against the syncrepl filter (which has the > entryCSN>=cookie filter prepended currently as we are in refresh). That > test fails because of the older entryCSN value. Because of that the > syncoperation will not be inserted into the smatches queue of the > opcookie and the delete will not get synched in the syncprov_op_response > callback (as the smatches queue is empty). > > (As a side note: Modification that happen during the refresh phase will > get synched as LDAP_SYNC_ADD instead of LDAP_SYNC_MODIFY for the above > reasons. This doesn't cause any failure AFAICS but seemed wrong as well.) OK, that explanation makes sense. Just wanted to make sure we didn't regress on ITS#4622, which seems to be the last time these filters were tweaked. -- -- 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:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs