openldap-bugs

openldap-bugs@openldap.org

1 participants
20963 discussions

Start a nNew thread

Re: (ITS#7577) hdb and mdb derefere aliases differently
by Juergen.Sprenger＠swisscom.com 17 May '13

17 May '13

tried the fix fb537d747c6fd43e08986e99b1fe7781660feaf3 but behavior did not change. Juergen Sprenger

1 0

(ITS#7593) Openldap - MySQL | Issue with displaying list of users from same domain
by sandeeps＠rediff-inc.com 15 May '13

15 May '13

Full_Name: Sandeep Singh Version: openldap-2.4.35 OS: CentOS Linux release 6.0 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (202.137.232.113) Hello, We have configured an openldap server with mysql as the backend. It is working fine as well. We have a scenario where we feel it is not behaving the way it is required. We have multiple domains say:- 1) abc.com 2) xyz.com Have mapped user as:- 1) mail=man1(a)red.com,dc=abc,dc=com with password=man1r 2) mail=man2(a)red.com,dc=abc,dc=com with password=man2r 3) mail=man1(a)sad.com,dc=xyz,dc=com with password=man1s 4) mail=man2(a)sad.com,dc=xyz,dc=com with password=man2s When we search for result using:- ldapsearch -x -D "mail=man1(a)red.com,dc=abc,dc=com" -W -b "dc=abc,dc=com" It gives us output / result shown is of domains abc.com i.e. mail=man1(a)red.com,dc=abc,dc=com & mail=man1@red.com,dc=abc,dc=com Which is correct But when we search for results using:- ldapsearch -x -D "mail=man1(a)red.com,dc=abc,dc=com" -W -b "dc=xyz,dc=com" Then the output / result shown is of domain xyz.com i.e. mail=man1(a)sad.com,dc=xyz,dc=com & mail=man2@sad.com,dc=xyz,dc=com because the base search is dc=xyz,dc=com Which is not correct as mail=man1(a)red.com,dc=abc,dc=com does not belong to xyz.com domain So we want to authenticate and display user along with the list of other users from the same domain and not from the other domain. Please suggest how to overcome / solve the issue.

1 0

