- openldap-bugs - openldap.org

Re: (ITS#6534) bad ifdef/elif clause in liblutil
by quanah＠zimbra.com 25 May '10

25 May '10

--On Friday, April 30, 2010 1:23 PM +0000 h.b.furuseth(a)usit.uio.no wrote: > quanah(a)zimbra.com writes: >> Actually, the issue seems to be name changes in the header files under >> BSD. This causes TIOCNOTTY to end up being undefined. > > That would not give the error message shown in > <http://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg776021. > html>: > > build/buildd-openldap_2.4.21-1-kfreebsd-amd64-VWAqZY/openldap-2.4.21/libr > aries/liblutil/detach.c:131:7: error: missing binary operator before > token "long" > > Line 131 is "#elif TIOCNOTTY". There's no 'long' there is TIOCNOTTY is > undefined, it'd just evaluate to #elif 0. So my guess is that TIOCNOTTY > somewhere is defined to expand to an expression involving a (long) cast. Apprently so. <http://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg785259.html> --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

ITS#6557 published: SECURITY: About Referrals and BIND
by openldap-its＠OpenLDAP.org 25 May '10

25 May '10

Private ITS#6557 is now publicly readable URL: http://www.OpenLDAP.org/its/?findid=6557

1 0

Re: (ITS#6551) wrapping lines option
by masarati＠aero.polimi.it 24 May '10

24 May '10

> this is a feature request for making wrapping optional. Duplicate of ITS#6149; see related discussion. p.

1 0

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

Re: (ITS#6555) Syncprov (refreshAndPersist) loses deletes
by ralf＠OpenLDAP.org 21 May '10

21 May '10

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.)

1 0

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

20 May '10

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. -- -- 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

Re: (ITS#6554) OpenLDAP + TLS multiple server certificates
by hyc＠symas.com 20 May '10

20 May '10

stepan.kipel(a)ab-group.biz wrote: > Full_Name: Stepan Kipel > Version: 2.4.19 > OS: Red Hat Enterprise Linux AS release 4 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (79.140.224.210) > > > In our network there are 2 servers running slapd, one is syncrepl-provider and > other is consumer. Both have identical IP address for LDAP requests and > configured in manner that when one goes down, second takes over (configured > externally, by routing). Also, TLS is configured and works transparently for > client machines (DNS resolves their "common" IP), but it`s hard to use their > Domain Name for TLS syncrepl - DNS resolves IP, that is up on local machine. We > decided to put up other interface on syncrepl-provider for replication purposes, > mapped another Domain Name on this interface and appended CA, server and private > server certs created for this Domain Names to files included by > TLSCACertificateFile, TLSCertificateFile and TLSCertificateKey in slapd.conf > file, respectively. We`ve tried to execute ldapsearch with two different > ldap.conf configs - for first and second domain name of the server, one works > and another - not? error looks like "TLS: hostname (first_srv_name) does not > match common name in certificate (second_srv_name)." > > The question is - can slapd server use more than 2 server certificates or we > should use another technology (tunneling, etc...) for encrypted syncrepl? > A server cert file and key file may only contain one item; that's a constraint from the underlying TLS library. You should not have needed to create a new CA for this situation. You should look at using a single server cert with a subjectAltName matching the the alternate interface name. The ITS is for bug reports, not for hetting help on using the software. This ITS will be closed. Use the -software mailing list. -- -- 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

Re: (ITS#6555) Syncprov (refreshAndPersist) loses deletes
by Ralf Haferkamp 20 May '10

20 May '10

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.

1 0

(ITS#6555) Syncprov (refreshAndPersist) loses deletes
by ralf＠OpenLDAP.org 20 May '10

20 May '10

Full_Name: Ralf Haferkamp Version: HEAD/RE24 OS: SLES11 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (92.252.42.18) Submitted by: ralf If entries are deleted on the provider during the refresh Phase of a "refreshAndPersist" sync session, those deletes won't get replicated to the provider. This only happens if the consumer provided a cookie with the search, i.e. after the consumer was restarted (not during the initial sync) and if there were changes since the last sync. I am working on a fix.

1 0

(ITS#6554) OpenLDAP + TLS multiple server certificates
by stepan.kipel＠ab-group.biz 20 May '10

20 May '10

Full_Name: Stepan Kipel Version: 2.4.19 OS: Red Hat Enterprise Linux AS release 4 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (79.140.224.210) In our network there are 2 servers running slapd, one is syncrepl-provider and other is consumer. Both have identical IP address for LDAP requests and configured in manner that when one goes down, second takes over (configured externally, by routing). Also, TLS is configured and works transparently for client machines (DNS resolves their "common" IP), but it`s hard to use their Domain Name for TLS syncrepl - DNS resolves IP, that is up on local machine. We decided to put up other interface on syncrepl-provider for replication purposes, mapped another Domain Name on this interface and appended CA, server and private server certs created for this Domain Names to files included by TLSCACertificateFile, TLSCertificateFile and TLSCertificateKey in slapd.conf file, respectively. We`ve tried to execute ldapsearch with two different ldap.conf configs - for first and second domain name of the server, one works and another - not? error looks like "TLS: hostname (first_srv_name) does not match common name in certificate (second_srv_name)." The question is - can slapd server use more than 2 server certificates or we should use another technology (tunneling, etc...) for encrypted syncrepl?

1 0

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

18 May '10

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#6549) test043 hasSubordinates attribute inconsistencies
by mhardin＠symas.com 18 May '10

18 May '10

> Hi Ando. I've tested on RHEL 4/5 x86 and all seems good. I'll test on = Windows in a little while. Back-ported to 2.4.22 and tested in Windows. Works. -Matt >=20 > Thanks! >=20 > -Matt >=20 > On May 17, 2010, at 6:27 PM, masarati(a)aero.polimi.it wrote: >=20 >>=20 >>> Indeed, syncprov_operational() is right: it duplicates the entry = only if >>> contextCSN is already present in the entry, and thus may need to be >>> updated. What's wrong is back-bdb, which gives up when the entry = does not >>> have e_private set appropriately, while it could do more to find out = about >>> the entry's subordinates. This may explain why in some cases the >>> attribute is present. This occurs whenever contextCSN is not = already >>> present in the entry. I'm preparing a fix for back-bdb. >>=20 >> Fixed in HEAD; please test. Thanks, p. >>=20 >=20

1 0

Re: (ITS#6549) test043 hasSubordinates attribute inconsistencies
by mhardin＠symas.com 18 May '10

18 May '10

Hi Ando. I've tested on RHEL 4/5 x86 and all seems good. I'll test on = Windows in a little while. Thanks! -Matt On May 17, 2010, at 6:27 PM, masarati(a)aero.polimi.it wrote: >=20 >> Indeed, syncprov_operational() is right: it duplicates the entry only = if >> contextCSN is already present in the entry, and thus may need to be >> updated. What's wrong is back-bdb, which gives up when the entry = does not >> have e_private set appropriately, while it could do more to find out = about >> the entry's subordinates. This may explain why in some cases the >> attribute is present. This occurs whenever contextCSN is not already >> present in the entry. I'm preparing a fix for back-bdb. >=20 > Fixed in HEAD; please test. Thanks, p. >=20

1 0

Re: (ITS#6544) how to implement password policy
by masarati＠aero.polimi.it 17 May '10

17 May '10

The ITS is intended to track bugs; please direct usage questions to openldap-software(a)openldap.org. This ITS will be closed. p. > Full_Name: Devender Singh > Version: openldap 2.4.16 > OS: RHEL5.4 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (122.177.190.226) > > > Hello Dear, > > Please let me know, how to implement ppolicy in > openldap2.4.16. I > am using RHEL5.4 > > I have followed below steps on installation time: > > ************************************************** > Installing BerkeleyDB > ************************************************** > 1) Create build_unix directory in /opt directory > 2) Copy db-4.7.25.tar.gz to /opt/build_unix directory > 3) Goto /opt/build_unix directory > 4) gzip -d db-4.7.25.tar.gz > 5) tar xvf db-4.7.25.tar > 6) db-4.7.25/dist/configure > 7) make > 8) make install > 9) vi /root/.bash_profile > 10) Add below lines in .bash_profile of root user > export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/BerkeleyDB.4.7/lib > export LD_RUN_PATH=$LD_RUN_PATH:/usr/local/BerkeleyDB.4.7/lib > 11) Close existing PUTTY and start new PUTTY > ************************************************** > > Before Installation check the below packages: > #rpm �qa|grep openssl* > After the above command if you don�t find the all openssl packages than > install > them via yum command > ************************************************** > Installing OpenLDAP > ************************************************** > 1) Copy openldap-stable-20090411.tgz to /opt directory > 2) gunzip -c openldap-stable-20090411.tgz | tar xf - > 3) cd openldap-2.4.16 > 4) CPPFLAGS="-I/usr/local/BerkeleyDB.4.7/include > -I/usr/local/ssl/include/openssl" > 5) export CPPFLAGS > 6) LDFLAGS="-L/usr/local/lib -L/usr/local/BerkeleyDB.4.7/lib > -L/usr/local/ssl/lib -R/usr/local/lib -R/usr/local/BerkeleyDB.4.7/lib > -R/usr/local/ssl/lib" > 7) export LDFLAGS > 8) LD_LIBRARY_PATH="/usr/local/BerkeleyDB.4.7/lib" > 9) export LD_LIBRARY_PATH > 10) ./configure > 11) make depend > 12) make > 13) make install > 14) vi /root/.bash_profile > 15) Add OpenLDAP sbin path in .bash_profile of root user (E.g. export > PATH=$PATH:$HOME/bin:/usr/local/sbin) > 16) Close existing PUTTY and start new PUTTY > ************************************************** > > > Thanks in Advance. > > Regards, > Devender Singh > (+919818107222) > >

1 0

Re: (ITS#6546) Default olcRootDN of "cn=config" should be documented
by masarati＠aero.polimi.it 17 May '10

17 May '10

> While using the "cn=config" configuration, I found that "cn=config" is > also the > default olcRootDN. By just configuring a olcRootPW , login to the config > database is possible using "cn=config" and the configured olcRootPW. This > default should be documented in the admin guide, etc. Fixed in HEAD's slapd-config(5); may be worth mentioning in the admin guide as well. Thanks, p.

1 0

Re: (ITS#6549) test043 hasSubordinates attribute inconsistencies
by masarati＠aero.polimi.it 17 May '10

17 May '10

> Indeed, syncprov_operational() is right: it duplicates the entry only if > contextCSN is already present in the entry, and thus may need to be > updated. What's wrong is back-bdb, which gives up when the entry does not > have e_private set appropriately, while it could do more to find out about > the entry's subordinates. This may explain why in some cases the > attribute is present. This occurs whenever contextCSN is not already > present in the entry. I'm preparing a fix for back-bdb. Fixed in HEAD; please test. Thanks, p.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs