openldap-bugs

openldap-bugs@openldap.org

1 participants
20960 discussions

(ITS#8622) Getting MDB_CORRUPTED when deleting within a DUPSORT database
by h.b.furuseth＠usit.uio.no 22 Mar '17

22 Mar '17

Full_Name: Hallvard B Furuseth Version: LMDB_0.9.19, mdb.master OS: Linux x86_64 URL: http://www.openldap.org/lists/openldap-technical/201703/msg00043.html Submission from: (NULL) (193.157.240.142) Submitted by: hallvard This is Klaus Malorny's test case from openldap-technical (linked below). Compiled with gcc -std=gnu99. Breaks mdv.master and mdb.RE: .... 33000000 records written testing mdb_cursor_get: unexpected error -30796: MDB_CORRUPTED: Located page was wrong type In LMDB 0.9.18, the test case instead asserted: mdb.c:5647: Assertion 'mc->mc_flags & C_INITIALIZED' failed in mdb_cursor_next() That was fixed by commit b46fc3e438d8085d5e5fc7d558c0002ee1e2753c "ITS#8406 fix xcursors after cursor_del". Then it broke again at 6b1df0e4c7fadd21d1233d7157229b2d89ccaa04 "More for ITS#8406 (xcursor fixups)", giving the MDB_CORRUPTED.

1 0

Re: (ITS#8467) LMDB creation
by quanah＠symas.com 21 Mar '17

21 Mar '17

--On Tuesday, July 19, 2016 3:44 PM +0000 potte324(a)umn.edu wrote: > I've been trying to create LMDB files for a particle physics project in > classifying particle interactions. Anyways, I modified an old code used to > create levelDB files from a TTree in the Root software developed by CERN > using c++. Then, I tried to run the neural net on the lmdb files and it > gave me an error that std::string_length was too large. And I tried to > show the images I had saved in it and it didn't show me anything, whereas > on an LMDB file I had from one of the caffe tutorials it did show me the > image. > > Do you have any ideas of what could be wrong? It think it is likely that I > messed something up and can't find a lot of documentation for building > LMDB files. In addition, I'm fairly new to coding and I had a hard time > reading the API page due to this. If you have any ideas of how to help > that would be great. Hi Jordan, The ITS system is for reporting bugs, rather than asking for help with programming questions, etc. The correct place for such questions would be the openldap-technical mailing list: <http://www.openldap.org/lists/mm/listinfo/openldap-technical> This ITS will be closed. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8621) Unique through multiple attribute
by quanah＠symas.com 21 Mar '17

21 Mar '17

--On Sunday, March 19, 2017 12:07 AM +0000 michael(a)stroeder.com wrote: > I'd say it works as designed and there is no bug. > > The work-around for your use-case is to use SUP to derive from a common > attribute type. But this should be discussed on openldap-technical > mailing list. Agreed. I've moved this to the enhancement queue in case anyone ever wants to work on enforcing uniqueness across > 1 attribute, but I would think that would require all of the attributes to have the same syntax, etc. Michael's suggestion for this specific use case seems to be the best solution for now. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8619) Enhancement request: Nested group support using dynlist recursion
by Christ.Klinge＠web.de 20 Mar '17

20 Mar '17

<html><head></head><body><div style="font-family: Verdana;font-size: 12.0px;"><div>I have encountered some scepticism regarding the benefits of nesting within OpenLDAP itself. Some have argued, that applications should resolve nested groups or that nested groups should be created using automation instead. Here, I'd like to respond to these two objections.</div> <div> </div> <div>1. applications should be responsible resolve nested groups</div> <div>First, I disagree from a philosophical point of view. The identity management system and thus the user directory is the central point of knowledge regarding group membership. For the sake of maintainability, all of the information as to why any given user is member of any of its groups, should be present at this central location. Whether a user is a direct member of a group or whether he is member of a sub-group, may interest applications, but what matters most, is that the user is in fact part of both the sub-group and all of its ancestors.</div> <div> </div> <div>Secondly, some applications simply don't have nested group support. It is a fairly common feature, but it just isn't part of every piece of software out there. Implementing nesting in the directory removes the need for support on the application side entirely. In the (from my curent point of view unlikely) event that some application demands to resolve nesting itself, aliasing can be used to deactivate dynlist for the given application.</div> <div> </div> <div>2. automation instead of nesting</div> <div>Automation comes with two caveats which I would like to address individually:</div> <div> </div> <div> <div>2.a additional software</div> <div>This may come as a no brainer for most, but I'd like to point out that automation requires some form of additional software, be it diy scripts or an application. This increases complexity both due to operation of this software and its interaction with the user directory.</div> <div> </div> </div> <div>2.b divergent center of information</div> <div>Instead of maintaining nesting information within the user directory, the software used most likely stores its data outside of the directory. Worst case, it is hardcoded into some scripts. Thus, the information as to which groups are related is likely stored outside of the actual directory itself. This point may be void if the automation system stores nesting information on the group objects inside of the user directory.<br/>  </div> <div>Sincerely,</div> <div>Christopher Klinge</div></div></body></html>

1 0

(ITS#8578)
by sca+openldap＠andreasschulze.de 19 Mar '17

19 Mar '17

Am 01.02.2017 um 23:04 schrieb openldap-its(a)OpenLDAP.org: > If you need to provide additional information in regards to your > issue report, you may do so by replying to this message. the patch I provided 20170201 remove variables that are unused as long as "configure --disable-rewrite" was given. Now I enabled rewrite and build fail :-/ server/slapd/syncrepl.c define variables named 'bv2' that are used if rewrite is enabled and unused otherwise. Maybe the definition of 'REWRITE_DN' ( server/slapd/syncrepl.c, ~line 1726 ) could declare bv2 as unused to avoid a compiler warning. uploaded a new version: ftp://ftp.openldap.org/incoming/andreas-schulze-its8578-20170319.patch Andreas

1 0

Re: (ITS#8621) Unique through multiple attribute
by michael＠stroeder.com 19 Mar '17

19 Mar '17

tatarenko(a)alpha-it.ru wrote: > When use Unique overlay it is not possible to prevent users from inserting value > in attributeA (like otherMailbox) that is already was used in attributeB (like > mail) through whole domain. > If i put multiple attributes to Unique overlay it still search through one > attribute. > If i use > olcUniqueURI: ldap:///dc=instatsport,dc=com?mail,otherMailbox,proxyAddresses?sub > Unique overlay still make this search for mail: > unique_search (|(mail=123(a)example.com)) > And this search for otherMailbox > unique_search (|(otherMailbox=123(a)example.com)) I'd say it works as designed and there is no bug. The work-around for your use-case is to use SUP to derive from a common attribute type. But this should be discussed on openldap-technical mailing list. Ciao, Michael.

1 0

(ITS#8621) Unique through multiple attribute
by tatarenko＠alpha-it.ru 18 Mar '17

18 Mar '17

Full_Name: Tatarenko Vasily Version: 2.4.44 OS: Freebsd 11.0 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (128.74.103.57) When use Unique overlay it is not possible to prevent users from inserting value in attributeA (like otherMailbox) that is already was used in attributeB (like mail) through whole domain. If i put multiple attributes to Unique overlay it still search through one attribute. If i use olcUniqueURI: ldap:///dc=instatsport,dc=com?mail,otherMailbox,proxyAddresses?sub Unique overlay still make this search for mail: unique_search (|(mail=123(a)example.com)) And this search for otherMailbox unique_search (|(otherMailbox=123(a)example.com))

1 0

Re: (ITS#8620) GCC error undeclared PTHREAD_MUTEX_ROBUST
by blissend＠gmail.com 18 Mar '17

18 Mar '17

--94eb2c184874dd3bec054af90cab Content-Type: text/plain; charset=UTF-8 Ahah, it compiles if you remove lines 277-279 which was... #if defined(MDB_OWNERDEAD) && (MDB_USE_ROBUST) #define MDB_ROBUST_SUPPORTED 1 #endif However, I'm not sure that's what one should do. --94eb2c184874dd3bec054af90cab Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">Ahah, it compiles if you remove lines 277-279 which was...= <div><br></div><div><div>#if defined(MDB_OWNERDEAD) && (MDB_USE_ROB= UST)</div><div>#define MDB_ROBUST_SUPPORTED<span class=3D"gmail-Apple-tab-s= pan" style=3D"white-space:pre"> </span>1</div><div>#endif</div></div><div><= br></div><div>However, I'm not sure that's what one should do.</div= ></div> --94eb2c184874dd3bec054af90cab--

1 0

(ITS#8620) GCC error undeclared PTHREAD_MUTEX_ROBUST
by blissend＠gmail.com 18 Mar '17

18 Mar '17

Full_Name: Adam Carlin Version: lmdb 0.9.20 OS: Windows 10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (108.27.217.230) I'm using Windows 10 with msys2 64bit (http://www.msys2.org/) which utilizes mingw-w64. When I compile lmdb (https://github.com/LMDB/lmdb/tree/mdb.RE/0.9) v0.9.20 it spits out the error message below... blissend@shockedloris MSYS /c/Compile/lmdb/libraries/liblmdb $ make gcc -pthread -O2 -g -W -Wall -Wno-unused-parameter -Wbad-function-cast -Wuninitialized -c mdb.c mdb.c: In function mdb_env_setup_locks: mdb.c:4853:17: warning: implicit declaration of function pthread_mutexattr_setrobust [-Wimplicit-function-declaration] if (!rc) rc = pthread_mutexattr_setrobust(&mattr, PTHREAD_MUTEX_ROBUST); ^~~~~~~~~~~~~~~~~~~~~~~~~~~ mdb.c:4853:53: error: PTHREAD_MUTEX_ROBUST undeclared (first use in this function) if (!rc) rc = pthread_mutexattr_setrobust(&mattr, PTHREAD_MUTEX_ROBUST); ^~~~~~~~~~~~~~~~~~~~ mdb.c:4853:53: note: each undeclared identifier is reported only once for each function it appears in mdb.c: In function mdb_mutex_failed: mdb.c:362:37: warning: implicit declaration of function pthread_mutex_consistent [-Wimplicit-function-declaration] #define mdb_mutex_consistent(mutex) pthread_mutex_consistent(mutex) ^ mdb.c:10220:10: note: in expansion of macro mdb_mutex_consistent rc2 = mdb_mutex_consistent(mutex); ^~~~~~~~~~~~~~~~~~~~ make: *** [Makefile:83: mdb.o] Error 1 Anyway to fix this? If this helps, I've noticed that line 4853 for above error has an if check for MDB_ROBUST_SUPPORTED which gets defined on line 278. However the missing declaration of pthread_mutexattr_setrobust is in another if check above line 278.

1 0

Re: (ITS#8506) Authentication issue in ldap client machine after successfully integrating ldap in freenas OS
by quanah＠symas.com 18 Mar '17

18 Mar '17

Hello, There is no evidence of a bug with OpenLDAP based on your report. The OpenLDAP ITS is for bug reports. Usage/configuration questions such as this report should be directed to the OpenLDAP Technical mailing list. <http://www.openldap.org/lists/mm/listinfo/openldap-technical> This ITS will be closed. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

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