- openldap-bugs - openldap.org

(ITS#7554) mdb_cursor_put() flag combinations broken
by h.b.furuseth＠usit.uio.no 25 Mar '13

25 Mar '13

Full_Name: Hallvard B Furuseth Version: mdb.master bbb27cde4af7 OS: URL: Submission from: (NULL) (193.69.163.163) Submitted by: hallvard mdb_cursor_put() and mdb_cursor_del() sometimes tests the flags argument with '==' or '!=' instead of '&'. That breaks flag combinations like MDB_CURRENT | MDB_RESERVE: grep -n 'flags [!=]= MDB_' mdb.c 4884: if (flags != MDB_CURRENT && (key->mv_size == 0 || key->mv_size > MDB_MAXKEYSIZE)) 4900: if (flags == MDB_CURRENT) { 4962: if (flags == MDB_CURRENT) { 4977: if (flags == MDB_CURRENT) 4992: return (flags == MDB_NODUPDATA) ? MDB_KEYEXIST : MDB_SUCCESS; 5025: if (flags == MDB_CURRENT) { 5274: if (flags != MDB_NODUPDATA) { The mdb_cursor_del() test is not a problem yet since only one flag is valid, but it'll become broken if more flags get supported.

1 0

Re: (ITS#7553) mdb_cursor_del() crash when deleting last key
by hyc＠symas.com 25 Mar '13

25 Mar '13

dw(a)botanicus.net wrote: > Full_Name: David Wilson > Version: master > OS: OS X > URL: http://pastie.org/7114932 > Submission from: (NULL) (109.149.47.172) > > > Please find attached a crash repro affecting current MDB master, where seeking > to the last database key followed by double mdb_cursor_del() results in a > crash. Thanks for the report, fixed in mdb.master/master > > The program supplied crashed with NULL+0x10 pointer dereference, however another > crash triggered by the same set of steps results in a separate stack trace: > > > Program received signal EXC_BAD_ACCESS, Could not access memory. > Reason: KERN_PROTECTION_FAILURE at address: 0x0000000100fffff0 > 0x00000001005e566c in memmove$VARIANT$sse3x () > (gdb) bt > #0 0x00000001005e566c in memmove$VARIANT$sse3x () > #1 0x0000000101dd81d0 in mdb_node_del (mp=0x10111ce20, ksize=10, indx=52758) at > mdb.c:5582 > #2 0x0000000101dda308 in mdb_cursor_del (mc=0x10202ed80, flags=0) at > mdb.c:6422 > #3 0x0000000101dd51a4 in _cffi_f_mdb_cursor_del (self=0x10111ce20, > args=0x10111ce20) at _cffi__xfbbb05bexaac0bea3.c:648 > #4 0x000000010008bd77 in PyEval_EvalFrameEx () > > -- -- 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#7553) mdb_cursor_del() crash when deleting last key
by dw＠botanicus.net 25 Mar '13

25 Mar '13

--089e010d857441189904d8c49b8f Content-Type: text/plain; charset=ISO-8859-1 The attached program has a bug, it assigns "val" to "mv_data" instead of "s" in setval(). However fixing this doesn't cure the issue (or trigger the related stack trace). --089e010d857441189904d8c49b8f Content-Type: text/html; charset=ISO-8859-1 The attached program has a bug, it assigns "val" to "mv_data" instead of "s" in setval(). However fixing this doesn't cure the issue (or trigger the related stack trace).<br><br> --089e010d857441189904d8c49b8f--

1 0

(ITS#7553) mdb_cursor_del() crash when deleting last key
by dw＠botanicus.net 25 Mar '13

25 Mar '13

Full_Name: David Wilson Version: master OS: OS X URL: http://pastie.org/7114932 Submission from: (NULL) (109.149.47.172) Please find attached a crash repro affecting current MDB master, where seeking to the last database key followed by double mdb_cursor_del() results in a crash. The program supplied crashed with NULL+0x10 pointer dereference, however another crash triggered by the same set of steps results in a separate stack trace: Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0x0000000100fffff0 0x00000001005e566c in memmove$VARIANT$sse3x () (gdb) bt #0 0x00000001005e566c in memmove$VARIANT$sse3x () #1 0x0000000101dd81d0 in mdb_node_del (mp=0x10111ce20, ksize=10, indx=52758) at mdb.c:5582 #2 0x0000000101dda308 in mdb_cursor_del (mc=0x10202ed80, flags=0) at mdb.c:6422 #3 0x0000000101dd51a4 in _cffi_f_mdb_cursor_del (self=0x10111ce20, args=0x10111ce20) at _cffi__xfbbb05bexaac0bea3.c:648 #4 0x000000010008bd77 in PyEval_EvalFrameEx ()

1 0

Re: (ITS#7552) PcacheAttrset directive is not behaving as it should
by hyc＠symas.com 25 Mar '13

25 Mar '13

btb(a)bitrate.net wrote: > Full_Name: ben thielsen > Version: 2.4.31 > OS: ubuntu 12.10 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (216.176.18.253) > > > i've set olcPcacheAttrset as follows: > > dn: olcOverlay={0}pcache,olcDatabase={2}ldap,cn=config > objectClass: olcPcacheConfig > objectClass: olcOverlayConfig > objectClass: olcConfig > objectClass: top > olcOverlay: {0}pcache > olcPcache: mdb 1000 100 1000 60 > olcPcacheAttrset: 0 "*" "+" > olcPcacheTemplate: "(objectClass=)" 0 3600 > olcPcacheTemplate: "(uid=)" 0 3600 > olcPcacheTemplate: "(&(objectClass=)(uid=))" 0 3600 > olcPcacheBind: "(uid=)" 0 60 "sub" "dc=example,dc=net" > structuralObjectClass: olcPcacheConfig > entryUUID: ddb05d7e-b4fa-1031-811e-353e11fff366 > creatorsName: cn=config > createTimestamp: 20121028032528Z > entryCSN: 20121030002115.179177Z#000000#000#000000 > modifiersName: cn=config > modifyTimestamp: 20121030002115Z > > but the logs indicate that a subsequent query won't be cached: > > Oct 31 08:42:15 deepfield slapd[12862]: query template of incoming query = > (&(objectClass=)(uid=)) > Oct 31 08:42:15 deepfield slapd[12862]: QUERY NOT ANSWERABLE > Oct 31 08:42:15 deepfield slapd[12862]: QUERY NOT CACHEABLE Now fixed in master. -- -- 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#7522) Admin Guide: bugs in example
by hyc＠symas.com 25 Mar '13

25 Mar '13

openldap(a)laimbock.com wrote: > Full_Name: Patrick Laimbock > Version: RE24 > OS: CentOS 6.3 x86_64 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (94.210.175.192) Thanks for the report. Now fixed in master. > > In the OpenLDAP Admin Guide on page 38 it says: > > 34. olcSuffix: "dc=example,dc=com" > 35. olcDbDirectory: /usr/local/var/openldap-data > 36. olcRootDN: "cn=Manager,dc=example,dc=com" > 37. olcRootPW: secret > 38. olcDbIndex: uid pres,eq > 39. olcDbIndex: cn,sn,uid pres,eq,approx,sub > > When I try to slapadd that example config I get the following errors: > > 5117a0af str2entry: invalid value for attributeType olcSuffix #0 (syntax > 1.3.6.1.4.1.1466.115.121.1.12) > > 5117a1ea str2entry: invalid value for attributeType olcRootDN #0 (syntax > 1.3.6.1.4.1.1466.115.121.1.12) > > /etc/openldap34/slapd.d: line 1: duplicate index definition for attr "uid" > > When I remove the quotes from the olcSuffix (line 34) and olcRootDN (line 36) > entries and remove the double uid from either line 38 or line 39 then the > slapadd action is successful. > > -- -- 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#7546) Proxycache overlay documentation cn=config example misleading
by hyc＠symas.com 25 Mar '13

25 Mar '13

Thanks, now fixed in master. bernd(a)net.t-labs.tu-berlin.de wrote: > This is an OpenPGP/MIME signed message (RFC 4880 and 3156) > ------enig2UKFBXSMIUKGELBPOGMTD > Content-Type: text/plain; charset=ISO-8859-1 > Content-Transfer-Encoding: quoted-printable > > Oops forgot the db in the second entry > > it should of course be > > # pcache overlay > dn: olcOverlay=3D{0}pcache,olcDatabase=3D{2}ldap,cn=3Dconfig > =2E.. > > This is also reflected in the following patch > > --- > doc/guide/admin/overlays.sdf | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/doc/guide/admin/overlays.sdf b/doc/guide/admin/overlays.sdf > index a8ceede..8e2c81e 100644 > --- a/doc/guide/admin/overlays.sdf > +++ b/doc/guide/admin/overlays.sdf > @@ -791,7 +791,7 @@ The same example as a LDIF file for back-config for > a caching server > which proxies for the {{EX:"dc=3Dexample,dc=3Dcom"}} subtree held > at server {{EX:ldap.example.com}}. > > -> dn: olcDatabase=3D{2}ldap > +> dn: olcDatabase=3D{2}ldap,cn=3Dconfig > > objectClass: olcDatabaseConfig > > objectClass: olcLDAPConfig > > olcDatabase: {2}ldap > @@ -799,7 +799,7 @@ at server {{EX:ldap.example.com}}. > > olcRootDN: dc=3Dexample,dc=3Dcom > > olcDbURI: "ldap://ldap.example.com" > > > -> dn: olcOverlay=3D{0}pcache > +> dn: olcOverlay=3D{0}pcache,olcDatabase=3D{2}ldap,cn=3Dconfig > > objectClass: olcOverlayConfig > > objectClass: olcPcacheConfig > > olcOverlay: {0}pcache > @@ -809,7 +809,7 @@ at server {{EX:ldap.example.com}}. > > olcPcacheTemplate: "(&(sn=3D)(givenName=3D))" 0 3600 0 0 0 > > olcPcacheTemplate: "(&(departmentNumber=3D)(secretary=3D))" 0 3600 > > > -> dn: olcDatabase=3D{0}hdb > +> dn: > olcDatabase=3D{0}hdb,olcOverlay=3D{0}pcache,olcDatabase=3D{2}ldap,cn=3Dco= > nfig > > objectClass: olcHdbConfig > > objectClass: olcPcacheDatabase > > olcDatabase: {0}hdb > --=20 > 1.7.10.4 > > > The attached patch file is derived from OpenLDAP Software. All of the > modifications to OpenLDAP Software represented in the following > patch(es) were developed by Bernd May bernd(a)net.t-labs.tu-berlin.de. I > have not assigned rights and/or interest in this work to any party. > > I, Bernd May, hereby place the following modifications to OpenLDAP > Software (and only these modifications) into the public domain. Hence, > these modifications may be freely used and/or redistributed for any > purpose with or without attribution and/or other notice. > > --=20 > Technische Universit=E4t Berlin - FGINET > > Bernd May > > System Administration > An-Institut Deutsche Telekom Laboratories > Sekr. TEL 16 > Ernst-Reuter-Platz 7 > 10587 BERLIN > GERMANY > > Mobile: 0160/90257737 > E-Mail: bernd(a)net.t-labs.tu-berlin.de (T-Labs work) > WWW: net.t-labs.tu-berlin.de > > > ------enig2UKFBXSMIUKGELBPOGMTD > Content-Type: application/pgp-signature; name="signature.asc" > Content-Description: OpenPGP digital signature > Content-Disposition: attachment; filename="signature.asc" > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > > iQIcBAEBCAAGBQJRSgl/AAoJEH7/++7GEirBB/MP/RTuLNh7okStVOm6MttcIWtl > Zb9LokAFUne74hRr+filAGEP+7UTWgChxaxnTUX48C0m3/7teHYzZ8ARXXP2R0JF > zLVcuexjJ4Kqb8NFflxOxarP3ycNTCUtwHwUM9/6B4okRu3KtqoLIOiCU78QC2yk > vFuA6AA3kiIDswvqxNuCJw+wvNzVLZSdlGFLS2839wQPFpijwSC09OKEMjVwA6bZ > bAKgwqLRqgVOUjODYvmrq+XvQcyv/PienCbEMu6rPB3mRiOAq795TcrnDfiEM8f5 > ClAcEXi31Qb3OTKBfOfFHIWxX/dE6DMKJn/kJturAoram1zQOS5DZyjqspaUHiY6 > i3XB3LPRZh6TcLQs3/sDzsBB+sGXJMG/z6JVrpdxr8J6Wr7haI3auT6nLE3NDZjX > oidet1D8uy2HPQxT3L3FQfjBBpl23h1lSC4UQdNAbztqR5+ATpzkjJNp5AODl+DT > 9rSPo1PRsIlL54L+pLcV2jzMJItm5bZ0DVYLXliJuCG2L7KuvSLkj86giQy/1JXL > BRiBRS5X49RNrlkZmDLXnqfBOcOFeJZ+N8YywJ44T/HeDyYKvGwgiCs9bN50PY8U > VSpmhw2pNJCnN1yfaI8UrK9hSHtLAfUBu0Gyf8P6G5qZk/XAvX8kYHVN0NuHtjkr > 0cqgfDAbtyw3A6/Jn2P4 > =SkKF > -----END PGP SIGNATURE----- > > ------enig2UKFBXSMIUKGELBPOGMTD-- > > > -- -- 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#7552) PcacheAttrset directive is not behaving as it should
by btb＠bitrate.net 24 Mar '13

24 Mar '13

Full_Name: ben thielsen Version: 2.4.31 OS: ubuntu 12.10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (216.176.18.253) i've set olcPcacheAttrset as follows: dn: olcOverlay={0}pcache,olcDatabase={2}ldap,cn=config objectClass: olcPcacheConfig objectClass: olcOverlayConfig objectClass: olcConfig objectClass: top olcOverlay: {0}pcache olcPcache: mdb 1000 100 1000 60 olcPcacheAttrset: 0 "*" "+" olcPcacheTemplate: "(objectClass=)" 0 3600 olcPcacheTemplate: "(uid=)" 0 3600 olcPcacheTemplate: "(&(objectClass=)(uid=))" 0 3600 olcPcacheBind: "(uid=)" 0 60 "sub" "dc=example,dc=net" structuralObjectClass: olcPcacheConfig entryUUID: ddb05d7e-b4fa-1031-811e-353e11fff366 creatorsName: cn=config createTimestamp: 20121028032528Z entryCSN: 20121030002115.179177Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20121030002115Z but the logs indicate that a subsequent query won't be cached: Oct 31 08:42:15 deepfield slapd[12862]: query template of incoming query = (&(objectClass=)(uid=)) Oct 31 08:42:15 deepfield slapd[12862]: QUERY NOT ANSWERABLE Oct 31 08:42:15 deepfield slapd[12862]: QUERY NOT CACHEABLE

1 0

Re: (ITS#7551) [lmdb] bugfix for mdb_cursor_put with MDB_MULTIPLE
by hyc＠symas.com 23 Mar '13

23 Mar '13

claude.brisson(a)gmail.com wrote: > Full_Name: Claude Brisson > Version: HEAD > OS: linux > URL: ftp://ftp.openldap.org/incoming/0001-bugfix-for-mdb_cursor_put-with-MDB_MUL… > Submission from: (NULL) (86.76.238.178) > > > (once again with the attachment...) > > This patch fixes the following problem: Thanks for the fix, applied to mdb.master. > > In mdb_cursor_put, section 'put_sub', if the variable dkey.mv_size is non-zero, > then it means dkey contains some original data which has to be put back in the > child db, typically when the child db has just been created. > > But when using MDB_MULTIPLE, if this variable has not been resetted to zero, we > may come back to this section and wrongly think that there is some original data > to be taken care of. > > Notice: I, Claude Brisson, hereby place the following modifications to OpenLDAP > Software (and only these modifications) into the public domain. Hence, these > modifications may be freely used and/or redistributed for any purpose with or > without attribution and/or other notice. > > -- -- 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#7549) OpenLDAP syncrepl client other than slapd
by flyjohny＠gmail.com 23 Mar '13

23 Mar '13

--047d7b3a98b8f77d2b04d892e62e Content-Type: text/plain; charset=ISO-8859-1 I did, but nobody responded there... Best regards, Mateusz On 22 March 2013 21:12, Howard Chu <hyc(a)symas.com> wrote: > mateusz.dziwny(a)gmail.com wrote: > >> Full_Name: Mateusz Dziwny >> Version: 2.4.3x >> OS: Red Hat 5.9 >> URL: >> Submission from: (NULL) (78.133.233.211) >> >> >> Hello, >> >> I would like to achieve a sync replication in refreshAndPersist mode as >> described in RFC 4533, but I would like to have my own C/C++ application >> as a >> consumer of the notifications. >> >> Is there any way to achieve this with libldap? Or maybe there are some >> libraries >> that could do this? Has anybody tried this? Any tips are welcome. I've >> been >> looking for some tips on this mailing list as well as in google, but no >> success... Most recent questions regarding this issues are dated back in >> 2008/9, >> and contain no straight answers. Maybe something changed since that time? >> > > The ITS is not for tips. Closing this issue. Use the -technical 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/<http://www.openldap.org/project/> > -- www.myspace.com/septiemereve "Basically, I'm trying to save the world from bad music! OK there are those, who might say how do I define bad music? My answer would be soulless music in whatever form it might be." - Derrick May --047d7b3a98b8f77d2b04d892e62e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I did, but nobody responded there...=A0<div><br></div><div>Best regards,</d= iv><div>Mateusz<br><div><br><div class=3D"gmail_quote">On 22 March 2013 21:= 12, Howard Chu <span dir=3D"ltr"><<a href=3D"mailto:hyc@symas.com" targe= t=3D"_blank">hyc(a)symas.com</a>></span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"><a href=3D"mailto:mateusz.dziwny@gmail.com" = target=3D"_blank">mateusz.dziwny(a)gmail.com</a> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Full_Name: Mateusz Dziwny<br> Version: 2.4.3x<br> OS: Red Hat 5.9<br> URL:<br> Submission from: (NULL) (78.133.233.211)<br> <br> <br> Hello,<br> <br> I would like to achieve a sync replication in refreshAndPersist mode as<br> described in RFC 4533, but I would like to have my own C/C++ application as= a<br> consumer of the notifications.<br> <br> Is there any way to achieve this with libldap? Or maybe there are some libr= aries<br> that could do this? Has anybody tried this? Any tips are welcome. I've = been<br> looking for some tips on this mailing list as well as in google, but no<br> success... Most recent questions regarding this issues are dated back in 20= 08/9,<br> and contain no straight answers. Maybe something changed since that time?<b= r> </blockquote> <br> The ITS is not for tips. Closing this issue. Use the -technical mailing lis= t.<span class=3D"HOEnZb"><font color=3D"#888888"><br> <br> -- <br> =A0 -- Howard Chu<br> =A0 CTO, Symas Corp. =A0 =A0 =A0 =A0 =A0 <a href=3D"http://www.symas.com" t= arget=3D"_blank">http://www.symas.com</a><br> =A0 Director, Highland Sun =A0 =A0 <a href=3D"http://highlandsun.com/hyc/" = target=3D"_blank">http://highlandsun.com/hyc/</a><br> =A0 Chief Architect, OpenLDAP =A0<a href=3D"http://www.openldap.org/project= /" target=3D"_blank">http://www.openldap.org/<u></u>project/</a><br> </font></span></blockquote></div><br><br clear=3D"all"><div><br></div>-- <b= r><a href=3D"http://www.myspace.com/septiemereve">www.myspace.com/septiemer= eve</a><br><br>"Basically, I'm trying to save the world from bad m= usic!<br> OK there are those, who might say how do I define bad music?<br><br>My answ= er would be soulless music in whatever form it might be." - Derrick Ma= y </div></div> --047d7b3a98b8f77d2b04d892e62e--

1 0

Re: (ITS#7549) OpenLDAP syncrepl client other than slapd
by hyc＠symas.com 22 Mar '13

22 Mar '13

mateusz.dziwny(a)gmail.com wrote: > Full_Name: Mateusz Dziwny > Version: 2.4.3x > OS: Red Hat 5.9 > URL: > Submission from: (NULL) (78.133.233.211) > > > Hello, > > I would like to achieve a sync replication in refreshAndPersist mode as > described in RFC 4533, but I would like to have my own C/C++ application as a > consumer of the notifications. > > Is there any way to achieve this with libldap? Or maybe there are some libraries > that could do this? Has anybody tried this? Any tips are welcome. I've been > looking for some tips on this mailing list as well as in google, but no > success... Most recent questions regarding this issues are dated back in 2008/9, > and contain no straight answers. Maybe something changed since that time? The ITS is not for tips. Closing this issue. Use the -technical 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

(ITS#7551) [lmdb] bugfix for mdb_cursor_put with MDB_MULTIPLE
by claude.brisson＠gmail.com 22 Mar '13

22 Mar '13

Full_Name: Claude Brisson Version: HEAD OS: linux URL: ftp://ftp.openldap.org/incoming/0001-bugfix-for-mdb_cursor_put-with-MDB_MUL… Submission from: (NULL) (86.76.238.178) (once again with the attachment...) This patch fixes the following problem: In mdb_cursor_put, section 'put_sub', if the variable dkey.mv_size is non-zero, then it means dkey contains some original data which has to be put back in the child db, typically when the child db has just been created. But when using MDB_MULTIPLE, if this variable has not been resetted to zero, we may come back to this section and wrongly think that there is some original data to be taken care of. Notice: I, Claude Brisson, hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

1 0

(ITS#7550) [lmdb] bugfix for mdb_cursor_put with MDB_MULTIPLE
by claude.brisson＠gmail.com 22 Mar '13

22 Mar '13

Full_Name: Claude Brisson Version: HEAD OS: linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (86.76.238.178) This patch fixes the following problem: In mdb_cursor_put, section 'put_sub', if the variable dkey.mv_size is non-zero, then it means dkey contains some original data which has to be put back in the child db, typically when the child db has just been created. But when using MDB_MULTIPLE, if this variable has not been resetted to zero, we may come back to this section and wrongly think that there is some original data to be taken care of. Notice: I, Claude Brisson, hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

1 0

(ITS#7549) OpenLDAP syncrepl client other than slapd
by mateusz.dziwny＠gmail.com 22 Mar '13

22 Mar '13

Full_Name: Mateusz Dziwny Version: 2.4.3x OS: Red Hat 5.9 URL: Submission from: (NULL) (78.133.233.211) Hello, I would like to achieve a sync replication in refreshAndPersist mode as described in RFC 4533, but I would like to have my own C/C++ application as a consumer of the notifications. Is there any way to achieve this with libldap? Or maybe there are some libraries that could do this? Has anybody tried this? Any tips are welcome. I've been looking for some tips on this mailing list as well as in google, but no success... Most recent questions regarding this issues are dated back in 2008/9, and contain no straight answers. Maybe something changed since that time? Br, Mateusz Dziwny

1 0

(ITS#7548) Split man pages
by melanhit＠gmail.com 21 Mar '13

21 Mar '13

Full_Name: Andrew Romanenko Version: 2.4.34 OS: FreeBSD 9.1 Stable URL: ftp://ftp.openldap.org/incoming/Andrew.Romanenko-130322.patch Submission from: (NULL) (130.185.43.169) Install only required man's for -client or -server

1 0

(ITS#7547) Split man pages
by melanhit＠gmail.com 21 Mar '13

21 Mar '13

Full_Name: Andrew Romanenko Version: 2.4.34 OS: FreeBSD 9.1 Stable URL: ftp://ftp.openldap.org/incoming/melanhit-130322.patch Submission from: (NULL) (46.211.181.12) Install only required man's for -client or -server

1 0

Re: (ITS#7546) Proxycache overlay documentation cn=config example misleading
by bernd＠net.t-labs.tu-berlin.de 20 Mar '13

20 Mar '13

This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2UKFBXSMIUKGELBPOGMTD Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Oops forgot the db in the second entry it should of course be # pcache overlay dn: olcOverlay=3D{0}pcache,olcDatabase=3D{2}ldap,cn=3Dconfig =2E.. This is also reflected in the following patch --- doc/guide/admin/overlays.sdf | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/doc/guide/admin/overlays.sdf b/doc/guide/admin/overlays.sdf index a8ceede..8e2c81e 100644 --- a/doc/guide/admin/overlays.sdf +++ b/doc/guide/admin/overlays.sdf @@ -791,7 +791,7 @@ The same example as a LDIF file for back-config for a caching server which proxies for the {{EX:"dc=3Dexample,dc=3Dcom"}} subtree held at server {{EX:ldap.example.com}}. -> dn: olcDatabase=3D{2}ldap +> dn: olcDatabase=3D{2}ldap,cn=3Dconfig > objectClass: olcDatabaseConfig > objectClass: olcLDAPConfig > olcDatabase: {2}ldap @@ -799,7 +799,7 @@ at server {{EX:ldap.example.com}}. > olcRootDN: dc=3Dexample,dc=3Dcom > olcDbURI: "ldap://ldap.example.com" > -> dn: olcOverlay=3D{0}pcache +> dn: olcOverlay=3D{0}pcache,olcDatabase=3D{2}ldap,cn=3Dconfig > objectClass: olcOverlayConfig > objectClass: olcPcacheConfig > olcOverlay: {0}pcache @@ -809,7 +809,7 @@ at server {{EX:ldap.example.com}}. > olcPcacheTemplate: "(&(sn=3D)(givenName=3D))" 0 3600 0 0 0 > olcPcacheTemplate: "(&(departmentNumber=3D)(secretary=3D))" 0 3600 > -> dn: olcDatabase=3D{0}hdb +> dn: olcDatabase=3D{0}hdb,olcOverlay=3D{0}pcache,olcDatabase=3D{2}ldap,cn=3Dco= nfig > objectClass: olcHdbConfig > objectClass: olcPcacheDatabase > olcDatabase: {0}hdb --=20 1.7.10.4 The attached patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Bernd May bernd(a)net.t-labs.tu-berlin.de. I have not assigned rights and/or interest in this work to any party. I, Bernd May, hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice. --=20 Technische Universit=E4t Berlin - FGINET Bernd May System Administration An-Institut Deutsche Telekom Laboratories Sekr. TEL 16 Ernst-Reuter-Platz 7 10587 BERLIN GERMANY Mobile: 0160/90257737 E-Mail: bernd(a)net.t-labs.tu-berlin.de (T-Labs work) WWW: net.t-labs.tu-berlin.de ------enig2UKFBXSMIUKGELBPOGMTD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBCAAGBQJRSgl/AAoJEH7/++7GEirBB/MP/RTuLNh7okStVOm6MttcIWtl Zb9LokAFUne74hRr+filAGEP+7UTWgChxaxnTUX48C0m3/7teHYzZ8ARXXP2R0JF zLVcuexjJ4Kqb8NFflxOxarP3ycNTCUtwHwUM9/6B4okRu3KtqoLIOiCU78QC2yk vFuA6AA3kiIDswvqxNuCJw+wvNzVLZSdlGFLS2839wQPFpijwSC09OKEMjVwA6bZ bAKgwqLRqgVOUjODYvmrq+XvQcyv/PienCbEMu6rPB3mRiOAq795TcrnDfiEM8f5 ClAcEXi31Qb3OTKBfOfFHIWxX/dE6DMKJn/kJturAoram1zQOS5DZyjqspaUHiY6 i3XB3LPRZh6TcLQs3/sDzsBB+sGXJMG/z6JVrpdxr8J6Wr7haI3auT6nLE3NDZjX oidet1D8uy2HPQxT3L3FQfjBBpl23h1lSC4UQdNAbztqR5+ATpzkjJNp5AODl+DT 9rSPo1PRsIlL54L+pLcV2jzMJItm5bZ0DVYLXliJuCG2L7KuvSLkj86giQy/1JXL BRiBRS5X49RNrlkZmDLXnqfBOcOFeJZ+N8YywJ44T/HeDyYKvGwgiCs9bN50PY8U VSpmhw2pNJCnN1yfaI8UrK9hSHtLAfUBu0Gyf8P6G5qZk/XAvX8kYHVN0NuHtjkr 0cqgfDAbtyw3A6/Jn2P4 =SkKF -----END PGP SIGNATURE----- ------enig2UKFBXSMIUKGELBPOGMTD--

1 0

RE: (ITS#7545) Problem with v2.4.30
by quanah＠zimbra.com 20 Mar '13

20 Mar '13

--On Tuesday, March 19, 2013 8:57 PM +0000 "Swenson_CNTR, Carl E." <Carl.Swenson(a)dodiis.mil> wrote: > Quanah, > > Thank you for the reply. > > I double checked my versions on some of my systems just to be sure. One > inconsistency I noticed was in the name of the DB package Possibly > downloaded at 2 different times from sunfreeware.com. > > Example - > Sun Enterprise SPARC T5220 (everything works on this system) > pkginfo -l SMColdap - version 2.4.30 > pkginfo -l SMCossl - version 1.0.1c > pkginfo -l SMCdb - version 4.7.25.NC > > Sun Enterprise SPARC T4-1 (the logs go crazy on this system) > pkginfo -l SMColdap - version 2.4.30 > pkginfo -l SMCossl - version 1.0.1c > pkginfo -l SMCdb47 - version 4.7.25.NC > > IDK how this would affect the system, but based on your suggestion there > is some difference in the package as the "pkginst" name on one system is > SMCdb, and SMCdb47 on the other while the version is exactly the same. I have no idea. I abandoned Slowaris years ago... I abandoned using BDB with OpenLDAP last year. However, no one has reported any issues like this. It really appears to be a bug in BDB rather than OpenLDAP however. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7546) Proxycache overlay documentation cn=config example misleading
by bernd＠net.t-labs.tu-berlin.de 20 Mar '13

20 Mar '13

Full_Name: Bernd May Version: 2.4 OS: GNU/Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (130.149.236.151) The OpenLDAP 2.4 Administrator's Guide has an example configuration for the ProxyCache overlay for the cn=config slapd backend in chapter 12.9.2.5. This example is ambigious in providing guidance about the fact that the pcache overlay requires a separate database to store its cached entries in. In fact the example makes it look like the ldap database to be cached for, the pcache overlay and the pcache database are totally individual entries below cn=config. This is not the case and the example should be edited to reflect the hierachy of those three entries, e.g. # database to be cached for dn: olcDatabase={2}ldap,cn=config ... # pcache overlay dn: olcOverlay={0}pcache,cn=config ... # dn: olcDatabase={0}hdb,olcOverlay={0}pcache,cn=config ... also indexing for the pcacheQueryid (as per the slapo-pcache manpage) might be useful to include in the example, e.g. olcDbIndex: pcacheQueryID eq hth

1 0

RE: (ITS#7545) Problem with v2.4.30
by Carl.Swenson＠dodiis.mil 19 Mar '13

19 Mar '13

Quanah, Thank you for the reply. I double checked my versions on some of my systems just to be sure. One inconsistency I noticed was in the name of the DB package Possibly downloaded at 2 different times from sunfreeware.com. Example - Sun Enterprise SPARC T5220 (everything works on this system) pkginfo -l SMColdap - version 2.4.30 pkginfo -l SMCossl - version 1.0.1c pkginfo -l SMCdb - version 4.7.25.NC Sun Enterprise SPARC T4-1 (the logs go crazy on this system) pkginfo -l SMColdap - version 2.4.30 pkginfo -l SMCossl - version 1.0.1c pkginfo -l SMCdb47 - version 4.7.25.NC IDK how this would affect the system, but based on your suggestion there is some difference in the package as the "pkginst" name on one system is SMCdb, and SMCdb47 on the other while the version is exactly the same. Has anyone reported this before? Any help would be greatly appreciated. Thank you Carl -----Original Message----- From: Quanah Gibson-Mount [mailto:quanah@zimbra.com] Sent: Tuesday, March 19, 2013 4:16 PM To: Swenson_CNTR, Carl E.; openldap-its(a)openldap.org Subject: Re: (ITS#7545) Problem with v2.4.30 --On Tuesday, March 19, 2013 7:37 PM +0000 carl.swenson(a)dia.mil wrote: > Full_Name: C. Swenson > Version: 2.4.30 > OS: Solaris 10 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (214.3.138.234) Sounds like a bug in BDB to me, rather than openldap. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#7545) Problem with v2.4.30
by quanah＠zimbra.com 19 Mar '13

19 Mar '13

--On Tuesday, March 19, 2013 7:37 PM +0000 carl.swenson(a)dia.mil wrote: > Full_Name: C. Swenson > Version: 2.4.30 > OS: Solaris 10 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (214.3.138.234) Sounds like a bug in BDB to me, rather than openldap. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7545) Problem with v2.4.30
by carl.swenson＠dia.mil 19 Mar '13

19 Mar '13

Full_Name: C. Swenson Version: 2.4.30 OS: Solaris 10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (214.3.138.234) All, We have used OpenLDAP for years, and currently using v2.4.30 on several systems. IDK if this is a bug on a specific platform, but there does not seem to be any other logical explanation. Sun Enterprise SPARC T4-1 Solaris 10 update10 8/11 Patch level 147440-27 OpenLDAP v2.4.30 data: /ldap/openLdapData/ logs: /ldap/openLdapLogs/ I have never seen an issue like this one. I have rebuilt and populated LDAP several times, and every time after a few days the number of 50mb logs in the logs directory "explodes". It will grow to the maximum size of the file system until ldap crashes. We have added: set_flags DB_LOG_AUTOREMOVE to the DB_CONFIG file, but this does not seem to do anything. This new model Sun server (T4-1) is the only one that this has happened on, and extensive searches turn up nothing but the autoremove suggestion. This system is on an isolated classified network and I can not upload any log files. Can someone tell us what kind of bug this is? Carl

1 0

(ITS#7544) liblmdb does not specify data lifetime
by h.b.furuseth＠usit.uio.no 19 Mar '13

19 Mar '13

Full_Name: Hallvard B Furuseth Version: 2.4.34 OS: URL: Submission from: (NULL) (193.157.249.58) Submitted by: hallvard I can't see that lmdb.h explains how long MDB_val data returned to the API remains valid: I know the data cannot be used after aborting/committing the txn. How about data in a dirty page - can future update operations in the same txn invalidate it?

1 0

Re: (ITS#7542) slapd segfault on modify
by m.gr＠gmx.de 18 Mar '13

18 Mar '13

On 03/18/2013 07:48 PM, Howard Chu wrote: > m.gr(a)gmx.de wrote: >> Full_Name: Matthias Grau >> Version: 2.4.34 >> OS: debian 6.7.0 x64 >> URL: ftp://ftp.openldap.org/incoming/matthias.grau.130318.bz2 >> Submission from: (NULL) (94.217.193.246) >> >> >> slapd can cause a segfault when sorting values in modify operation. >> Under rare circumstances modify.c:802: jstack += 2; can reach a value >> of greater >> 63 which leads to an overwritten pointer for AttributeDescription. > > Thanks for the report. > >> Changing the size of istack from sizeof(int) * 16 to sizeof(int)*16 + >> 1 solves >> the segfault. But I don't think that's the correct solution. >> As shown here: >> http://theory.stanford.edu/~amitp/rants/c++-vs-c/test5.cc >> there should be a condition to break if jstack reaches the size of of >> istack. > > No. In a correct implementation, jstack can never exceed the size of > istack. > This was fixed in similar/identical code elsewhere, e.g. commit > bb36bdcd1c22d1fbc6575452ef5c9112715ab083 and > e1559100eb8e9a664cd68915e5acbf8caa334fa1 but for some reason we missed > these other instances. > > Fixed now in git master. Thanks for your fast solution. Problem is solved in git master.

1 0

(ITS#7543) Statslog "conn=-1 ... ACCEPT"
by h.b.furuseth＠usit.uio.no 18 Mar '13

18 Mar '13

Full_Name: Hallvard B Furuseth Version: 2.4.34 OS: Linux x86_64 URL: Submission from: (NULL) (193.69.163.163) Submitted by: hallvard slapd logs "conn=-1 fd=.. ACCEPT" if the connection is closed before logging ACCEPT. This became more common recently. I'll fix it by moving Statslog into connection_init(), which knows the connection ID. Not fixing "ACCEPT" to always be logged before "close": It would need the Statslog() done before unlocking c->c_mutex, which looks like it could impact throughput.

1 0

Re: (ITS#7542) slapd segfault on modify
by hyc＠symas.com 18 Mar '13

18 Mar '13

m.gr(a)gmx.de wrote: > Full_Name: Matthias Grau > Version: 2.4.34 > OS: debian 6.7.0 x64 > URL: ftp://ftp.openldap.org/incoming/matthias.grau.130318.bz2 > Submission from: (NULL) (94.217.193.246) > > > slapd can cause a segfault when sorting values in modify operation. > Under rare circumstances modify.c:802: jstack += 2; can reach a value of greater > 63 which leads to an overwritten pointer for AttributeDescription. Thanks for the report. > Changing the size of istack from sizeof(int) * 16 to sizeof(int)*16 + 1 solves > the segfault. But I don't think that's the correct solution. > As shown here: > http://theory.stanford.edu/~amitp/rants/c++-vs-c/test5.cc > there should be a condition to break if jstack reaches the size of of istack. No. In a correct implementation, jstack can never exceed the size of istack. This was fixed in similar/identical code elsewhere, e.g. commit bb36bdcd1c22d1fbc6575452ef5c9112715ab083 and e1559100eb8e9a664cd68915e5acbf8caa334fa1 but for some reason we missed these other instances. Fixed now in git master. -- -- 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#7542) slapd segfault on modify
by m.gr＠gmx.de 18 Mar '13

18 Mar '13

Full_Name: Matthias Grau Version: 2.4.34 OS: debian 6.7.0 x64 URL: ftp://ftp.openldap.org/incoming/matthias.grau.130318.bz2 Submission from: (NULL) (94.217.193.246) slapd can cause a segfault when sorting values in modify operation. Under rare circumstances modify.c:802: jstack += 2; can reach a value of greater 63 which leads to an overwritten pointer for AttributeDescription. Changing the size of istack from sizeof(int) * 16 to sizeof(int)*16 + 1 solves the segfault. But I don't think that's the correct solution. As shown here: http://theory.stanford.edu/~amitp/rants/c++-vs-c/test5.cc there should be a condition to break if jstack reaches the size of of istack. root@debian:/root# gdb /usr/local/libexec/slapd GNU gdb (GDB) 7.0.1-debian Copyright (C) 2009 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /usr/local/libexec/slapd...done. (gdb) r -h ldap://localhost:389 -f /root/slapd.conf -d 0 Starting program: /usr/local/libexec/slapd -h ldap://localhost:389 -f /root/slapd.conf -d 0 [Thread debugging using libthread_db enabled] [New Thread 0x7ffff6dc8700 (LWP 3728)] [New Thread 0x7ffff65c7700 (LWP 3730)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7ffff65c7700 (LWP 3730)] 0x000000000045135b in ordered_value_match (match=0x7ffff65c56cc, ad=0x17c4, mr=0x92ddb0, flags=269, v1=0xcc0820, v2=0x7ffff65c56b0, text=0x7ffff65c6a90) at value.c:633 633 if ( ad->ad_type->sat_flags & SLAP_AT_ORDERED ) { (gdb) bt #0 0x000000000045135b in ordered_value_match (match=0x7ffff65c56cc, ad=0x17c4, mr=0x92ddb0, flags=269, v1=0xcc0820, v2=0x7ffff65c56b0, text=0x7ffff65c6a90) at value.c:633 #1 0x000000000044b71c in slap_sort_vals (ml=0xca8900, text=0x7ffff65c6a90, dup=0x7ffff65c587c, ctx=0x0) at modify.c:741 #2 0x000000000044b497 in slap_mods_check (op=0xaae2a0, ml=0xca8900, text=0x7ffff65c6a90, textbuf=0x7ffff65c6900 "", textlen=256, ctx=0x0) at modify.c:652 #3 0x000000000044a125 in do_modify (op=0xaae2a0, rs=0x7ffff65c6a70) at modify.c:168 #4 0x000000000042a7b0 in connection_operation (ctx=0x7ffff65c6ba0, arg_v=0xaae2a0) at connection.c:1150 #5 0x000000000042ad51 in connection_read_thread (ctx=0x7ffff65c6ba0, argv=0xd) at connection.c:1286 #6 0x00000000005ad930 in ldap_int_thread_pool_wrapper (xpool=<value optimized out>) at tpool.c:688 #7 0x00007ffff784f8ca in start_thread () from /lib/libpthread.so.0 #8 0x00007ffff7169b6d in clone () from /lib/libc.so.6 #9 0x0000000000000000 in ?? () (gdb) p ad $1 = (AttributeDescription *) 0x17c4 (gdb) p *ad Cannot access memory at address 0x17c4 (gdb)

1 0

Re: (ITS#7540) syncrepl "replicates" entries with unknown schema elements
by hyc＠symas.com 18 Mar '13

18 Mar '13

quanah(a)OpenLDAP.org wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.34 > OS: Linux 2.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.39.181) > > > This is similar to ITS#6473, but somewhat new and unique to back-mdb and > syncrepl fallback. > > If, during the process of upgrading a provider/replica cluster, a new schema > element is introduced to the provider, and a modification introducing a value > pair to that attribute is introduced to the provider prior to the replica having > its schema updated, very bad things happen. Don't turn schemacheck off in the consumer. -- -- 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#7541) nssov cannot create socket directory
by hyc＠symas.com 18 Mar '13

18 Mar '13

ryan.g.steele(a)gmail.com wrote: > Full_Name: Ryan Steele > Version: 2.4.34 > OS: Ubuntu, RedHat > URL: > Submission from: (NULL) (12.150.6.65) > > > According to https://github.com/gcp/openldap/blob/master/contrib/slapd-modules/nssov/nss…, > nssov tries to create the socket/PID directory /var/run/nslcd if it does not > exist. However, that mkdir attempt will always fail because slapd runs as a > non-privileged user and the permissions on /var/run are, appropriately, > root:root and 755. As a result, when a system using slapd+nssov is rebooted, > slapd fails to start and user lookups thusly fail until /var/run/nslcd is > manually created so that slapd can be started. Nonsense. That mkdir cannot cause slapd to fail to start, since its success/failure result is ignored. Take this up with your distro provider if the directory isn't available at start time. Closing this ITS. -- -- 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#7541) nssov cannot create socket directory
by ryan.g.steele＠gmail.com 18 Mar '13

18 Mar '13

Full_Name: Ryan Steele Version: 2.4.34 OS: Ubuntu, RedHat URL: Submission from: (NULL) (12.150.6.65) According to https://github.com/gcp/openldap/blob/master/contrib/slapd-modules/nssov/nss…, nssov tries to create the socket/PID directory /var/run/nslcd if it does not exist. However, that mkdir attempt will always fail because slapd runs as a non-privileged user and the permissions on /var/run are, appropriately, root:root and 755. As a result, when a system using slapd+nssov is rebooted, slapd fails to start and user lookups thusly fail until /var/run/nslcd is manually created so that slapd can be started. Traditionally, things in /var/run are created via init scripts, since they run as root. Once that is done, privileges can be dropped and the daemon started. Given that nssov is a contrib overlay, we could make a separate init script for nssov that runs before slapd's and creates the appropriate directory in /var/run. Alternatively, we could make --with-nslcd-pidfile and --with-nslcd-socket configurable post-install options instead of being set in stone at compile time, making it possible to set the PID/socket directory to something we know will exist and have the right perms, like /var/run/slapd (i.e., /var/run/slapd/nslcd.socket). It would probably make sense to remove the mkdir-related lines from nssov.c entirely, since non-privileged users do not have write perms on /var/run. I consider this a pretty serious issue, as it prevents the software from working.

1 0

(ITS#7540) syncrepl "replicates" entries with unknown schema elements
by quanah＠OpenLDAP.org 17 Mar '13

17 Mar '13

Full_Name: Quanah Gibson-Mount Version: 2.4.34 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.39.181) This is similar to ITS#6473, but somewhat new and unique to back-mdb and syncrepl fallback. If, during the process of upgrading a provider/replica cluster, a new schema element is introduced to the provider, and a modification introducing a value pair to that attribute is introduced to the provider prior to the replica having its schema updated, very bad things happen. In essence, a control-charactered version of the attribute is introduced into the replica's DB. The value for the attribute is not necessarily the value that was written into the providers DB. The result is a somewhat corrupted DB on the replica. For example, when this occurs with an attribute with binary syntax, what we see on the replica is things like: ZIMBRAMOBILEMETADATAMAXSIZEENABLED^]: 30 ZIMBRAMOBILEMETADATAMAXSIZEENABLED^]: -1 ZIMBRAMOBILEMETADATAMAXSIZEENABLED^]: 10000 ZIMBRAMOBILEMETADATAMAXSIZEENABLED^]: 60000 in the slapcat output of the DB. Clearly these values are *not* binary, and the introduction of ^] (or sometimes ^Z) is clearly a very bad thing as well. On the provider, we see something like this in the accesslog: dn: reqStart=20130317181046.000001Z,cn=accesslog objectClass: auditModify structuralObjectClass: auditModify reqStart: 20130317181046.000001Z reqEnd: 20130317181046.000002Z reqType: modify reqSession: 1001 reqAuthzID: uid=zimbra,cn=admins,cn=zimbra reqDN: cn=config,cn=zimbra reqResult: 0 reqMod: zimbraMobileMetadataMaxSizeEnabled:= FALSE reqMod: entryCSN:= 20130317181046.334253Z#000000#000#000000 reqMod: modifiersName:= uid=zimbra,cn=admins,cn=zimbra reqMod: modifyTimestamp:= 20130317181046Z reqEntryUUID: c8e8ac5a-22de-1032-8b13-915a6d80e6d8 entryUUID: bc0a83f0-2379-1032-8335-47fcfae022fc creatorsName: cn=config createTimestamp: 20130317181046Z entryCSN: 20130317181046.334253Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20130317181046Z However, as a part of this particular upgrade process, the accesslog DB was recreated (because of the MDB corruption issues). So delta-syncrepl "falls back" to normal syncrepl refresh mode. Instead of halting its fallback due to the missing schema entry, it *blindly* replicates the entire entry: Mar 17 11:10:47 zre-ldap003 slapd[8104]: do_syncrep2: rid=100 cookie=rid=100,csn=20130317181046.501990Z#000000#000#000000 Mar 17 11:10:47 zre-ldap003 slapd[8104]: nonpresent_callback: rid=100 present UUID c8df54ac-22de-1032-8b02-915a6d80e6d8, dn cn=zimbra Mar 17 11:10:47 zre-ldap003 slapd[8104]: nonpresent_callback: rid=100 present UUID c8df7662-22de-1032-8b03-915a6d80e6d8, dn cn=admins,cn=zimbra Mar 17 11:10:47 zre-ldap003 slapd[8104]: nonpresent_callback: rid=100 present UUID c8dfa1fa-22de-1032-8b04-915a6d80e6d8, dn uid=zimbra,cn=admins,cn=zimbra Now when the DB is slapcat'd, we see: zimbra@zre-ldap003:~$ ./libexec/zmslapcat /tmp 51460a8c UNKNOWN attributeDescription "ZIMBRAMOBILEMETADATAMAXSIZEENABLED" inserted. And then in the entry itself we have: zimbraVersionCheckLastAttempt: 20130317011805Z zimbraVersionCheckLastSuccess: 20130317011805Z ZIMBRAMOBILEMETADATAMAXSIZEENABLED^]: FALSE ZIMBRAMOBILEMETADATAMAXSIZEENABLED^]: 30 ZIMBRAMOBILEMETADATAMAXSIZEENABLED^]: -1 ZIMBRAMOBILEMETADATAMAXSIZEENABLED^]: 10000 ZIMBRAMOBILEMETADATAMAXSIZEENABLED^]: 60000 zimbraRedoLogDeleteOnRollover: FALSE So syncrepl not only incorrectly replicated the entry with an unknown schema element, it corrupted the database in the process. Here is the actual data from the provider for this entry: zimbraVersionCheckLastAttempt: 20130317011805Z zimbraVersionCheckLastSuccess: 20130317011805Z zimbraMobileMetadataMaxSizeEnabled: FALSE zimbraHttpDosFilterMaxRequestsPerSec: 30 zimbraHttpDosFilterDelayMillis: -1 zimbraHttpThreadPoolMaxIdleTimeMillis: 10000 zimbraHttpConnectorMaxIdleTimeMillis: 60000 zimbraRedoLogDeleteOnRollover: FALSE --Quanah

1 0

Re: (ITS#7531) Syncrepl push delete operation does not recover when slave is unavailable
by hans.moser＠ofd-z.niedersachsen.de 14 Mar '13

14 Mar '13

--------------000301090802050902000107 Content-Type: text/plain; charset="ISO-8859-15"; format=flowed Content-Transfer-Encoding: 7bit Howard, hyc(a)symas.com schrieb (14.03.2013 16:24 Uhr): > Marc Patermann wrote: >> hyc(a)symas.com schrieb (14.03.2013 15:14 Uhr): >>> hans.moser(a)ofd-z.niedersachsen.de wrote: >>>> I think we had situations like this before... >>>> >>>> How about having a test for this? >>>> What is the test which is nearest to this situation where a test could >>>> be based on? >>> test045. Feel free to submit patches for this test script. >> If I'm not mistaken, >> - in lines 262-264 the consumer is stopped >> - in lines 266-284 changes are made to the provider >> - in lines 286-294 the consumer is started again. > > Sounds reasonable but your line numbers don't match anything in our tree. > Please send an actual patch, e.g. from git format-patch (or just diff -u.) Sorry, I was in test054, not test045. But as base 054 seems to be just fine. I hope, I did the patch right. Marc --------------000301090802050902000107 Content-Type: text/x-patch; name="test-054.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="test-054.patch" --- openldap-051dba8/tests/scripts/test054-syncreplication-parallel-load 2013-03-14 14:55:44.000000000 +0100 +++ test054-syncreplication-parallel-load 2013-03-14 17:16:25.516490000 +0100 @@ -236,6 +236,14 @@ dn: cn=James A Jones 2, ou=Information Technology Division, ou=People, dc=example,dc=com changetype: delete +dn: cn=Invisible Man, ou=Information Technology Division, ou=People, dc=example,dc=com +changetype: add +objectclass: OpenLDAPperson +cn: Invisible Man +sn: Man +uid: invisibleman +description: Ghost + EOMODS RC=$? @@ -281,6 +289,9 @@ uid: rosco cn: Rosco P. Coltrane +dn: cn=Invisible Man, ou=Information Technology Division, ou=People, dc=example,dc=com +changetype: delete + EOMODS echo "Restarting consumer..." --------------000301090802050902000107--

1 0

Re: (ITS#7531) Syncrepl push delete operation does not recover when slave is unavailable
by hyc＠symas.com 14 Mar '13

14 Mar '13

Marc Patermann wrote: > Howard, > > hyc(a)symas.com schrieb (14.03.2013 15:14 Uhr): >> hans.moser(a)ofd-z.niedersachsen.de wrote: > >>> I think we had situations like this before... >>> >>> How about having a test for this? >>> What is the test which is nearest to this situation where a test could >>> be based on? >> >> test045. Feel free to submit patches for this test script. > If I'm not mistaken, > - in lines 262-264 the consumer is stopped > - in lines 266-284 changes are made to the provider > - in lines 286-294 the consumer is started again. Sounds reasonable but your line numbers don't match anything in our tree. Please send an actual patch, e.g. from git format-patch (or just diff -u.) > > But the changes do > - delete cn=Rosco P. Coltrane, ou=Retired, ou=People, dc=example,dc=com > (lines 269-270) > - modify cn=Bjorn Jensen, ou=Information Technology Division, ou=People, > dc=example,dc=com (lines 272-275) > - add cn=Rosco P. Coltrane, ou=Retired, ou=People, dc=example,dc=com > _again_ (lines 277-282) > So while the consumer is down Coltrane is deleted and added again. > We miss a scenario where an object is still deleted, when the consumer > is back again. > > There is no object, which is not used later on, so we should add a new > object first: > > (before line 239) > > dn: cn=Invisible Man, ou=Information Technology Division, ou=People, > dc=example,dc=com > changetype: add > objectclass: OpenLDAPperson > cn: Invisible Man > sn: Man > uid: invisibleman > description: Ghost > > And delete the object while the consumer is down: > > (before line 284) > > dn: cn=Invisible Man, ou=Information Technology Division, ou=People, > dc=example,dc=com > changetype: delete > > > That would do, I think. > > > Sorry for not patching it myself, I'm not too familiar with it. > > > Marc > -- -- 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#7531) Syncrepl push delete operation does not recover when slave is unavailable
by hans.moser＠ofd-z.niedersachsen.de 14 Mar '13

14 Mar '13

Howard, hyc(a)symas.com schrieb (14.03.2013 15:14 Uhr): > hans.moser(a)ofd-z.niedersachsen.de wrote: >> I think we had situations like this before... >> >> How about having a test for this? >> What is the test which is nearest to this situation where a test could >> be based on? > > test045. Feel free to submit patches for this test script. If I'm not mistaken, - in lines 262-264 the consumer is stopped - in lines 266-284 changes are made to the provider - in lines 286-294 the consumer is started again. But the changes do - delete cn=Rosco P. Coltrane, ou=Retired, ou=People, dc=example,dc=com (lines 269-270) - modify cn=Bjorn Jensen, ou=Information Technology Division, ou=People, dc=example,dc=com (lines 272-275) - add cn=Rosco P. Coltrane, ou=Retired, ou=People, dc=example,dc=com _again_ (lines 277-282) So while the consumer is down Coltrane is deleted and added again. We miss a scenario where an object is still deleted, when the consumer is back again. There is no object, which is not used later on, so we should add a new object first: (before line 239) dn: cn=Invisible Man, ou=Information Technology Division, ou=People, dc=example,dc=com changetype: add objectclass: OpenLDAPperson cn: Invisible Man sn: Man uid: invisibleman description: Ghost And delete the object while the consumer is down: (before line 284) dn: cn=Invisible Man, ou=Information Technology Division, ou=People, dc=example,dc=com changetype: delete That would do, I think. Sorry for not patching it myself, I'm not too familiar with it. Marc

1 0

Re: (ITS#7528) ldapadd not working while adding attribute having long list of values
by hyc＠symas.com 14 Mar '13

14 Mar '13

omkar(a)mithi.com wrote: > Full_Name: Omkar Phadke > Version: 2.4.30 > OS: Red Hat Enterprise Linux Server release 6.0 (Santiago) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (115.111.211.142) > > > I am trying to add bellow ldif file. Read the ldif(5) manpage. You appear to have line breaks in the data which breaks the format. -- -- 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#7531) Syncrepl push delete operation does not recover when slave is unavailable
by hyc＠symas.com 14 Mar '13

14 Mar '13

hans.moser(a)ofd-z.niedersachsen.de wrote: > Hi, > > jsynacek(a)redhat.com schrieb (27.02.2013 12:25 Uhr): > >> The setup is a master with an ldap backend and a slave consumer. If the master >> is running and slave is not, delete operation results in the master being >> stuck. A patch for this is now in git master, please test. > I think we had situations like this before... > > How about having a test for this? > What is the test which is nearest to this situation where a test could > be based on? test045. Feel free to submit patches for this test script. -- -- 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#7531) Syncrepl push delete operation does not recover when slave is unavailable
by hans.moser＠ofd-z.niedersachsen.de 14 Mar '13

14 Mar '13

Hi, jsynacek(a)redhat.com schrieb (27.02.2013 12:25 Uhr): > The setup is a master with an ldap backend and a slave consumer. If the master > is running and slave is not, delete operation results in the master being > stuck. I think we had situations like this before... How about having a test for this? What is the test which is nearest to this situation where a test could be based on? Marc

1 0

Re: (ITS#7538) mdb_add: txn_commit failed : MDB_PAGE_FULL: Internal error - page has no more space
by hyc＠symas.com 12 Mar '13

12 Mar '13

quanah(a)OpenLDAP.org wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.34 > OS: linux 2.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (74.196.25.250) > > > 2.4.34 + d74330128ac0c5b1ba3a06a199238f9780f685fd This bug was caused by the above patch for ITS#7536. Since it is now resolved, I'm closing this ITS, it should not have been tracked separately. > > Seeing the following when writing to MDB under load: > > Mar 11 10:49:57 zqa-376 slapd[22478]: mdb_add: txn_commit failed : > MDB_PAGE_FULL: Internal error - page has no more space (-30786) > > I do not see this error in a build of RE24 that has everything in 2.4.34 except > 1f7b6c1199ccb986a240871a8b54f5dc9041136d > > -- -- 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#7538) mdb_add: txn_commit failed : MDB_PAGE_FULL: Internal error - page has no more space
by quanah＠zimbra.com 11 Mar '13

11 Mar '13

--On Monday, March 11, 2013 6:02 PM +0000 quanah(a)OpenLDAP.org wrote: Another side effect -- DB entries are being created out of order, meaning slapcat dumps are not loadable via ldapadd. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7539) Bug in JLDAP LDAPAttributeSchema.java code
by maleks＠gmail.com 11 Mar '13

11 Mar '13

Full_Name: Aleksandar M. Version: JLDAP OS: Windows 8 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (78.73.228.218) Hello, This is not a bug in OpenLDAP but in the Java client library, JLDAP. The LDAPAttributeSchema.java file is not parsing attributes correctly. The issue is in the method: public LDAPAttributeSchema(String raw) It doesn't set the usage and collective fields when using that method. The fix is to add the following code: this.usage = parser.getUsage(); this.collective = parser.getCollective(); I have added it and uploaded the changed file to the incoming directory. The file is named AleksandarM-LDAPAttributeSchema-20130311.java

1 0

(ITS#7538) mdb_add: txn_commit failed : MDB_PAGE_FULL: Internal error - page has no more space
by quanah＠OpenLDAP.org 11 Mar '13

11 Mar '13

Full_Name: Quanah Gibson-Mount Version: 2.4.34 OS: linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (74.196.25.250) 2.4.34 + d74330128ac0c5b1ba3a06a199238f9780f685fd Seeing the following when writing to MDB under load: Mar 11 10:49:57 zqa-376 slapd[22478]: mdb_add: txn_commit failed : MDB_PAGE_FULL: Internal error - page has no more space (-30786) I do not see this error in a build of RE24 that has everything in 2.4.34 except 1f7b6c1199ccb986a240871a8b54f5dc9041136d

1 0

Re: (ITS#7531) Syncrepl push delete operation does not recover when slave is unavailable
by jsynacek＠redhat.com 11 Mar '13

11 Mar '13

On 03/02/2013 02:59 AM, hyc(a)symas.com wrote: > jsynacek(a)redhat.com wrote: >> On 02/27/2013 02:48 PM, jsynacek(a)redhat.com wrote: >>> On 02/27/2013 12:25 PM, jsynacek(a)redhat.com wrote: >>>> Full_Name: Jan Synacek >>>> Version: RE24 (7b03a58) >>>> OS: Linux - Fedora 18 >>>> URL: ftp://ftp.openldap.org/incoming/jsynacek-reproducer.tar.gz >>>> Submission from: (NULL) (209.132.186.34) >>>> >>>> >>>> The setup is a master with an ldap backend and a slave consumer. If the master >>>> is running and slave is not, delete operation results in the master being >>>> stuck. >>>> >>>> Steps to reproduce: >>>> 1. Start master. >>>> 2. Add the example ldif. >>>> 3. Delete one of the test org units. >>>> 4. Observe the error. >>>> >>>> I would expect the master to honor the retry setting. >>>> >>> >>> During the reproduction, it may be necessary to first have both master and slave >>> running, delete a testing test org unit (so the first replication is >>> successful), stop the slave and then continue to step 3. >>> >> >> URL: >> ftp://ftp.openldap.org/incoming/jsynacek-20130103-syncrepl-retry.patch > > This patch is clearly unacceptable. Your goto obviously skips over two _free() > invocations, thus introducing a memory leak. > I'm sorry that I didn't notice this before sending the patch. New URL: ftp://ftp.openldap.org/incoming/jsynacek-20130311-syncrepl-retry.patch -- Jan Synacek Software Engineer, Red Hat

1 0

Re: (ITS#7536) mdb assert when cleaning up accesslog
by hyc＠symas.com 06 Mar '13

06 Mar '13

This is a multi-part message in MIME format. --------------080809050807080004080107 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Fixed in the attached patch, please test. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ --------------080809050807080004080107 Content-Type: text/x-patch; name="0001-ITS-7536-fix-mdb_rebalance.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="0001-ITS-7536-fix-mdb_rebalance.patch" >From aee706272c660e052c991fea82ce6269c605be1d Mon Sep 17 00:00:00 2001 From: Howard Chu <hyc(a)openldap.org> Date: Wed, 6 Mar 2013 12:30:37 -0800 Subject: [PATCH] ITS#7536 fix mdb_rebalance A page must always have at least 2 keys (unless it's a root page) --- libraries/liblmdb/mdb.c | 7 ++++--- 1 files changed, 4 insertions(+), 3 deletions(-) diff --git a/libraries/liblmdb/mdb.c b/libraries/liblmdb/mdb.c index 4d8bfa3..058c68b 100644 --- a/libraries/liblmdb/mdb.c +++ b/libraries/liblmdb/mdb.c @@ -6368,12 +6368,13 @@ mdb_rebalance(MDB_cursor *mc) DPRINTF("found neighbor page %zu (%u keys, %.1f%% full)", mn.mc_pg[mn.mc_top]->mp_pgno, NUMKEYS(mn.mc_pg[mn.mc_top]), (float)PAGEFILL(mc->mc_txn->mt_env, mn.mc_pg[mn.mc_top]) / 10); - /* If the neighbor page is above threshold and has at least two - * keys, move one key from it. + /* If the neighbor page is above threshold and has at least three + * keys, move one key from it. (A page must never have fewer than + * 2 keys.) * * Otherwise we should try to merge them. */ - if (PAGEFILL(mc->mc_txn->mt_env, mn.mc_pg[mn.mc_top]) >= FILL_THRESHOLD && NUMKEYS(mn.mc_pg[mn.mc_top]) >= 2) + if (PAGEFILL(mc->mc_txn->mt_env, mn.mc_pg[mn.mc_top]) >= FILL_THRESHOLD && NUMKEYS(mn.mc_pg[mn.mc_top]) > 2) return mdb_node_move(&mn, mc); else { if (mc->mc_ki[ptop] == 0) -- 1.7.2.5 --------------080809050807080004080107--

1 0

Re: (ITS#7536) mdb assert when cleaning up accesslog
by quanah＠zimbra.com 06 Mar '13

06 Mar '13

--On Wednesday, March 06, 2013 2:11 AM +0000 quanah(a)OpenLDAP.org wrote: Thread 7 (Thread 0x7fd7f09c9700 (LWP 1927)): #0 0x000000341dc0b3dc in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 No symbol table info available. #1 0x00007ffff7daed7f in ldap_pvt_thread_cond_wait (cond=0x7d9fd0, mutex=0x7d9fa8) at thr_posix.c:277 No locals. #2 0x00007ffff7dad70b in ldap_int_thread_pool_wrapper (xpool=0x7d9fa0) at tpool.c:675 pool = 0x7d9fa0 task = 0x0 work_list = 0x7da038 ctx = {ltu_id = 140565431490304, ltu_key = {{ltk_key = 0x4ad88b, ltk_data = 0x7fd7d80008c0, ltk_free = 0x4ad6b0 <slap_sl_mem_destroy>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 28 times>, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0x80}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}}} kctx = 0x0 i = 32 keyslot = 985 hash = 2179612633 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #3 0x000000341dc077f1 in start_thread () from /lib64/libpthread.so.0 No symbol table info available. #4 0x000000341d8e570d in clone () from /lib64/libc.so.6 No symbol table info available. Thread 6 (Thread 0x7fd7f11ca700 (LWP 1926)): #0 0x000000341d832885 in raise () from /lib64/libc.so.6 No symbol table info available. #1 0x000000341d834065 in abort () from /lib64/libc.so.6 No symbol table info available. #2 0x000000341d82b9fe in __assert_fail_base () from /lib64/libc.so.6 No symbol table info available. #3 0x000000341d82bac0 in __assert_fail () from /lib64/libc.so.6 No symbol table info available. #4 0x00007ffff4317bfa in mdb_page_search_root (mc=0x7fd7e81023f8, key=0x0, modify=0) at ./../../../libraries/liblmdb/mdb.c:4017 node = 0x7febf6dceff8 i = 0 mp = 0x7febf6dd2000 rc = 0 __PRETTY_FUNCTION__ = "mdb_page_search_root" #5 0x00007ffff431813a in mdb_page_search (mc=0x7fd7e81023f8, key=0x0, flags=0) at ./../../../libraries/liblmdb/mdb.c:4153 rc = 0 root = 14843 __PRETTY_FUNCTION__ = "mdb_page_search" #6 0x00007ffff43196c5 in mdb_cursor_first (mc=0x7fd7e81023f8, key=0x7fd7f11c8df0, data=0x0) at ./../../../libraries/liblmdb/mdb.c:4599 rc = 32727 leaf = 0x7ffff431749f __PRETTY_FUNCTION__ = "mdb_cursor_first" #7 0x00007ffff43194f5 in mdb_cursor_set (mc=0x7fd7e8102270, key=0x7fd7f11c8e00, data=0x7fd7f11c8df0, op=MDB_SET, exactp=0x7fd7f11c8d80) at ./../../../libraries/liblmdb/mdb.c:4552 rc = 0 mp = 0x7febf6dcc000 leaf = 0x7febf6dccf54 __PRETTY_FUNCTION__ = "mdb_cursor_set" #8 0x00007ffff4319ec6 in mdb_cursor_get (mc=0x7fd7e8102270, key=0x7fd7f11c8e00, data=0x7fd7f11c8df0, op=MDB_SET) at ./../../../libraries/liblmdb/mdb.c:4735 rc = 0 exact = 1 __PRETTY_FUNCTION__ = "mdb_cursor_get" key = {mv_size = 8, mv_data = 0x7fd7f11c8e30} data = {mv_size = 0, mv_data = 0x7fd7e8000df8} subs = 140737290221723 nid = 1 ptr = 0x7febf6da0f0a "" rc = 0 #10 0x00007ffff42f9754 in mdb_delete (op=0x7fd7f11c9480, rs=0x7fd7f11c9410) at delete.c:335 mdb = 0x8d09c0 pdn = {bv_len = 12, bv_val = 0x7fd7e810347f "cn=accesslog"} e = 0x7fd7e8000df8 p = 0x7fd7e80009b0 manageDSAit = 0 children = 0x7d56a0 entry = 0x7d5400 txn = 0x7fd7e82fd3b0 mc = 0x7fd7e8102270 opinfo = {moi_oe = {oe_next = {sle_next = 0x0}, oe_key = 0x8d09c0}, moi_txn = 0x7fd7e82fd3b0, moi_ref = 1, moi_flag = 0 '\000'} moi = 0x7fd7f11c8f30 preread_ctrl = 0x0 ctrls = {0x0, 0x7fd7f11c933e, 0x7fd7e8000908, 0x7fd7f11c9341, 0x7fd7f11c933e, 0x100000001} num_ctrls = 0 parent_is_glue = 0 parent_is_leaf = 0 __PRETTY_FUNCTION__ = "mdb_delete" #11 0x00000000004cd715 in overlay_op_walk (op=0x7fd7f11c9480, rs=0x7fd7f11c9410, which=op_delete, oi=0x8cf4f0, on=0x0) at backover.c:671 func = 0x7ffff452c258 rc = 32768 #12 0x00000000004cd92c in over_op_func (op=0x7fd7f11c9480, rs=0x7fd7f11c9410, which=op_delete) at backover.c:723 oi = 0x8cf4f0 on = 0x8a8330 be = 0x8c2720 db = {bd_info = 0x7ffff452c200, bd_self = 0x8c2720, be_ctrls = "\000\001\001\001\000\001\000\000\001\000\000\001\001\000\001\000\000\001", '\000' <repeats 14 times>, "\001", be_flags = 2312, be_restrictops = 0, be_requires = 0, be_ssf_set = {sss_ssf = 0, sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 0}, be_suffix = 0x8ce9c0, be_nsuffix = 0x8c4760, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = { bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 9, bv_val = 0x8bea90 "cn=config"}, be_rootndn = {bv_len = 9, bv_val = 0x8ce0d0 "cn=config"}, be_rootpw = {bv_len = 0, bv_val = 0x0}, be_max_deref_depth = 15, be_def_limit = {lms_t_soft = -1, lms_t_hard = 0, lms_s_soft = -1, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x0, be_acl = 0x8c4840, be_dfltaccess = ACL_READ, be_extra_anlist = 0x0, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x0, be_pending_csn_list = 0xe1ef70, be_pcl_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __list = { __prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, be_syncinfo = 0x0, be_pb = 0x0, be_cf_ocs = 0x7ffff452bf80, be_private = 0x8d09c0, be_next = {stqe_next = 0x99fd90}} cb = {sc_next = 0x7ffff3eb2fe0, sc_response = 0x4cc6f2 <over_back_response>, sc_cleanup = 0, sc_private = 0x8cf4f0} sc = 0x7fd7f11c9414 rc = 32768 __PRETTY_FUNCTION__ = "over_op_func" #13 0x00000000004cdae6 in over_op_delete (op=0x7fd7f11c9480, rs=0x7fd7f11c9410) at backover.c:780 No locals. #14 0x00007ffff3ca9bc6 in accesslog_purge (ctx=0x7fd7f11c9b60, arg=0x8cb090) at accesslog.c:700 i = 0 rtask = 0x8cb090 li = 0x8a7f70 conn = {c_struct_state = SLAP_C_UNINITIALIZED, c_conn_state = SLAP_C_INVALID, c_conn_idx = -1, c_sd = 0, c_close_reason = 0x0, c_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, c_sb = 0x0, c_starttime = 0, c_activitytime = 0, c_connid = 18446744073709551615, c_peer_domain = {bv_len = 0, bv_val = 0x4f1c90 ""}, c_peer_name = {bv_len = 0, bv_val = 0x4f1c90 ""}, c_listener = 0x4f9bc0, c_sasl_bind_mech = {bv_len = 0, bv_val = 0x0}, c_sasl_dn = {bv_len = 0, bv_val = 0x0}, c_sasl_authz_dn = {bv_len = 0, bv_val = 0x0}, c_authz_backend = 0x0, c_authz_cookie = 0x0, c_authz = {sai_method = 0, sai_mech = {bv_len = 0, bv_val = 0x0}, sai_dn = {bv_len = 0, bv_val = 0x0}, sai_ndn = {bv_len = 0, bv_val = 0x0}, sai_ssf = 0, sai_transport_ssf = 0, sai_tls_ssf = 0, sai_sasl_ssf = 0}, c_protocol = 0, c_ops = {stqh_first = 0x0, stqh_last = 0x0}, c_pending_ops = {stqh_first = 0x0, stqh_last = 0x0}, c_write1_mutex = { __data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, c_write1_cv = {__data = {__lock = 0, __futex = 0, __total_seq = 0, __wakeup_seq = 0, __woken_seq = 0, __mutex = 0x0, __nwaiters = 0, __broadcast_seq = 0}, __size = '\000' <repeats 47 times>, __align = 0}, c_write2_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __list = { __prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, c_write2_cv = {__data = {__lock = 0, __futex = 0, __total_seq = 0, __wakeup_seq = 0, __woken_seq = 0, __mutex = 0x0, __nwaiters = 0, __broadcast_seq = 0}, __size = '\000' <repeats 47 times>, __align = 0}, c_currentber = 0x0, c_writers = 0, c_writing = 0 '\000', c_sasl_bind_in_progress = 0 '\000', c_writewaiter = 0 '\000', c_is_tls = 0 '\000', c_needs_tls_accept = 0 '\000', c_sasl_layers = 0 '\000', c_sasl_done = 0 '\000', c_sasl_authctx = 0x0, c_sasl_sockctx = 0x0, c_sasl_extra = 0x0, c_sasl_bindop = 0x0, c_pagedresults_state = {ps_be = 0x0, ps_size = 0, ps_count = 0, ps_cookie = 0, ps_cookieval = {bv_len = 0, bv_val = 0x0}}, c_n_ops_received = 0, c_n_ops_executing = 0, c_n_ops_pending = 0, c_n_ops_completed = 0, c_n_get = 0, c_n_read = 0, c_n_write = 0, c_extensions = 0x0, c_clientfunc = 0, c_clientarg = 0x0, c_send_ldap_result = 0x45118c <slap_send_ldap_result>, c_send_search_entry = 0x451e94 <slap_send_search_entry>, c_send_search_reference = 0x453f44 <slap_send_search_reference>, c_send_ldap_extended = 0x4519f3 <slap_send_ldap_extended>, c_send_ldap_intermediate = 0x451c71 <slap_send_ldap_intermediate>} opbuf = {ob_op = {o_hdr = 0x7fd7f11c95f0, o_tag = 74, o_time = 1362595264, o_tincr = 5, o_bd = 0x7fd7f11c90a0, o_req_dn = {bv_len = 44, bv_val = 0x7fd7e8103420 "reqStart=20130227005207.000010Z,cn=accesslog"}, o_req_ndn = {bv_len = 43, bv_val = 0x7fd7e8103460 "reqStart=20130227005207.00001Z,cn=accesslog"}, o_request = {oq_add = {rs_modlist = 0x1, rs_e = 0xffffffffffffffff}, oq_bind = {rb_method = 1, rb_cred = {bv_len = 18446744073709551615, bv_val = 0x0}, rb_edn = {bv_len = 1, bv_val = 0x755cc0 "\003"}, rb_ssf = 4045181904, rb_mech = {bv_len = 27, bv_val = 0x7fd7e8000908 "\200\220\034\361\327\177"}}, oq_compare = {rs_ava = 0x1}, oq_modify = { rs_mods = {rs_modlist = 0x1, rs_no_opattrs = -1 '\377'}, rs_increment = 0}, oq_modrdn = {rs_mods = {rs_modlist = 0x1, rs_no_opattrs = -1 '\377'}, rs_deleteoldrdn = 0, rs_newrdn = {bv_len = 1, bv_val = 0x755cc0 "\003"}, rs_nnewrdn = {bv_len = 140565439878096, bv_val = 0x1b <Address 0x1b out of bounds>}, rs_newSup = 0x7fd7e8000908, rs_nnewSup = 0x0}, oq_search = {rs_scope = 1, rs_deref = 0, rs_slimit = -1, rs_tlimit = -1, rs_limit = 0x0, rs_attrsonly = 1, rs_attrs = 0x755cc0, rs_filter = 0x7fd7f11c93d0, rs_filterstr = {bv_len = 27, bv_val = 0x7fd7e8000908 "\200\220\034\361\327\177"}}, oq_abandon = {rs_msgid = 1}, oq_cancel = {rs_msgid = 1}, oq_extended = {rs_reqoid = {bv_len = 1, bv_val = 0xffffffffffffffff <Address 0xffffffffffffffff out of bounds>}, rs_flags = 0, rs_reqdata = 0x1}, oq_pwdexop = { rs_extended = {rs_reqoid = {bv_len = 1, bv_val = 0xffffffffffffffff <Address 0xffffffffffffffff out of bounds>}, rs_flags = 0, rs_reqdata = 0x1}, rs_old = { bv_len = 7691456, bv_val = 0x7fd7f11c93d0 "\246"}, rs_new = {bv_len = 27, bv_val = 0x7fd7e8000908 "\200\220\034\361\327\177"}, rs_mods = 0x0, rs_modtail = 0x0}}, o_abandon = 0, o_cancel = 0, o_groups = 0x0, o_do_not_cache = 0 '\000', o_is_auth_check = 0 '\000', o_dont_replicate = 1 '\001', o_acl_priv = ACL_NONE, o_nocaching = 0 '\000', o_delete_glue_parent = 0 '\000', o_no_schema_check = 0 '\000', o_no_subordinate_glue = 0 '\000', o_ctrlflag = '\000' <repeats 31 times>, o_controls = 0x7fd7f11c9738, o_authz = {sai_method = 0, sai_mech = {bv_len = 0, bv_val = 0x0}, sai_dn = {bv_len = 9, bv_val = 0x8bea90 "cn=config"}, sai_ndn = {bv_len = 9, bv_val = 0x8ce0d0 "cn=config"}, sai_ssf = 0, sai_transport_ssf = 0, sai_tls_ssf = 0, sai_sasl_ssf = 0}, o_ber = 0x0, o_res_ber = 0x0, o_callback = 0x7fd7e8000908, o_ctrls = 0x0, o_csn = {bv_len = 40, bv_val = 0x7fd7f11c9320 "20130228042415.556142Z#000000#001#000000"}, o_private = 0x0, o_extra = {slh_first = 0x7fd7f11c8f30}, o_next = {stqe_next = 0x0}}, ob_hdr = { oh_opid = 0, oh_connid = 18446744073709551615, oh_conn = 0x7fd7f11c9840, oh_msgid = 0, oh_protocol = 0, oh_tid = 140565439883008, oh_threadctx = 0x7fd7f11c9b60, oh_tmpmemctx = 0x7fd7e80008c0, oh_tmpmfuncs = 0x756280, oh_counters = 0x7597c0, oh_log_prefix = "conn=-1 op=0", '\000' <repeats 243 times>}, ob_controls = { 0x0 <repeats 32 times>}} op = 0x7fd7f11c9480 rs = {sr_type = REP_RESULT, sr_tag = 0, sr_msgid = 0, sr_err = -30798, 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 = 0, r_v2ref = 0x0}, sru_sasl = {r_sasldata = 0x0}, sru_extended = {r_rspoid = 0x0, r_rspdata = 0x0}}, sr_flags = 0} cb = {sc_next = 0x0, sc_response = 0x7ffff3ca9570 <log_old_lookup>, sc_cleanup = 0, sc_private = 0x7fd7f11c9380} f = {f_choice = 166, f_un = {f_un_result = -249785424, f_un_desc = 0x7fd7f11c93b0, f_un_ava = 0x7fd7f11c93b0, f_un_ssa = 0x7fd7f11c93b0, f_un_mra = 0x7fd7f11c93b0, f_un_complex = 0x7fd7f11c93b0}, f_next = 0x0} ava = {aa_desc = 0x82b4a0, aa_value = {bv_len = 15, bv_val = 0x7fd7f11c9360 "20130305184104Z"}} pd = {slots = 18200, used = 18152, dn = 0x7fd7e837aed0, ndn = 0x7fd7e83c2060, csn = {bv_len = 40, bv_val = 0x7fd7f11c9320 "20130228042415.556142Z#000000#001#000000"}} timebuf = "20130305184104Z\000\000\000\000\000\000" csnbuf = "20130228042415.556142Z#000000#001#000000", '\000' <repeats 23 times> old = 1362508864 __PRETTY_FUNCTION__ = "accesslog_purge" #15 0x00007ffff7dad7b2 in ldap_int_thread_pool_wrapper (xpool=0x7d9fa0) at tpool.c:688 pool = 0x7d9fa0 task = 0x7fd7ec000a00 work_list = 0x7da038 ctx = {ltu_id = 140565439883008, ltu_key = {{ltk_key = 0x4ad88b, ltk_data = 0x7fd7e80008c0, ltk_free = 0x4ad6b0 <slap_sl_mem_destroy>}, {ltk_key = 0x7ffff33d2010, ltk_data = 0x7fd7e8100910, ltk_free = 0x7ffff430d65e <mdb_reader_free>}, {ltk_key = 0x7ffff4302b9c, ltk_data = 0x7fd7e2cfe010, ltk_free = 0x7ffff4302b79 <search_stack_free>}, {ltk_key = 0x7ffff42fff19, ltk_data = 0x7fd7e3cff010, ltk_free = 0x7ffff42ffed1 <scope_chunk_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 25 times>, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0x80}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}}} kctx = 0x0 i = 32 keyslot = 42 hash = 2079142954 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #16 0x000000341dc077f1 in start_thread () from /lib64/libpthread.so.0 No symbol table info available. #17 0x000000341d8e570d in clone () from /lib64/libc.so.6 No symbol table info available. Thread 5 (Thread 0x7fd7f19cb700 (LWP 1925)): #0 0x000000341dc0b3dc in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 No symbol table info available. #1 0x00007ffff7daed7f in ldap_pvt_thread_cond_wait (cond=0x7d9fd0, mutex=0x7d9fa8) at thr_posix.c:277 No locals. #2 0x00007ffff7dad70b in ldap_int_thread_pool_wrapper (xpool=0x7d9fa0) at tpool.c:675 pool = 0x7d9fa0 task = 0x0 work_list = 0x7da038 ctx = {ltu_id = 140565448275712, ltu_key = {{ltk_key = 0x4ad88b, ltk_data = 0x7fd7d40008c0, ltk_free = 0x4ad6b0 <slap_sl_mem_destroy>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 28 times>, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0x80}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}}} kctx = 0x0 i = 32 keyslot = 954 hash = 553430970 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #3 0x000000341dc077f1 in start_thread () from /lib64/libpthread.so.0 No symbol table info available. #4 0x000000341d8e570d in clone () from /lib64/libc.so.6 No symbol table info available. Thread 4 (Thread 0x7fd7f21cc700 (LWP 1924)): #0 0x000000341dc0b3dc in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 No symbol table info available. #1 0x00007ffff7daed7f in ldap_pvt_thread_cond_wait (cond=0x7d9fd0, mutex=0x7d9fa8) at thr_posix.c:277 No locals. #2 0x00007ffff7dad70b in ldap_int_thread_pool_wrapper (xpool=0x7d9fa0) at tpool.c:675 pool = 0x7d9fa0 task = 0x0 work_list = 0x7da038 ctx = {ltu_id = 140565456668416, ltu_key = {{ltk_key = 0x4ad88b, ltk_data = 0x7fd7dc0008c0, ltk_free = 0x4ad6b0 <slap_sl_mem_destroy>}, {ltk_key = 0x7febf31d1010, ltk_data = 0x7fd7dc101670, ltk_free = 0x7ffff430d65e <mdb_reader_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 27 times>, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0x80}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}}} kctx = 0x0 i = 32 keyslot = 395 hash = 457840011 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #3 0x000000341dc077f1 in start_thread () from /lib64/libpthread.so.0 No symbol table info available. #4 0x000000341d8e570d in clone () from /lib64/libc.so.6 No symbol table info available. Thread 3 (Thread 0x7fd7f29cd700 (LWP 1923)): #0 0x000000341dc0b3dc in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 No symbol table info available. #1 0x00007ffff7daed7f in ldap_pvt_thread_cond_wait (cond=0x7d9fd0, mutex=0x7d9fa8) at thr_posix.c:277 No locals. #2 0x00007ffff7dad70b in ldap_int_thread_pool_wrapper (xpool=0x7d9fa0) at tpool.c:675 pool = 0x7d9fa0 task = 0x0 work_list = 0x7da038 ctx = {ltu_id = 140565465061120, ltu_key = {{ltk_key = 0x4ad88b, ltk_data = 0x7fd7e40008c0, ltk_free = 0x4ad6b0 <slap_sl_mem_destroy>}, {ltk_key = 0x7ffff33d2010, ltk_data = 0x7fd7e4100910, ltk_free = 0x7ffff430d65e <mdb_reader_free>}, {ltk_key = 0x7febf31d1010, ltk_data = 0x7fd7e410fa50, ltk_free = 0x7ffff430d65e <mdb_reader_free>}, { ltk_key = 0x7ffff4302b9c, ltk_data = 0x7fd7e17f6010, ltk_free = 0x7ffff4302b79 <search_stack_free>}, {ltk_key = 0x7ffff42fff19, ltk_data = 0x7fd7e27f7010, ltk_free = 0x7ffff42ffed1 <scope_chunk_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 24 times>, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0x80}, { ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}}} kctx = 0x0 i = 32 keyslot = 283 hash = 3227095323 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #3 0x000000341dc077f1 in start_thread () from /lib64/libpthread.so.0 No symbol table info available. #4 0x000000341d8e570d in clone () from /lib64/libc.so.6 No symbol table info available. Thread 2 (Thread 0x7fd7f31ce700 (LWP 1922)): #0 0x000000341d8e5d03 in epoll_wait () from /lib64/libc.so.6 No symbol table info available. #1 0x00000000004362dc in slapd_daemon_task (ptr=0x8cb050) at daemon.c:2542 ns = 1 at = 0 nfds = 3 revents = 0x7b0c90 tvp = 0x7fd7f31cdda0 cat = {tv_sec = 1362595564, tv_usec = 0} i = 1 nwriters = 0 now = 1362595266 tv = {tv_sec = 298, tv_usec = 0} tdelta = 1 rtask = 0x8b29b0 l = 1 last_idle_check = 1362595264 ebadf = 0 tid = 0 #2 0x000000341dc077f1 in start_thread () from /lib64/libpthread.so.0 No symbol table info available. #3 0x000000341d8e570d in clone () from /lib64/libc.so.6 No symbol table info available. Thread 1 (Thread 0x7ffff7117700 (LWP 1919)): #0 0x000000341dc0804d in pthread_join () from /lib64/libpthread.so.0 No symbol table info available. #1 0x00007ffff7daecc0 in ldap_pvt_thread_join (thread=140565473453824, thread_return=0x0) at thr_posix.c:197 No locals. #2 0x0000000000437437 in slapd_daemon () at daemon.c:2935 i = 0 rc = 0 #3 0x00000000004149eb in main (argc=9, argv=0x7fffffffe498) at main.c:1012 i = 9 no_detach = 1 rc = 0 urls = 0x7aa090 "ldapi:///" username = 0x7aa0b0 "root" groupname = 0x0 sandbox = 0x0 syslogUser = 160 pid = 501312480 waitfds = {0, 0} g_argc = 9 g_argv = 0x7fffffffe498 configfile = 0x0 configdir = 0x7aa0d0 "/opt/zimbra/data/ldap/config" serverName = 0x7fffffffe759 "slapd" serverMode = 1 scp = 0x0 scp_entry = 0x0 debug_unknowns = 0x0 syslog_unknowns = 0x0 serverNamePrefix = 0x4f1728 "" l = 5181968 slapd_pid_file_unlink = 1 slapd_args_file_unlink = 1 firstopt = 0 __PRETTY_FUNCTION__ = "main" -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#7537) ppolicy hangs slapd on 64bit version debian
by michael＠stroeder.com 06 Mar '13

06 Mar '13

On Wed, 6 Mar 2013 10:11:53 GMT hyc(a)symas.com wrote > marek.platta(a)blstream.com wrote: > > Full_Name: Marek Platta > > Version: 2.4.23-7.2 > > OS: Debian6 > > URL: ldap.zumbai.pl > > Submission from: (NULL) (83.168.110.42) > > 2.4.23 is quite old, plus yours has been patched by Debian so we don't know > what it contains. You will have to get support from Debian. If you can > reproduce the issue on our current release (2.4.34) then we will investigate > it. To add: I tried that with our own build of OpenLDAP 2.4.34 on Debian Squeeze 2.6.32-5-amd64 and I can't reproduce the lockup. Ciao, Michael.

1 0

Re: (ITS#7537) ppolicy hangs slapd on 64bit version debian
by hyc＠symas.com 06 Mar '13

06 Mar '13

marek.platta(a)blstream.com wrote: > Full_Name: Marek Platta > Version: 2.4.23-7.2 > OS: Debian6 > URL: ldap.zumbai.pl > Submission from: (NULL) (83.168.110.42) > > > Hi!, 2.4.23 is quite old, plus yours has been patched by Debian so we don't know what it contains. You will have to get support from Debian. If you can reproduce the issue on our current release (2.4.34) then we will investigate it. > I got problem implementing ppolicy on slapd 64bit version > > Tested on > debian6 2.6.32-5-xen-amd64 with slapd 2.4.23-7.2 > > debian6 2.6.32-5-amd64 with slapd 2.4.23-7.2 > > and > > debian7 3.2.0-4-amd64 with slapd 2.4.31-1 > > > Problem occours when i try to change parameters of ppolicy (using phpldapadmin, > luma, etc.) for example: > > pwdMaxFailure: 6 to 5 > > Slapd process hangs and you can only stop it by "kill -9" > > > On Debian 32bit works fine > > -- -- 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#7537) ppolicy hangs slapd on 64bit version debian
by marek.platta＠blstream.com 06 Mar '13

06 Mar '13

Full_Name: Marek Platta Version: 2.4.23-7.2 OS: Debian6 URL: ldap.zumbai.pl Submission from: (NULL) (83.168.110.42) Hi!, I got problem implementing ppolicy on slapd 64bit version Tested on debian6 2.6.32-5-xen-amd64 with slapd 2.4.23-7.2 debian6 2.6.32-5-amd64 with slapd 2.4.23-7.2 and debian7 3.2.0-4-amd64 with slapd 2.4.31-1 Problem occours when i try to change parameters of ppolicy (using phpldapadmin, luma, etc.) for example: pwdMaxFailure: 6 to 5 Slapd process hangs and you can only stop it by "kill -9" On Debian 32bit works fine

1 0

(ITS#7536) mdb assert when cleaning up accesslog
by quanah＠OpenLDAP.org 05 Mar '13

05 Mar '13

Full_Name: Quanah Gibson-Mount Version: 2.4.34 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (74.196.25.250) When deleting entries from the accesslog, slapd dies after hitting an assert: 5136a59f => access_allowed: delete access to "cn=accesslog" "children" requested 5136a59f <= root access granted 5136a59f => access_allowed: delete access granted by manage(=mwrscxd) 5136a59f => access_allowed: delete access to "reqStart=20130227005207.000010Z,cn=accesslog" "entry" requested 5136a59f <= root access granted 5136a59f => access_allowed: delete access granted by manage(=mwrscxd) 5136a59f => mdb_dn2id_delete 0x5bd1e slapd: ./../../../libraries/liblmdb/mdb.c:4017: mdb_page_search_root: Assertion `(((mp)->mp_pb.pb.pb_lower - ((unsigned) __builtin_offsetof (MDB_page, mp_ptrs))) >> 1) > 1' failed.

1 0

Re: (ITS#7531) Syncrepl push delete operation does not recover when slave is unavailable
by hyc＠symas.com 01 Mar '13

01 Mar '13

jsynacek(a)redhat.com wrote: > On 02/27/2013 02:48 PM, jsynacek(a)redhat.com wrote: >> On 02/27/2013 12:25 PM, jsynacek(a)redhat.com wrote: >>> Full_Name: Jan Synacek >>> Version: RE24 (7b03a58) >>> OS: Linux - Fedora 18 >>> URL: ftp://ftp.openldap.org/incoming/jsynacek-reproducer.tar.gz >>> Submission from: (NULL) (209.132.186.34) >>> >>> >>> The setup is a master with an ldap backend and a slave consumer. If the master >>> is running and slave is not, delete operation results in the master being >>> stuck. >>> >>> Steps to reproduce: >>> 1. Start master. >>> 2. Add the example ldif. >>> 3. Delete one of the test org units. >>> 4. Observe the error. >>> >>> I would expect the master to honor the retry setting. >>> >> >> During the reproduction, it may be necessary to first have both master and slave >> running, delete a testing test org unit (so the first replication is >> successful), stop the slave and then continue to step 3. >> > > URL: > ftp://ftp.openldap.org/incoming/jsynacek-20130103-syncrepl-retry.patch This patch is clearly unacceptable. Your goto obviously skips over two _free() invocations, thus introducing a memory leak. -- -- 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#7535) MDB_PREV on a cursor which was at EOF
by hyc＠symas.com 01 Mar '13

01 Mar '13

claude(a)renegat.net wrote: > Full_Name: Claude Brisson > Version: 2.4.33 > OS: debian > URL: > Submission from: (NULL) (86.76.238.166) > > > When calling mdb_cursor_get with operation MDB_PREV on a cursor which was at > EOF, the last key is fetched as expected, but the cursor state is left > uninitialized. > > It looks like there is a missing "mc->mc_flags |= C_INITIALIZED" somewhere in > this case. This was fixed in git rev 5c1ee7f7ba9580d5ff29e74cbb02eee335c33d94 2012-10-22. The fix will be in 2.4.34. Bug reports should only be reported against latest source. Closing this ITS. -- -- 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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs