openldap-bugs

openldap-bugs@openldap.org

1 participants
20965 discussions

(ITS#5738) back-monitor: registering a new backend (via moduleload) should add the corresponding entry in cn=monitor
by ando＠sys-net.it 12 Oct '08

12 Oct '08

Full_Name: Pierangelo Masarati Version: HEAD OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando p.

1 0

(ITS#5737) back-monitor: adding a database should add its entry in cn=monitor
by ando＠sys-net.it 12 Oct '08

12 Oct '08

Full_Name: Pierangelo Masarati Version: HEAD OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando p.

1 0

(ITS#5736) slapo-chain & slapo-translucent need work to interoperate with back-config
by ando＠sys-net.it 12 Oct '08

12 Oct '08

Full_Name: Pierangelo Masarati Version: HEAD OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (151.30.65.135) the *ldadd function of both overlays associated to private database instantiation does not intercept the olcDatabase attributeType. slapo-chain might also have an issue related to defferring *db_open(). A fix is coming. p.

1 0

(ITS#5735) global overlays not handled correctly in back-config
by ando＠sys-net.it 12 Oct '08

12 Oct '08

Full_Name: Pierangelo Masarati Version: HEAD OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (151.30.65.135) When global overlays instantiate private databases, they are not correctly handled by back-config. A fix is coming.

1 0

Re: ITS#5707
by hyc＠symas.com 11 Oct '08

11 Oct '08

ando(a)sys-net.it wrote: > Just to clarify: is the patch available from Oracle's web site > <http://www.oracle.com/technology/products/berkeley-db/db/update/4.7.25/patc…> > related? Is it alternative or complementary to<build/db.4.7.25.patch>? I suspect the contents of that URL will change over time. At the moment, that page has only one patch, and it only affects BerkeleyDB replication, which is a feature that we have never used. -- -- 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#5707
by ando＠sys-net.it 11 Oct '08

11 Oct '08

Just to clarify: is the patch available from Oracle's web site <http://www.oracle.com/technology/products/berkeley-db/db/update/4.7.25/patc…> related? Is it alternative or complementary to <build/db.4.7.25.patch>? p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

(ITS#5734) Serch limits by baseDN
by h.b.furuseth＠usit.uio.no 09 Oct '08

09 Oct '08

Full_Name: Hallvard B Furuseth Version: HEAD OS: URL: http://folk.uio.no/hbf/OpenLDAP/limits.txt Submission from: (NULL) (129.240.6.233) Submitted by: hallvard I want to give part of a database different limits than the rest. Here a suggested patch, currently a quick hack for inspection. It gives ".this" and ".self" modifiers to "dn" in the "limits" keyword: limits dn[.this | .self][.exact | .base | ...] ... "Self" is default and matches the specified DN against the bound DN. "This" matches against the base DN of the search. (Keywords chosen from "this"/"self" in set ACLs, since names like "base" are taken.) This needs an API change: Currently slapd/limits.c:limits_gets() takes the bound DN as an argument. The change needs a function which fetches the bound or examined DN from the Operation structure. Is it OK to just remove the DN argument and make the function static, so any existing binaries that call it won't silently get the changed API? Slapd doesn't call this function anywhere.

1 0

Re: (ITS#5731) Don't rewrite filter when it is undefined
by ando＠sys-net.it 09 Oct '08

09 Oct '08

The bug is confirmed; the proposed fix is incorrect, since it only addresses the case of a(n undefined) simple filter. A more complete fix (see also ITS#5732) is in HEAD, please test. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

(ITS#5733) core dump in re24's slapd-ldap(5)
by ando＠sys-net.it 09 Oct '08

09 Oct '08

Full_Name: Pierangelo Masarati Version: re24 OS: Linux x86 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando I had a strange core dump while testing re24 (test039). I'm reporting it in order to be able to investigate it further later. Backtrace follows: (gdb) bt #0 0x00800402 in __kernel_vsyscall () #1 0x00c9ad20 in raise () from /lib/libc.so.6 #2 0x00c9c631 in abort () from /lib/libc.so.6 #3 0x00c9416b in __assert_fail () from /lib/libc.so.6 #4 0x0817c7e5 in ldap_back_conn_delete (li=0x8a9ef30, lc=0x8b55df8) at bind.c:157 #5 0x0817d20a in ldap_back_freeconn (li=0x8a9ef30, lc=0x8b55df8, dolock=0) at bind.c:467 #6 0x0817e8cf in ldap_back_release_conn_lock (li=0x8a9ef30, lcp=0xb4376d10, dolock=1) at bind.c:1144 #7 0x0817cf12 in ldap_back_bind (op=0x8b973e0, rs=0xb4377128) at bind.c:355 #8 0x080fac38 in overlay_op_walk (op=0x8b973e0, rs=0xb4377128, which=op_bind, oi=0x8a82d78, on=0x0) at backover.c:667 #9 0x080faded in over_op_func (op=0x8b973e0, rs=0xb4377128, which=op_bind) at backover.c:719 #10 0x080fae2d in over_op_bind (op=0x8b973e0, rs=0xb4377128) at backover.c:729 #11 0x080a8311 in fe_op_bind (op=0x8b973e0, rs=0xb4377128) at bind.c:383 #12 0x080fac38 in overlay_op_walk (op=0x8b973e0, rs=0xb4377128, which=op_bind, oi=0x8a85090, on=0x0) at backover.c:667 #13 0x080faded in over_op_func (op=0x8b973e0, rs=0xb4377128, which=op_bind) at backover.c:719 #14 0x080fae2d in over_op_bind (op=0x8b973e0, rs=0xb4377128) at backover.c:729 #15 0x080a7aa7 in do_bind (op=0x8b973e0, rs=0xb4377128) at bind.c:205 #16 0x08083c40 in connection_operation (ctx=0xb4377210, arg_v=0x8b973e0) at connection.c:1084 #17 0x0808411a in connection_read_thread (ctx=0xb4377210, argv=0x1f) at connection.c:1210 #18 0x08207d35 in ldap_int_thread_pool_wrapper (xpool=0x8a595b8) at tpool.c:663 #19 0x00deb46b in start_thread () from /lib/libpthread.so.0 #20 0x00d42dbe in clone () from /lib/libc.so.6 (gdb) f 4 #4 0x0817c7e5 in ldap_back_conn_delete (li=0x8a9ef30, lc=0x8b55df8) at bind.c:157 157 assert( !LDAP_BACK_CONN_TAINTED( lc ) ); (gdb) p *lc $1 = {lc_conn = 0xb7e91ba0, lc_ld = 0x8b79160, lc_cred = {bv_len = 0, bv_val = 0x0}, lc_bound_ndn = {bv_len = 68, bv_val = 0x8b2dce8 "cn=james a jones 1,ou=alumni association,ou=people,dc=example,dc=com"}, lc_local_ndn = {bv_len = 68, bv_val = 0x8b37e28 "cn=james a jones 1,ou=alumni association,ou=people,dc=example,dc=com"}, lc_lcflags = 289, lc_refcnt = 0, lc_flags = 4096, lc_create_time = 0, lc_time = 0, lc_q = {tqe_next = 0x0, tqe_prev = 0x0}} (gdb) p /x lc->lc_lcflags $2 = 0x121 The connection is simultaneously cached (0x100) and tainted (0x20); this triggers an assert. Note that (gdb) f 7 #7 0x0817cf12 in ldap_back_bind (op=0x8b973e0, rs=0xb4377128) at bind.c:355 355 ldap_back_release_conn( li, lc ); (gdb) p retrying $4 = LDAP_BACK_RETRYING so apparently no one had a chance to taint the connection (from within this thread). Probably, the assert is too tight. Either tainting and uncaching should occur simultaneously, or the assert should just be relaxed. p.

1 0

(ITS#5732) slapo-rwm can free and reuse a filter in case of error
by ando＠sys-net.it 09 Oct '08

09 Oct '08

Full_Name: Pierangelo Masarati Version: HEAD/re24/re23 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando A fix is coming, along with the right fix to ITS#5731 p.

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