Re: (ITS#7591) back-meta modify operation not sending result to client
by jorge.perez.burgos＠ericsson.com 14 May '13

14 May '13

kludge fix for the problem --- servers/slapd/back-meta/modify.c 2012-07-31 18:39:26.000000000 +0200 +++ servers/slapd/back-meta/modify.c 2013-05-14 12:45:39.273333000 +0200 @@ -176,6 +176,7 @@ } modv[ i ] = 0; + rs->sr_type = -1; retry:; ctrls = op->o_ctrls; rc = meta_back_controls_add( op, rs, mc, candidate, &ctrls ); @@ -198,6 +200,10 @@ } cleanup:; + if (rs->sr_type != REP_RESULT) { + send_ldap_error(op, rs, LDAP_OTHER, "connection problem trying to reach the other node"); + } + (void)mi->mi_ldap_extra->controls_free( op, rs, &ctrls ); if ( mdn.bv_val != op->o_req_dn.bv_val ) {

1 0

(ITS#7592) LMDB corruption
by hyc＠OpenLDAP.org 14 May '13

14 May '13

Full_Name: Howard Chu Version: 2.4.33+ OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (78.155.233.73) Submitted by: hyc Already fixed in mdb.master commit 7233bc295bb3e40b2758158ae2de6f42516962f8 In mdb_page_split, if updating the parent's separator triggers a split in the parent, and the current cursor position happens to point to the split index, the cursor will be left pointing to the old parent page instead of the correct page.

1 0

(ITS#7591) back-meta modify operation not sending result to client
by jorge.perez.burgos＠ericsson.com 14 May '13

14 May '13

Full_Name: Jorge Perez Burgos Version: 2.4.32 OS: SLES 10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (195.235.15.243) Right now when sending bulk traffic trough back-meta and killing the slapds receiving the proxy traffic, it can be seen that a very few modify operations are not receiving the result of the operations, looking at the code it seems the same for the add and delete operation. Basically when ldap_modify_ext returns an errno it seems that is not properly handle afterwards.

1 0

Re: (ITS#7589) MDB nodesize issues
by h.b.furuseth＠usit.uio.no 13 May '13

13 May '13

I wrote: > OTOH if you add a bunch of slightly smaller nodes, mdb will put > most of them in separate pages anyway without MDB_APPEND. ...because mdb_page_split() has been wasteful since 48ef27b6f5c804eca6a9 "ITS#7385 fix mdb_page_split (again)". When a txn put()s ascending keys with nodes of the same size, the new item goes in the fullest page. E.g. put data size 1010 with 'int' keys 1,2,3... to an MDB_INTEGERKEY DB. As the txn progresses, (page: #key #key...) get distributed thus: Page 2: #1. Page 2: #1 #2. Page 2: #1 #2 #3. Page 2: #1. Page 3: #2 #3 #4. Page 2: #1. Page 3: #2. Page 5: #3 #4 #5. Page 2: #1. Page 3: #2. Page 5: #3. Page 6: #4 #5 #6. 2/3 wasted space. Descending put() work better: Page 2: #6. Page 2: #5 #6. Page 2: #4 #5 #6. Page 2: #3 #4. Page 3: #5 #6. Page 2: #2 #3 #4. Page 3: #5 #6. Page 2: #2 #1. Page 3: #5 #6. Page 5: #3 #4. Ascending put() with datasize 1348, so only 2 nodes fit in a page: Page 2: #1. Page 2: #1 #2. Page 2: #1. Page 3: #2 #3. Page 2: #1. Page 3: #2. Page 5: #3 #4. Half of the space is wasted. Descending order does not help. page_split() cannot know which split is best in this case. But it'll help to guess that the next put() key sometimes will be near this one, and ensure that the node with the new key will be the smallest. That will also avoid touching the old page when the nodes are that large, since the "split" will keep all old nodes in the old page. Trying a simpler patch for this one: > Nodes of size MDB_env.me_nodemax-1 do not go in overflow pages, > but are too big for two of them to fit in the same page. (...) Let mdb_env_open2() round me_nodemax down to an odd number: env->me_nodemax = (((env->me_psize - PAGEHDRSZ) / MDB_MINKEYS) - 1) | 1; Then a leaf page with just 1 node can always get another one, since mdb_node_add() will always put too big items in overflow pages. In a DB newer than this patch, anyway... Maybe mdb_cursor_put() should use the value from before 'offset += offset & 1;' in next line's compare with me_nodemax: @@ -5128,5 +5128,6 @@ } + i = offset; offset += offset & 1; if (NODESIZE + sizeof(indx_t) + NODEKSZ(leaf) + NODEDSZ(leaf) + - offset >= mc->mc_txn->mt_env->me_nodemax) { + i >= mc->mc_txn->mt_env->me_nodemax) { /* yes, convert it */ This passes 'make test', with or without changing cursor_put(). But I still don't quite know what I'm doing - otherwise my LEAFSIZE patch would have worked too. -- Hallvard

1 0

(ITS#7590) admin24 incorrectly says "back-bdb" is recommended
by quanah＠OpenLDAP.org 13 May '13

13 May '13

Full_Name: Quanah Gibson-Mount Version: 2.4.35 OS: linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.58.125) H3: Overview The {{bdb}} backend to {{slapd}}(8) is the recommended primary backend for a normal {{slapd}} database. Which stopped being true with OpenLDAP 2.3 IIRC, which is when back-hdb was made the recommended backend.

1 0

Re: (ITS#7588) SSSVLV can cause segmentation fault
by hyc＠symas.com 13 May '13

13 May '13

kevinanties(a)gmail.com wrote: > Full_Name: kevin > Version: 2.4.35 > OS: ubuntu > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (202.64.130.126) > > > The problem is due to double free pointers in send_page() and free_sort_op() > function. > > In send_page function, some nodes of so_tree have been free by ch_free and > ber_memfree function. If a client suddenly aborts the connection, free_sort_op > function will be called. In free_sort_op function, tavl_free() will be called > and it try to free the nodes of so_tree. Hoverer, some of nodes had already free > before and segmentation resulted. > > A possible solution is to to check whether it is a paged request in free_sort_op > function. If yes, continuous to free the next node of so_tree but not free > previous node. Thanks for the report. The fix is simpler than that, and 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

(ITS#7589) MDB nodesize issues
by h.b.furuseth＠usit.uio.no 10 May '13

10 May '13

Full_Name: Hallvard B Furuseth Version: 2.4.35 OS: Linux x86_64 URL: Submission from: (NULL) (2001:700:100:556::233) Submitted by: hallvard Nodes of size MDB_env.me_nodemax-1 do not go in overflow pages, but are too big for two of them to fit in the same page. Because: - LEAFSIZE() does not round up to a factor of 2. - MDB_env.me_nodemax is described as /** Max size of a node on a page */ (i.e. non-overflow page), but actually it's the minimum node size which mdb_node_add() *will* put in an overflow page. I don't see a reason to treat nodes of size 2k-1 and 2k differently when seen "from the outside", so I think LEAFSIZE should have been #define LEAFSIZE(k, d) ((1 + NODESIZE + (k)->mv_size + (d)->mv_size) & -2) Also mdb_leaf_size(): sz = LEAFSIZE(key, data); if (sz >= env->me_nodemax) sz = (1 + NODESIZE + sizeof(pgno_t) + key->mv_size) & -2; return sz + sizeof(indx_t); and a corresponding fix in mdb_node_add(). Those changes crash test001. I don't know what else would need fixing. Subpage sizes for one thing. OTOH if you add a bunch of slightly smaller nodes, mdb will put most of them in separate pages anyway without MDB_APPEND. To keep down rebalancing when adding nodes in the middle? Or is this another bug? So I don't know if more than the me_nodemax doc a fix. And maybe a rename to something which fits what it does. ...and also the doc of mdb_branch_size(). "Sizes are always rounded up to an even number of bytes, to guarantee 2-byte alignment" happens somewhere, but not in mdb_branch_size() which happily returns uneven sizes. But it works fine since it's only used as SIZELEFT()<mdb_branch_size() where SIZELEFT() does return an even size. Rounding branch_size up would make no difference.

1 0

(ITS#7588) SSSVLV can cause segmentation fault
by kevinanties＠gmail.com 09 May '13

09 May '13

Full_Name: kevin Version: 2.4.35 OS: ubuntu URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (202.64.130.126) The problem is due to double free pointers in send_page() and free_sort_op() function. In send_page function, some nodes of so_tree have been free by ch_free and ber_memfree function. If a client suddenly aborts the connection, free_sort_op function will be called. In free_sort_op function, tavl_free() will be called and it try to free the nodes of so_tree. Hoverer, some of nodes had already free before and segmentation resulted. A possible solution is to to check whether it is a paged request in free_sort_op function. If yes, continuous to free the next node of so_tree but not free previous node.

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