openldap-bugs June 2016

openldap-bugs@openldap.org

29 participants
73 discussions

Re: (ITS#8445) LibreSSL v2.4 compile
by hyc＠symas.com 19 Jun '16

19 Jun '16

cpaynetaffe(a)gmail.com wrote: > Full_Name: Connor Taffe > Version: master > OS: Ubuntu devel > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (50.25.160.41) > > > Compiling against LibreSSL v2.4.1 failed linking with SSL_CTX_up_ref and > X509_NAME_get0_der undefined. I added checking if LIBRESSL_VERSION_NUMBER to the > same conditional compilation ifs that are defined for old versions of OpenSSL. > > https://github.com/cptaffe/openldap Please read the Developer Guidelines. I'm not going to pull an arbitrary repo to find someone's patch. http://www.openldap.org/devel/contributing.html -- -- 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#8445) LibreSSL v2.4 compile
by cpaynetaffe＠gmail.com 19 Jun '16

19 Jun '16

Full_Name: Connor Taffe Version: master OS: Ubuntu devel URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (50.25.160.41) Compiling against LibreSSL v2.4.1 failed linking with SSL_CTX_up_ref and X509_NAME_get0_der undefined. I added checking if LIBRESSL_VERSION_NUMBER to the same conditional compilation ifs that are defined for old versions of OpenSSL. https://github.com/cptaffe/openldap

1 0

Re: (ITS#8434) Config entry cleanup on Add should be run unconditionally
by ondra＠mistotebe.net 18 Jun '16

18 Jun '16

On Wed, Jun 08, 2016 at 10:15:13PM +0000, hyc(a)symas.com wrote: > okuznik(a)symas.com wrote: >> With cn=config the ConfigLDAPadd function might have to allocate resources that >> are needed by the time the attributes/config directives are being processed >> since there is no indication which directives there are and what order they come >> in. > > When using LDAPAdd, attributes are processed in the order of their schema > definitions. > >> If any of the config values fail validation, the configuration code has to react >> and clean up - which is possible using ca->cleanup. > > No, that's not its purpose. If anything fails, the entire config entry must be > wiped out. LDAPAdd is all-or-nothing. Yes, but the resource usually has to be allocated before the any of the attributes are processed. In case of failure, the overlay does not have a chance to react and free it since it has no idea when the reversal of all of the attributes has finished.

1 0

(ITS#8444) Out-of-sync issue with memberOf overlay, Delta-syncrepl MMR and >2 nodes
by Mark.Cairney＠ed.ac.uk 16 Jun '16

16 Jun '16

Full_Name: Mark Cairney Version: 2.4.44 (git_master) OS: Centos 6 x86_64 URL: http://homepages.ed.ac.uk/mcairney/delta-mmr-memberof.tar.gz Submission from: (NULL) (129.215.201.136) Hi, I think I've identified an issue where if you have more than 2 OpenLDAP servers set up in MMR using delta-syncrepl and push-based replication (refreshAndPersist) and the memberOf overlay. If you add/delete objects which are maintained by the memberOf overlay i.e. users and groups delta-syncrepl goes out-of-sync and triggers a SYNC_ID_SET refresh on the consumers. It looks like it receives the same change from all other nodes. This behaviour doesn't appear to happen when using pull-based replication with delta-syncrepl or standard syncrepl (push and pull-based). To confirm this behaviour I removed the memberOf overlay from the config, dumped the database, removed any "memberOf" attributes and put the database back in place (slapcat/slapadd on both cn=config and my main DB) on all 3 nodes. Without the memberof overlay loaded sync behaved normally on all 3 nodes. In the tarball I've included a sanitised copy of my config (Schema, ACLs, password hashes, indices for non-standard attributes, operational attributes all removed), a log entry showing deletion of an object not managed by memberOf (a netgroup entry), and log entries showing what happens when a group is deleted both with and without the memberOf overlay. The 3 servers are identical in both config and hardware spec apart from the olcSASLHost. They are Sun X4150's with 24GB RAM, 10KRPM HDDs in 2 pairs of RAID-1 and 2x4 CPU cores (Xeon E5540 @2.53GHz).

1 0

Re: (ITS#8443) segfault in lmdb following mdb_env_set_mapsize
by gdochev＠gmail.com 14 Jun '16

14 Jun '16

Confirmed that this fixes the issue. Thanks for the quick response.

1 0

Re: (ITS#8443) segfault in lmdb following mdb_env_set_mapsize
by hyc＠symas.com 13 Jun '16

13 Jun '16

gdochev(a)yahoo.com wrote: > Full_Name: George Dochev > Version: > OS: Windows/OSX/Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2601:582:4500:e134:1d59:965c:aecc:5697) > > > I updated from 0.9.15 to 0.9.18 and started getting intermittent segfaults in > one of my unit tests. In my test when I issue mdb_txn_commit and get back > MDB_MAP_FULL I abort the transaction, You've misused the API. The txn has already been released by txn_commit, you cannot call abort on it at that point. This was already clearly spelled out in the docs for mdb_txn_commit. Closing this ITS. expand the database through a call to > mdb_env_set_mapsize and attempt a retry. In the retry I issue mdb_txn_begin > again which is where I crash when it calls mdb_txn_renew0(MDB_txn *txn) with txn > pointing to garbage. > > Some additional info which may or may not be relevant: > > The db size is 1MB aligned and there are no active transactions prior to the > call to mdb_env_set_mapsize other than the one that I aborted as a result of the > MDB_MAP_FULL. > The environment was initially opened with MDB_NOSYNC | MDB_WRITEMAP | > MDB_NOMETASYNC | MDB_NOTLS. > > The crash is intermittent but reproducible in all my configurations. > > Regards, > George > > -- -- 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#8443) segfault in lmdb following mdb_env_set_mapsize
by gdochev＠gmail.com 13 Jun '16

13 Jun '16

It seems that env->me_txn0 is a cached write transaction, which = shouldn't be deleted, yet I see that the mdb_txn_abort calls mdb_txn_end = which before the crash frees env->me_txn0.=

1 0

(ITS#8443) segfault in lmdb following mdb_env_set_mapsize
by gdochev＠yahoo.com 13 Jun '16

13 Jun '16

Full_Name: George Dochev Version: OS: Windows/OSX/Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2601:582:4500:e134:1d59:965c:aecc:5697) I updated from 0.9.15 to 0.9.18 and started getting intermittent segfaults in one of my unit tests. In my test when I issue mdb_txn_commit and get back MDB_MAP_FULL I abort the transaction, expand the database through a call to mdb_env_set_mapsize and attempt a retry. In the retry I issue mdb_txn_begin again which is where I crash when it calls mdb_txn_renew0(MDB_txn *txn) with txn pointing to garbage. Some additional info which may or may not be relevant: The db size is 1MB aligned and there are no active transactions prior to the call to mdb_env_set_mapsize other than the one that I aborted as a result of the MDB_MAP_FULL. The environment was initially opened with MDB_NOSYNC | MDB_WRITEMAP | MDB_NOMETASYNC | MDB_NOTLS. The crash is intermittent but reproducible in all my configurations. Regards, George

1 0

(ITS#8442) Uninitialized diagnosticMessage in back-meta
by h.b.furuseth＠usit.uio.no 12 Jun '16

12 Jun '16

Full_Name: Hallvard B Furuseth Version: 2.4.41 and later OS: URL: Submission from: (NULL) (81.191.45.31) Submitted by: hallvard meta_back_search() does a goto past const char *save_text = rs->sr_text; which is later "restored" to rs->sr_text. Fixing.

1 0

(ITS#8441) MDB is missing in teh list of possible config for proxy-cache in the admin guide
by elecharny＠apache.org 10 Jun '16

10 Jun '16

Full_Name: Emmanuel L.charny Version: 2.4.44 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (83.35.197.172) The current Administrative Guide says : "The <DB> parameter specifies which underlying database is to be used to hold cached entries. It should be set to bdb or hdb" (12.9.2.1) 'mdb' should at least be listed here.

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs June 2016