openldap-bugs

openldap-bugs@openldap.org

1 participants
20959 discussions

(ITS#7856) TLS_REQCERT try is same as TLS_REQCERT hard?
by pguenther＠proofpoint.com 16 May '14

16 May '14

Full_Name: Philip Guenther Version: 2.4.39 OS: OpenBSD URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.253.0.176) The ldap.conf(5) manpage says this about TLS_REQCERT TLS_REQCERT <level> Specifies what checks to perform on server certificates in a TLS session, if any. The <level> can be specified as one of the following keywords: ... try The server certificate is requested. If no certificate is provided, the session proceeds normally. If a bad certificate is provided, the session is immediately terminated. demand | hard These keywords are equivalent. The server certificate is requested. If no certificate is provided, or a bad certificate is provided, the session is immediately terminated. This is the default setting. In testing, I can find no difference in behavior between the 'try' and 'hard' keywords. For the ldap* tools, both 'try' and 'hard' seem to place the same requirements on the server. What does "if no certificate is provided" *mean* in terms of server and/or client configuration?

1 0

Re: (ITS#7705) mdb back-end segfaults sporadically with paged searches
by hyc＠symas.com 16 May '14

16 May '14

openldap(a)semyon.org wrote: > On 13-09-23 10:16 PM, Howard Chu wrote: > >> If you backup the DB with slapcat and reload it on another server with >> slapadd, can you still reproduce the fault on the copy? > > Unfortunately, yes. It breaks trying to retrieve the same record as > before, on the same instruction in back_mdb: > > yesterday: > [126393.233615] slapd[19244]: segfault at 7f499f38d000 ip > 00007f4da0e9b6a1 sp 00007f499f1fa540 error 6 in > back_mdb-2.4.so.2.9.2[7f4da0e80000+34000] > > today: > [517860.953779] slapd[24871]: segfault at 7fdeb50a0000 ip > 00007fe2b63ad6a1 sp 00007fdeb4f0d540 error 6 in > back_mdb-2.4.so.2.9.2[7fe2b6392000+34000] > > Semyon A fix is 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

Re: (ITS#7855) Update to latest autotools to support new architecture ppc64le
by hyc＠symas.com 15 May '14

15 May '14

rajesh(a)linux.vnet.ibm.com wrote: > Full_Name: Rajeshkumar S > Version: 2.4.39 > OS: Ubuntu 14.04 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (122.248.161.59) > > > > I am trying to build the openldap package from the source following the > release tarball from > ftp://ftp.openldap.org/pub/OpenLDAP/openldap-release/openldap-2.4.39.tgz. in a > new architecture ppc64le ( IBM PowerPC Little endian ). As the config.guess and > libtool did not have the required patches to identify this new architecture, I > did autoreconf -f -i in my build system whose latest automake and libtool has > the patches > of ppc64le. > autoreconf fails with automake errors as shown below > > automake: error: no 'Makefile.am' found for any configure output > autoreconf: automake failed with exit status: 1 That's to be expected, since there certainly are no Makefile.am files in our source tree. We don't use automake. This is not a bug. > As discussed in the mailing list, Quanah Gibson-Mount suggested me to request an > update for auto-tools to support new architectures. > > The automake with version >= 1.13.4 has the correct config.guess with the > required ppc64le fixes. > Regarding the libtool, the last release is more than 2 years ago I believe, we > managed to get an alpha source release which has all the latest patches to > support the new architecture ppc64le > > An alpha version of libtool with ppc64le support is available at > ftp://alpha.gnu.org/gnu/libtool/libtool-2.4.2.418.tar.gz. Libtool is so perpetually problematic that we will certainly not integrate an alpha version into our source tree. > Hence I request for an update of the auto tools in your build system to support > these new architectures. > > Thanks and Regards > Rajeshkumar S > Linux Technology Center, IBM > > -- -- 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#7855) Update to latest autotools to support new architecture ppc64le
by rajesh＠linux.vnet.ibm.com 15 May '14

15 May '14

Full_Name: Rajeshkumar S Version: 2.4.39 OS: Ubuntu 14.04 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (122.248.161.59) I am trying to build the openldap package from the source following the release tarball from ftp://ftp.openldap.org/pub/OpenLDAP/openldap-release/openldap-2.4.39.tgz. in a new architecture ppc64le ( IBM PowerPC Little endian ). As the config.guess and libtool did not have the required patches to identify this new architecture, I did autoreconf -f -i in my build system whose latest automake and libtool has the patches of ppc64le. autoreconf fails with automake errors as shown below automake: error: no 'Makefile.am' found for any configure output autoreconf: automake failed with exit status: 1 As discussed in the mailing list, Quanah Gibson-Mount suggested me to request an update for auto-tools to support new architectures. The automake with version >= 1.13.4 has the correct config.guess with the required ppc64le fixes. Regarding the libtool, the last release is more than 2 years ago I believe, we managed to get an alpha source release which has all the latest patches to support the new architecture ppc64le An alpha version of libtool with ppc64le support is available at ftp://alpha.gnu.org/gnu/libtool/libtool-2.4.2.418.tar.gz. Hence I request for an update of the auto tools in your build system to support these new architectures. Thanks and Regards Rajeshkumar S Linux Technology Center, IBM

1 0

Re: (ITS#7853) Improve safety of mdb_env_close
by hbf＠mail.uio.no 14 May '14

14 May '14

On 05/14/2014 01:18 AM, hyc(a)symas.com wrote: > dw(a)botanicus.net wrote: >> Currently if a user (wilfully or accidentally, say, through composition of >> third party libs) opens the same LMDB environment twice within a process, and >> maintains active read transactions at the time one mdb_env_close() is called, >> all reader slots will be deallocated in all environments due to the logic >> around line 4253 that unconditionally clears reader slots based on PID. >> >> I'd like to avoid this in py-lmdb, and seems there are a few alternatives to >> fix it: >> >> 1) Tell users not to do that (doc fix, nobody reads docs) > > This is already in the doc - don't open the same env twice within one process. 1.5) Use something else than fcntl locks on the lock-file descriptor to control whether to re-init the lockfile and its mutexes/semaphores. Like MDB_NOLOCK. Needed to get any other suggestions off the ground, see Caveats in lmdb.h. Once two MDB_env's in a process has the lockfile open, both lose their fcntl locks when either closes it - and the next mdb_env_open() will reset the lockfile. Then both readers and writers are screwed, and more care with reader slots won't help. Well, one MDB_env could leak its lockfile descriptor instead of closing it, or it could give the descriptor to the other MDB_env for a deferred close if it could find it using some global state. (Could work until someone wrote an open-close loop which would run into the max-open-FD limit.) Either way, no fun. Another way would be #ifdef ... more unportable code ... #endif:-( Surely some OSes have come up with sane way to address this problem, there's just no portable way. >> 2) Externally maintain a set of (st_dev, st_ino) keys representing already >> opened environments, and check any attempt to open an environment against this >> list, failing if data.mdb's key already appears. > > That would require global library state, which is definitely unwanted. Though in one sense we already have that, which is the problem. Global (well, per-process) lock state on open files and mutexes. >> 3) Disable the mdb_env_close() cleanup loop when MDB_NOTLS is enabled. Since no >> reader slot will ever exist in TLS in this mode, the existing mdb_env_close() >> doc "All transactions, databases, and cursors must already be closed before >> calling this function." ensures no readers exist at close time, and the loop >> need not run. > > Could do this, but since it's an incomplete solution, not sure there's any point. That's MDB_NOLOCK anyway. MDB_NOTLS does have reader table entries. > (...) -- Hallvard

1 0

(ITS#7854) minor patches to allow compile with VS2012
by louis＠steelbytes.com 14 May '14

14 May '14

Full_Name: Louis Solomon Version: 2.4.39 OS: Win32 & Win64 URL: Submission from: (NULL) (59.167.196.195) 1) in libraries/libldap/ldif.c move int ldif_debug = 0; to after _all_ the includes. Why? because the linker gets confused with it being declared as declspec(dllexport). Order matters. 2) in include/ac/socket.h EWOULDBLOCK, EINPROGRESS, ETIMEDOUT (lines 101-103) conflict with the windows header files. simply wrap with any rational choice of ifdef/ifndef 3) in include/ldap_utf8.h wrap prototypes for ldap_x_utf8_to_wc (line 61) through to ldap_x_mbs_utf8s (line 99) with #if SIZEOF_WCHAR>=4 to match the ifdef at the top of utf-8-conv.c. Why? because the linker tries to export them as they are defined in the header with declspec(dllexport) but are not in any .o/.obj 4) in include/ldap_cdefs.h the usage of __declspec(dllexport/dllimport) is not quite right ... should be like #if defined(_WIN32) ... # define LDAP_F(type) __declspec(dllimport) type # define LDAP_V(type) extern __declspec(dllimport) type #else # define LDAP_F(type) __declspec(dllexport) type # define LDAP_V(type) extern __declspec(dllexport) type #endif and of course the same for each of the other sets (LBER, LDAP, LDAP_AVL, LDAP_LDIF, etc) With the above patches and making the appropriate .h files from .hin files manually and then creating VS2012 project files, I was successfully able to create and use liblber, libldap, libldap_r as .dlls

1 0

Re: (ITS#7844) LMDB Delete Cursor inconsistencies
by armon.dadgar＠gmail.com 13 May '14

13 May '14

--5372ac85_8edbdab_1271 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline =46or now, we have application code to retry the delete until no further = rows are removed. Still, it would be nice to have this resolved (and tested) in master=21 Best Regards, Armon Dadgar =46rom:=C2=A0David Wilson dw=40hmmz.org Reply:=C2=A0David Wilson dw=40hmmz.org Date:=C2=A0May 13, 2014 at 3:41:08 PM To:=C2=A0armon.dadgar=40gmail.com armon.dadgar=40gmail.com Cc:=C2=A0openldap-its=40openldap.org openldap-its=40openldap.org Subject:=C2=A0 Re: (ITS=237844) LMDB Delete Cursor inconsistencies =20 This sounds very much like a known regression in mdb.master in the past =20 few months. If you are still affected, please retest against LMDB 0.9.11 = =20 which at least was not affected by the regression. =20 David =20 --5372ac85_8edbdab_1271 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline <html><head><style>body=7Bfont-family:Helvetica,Arial;font-size:13px=7D</= style></head><body style=3D=22word-wrap: break-word; -webkit-nbsp-mode: s= pace; -webkit-line-break: after-white-space;=22><div id=3D=22bloop=5Fcust= omfont=22 style=3D=22font-family:Helvetica,Arial;font-size:13px; color: r= gba(0,0,0,1.0); margin: 0px; line-height: auto;=22>=46or now, we have app= lication code to retry the delete until no further rows are removed.</div= ><div id=3D=22bloop=5Fcustomfont=22 style=3D=22font-family:Helvetica,Aria= l;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;= =22>Still, it would be nice to have this resolved (and tested) in master=21= </div><div id=3D=22bloop=5Fcustomfont=22 style=3D=22font-family:Helvetica= ,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: = auto;=22><br></div> <div id=3D=22bloop=5Fsign=5F1400024102388026112=22 cl= ass=3D=22bloop=5Fsign=22><div style=3D=22font-family:helvetica,arial;font= -size:13px=22>Best Regards,</div><div style=3D=22font-family:helvetica,ar= ial;font-size:13px=22>Armon Dadgar<br></div></div> <div style=3D=22color:= black=22><br>=46rom: <span style=3D=22color:black=22>David Wilson</s= pan> <a href=3D=22mailto:dw=40hmmz.org=22>dw=40hmmz.org</a><br>Reply:&nbs= p;<span style=3D=22color:black=22>David Wilson</span> <a href=3D=22mailto= :dw=40hmmz.org=22>dw=40hmmz.org</a><br>Date: <span style=3D=22color:= black=22>May 13, 2014 at 3:41:08 PM</span><br>To: <span style=3D=22c= olor:black=22>armon.dadgar=40gmail.com</span> <a href=3D=22mailto:armon.d= adgar=40gmail.com=22>armon.dadgar=40gmail.com</a><br>Cc: <span style= =3D=22color:black=22>openldap-its=40openldap.org</span> <a href=3D=22mail= to:openldap-its=40openldap.org=22>openldap-its=40openldap.org</a><br>Subj= ect: <span style=3D=22color:black=22> Re: (ITS=237844) LMDB Delete C= ursor inconsistencies <br></span></div><br> <blockquote type=3D=22cite=22= class=3D=22clean=5Fbq=22><span><div><div></div><div>This sounds very muc= h like a known regression in mdb.master in the past <br>few months. If you are still affected, please retest against LMDB 0.9= .11 <br>which at least was not affected by the regression. <br> <br> <br>David <br></div></div></span></blockquote></body></html> --5372ac85_8edbdab_1271--

1 0

Re: (ITS#7853) Improve safety of mdb_env_close
by hyc＠symas.com 13 May '14

13 May '14

dw(a)botanicus.net wrote: > Full_Name: David Wilson > Version: LMDB 0.9.11 > OS: > URL: https://raw.githubusercontent.com/dw/py-lmdb/master/misc/readers_mrb_env.pa… > Submission from: (NULL) (178.238.153.20) > > > Currently if a user (wilfully or accidentally, say, through composition of > third party libs) opens the same LMDB environment twice within a process, and > maintains active read transactions at the time one mdb_env_close() is called, > all reader slots will be deallocated in all environments due to the logic > around line 4253 that unconditionally clears reader slots based on PID. > > I'd like to avoid this in py-lmdb, and seems there are a few alternatives to > fix it: > > > 1) Tell users not to do that (doc fix, nobody reads docs) This is already in the doc - don't open the same env twice within one process. > 2) Externally maintain a set of (st_dev, st_ino) keys representing already > opened environments, and check any attempt to open an environment against this > list, failing if data.mdb's key already appears. That would require global library state, which is definitely unwanted. > 3) Disable the mdb_env_close() cleanup loop when MDB_NOTLS is enabled. Since no > reader slot will ever exist in TLS in this mode, the existing mdb_env_close() > doc "All transactions, databases, and cursors must already be closed before > calling this function." ensures no readers exist at close time, and the loop > need not run. Could do this, but since it's an incomplete solution, not sure there's any point. > 4) Modify lock.mdb to include MDB_env* address within the process, and update > mdb_env_close() to invalidate only readers associated with the environment > being closed. I dislike using the MDB_env* as an opaque publicly visible > cookie, but perhaps storing this field might be reused for other things in > future. Hmm. I guess this could work. I think storing the MDB_env* is harmless since the pointer is meaningless to any other process. > Option 3 lets the user wilfully mix py-lmdb Environment objects within the > process, since py-lmdb always enables NOTLS, but it does not fix the case where > the user is integrating a Python application with a C library with some opaque > interface, and both the application and the library independently have need to > access the environment. Allowing multiple independent libraries to open the same environment would consume redundant chunks of address space. For large enough DBs this may simply fail. Unfortunately the semantics of fcntl locks prevents us from even detecting that this problem has occurred. > This kind of scenario regularly crops up in huge software projects, the user > may not even be aware the library uses LMDB internally. In that case, the user > is again exposed to having their reader slots silently become deallocated > through no fault of their own. > > > Option 4 is the least aesthetic, but has all the benefits of option 3 in > addition to preventing the "accidental integration" scenario. I've attached a > patch for it (against 0.9.11), although I completely understand if it does not > get applied. :) > > One alternative would be instead of using MDB_env* address, using a > monotonically increasing counter based on a static global, say, "mrb_token", > but this might break in the case two copies of LMDB were somehow linked in the > application. (It's easy to argue the user is an idiot in this case ;) Global state is verboten. > > > David > > -- -- 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#7844) LMDB Delete Cursor inconsistencies
by dw＠hmmz.org 13 May '14

13 May '14

This sounds very much like a known regression in mdb.master in the past few months. If you are still affected, please retest against LMDB 0.9.11 which at least was not affected by the regression. David

1 0

Re: (ITS#7853) Improve safety of mdb_env_close
by dw＠botanicus.net 13 May '14

13 May '14

It's worth mentioning that this is not a theoretical issue, I've already hit it while writing unit tests.

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