openldap-bugs

openldap-bugs@openldap.org

1 participants
21065 discussions

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

Re: (ITS#8437) openldap-2.4.44 slapd.conf: back-sql database parameters, only first character
by piero.astolfi＠gmx.com 10 Jun '16

10 Jun '16

Switching from iodbc to unixodbc solved my issue.

1 0

Re: (ITS#8432) Never ending operation modifications with 3+ MMR nodes
by hyc＠symas.com 09 Jun '16

09 Jun '16

quanah(a)zimbra.com wrote: > --On Thursday, June 09, 2016 1:19 AM +0100 Howard Chu <hyc(a)symas.com> wrote: > >> quanah(a)openldap.org wrote: >>> Full_Name: Quanah Gibson-Mount >>> Version: 2.4.44 >>> OS: Linux 2.6 >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (75.111.52.177) >>> >>> >>> In MMR node, when there is > 2 nodes, operations can get sent out >>> endlessly. >>> >>> For example, we see this modification occur at 20160603194926.427963Z >> >> You seem to have a large clock sync problem. Summary: after fixing the clock skew, the problem was still present. Analyzing debug logs with sync+stats+packets, we see that the offending mods were propagated by syncprov without a CSN in the sync cookie. Since the cookie contained no CSN, the existing check for "CSN too old, ignoring" was not taking place, so the mods were not being filtered out as they should be. syncprov sends mods out without a CSN in the cookie when the mod's CSN is older than the newest contextCSN. In this particular case, between the time that the provider processed the original mod, and the time it was queued up to be sent to the relevant consumers, this server's own consumers had received newer updates from other providers. So, the mod was older than the current contextCSN and was sent without a cookie CSN. (The usual case for syncprov's behavior is when queued mods get sent out of order; since transmission order is not guaranteed to be the same as write/commit order this is a normal occurrence.) It's possible that regular syncrepl+mmr needs a corresponding fix. I haven't looked at that yet. -- -- 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