openldap-bugs

openldap-bugs@openldap.org

1 participants
20963 discussions

Re: (ITS#7545) Problem with v2.4.30
by hyc＠symas.com 26 Mar '13

26 Mar '13

Carl.Swenson(a)dodiis.mil wrote: > Quanah, > > Fine, I get it, you hate Solaris, BDB, etc...... But this is what I have > to work with, and I still have an issue that I have never heard of, nor do I know what to even look for. Google searches turn up very little. > > Is there an "OpenLDAP forum" where you can get help? I have tried removing the package labeled SMCdb47, and loaded SMCdb. The result is still the same. I know you don't like BDB, (you didn't mention what you do prefer) but in any case we are approved to use OpenLDAP w/ BDB. Normally we download all the supporting packages from sunfreeware.com, and if I remember correctly, it is defaulted to use BDB. > > So I have to use: > Solaris 10 > BDB 4.7.25.NC > OpenSSL 1.0.1c > OpenLDAP 2.4.30 > > What can I do. I have configured hundreds of servers using these packages, and their predecessors. We have never seen this behavior. Well... Oracle now owns your hardware manufacturer and the software in question. They'd be the obvious place to ask for help. Frankly I'm surprised that a military site on a classified network is allowed to install freeware binaries from any internet site. You have no idea how those binaries were built, and certainly no recourse if they fail in any way or happen to have trojans/malware embedded within. My first step would be to compile current source code. If the behavior still exists on current code, then start debugging/diagnosing. BDB 4.7.25 is quite old, as Quanah already pointed out. We've never seen any other cases reported like this, but it's always possible for a mixture of old binaries and new hardware to go bad. For all you know it's an instruction set incompatibility and recompiling BDB for your T4 will make it go away. > > > Carl > > > -----Original Message----- > From: Quanah Gibson-Mount [mailto:quanah@zimbra.com] > Sent: Wednesday, March 20, 2013 2:20 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 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 > > > -- -- 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#7545) Problem with v2.4.30
by quanah＠zimbra.com 26 Mar '13

26 Mar '13

--On Tuesday, March 26, 2013 6:09 PM +0000 "Swenson_CNTR, Carl E." <Carl.Swenson(a)dodiis.mil> wrote: > Quanah, > > Fine, I get it, you hate Solaris, BDB, etc...... But this is what I have > to work with, and I still have an issue that I have never heard of, nor > do I know what to even look for. Google searches turn up very little. > > Is there an "OpenLDAP forum" where you can get help? I have tried > removing the package labeled SMCdb47, and loaded SMCdb. The result is > still the same. I know you don't like BDB, (you didn't mention what you > do prefer) but in any case we are approved to use OpenLDAP w/ BDB. > Normally we download all the supporting packages from sunfreeware.com, > and if I remember correctly, it is defaulted to use BDB. As I initially stated, there is nothing in your bug report to indicate a bug with OpenLDAP. I would note that BDB 4.7.25 is ancient. I would note that OpenLDAP 2.4.30 is fairly old. Who knows how OpenLDAP or BDB was built with those packages you are using. There certainly isn't enough detail in your report to really offer you any particular direction to pursue. If it was *me*, I would build the latest OpenLDAP with a current version of BDB, where I could control the compile options and flags. By the way, BDB support in OpenLDAP is essentially deprecated. All ongoing development is with the new MDB backend. --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 Carl.Swenson＠dodiis.mil 26 Mar '13

26 Mar '13

Quanah, Fine, I get it, you hate Solaris, BDB, etc...... But this is what I have to work with, and I still have an issue that I have never heard of, nor do I know what to even look for. Google searches turn up very little. Is there an "OpenLDAP forum" where you can get help? I have tried removing the package labeled SMCdb47, and loaded SMCdb. The result is still the same. I know you don't like BDB, (you didn't mention what you do prefer) but in any case we are approved to use OpenLDAP w/ BDB. Normally we download all the supporting packages from sunfreeware.com, and if I remember correctly, it is defaulted to use BDB. So I have to use: Solaris 10 BDB 4.7.25.NC OpenSSL 1.0.1c OpenLDAP 2.4.30 What can I do. I have configured hundreds of servers using these packages, and their predecessors. We have never seen this behavior. Carl -----Original Message----- From: Quanah Gibson-Mount [mailto:quanah@zimbra.com] Sent: Wednesday, March 20, 2013 2:20 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 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

Re: (ITS#7554) mdb_cursor_put() flag combinations broken
by hyc＠symas.com 25 Mar '13

25 Mar '13

h.b.furuseth(a)usit.uio.no wrote: > 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: The cursor_put flags are not combinable. The doc already says only one value may be set. Closing this ITS. > > 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. > > -- -- 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#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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs