openldap-bugs

openldap-bugs@openldap.org

1 participants
20961 discussions

Re: (ITS#7268) syncrepl issue
by quanah＠zimbra.com 10 May '12

10 May '12

--On Thursday, May 10, 2012 9:41 AM +0000 Nithya.narasimhan(a)hp.com wrote: > Full_Name: Nithya Narasimhan > Version: Symas OpenLDAP version 2.4.26 > OS: RHEL 5.5 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (15.219.201.69) > > > We have configured 2 nodes in an n way multimaster configuration. The ITS system is for reporting bug, not asking usage questions. Please (a) upgrade to the lastest version of OpenLDAP (2.4.31) and (b) direct your questions to the openldap-technical(a)openldap.org discussion list. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7269) [PATCH] Make slapd-sha2 module thread-safe
by fumiyas＠osstech.co.jp 10 May '12

10 May '12

Full_Name: SATOH Fumiyasu Version: master OS: URL: ftp://ftp.openldap.org/incoming/openldap-2.4.31-sha2-multithread.patch Submission from: (NULL) (125.2.180.244) In contrib/slapd-modules/passwd/sha2/slapd-sha2.c:sha*_hex_hash(), a static buffer "static char real_hash[]" is declared and is used by threads, but it is not TLS (Thread Local Storage) and no lock. This patch removes sha*_hex_hash() and replaces chk_sha*() with libraries/liblutil/passwd.c:chk_sha1() implementation to fix this problem.

1 0

(ITS#7268) syncrepl issue
by Nithya.narasimhan＠hp.com 10 May '12

10 May '12

Full_Name: Nithya Narasimhan Version: Symas OpenLDAP version 2.4.26 OS: RHEL 5.5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (15.219.201.69) We have configured 2 nodes in an n way multimaster configuration. Server Definition is configured as follows - Slapd.conf entry in first server serverID 001 ldap://16.181.233.72:1389 serverID 002 ldap://16.181.233.71:1389 Slapd.conf entry in second server serverID 001 ldap://16.181.233.72:1389 serverID 002 ldap://16.181.233.71:1389 Offline replication does not occur.ie:Bring down node1, add entries to node2 which is up.Then bring up the node1 after sometime.In this case the entries added in node2 are not available in node1. However when ServerID is configured as follows in slapd.conf file - Slapd.conf entry in first server serverID 1 Slapd.conf entry in second server serverID 2 offline replication occurs correctly. My Questions are - 1) What is the correct Server Definition for n way multimaster. 2) Is there any other configuration we need to change to make this work? 3) If we are adding LDAP URL to Server Definition , what is the correct format we must use ? 4) If N-way multi-master mode for 2 servers (2-way multi-master Mode), should both nodes information be configured in both servers under syncrepl. Should the syncrepl ID be different in both servers ? Can you share me a sample 2-way multi-master mode setup. 5) Offline data load (Node 1 is up and Node 2 is down Now entries are added in Node 1 and then Node 2 is brought up) How does this synchronization work ? Will it work in Physical server and Virtual Machine as well ? Scenarios of addition/deletion/modification of entries/attributes. 6) What happens if I define an interval even if I have it refreshandpersist type Will it ignore that parameter or does it have any side effects ?

1 0

Re: (ITS#7265) reaching back-mdb database sizelimit can result in corrupt DB
by quanah＠zimbra.com 09 May '12

09 May '12

--On Monday, May 07, 2012 6:05 PM +0000 quanah(a)OpenLDAP.org wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.30+patches > OS: Linux 2.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.108.184.39) > > > With a database maxsize of 1GB, found that when the DB hit 1GB in size, > slapd stopped. After upping the maxsize, the mdb database was unreadable > via ldapsearch. Slapcat also failed to pull any data out of the database. > Appears related to ITS7266, this ITS can be closed. There was a size mismatch between data sizes in slapd & libmdb. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#7267) [PATCH] Make slapd-sha2 portable
by hyc＠symas.com 08 May '12

08 May '12

fumiyas(a)osstech.jp wrote: > Hi, > >> Full_Name: SATOH Fumiyasu >> Version: master >> OS: >> URL: ftp://ftp.openldap.org/incoming/openldap-2.4.31-sha2-portable.patch > > Revised patch: > ftp://ftp.openldap.org/incoming/openldap-2.4.31-sha2-portable-v2.patch > > Sorry. Thanks for the patch. It's always better to preserve comments than to delete them, you should have changed the C++ comments to regular C comments. I'll tweak this and commit. -- -- 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#7267) [PATCH] Make slapd-sha2 portable
by fumiyas＠osstech.jp 08 May '12

08 May '12

Hi, > Full_Name: SATOH Fumiyasu > Version: master > OS: > URL: ftp://ftp.openldap.org/incoming/openldap-2.4.31-sha2-portable.patch Revised patch: ftp://ftp.openldap.org/incoming/openldap-2.4.31-sha2-portable-v2.patch Sorry. > Submission from: (NULL) (125.2.180.244) -- -- Name: SATOH Fumiyasu (fumiyas @ osstech co jp) -- Business Home: http://www.OSSTech.co.jp/ -- Personal Home: https://github.com/fumiyas/

1 0

(ITS#7267) [PATCH] Make slapd-sha2 portable
by fumiyas＠osstech.co.jp 08 May '12

08 May '12

Full_Name: SATOH Fumiyasu Version: master OS: URL: ftp://ftp.openldap.org/incoming/openldap-2.4.31-sha2-portable.patch Submission from: (NULL) (125.2.180.244) contrib/slapd-modules/passwd/sha2/sha2.[ch] need portable.h and some macros to be portable source.

1 0

(ITS#7266) back-mdb deletion failures
by quanah＠OpenLDAP.org 07 May '12

07 May '12

Full_Name: Quanah Gibson-Mount Version: 2.4.31 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.108.184.39) Create an MDB database with approximately 130,000 entries. Delete the entries sequentially. Deletes will sporadically fail in blocks: deleting entry "uid=testuser44968,ou=people,dc=zre-ldap004,dc=eng,dc=vmware,dc=com" deleting entry "uid=testuser44969,ou=people,dc=zre-ldap004,dc=eng,dc=vmware,dc=com" ldap_delete: Other (e.g., implementation specific) error (80) additional info: entry index delete failed deleting entry "uid=testuser44970,ou=people,dc=zre-ldap004,dc=eng,dc=vmware,dc=com" ldap_delete: Other (e.g., implementation specific) error (80) additional info: entry index delete failed ... continues to fail up to: deleting entry "uid=testuser45093,ou=people,dc=zre-ldap004,dc=eng,dc=vmware,dc=com" ldap_delete: Other (e.g., implementation specific) error (80) additional info: entry index delete failed deleting entry "uid=testuser45094,ou=people,dc=zre-ldap004,dc=eng,dc=vmware,dc=com" ldap_delete: Other (e.g., implementation specific) error (80) additional info: entry index delete failed deleting entry "uid=testuser45095,ou=people,dc=zre-ldap004,dc=eng,dc=vmware,dc=com" ldap_delete: Other (e.g., implementation specific) error (80) additional info: entry index delete failed deleting entry "uid=testuser45096,ou=people,dc=zre-ldap004,dc=eng,dc=vmware,dc=com" deleting entry "uid=testuser45097,ou=people,dc=zre-ldap004,dc=eng,dc=vmware,dc=com" deleting entry "uid=testuser45098,ou=people,dc=zre-ldap004,dc=eng,dc=vmware,dc=com" deleting entry "uid=testuser45099,ou=people,dc=zre-ldap004,dc=eng,dc=vmware,dc=com" then deletes work for a while again, then fail again for a while, etc.

1 0

(ITS#7265) reaching back-mdb database sizelimit can result in corrupt DB
by quanah＠OpenLDAP.org 07 May '12

07 May '12

Full_Name: Quanah Gibson-Mount Version: 2.4.30+patches OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.108.184.39) With a database maxsize of 1GB, found that when the DB hit 1GB in size, slapd stopped. After upping the maxsize, the mdb database was unreadable via ldapsearch. Slapcat also failed to pull any data out of the database.

1 0

Re: (ITS#7249) slapd segfault with memberof overlay on frontend db
by jvcelak＠redhat.com 07 May '12

07 May '12

--nextPart2505210.xvcxic42sH Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" On Friday 27 of April 2012 12:26:22, Howard Chu wrote: > jvcelak(a)redhat.com wrote: > >> What happens is that the memberof overlay, when stacked on the frontend > >> database, keeps looping until the stack is exhausted, since internal > >> modifications keep calling the frontend's modify hook rather than the > >> actual one that needs to be called. > > > > I have no idea how to fix it. I probably do not understand the > > manipulation > > with BackedInfo structures fully. > > > > It is obious that it is caused by doing a search from the modrdn operation > > callback memberof_res_modrdn() which is set up in memberof_op_modrdn(). > > Other backends does not call any backend operation at the same moment > > (op->callback). > > > > Frontend fe_op_search() is called. It tries to choose the right backend > > with select_backend(). Which returns the overlay backend (bi_type == > > "over"), over_op_walk() then selects fe_op_search() again, and we are > > looping infinitely. > > > > I have no clue how to hide or temporarily deactivate the overlay in > > memberof_res_modrdn() to make the select_backend() function to choose the > > right underlaying backend. Or maybe I have choosen a wrong way of fixing > > it. > > > > All ideas are welcomed. :-) > > The attached diff fixes this particular problem. I haven't spent any time to > see if the other be_* invocations need to be protected the same way. Thank you. I have added this check to another places (attaching patch). But it seems that it is not sufficient. In certain situations I can still trigger the segfault - from memberof_res_modrdn() by calling backend_attribute(). At a first glance, the circumstances are a little bit different but I see no difference in the structures when calling the function with overlay set on frontend and backend database. I hope I will have some time to look at it soon. (gdb) bt -30 #35697 0x00000000004d9368 in overlay_entry_get_ov (op=0x7fffe40028f0, dn=0x7ffff23d9050, oc=0x0, ad=0x9e8450, rw=0, e=0x7ffff23d8d28, on=0x0) at ../../../servers/slapd/backover.c:364 #35698 0x00000000004d9460 in over_entry_get_rw (op=0x7fffe40028f0, dn=0x7ffff23d9050, oc=0x0, ad=0x9e8450, rw=0, e=0x7ffff23d8d28) at ../../../servers/slapd/backover.c:396 #35699 0x00000000004dd448 in fe_entry_get_rw (op=0x7fffe40028f0, ndn=0x7ffff23d9050, oc=0x0, at=0x9e8450, rw=0, e=0x7ffff23d8d28) at ../../../servers/slapd/frontend.c:62 #35700 0x00000000004d9368 in overlay_entry_get_ov (op=0x7fffe40028f0, dn=0x7ffff23d9050, oc=0x0, ad=0x9e8450, rw=0, e=0x7ffff23d8d28, on=0x0) at ../../../servers/slapd/backover.c:364 #35701 0x00000000004d9460 in over_entry_get_rw (op=0x7fffe40028f0, dn=0x7ffff23d9050, oc=0x0, ad=0x9e8450, rw=0, e=0x7ffff23d8d28) at ../../../servers/slapd/backover.c:396 #35702 0x00000000004dd448 in fe_entry_get_rw (op=0x7fffe40028f0, ndn=0x7ffff23d9050, oc=0x0, at=0x9e8450, rw=0, e=0x7ffff23d8d28) at ../../../servers/slapd/frontend.c:62 #35703 0x00000000004d9368 in overlay_entry_get_ov (op=0x7fffe40028f0, dn=0x7ffff23d9050, oc=0x0, ad=0x9e8450, rw=0, e=0x7ffff23d8d28, on=0x0) at ../../../servers/slapd/backover.c:364 #35704 0x00000000004d9460 in over_entry_get_rw (op=0x7fffe40028f0, dn=0x7ffff23d9050, oc=0x0, ad=0x9e8450, rw=0, e=0x7ffff23d8d28) at ../../../servers/slapd/backover.c:396 #35705 0x00000000004dd448 in fe_entry_get_rw (op=0x7fffe40028f0, ndn=0x7ffff23d9050, oc=0x0, at=0x9e8450, rw=0, e=0x7ffff23d8d28) at ../../../servers/slapd/frontend.c:62 #35706 0x00000000004d9368 in overlay_entry_get_ov (op=0x7fffe40028f0, dn=0x7ffff23d9050, oc=0x0, ad=0x9e8450, rw=0, e=0x7ffff23d8d28, on=0x0) at ../../../servers/slapd/backover.c:364 #35707 0x00000000004d9460 in over_entry_get_rw (op=0x7fffe40028f0, dn=0x7ffff23d9050, oc=0x0, ad=0x9e8450, rw=0, e=0x7ffff23d8d28) at ../../../servers/slapd/backover.c:396 #35708 0x000000000044fc46 in be_entry_get_rw (op=0x7fffe40028f0, ndn=0x7ffff23d9050, oc=0x0, at=0x9e8450, rw=0, e=0x7ffff23d8d28) at ../../../servers/slapd/backend.c:1366 #35709 0x0000000000450990 in fe_acl_attribute (op=0x7fffe40028f0, target=0x0, edn=0x7ffff23d9050, entry_at=0x9e8450, vals=0x7ffff23d9088, access=ACL_READ) at ../../../servers/slapd/backend.c:1658 #35710 0x00000000004d9cdb in over_acl_attribute (op=0x7fffe40028f0, target=0x0, entry_ndn=0x7ffff23d9050, entry_at=0x9e8450, vals=0x7ffff23d9088, access=ACL_READ) at ../../../servers/slapd/backover.c:589 #35711 0x0000000000450ed5 in backend_attribute (op=0x7fffe40028f0, target=0x0, edn=0x7ffff23d9050, entry_at=0x9e8450, vals=0x7ffff23d9088, access=ACL_READ) at ../../../servers/slapd/backend.c:1778 #35712 0x00000000005a4c9f in memberof_res_modrdn (op=0x7fffe40028f0, rs=0x7ffff23d9a60) at ../../../../servers/slapd/overlays/memberof.c:1558 #35713 0x000000000045252c in slap_response_play (op=0x7fffe40028f0, rs=0x7ffff23d9a60) at ../../../servers/slapd/result.c:507 #35714 0x0000000000452768 in send_ldap_response (op=0x7fffe40028f0, rs=0x7ffff23d9a60) at ../../../servers/slapd/result.c:582 #35715 0x0000000000453952 in slap_send_ldap_result (op=0x7fffe40028f0, rs=0x7ffff23d9a60) at ../../../servers/slapd/result.c:860 #35716 0x000000000050dfa9 in bdb_modrdn (op=0x7fffe40028f0, rs=0x7ffff23d9a60) at ../../../../servers/slapd/back-bdb/modrdn.c:789 #35717 0x00000000004625be in fe_op_modrdn (op=0x7fffe40028f0, rs=0x7ffff23d9a60) at ../../../servers/slapd/modrdn.c:314 #35718 0x00000000004d9ed4 in overlay_op_walk (op=0x7fffe40028f0, rs=0x7ffff23d9a60, which=op_modrdn, oi=0x7fffe41050e0, on=0x0) at ../../../servers/slapd/backover.c:671 #35719 0x00000000004da125 in over_op_func (op=0x7fffe40028f0, rs=0x7ffff23d9a60, which=op_modrdn) at ../../../servers/slapd/backover.c:723 #35720 0x00000000004da2b2 in over_op_modrdn (op=0x7fffe40028f0, rs=0x7ffff23d9a60) at ../../../servers/slapd/backover.c:768 #35721 0x0000000000461d20 in do_modrdn (op=0x7fffe40028f0, rs=0x7ffff23d9a60) at ../../../servers/slapd/modrdn.c:186 #35722 0x000000000043a8df in connection_operation (ctx=0x7ffff23d9ba0, arg_v=0x7fffe40028f0) at ../../../servers/slapd/connection.c:1150 #35723 0x000000000043ae9c in connection_read_thread (ctx=0x7ffff23d9ba0, argv=0x15) at ../../../servers/slapd/connection.c:1286 #35724 0x00000000005d12ce in ldap_int_thread_pool_wrapper (xpool=0x9b0bf0) at ../../../libraries/libldap_r/tpool.c:688 #35725 0x00007ffff73e4d90 in start_thread () from /lib64/libpthread.so.0 #35726 0x00007ffff5cf5f5d in clone () from /lib64/libc.so.6 --nextPart2505210.xvcxic42sH Content-Disposition: attachment; filename="memberof_partial.patch" Content-Transfer-Encoding: 7Bit Content-Type: text/x-patch; charset="UTF-8"; name="memberof_partial.patch" diff --git a/servers/slapd/overlays/memberof.c b/servers/slapd/overlays/memberof.c index 502cb46..356c1e6 100644 --- a/servers/slapd/overlays/memberof.c +++ b/servers/slapd/overlays/memberof.c @@ -190,7 +190,16 @@ typedef struct memberof_cbinfo_t { BerVarray memberof; memberof_is_t what; } memberof_cbinfo_t; - + +static void +memberof_set_backend(Operation *op_target, Operation *op, slap_overinst *on) +{ + BackendInfo *bi = op->o_bd->bd_info; + + if (bi->bi_type == memberof.on_bi.bi_type) + op_target->o_bd->bd_info = (BackendInfo *)on->on_info; +} + static int memberof_isGroupOrMember_cb( Operation *op, SlapReply *rs ) { @@ -285,7 +294,7 @@ memberof_isGroupOrMember( Operation *op, memberof_cbinfo_t *mci ) op2.ors_filterstr = mo->mo_groupFilterstr; op2.ors_filter = &mo->mo_groupFilter; - op2.o_bd->bd_info = (BackendInfo *)on->on_info; + memberof_set_backend(&op2, op, on); (void)op->o_bd->be_search( &op2, &rs2 ); op2.o_bd->bd_info = bi; @@ -307,7 +316,7 @@ memberof_isGroupOrMember( Operation *op, memberof_cbinfo_t *mci ) op2.ors_filterstr = mo->mo_memberFilterstr; op2.ors_filter = &mo->mo_memberFilter; - op2.o_bd->bd_info = (BackendInfo *)on->on_info; + memberof_set_backend(&op2, op, on); (void)op->o_bd->be_search( &op2, &rs2 ); op2.o_bd->bd_info = bi; @@ -407,7 +416,7 @@ memberof_value_modify( oex.oe_key = (void *)&memberof; LDAP_SLIST_INSERT_HEAD(&op2.o_extra, &oex, oe_next); - op2.o_bd->bd_info = (BackendInfo *)on->on_info; + memberof_set_backend(&op2, op, on); (void)op->o_bd->be_modify( &op2, &rs2 ); op2.o_bd->bd_info = bi; LDAP_SLIST_REMOVE(&op2.o_extra, &oex, OpExtra, oe_next); @@ -449,7 +458,7 @@ memberof_value_modify( oex.oe_key = (void *)&memberof; LDAP_SLIST_INSERT_HEAD(&op2.o_extra, &oex, oe_next); - op2.o_bd->bd_info = (BackendInfo *)on->on_info; + memberof_set_backend(&op2, op, on); (void)op->o_bd->be_modify( &op2, &rs2 ); op2.o_bd->bd_info = bi; LDAP_SLIST_REMOVE(&op2.o_extra, &oex, OpExtra, oe_next); --nextPart2505210.xvcxic42sH--

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