openldap-bugs

openldap-bugs@openldap.org

1 participants
21065 discussions

(ITS#7706) RFE: contrib/slapo-lastbind extension
by marco.pizzoli＠gmail.com 24 Sep '13

24 Sep '13

Full_Name: Marco Pizzoli Version: until 2.4.36 OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (194.11.209.11) This is another RFE for slapo-lastbind I would appreciate being able to prevent some users from having their entry updated/populated with the authTimestamp attribute. I suppose this could be implemented with just the check of a specific attribute (i.e. authTimestampLogging: FALSE) on the user entry. Thanks in advance as usual

1 0

Re: (ITS#7705) mdb back-end segfaults sporadically with paged searches
by hyc＠symas.com 23 Sep '13

23 Sep '13

openldap(a)semyon.org wrote: > Full_Name: Semyon Chaichenets > Version: 2.4.36 > OS: Linux 3.2.0-51-generic #77-Ubuntu SMP Wed Jul 24 20:18:19 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (129.128.11.113) > > > We have an issue whereby a paged-search operation causes slapd to segfault. At > this point, I can only reproduce the issue on our production data - for which I > cannot share coredumps. I am working on isolating the issue but would appreciate > any help from openLDAP developers. > > The issue is triggered by the following search: > > ldapsearch -H ldap://ldaphost -b 'ou=people,dc=our,dc=org' -x -E pr=126/noprompt > '(uid=m*)' > > We have ~59k entries starting matching uid=m*; the issue occurs unpredictably in > the sense that it may or may not happen for filters matching other sets, but it > can be reproduced reliably for any given filter/page size combination. On our > setup, I could reproduce it for page-sizes 81,84,87,96,112,114,116,126. > > The issue is specific to back-mdb; backtrace points to dn2id.c: > > #0 0x00007f6d6a5ea6a1 in mdb_idscopes (op=0x7f695c110df0, isc=0x7f69692ca670) > at ../../../../../servers/slapd/back-mdb/dn2id.c:738 > #1 0x00007f6d6a5e399b in mdb_search (op=0x7f695c110df0, rs=0x7f69692dba00) > at ../../../../../servers/slapd/back-mdb/search.c:747 > > [..] > > I would greatly appreciate any help you could give me with this problem. If you backup the DB with slapcat and reload it on another server with slapadd, can you still reproduce the fault on the copy? > > > Best, > Semyon > > -- -- 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#7705) mdb back-end segfaults sporadically with paged searches
by quanah＠zimbra.com 23 Sep '13

23 Sep '13

--On Monday, September 23, 2013 10:09 PM +0000 openldap(a)semyon.org wrote: > Full_Name: Semyon Chaichenets > Version: 2.4.36 > OS: Linux 3.2.0-51-generic #77-Ubuntu SMP Wed Jul 24 20:18:19 UTC 2013 > x86_64 x86_64 x86_64 GNU/Linux URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (129.128.11.113) > > > We have an issue whereby a paged-search operation causes slapd to > segfault. At this point, I can only reproduce the issue on our production > data - for which I cannot share coredumps. I am working on isolating the > issue but would appreciate any help from openLDAP developers. Was this database created with OpenLDAP 2.4.36 back-mdb, or did it originate with a previous release of OpenLDAP? --Quanah -- Quanah Gibson-Mount Lead Engineer Zimbra Software, LLC -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7705) mdb back-end segfaults sporadically with paged searches
by openldap＠semyon.org 23 Sep '13

23 Sep '13

Full_Name: Semyon Chaichenets Version: 2.4.36 OS: Linux 3.2.0-51-generic #77-Ubuntu SMP Wed Jul 24 20:18:19 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (129.128.11.113) We have an issue whereby a paged-search operation causes slapd to segfault. At this point, I can only reproduce the issue on our production data - for which I cannot share coredumps. I am working on isolating the issue but would appreciate any help from openLDAP developers. The issue is triggered by the following search: ldapsearch -H ldap://ldaphost -b 'ou=people,dc=our,dc=org' -x -E pr=126/noprompt '(uid=m*)' We have ~59k entries starting matching uid=m*; the issue occurs unpredictably in the sense that it may or may not happen for filters matching other sets, but it can be reproduced reliably for any given filter/page size combination. On our setup, I could reproduce it for page-sizes 81,84,87,96,112,114,116,126. The issue is specific to back-mdb; backtrace points to dn2id.c: #0 0x00007f6d6a5ea6a1 in mdb_idscopes (op=0x7f695c110df0, isc=0x7f69692ca670) at ../../../../../servers/slapd/back-mdb/dn2id.c:738 #1 0x00007f6d6a5e399b in mdb_search (op=0x7f695c110df0, rs=0x7f69692dba00) at ../../../../../servers/slapd/back-mdb/search.c:747 [..] I would greatly appreciate any help you could give me with this problem. Best, Semyon

1 0

Re: (ITS#7704) OpenLDAP-Max connection retry over issue
by quanah＠zimbra.com 23 Sep '13

23 Sep '13

--On Monday, September 23, 2013 7:37 AM +0000 saurabh.4091(a)gmail.com wrote: > Full_Name: Saurabh Sudhir Bade > Version: 0.9.8a > OS: Windows server 2003 > URL: > Submission from: (NULL) (213.42.50.245) > > > Hi, > > We are using OpenLDAP to authenticate users accessing our web service. > The LDAP is configured in TIBCO Activematrix Administrator where the > services are deployed. > We get the below mentioned error quite frequently. > Error in authenticating credentials.Ldap Max connection retry over (3): > localhost:9430: Connection refused: connect > This happens because the connection pool is full and a new connection to > LDAP is unavailable . > Is there any way to increase the connection pool in LDAP? Please help me > out. Please let me know if you need any further information on this issue. Usage and configuration questions should be sent to the openldap-technical(a)openldap.org email list. The ITS system is for reporting bugs. This ITS will be closed. --Quanah -- Quanah Gibson-Mount Lead Engineer Zimbra Software, LLC -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7704) OpenLDAP-Max connection retry over issue
by saurabh.4091＠gmail.com 23 Sep '13

23 Sep '13

Full_Name: Saurabh Sudhir Bade Version: 0.9.8a OS: Windows server 2003 URL: Submission from: (NULL) (213.42.50.245) Hi, We are using OpenLDAP to authenticate users accessing our web service. The LDAP is configured in TIBCO Activematrix Administrator where the services are deployed. We get the below mentioned error quite frequently. Error in authenticating credentials.Ldap Max connection retry over (3): localhost:9430: Connection refused: connect This happens because the connection pool is full and a new connection to LDAP is unavailable . Is there any way to increase the connection pool in LDAP? Please help me out. Please let me know if you need any further information on this issue. Thanks Regards Saurabh

1 0

Re: (ITS#7703) mdb sync() issues vs. ACID
by hyc＠symas.com 21 Sep '13

21 Sep '13

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: LMDB_0.9.8 > OS: > URL: > Submission from: (NULL) (81.191.45.35) > Submitted by: hallvard > > > mdb_env_sync() uses the wrong sync method when syncing a commit > written with a different MDB_WRITEMAP setting in another MDB_env. > > Two processes with MDB_NOMETASYNC, each process doing every 2nd > write txn, will sync each other's meta pages. If they have > different MDB_WRITEMAPs, every meta page gets synced wrongly. > This breaks durability of ACID. Sounds like a doc issue. This can only arise if two separate processes are using different configurations to access the same MDB environment. Most applications will always use identical configurations to access their databases, so this won't occur. > There is a similar problem if a process crashes after writing > the meta page but before sync succeeds, and mdb_env_open() then > resets the lockfile to refer to the unsynced commit. Robust > mutexes will introduce a similar problem without mdb_env_open. > > > I'm not volunteering to figure out how to do this right, e.g. how > do fsync/msync/FlushFileBuffers work on various OSes if the file > descriptor or memory map is read-only, do we need to set a "need > to sync" flag in the lockfile in this case for the first writer > or write txn to obey? > > Another fix: Disable this scenario. Store the MDB_WRITEMAP > setting in the lockfile when resetting it, even with MDB_RDONLY. > Obey that flag rather than the writemap flag to mdb_env_open() > when not resetting the lockfile. However, now a small program > like mdb_stat can have disproportionate effect on another process > which opens the env at the same time. Also nested txns need to > work with MDB_WRITEMAP. > > > For the crash case above and robust mutexes: > > Maybe mdb_env_open() should not modify me_txns->mti_txnid if it > refers to the oldest meta page. That way the possibly unsynced > commit will never be exposed unless the lockfile is removed. > But next write txn must then reset the "hidden" metapage and sync > before proceeding, similar to how mdb_env_write_meta() does at > failure. Otherwise removing the lockfile would expose a meta > page referring to data which may have been overwritten, e.g. by > an mdb_abort()ed commit. > > Another variant would be to sync in mdb_env_open() when resetting > the lockfile, or maybe an MDB_RDONLY env must set a "sync needed" > flag. Nothing to fix in code. Doc this as "don't do this." Nobody currently does it anyway so it will have no impact. -- -- 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#7703) mdb sync() issues vs. ACID
by h.b.furuseth＠usit.uio.no 21 Sep '13

21 Sep '13

Full_Name: Hallvard B Furuseth Version: LMDB_0.9.8 OS: URL: Submission from: (NULL) (81.191.45.35) Submitted by: hallvard mdb_env_sync() uses the wrong sync method when syncing a commit written with a different MDB_WRITEMAP setting in another MDB_env. Two processes with MDB_NOMETASYNC, each process doing every 2nd write txn, will sync each other's meta pages. If they have different MDB_WRITEMAPs, every meta page gets synced wrongly. This breaks durability of ACID. There is a similar problem if a process crashes after writing the meta page but before sync succeeds, and mdb_env_open() then resets the lockfile to refer to the unsynced commit. Robust mutexes will introduce a similar problem without mdb_env_open. I'm not volunteering to figure out how to do this right, e.g. how do fsync/msync/FlushFileBuffers work on various OSes if the file descriptor or memory map is read-only, do we need to set a "need to sync" flag in the lockfile in this case for the first writer or write txn to obey? Another fix: Disable this scenario. Store the MDB_WRITEMAP setting in the lockfile when resetting it, even with MDB_RDONLY. Obey that flag rather than the writemap flag to mdb_env_open() when not resetting the lockfile. However, now a small program like mdb_stat can have disproportionate effect on another process which opens the env at the same time. Also nested txns need to work with MDB_WRITEMAP. For the crash case above and robust mutexes: Maybe mdb_env_open() should not modify me_txns->mti_txnid if it refers to the oldest meta page. That way the possibly unsynced commit will never be exposed unless the lockfile is removed. But next write txn must then reset the "hidden" metapage and sync before proceeding, similar to how mdb_env_write_meta() does at failure. Otherwise removing the lockfile would expose a meta page referring to data which may have been overwritten, e.g. by an mdb_abort()ed commit. Another variant would be to sync in mdb_env_open() when resetting the lockfile, or maybe an MDB_RDONLY env must set a "sync needed" flag.

1 0

(ITS#7702) hdb and mdb derefere aliases differently
by julien.combes＠i-carre.net 20 Sep '13

20 Sep '13

Full_Name: Julien COMBES Version: 2.4.36 OS: debian squeeze URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.23.175.188) Hello, With openldap 2.4.36, i found a case where the aliases are deref differently between hdb and mdb. A search with deref aliases on an attribut not indexed (or on "*"), mdb backend returns the entry twice where hdb backend returns the entry once. For example : With a directory like that : --------------------------------------------------------------------- dn: dc=test,dc=com objectClass: top objectClass: dcObject objectClass: organization dc: test o: test dn: ou=a,dc=test,dc=com objectClass: top objectClass: organizationalUnit ou: a dn: ou=b,ou=a,dc=test,dc=com objectClass: top objectClass: organizationalUnit ou: b dn: ou=c,ou=a,dc=test,dc=com objectClass: top objectClass: organizationalUnit ou: c dn: cn=foo,ou=b,ou=a,dc=test,dc=com objectClass: top objectClass: person cn: foo sn: foo dn: cn=bar,ou=c,ou=a,dc=test,dc=com objectClass: top objectClass: alias objectClass: extensibleObject aliasedObjectName: cn=foo,ou=b,ou=a,dc=test,dc=com cn: bar --------------------------------------------------------------------- I have that kind of result : -> Search on mdb, cn not indexed : $ ldapsearch -x -LLL -b "ou=a,dc=test,dc=com" cn=foo dn -a always dn: cn=foo,ou=b,ou=a,dc=test,dc=com dn: cn=foo,ou=b,ou=a,dc=test,dc=com $ ldapsearch -x -LLL -b "ou=a,dc=test,dc=com" cn=* dn -a always dn: cn=foo,ou=b,ou=a,dc=test,dc=com dn: cn=foo,ou=b,ou=a,dc=test,dc=com -> Search on mdb, cn indexed eq,sub : $ ldapsearch -x -LLL -b "ou=a,dc=test,dc=com" cn=foo dn -a always dn: cn=foo,ou=b,ou=a,dc=test,dc=com $ ldapsearch -x -LLL -b "ou=a,dc=test,dc=com" cn=* dn -a always dn: cn=foo,ou=b,ou=a,dc=test,dc=com dn: cn=foo,ou=b,ou=a,dc=test,dc=com -> Search on hdb, cn not indexed : $ ldapsearch -x -LLL -b "ou=a,dc=test,dc=com" cn=foo dn -a always dn: cn=foo,ou=b,ou=a,dc=test,dc=com $ ldapsearch -x -LLL -b "ou=a,dc=test,dc=com" cn=* dn -a always dn: cn=foo,ou=b,ou=a,dc=test,dc=com -> Search on hdb $ ldapsearch -x -LLL -b "ou=a,dc=test,dc=com" cn=foo dn -a always dn: cn=foo,ou=b,ou=a,dc=test,dc=commits $ ldapsearch -x -LLL -b "ou=a,dc=test,dc=com" cn=* dn -a always dn: cn=foo,ou=b,ou=a,dc=test,dc=com Regards, Julien COMBES P.S: I have first posted this message as a comment in ITS7577 the 25 Jul 2013. But as the ITS7577 is tagged closed and has no answers since this date, I decide to repost as a new report.

1 0

(ITS#7701) Deletion triggers SEGV on next access of existing cursor
by dw＠botanicus.net 19 Sep '13

19 Sep '13

Full_Name: David Wilson Version: 919a0f5b54dad3acf2f84e7993bb00e7aa098037 OS: Linux URL: http://www.h1.botanicus.net/20130919-lmdb.trace.bz2 Submission from: (NULL) (178.238.153.20) In some circumstances LMDB will segfault in mdb_cursor_get() on a cursor that existed prior to a deletion that just occurred. It is apparently related to the page the cursor points to becoming mutated by the deletion. In LMDB 0.9.8, the issue may manifest as a NULL ptr dereference: #0 mdb_xcursor_init1 (mc=mc@entry=0x1013da0, node=node@entry=0x7ffd76031ac2) at lib/mdb.c:6525 #1 0x00007ffff5209b73 in mdb_cursor_next (mc=0x1013da0, key=0xce39a0, data=data@entry=0xce3660, op=<optimized out>) at lib/mdb.c:5042 #2 0x00007ffff5208a6e in mdb_cursor_get (mc=0x1013da0, key=0xce39a0, data=0xce3660, op=op@entry=MDB_NEXT) at lib/mdb.c:5526 #3 0x00007ffff5202a83 in _cffi_f_mdb_cursor_get (self=<optimized out>, args=<optimized out>) at lmdb/__pycache__/lmdb_cffi.c:714 #4 0x0000000000471a8b in call_function (oparg=<optimized out>, pp_stack=0x7fffffffcf30) at ../Python/ceval.c:4021 #5 PyEval_EvalFrameEx ( Due to F_DUPDATA bit being set as tested on line 5041. Examining the leaf structure reveals a large chunk of ASCII text (which should have been written to the DB), interspersed with some integer values. Versions of LMDB <= 0.9.7 exhibit similar crashes, although in a different place: "assert(mc)" at the start of mdb_cursor_get(). Various MDB versions going back 6 months were tested, and none exhibited any better behaviour. In the attached trace/replay, version c0575825730dd2aab4031100b25d632a3d052447 from April exhibited the bug after only 1993 operations executed from the trace file. Any more recent version requires the entire trace file to execute before triggering the assert or SEGV. http://www.h1.botanicus.net/20130919-lmdb.trace.bz2 is a 33MiB trace file that can be loaded and executed using https://github.com/dw/acid/blob/master/misc/lmdb-replay.c The apparent workaround is to reinitialize any existing cursors should a deletion occur within a transaction, as demonstrated in https://github.com/dw/acid/commit/56f183c71a668e540df58d5137e946616a446c49

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