openldap-devel January 2011

openldap-devel@openldap.org

16 participants
20 discussions

Re: ITS#6607 to be fixed in 2.4.24?
by Quanah Gibson-Mount 10 Jan '11

10 Jan '11

--On Saturday, January 08, 2011 7:32 PM +0100 masarati(a)aero.polimi.it wrote: >> With 2.4.23, i ran into the bug in IDS#6607 "Forwarded bind failure >> messages cause success", but was able to fix it by applying the minor >> diff of back-ldap/chain.c rev 1.77 (as was mentioned in the bug >> follow-up). >> >> I've downloaded RE24 as of today & compiled it up. However, the bug is >> still there. Is this fix going to make it into 2.4.24 by any chance? > > That fix was related to ITS#6475, but apparently is beneficial in other > issues. Right now, ITS#6475 is not going to be released with 2.4.24, > although I do not have any objection. In any case, I believe > back-ldap/chain.c 1.77 could be released as 2.4.24. I've dropped just this part of ITS#6475 into RE24. I will mark 6607 as fixed. --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

2 1

Re: RE24 testing call #2 (OL2.4.24)
by Brett ＠Google 10 Jan '11

10 Jan '11

make test stops indefinitely at >>>>> Starting test036-meta-concurrency for bdb... PID=15362 - Read(1000): entry="cn=Backend 1,cn=Backends,cn=Monitor". PID=14534 - Add/Delete done (0). PID=15384 - Bind(1000): base="ou=People,o=Example,c=US", filter="(userPassword=*)" attr="userPassword". PID=13274 - Read done (0). PID=15420 - Search(500): base="cn=Monitor" scope=sub filter="(objectClass=*)" attrs=cn (more...). PID=13282 - Read done (0). PID=15422 - Read(1000): entry="cn=Entries,cn=Statistics,cn=Monitor". PID=15384 - Bind base="ou=People,o=Example,c=US" filter="(userPassword=*)" got 3 values. PID=13288 - Read done (0). PID=15424 - Bind(1000): dn="cn=Foo,ou=Meta,o=Example,c=US". slapd-bind PID=15384: ldap_sasl_bind_s: Invalid credentials (49) slapd-bind PID=15424: ldap_sasl_bind_s: Invalid credentials (49) <then nothing> no error the make test just freezes... (12 minutes without any new log output from when i started noticing) maxfieb@qgdevcore ~> uname -a SunOS qgdevcore 5.10 Generic_141414-07 sun4v sparc SUNW,Sun-Fire-T200 Let me know if you want detailed information & to whom to send it. Using sun compiler, 64 bit build.. Cheers Brett On Fri, Jan 7, 2011 at 8:17 AM, Quanah Gibson-Mount <quanah(a)zimbra.com>wrote: > There have been substantial updates to RE24. Please test! > > Thanks, > 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 >

2 1

Wrapping backend operation calls in macros
by Hallvard B Furuseth 09 Jan '11

09 Jan '11

May I wrap all "foo->backend_op(op, rs)" calls in new macros SLAP_OP()/slap_be_op()/slap_bi_op()? It's for ITS#6758, SlapReply cleanup. The macros expand to the original code, except CPPFLAGS=-D"SOMETHING" uncovers a backend.c function with assertions before and after the backend call. Also code using a backend function array (example 4 below) needs tweaks. Four types of changes. Examples, -old +new: - rc = op->o_bd->be_modrdn( op, rs ); /* Operation *op */ + rc = SLAP_OP( op_modrdn, op, rs ); - rc = be->be_operational( op, rs ); /* BackendDB *be */ + rc = slap_be_op( be, op_aux_operational, op, rs ); - rc = bi.bi_op_search( op, rs ); /* BackendInfo bi */ + rc = slap_bi_op( &bi, op_search, op, rs ); /* &be->be_bind == "array of backend function ptrs" hack */ - func = &be->be_bind; ...; rc = func[ which ]( op, rs ); + bi = be->bd_info; ...; rc = slap_bi_op( bi, which, op, rs ); Quanah, the first three are ~150 changes to 50 files, which I expect can be a bother to merge into RE24. I can instead commit the script which makes the diffs, and let you run it when it suits you. (Generate the diffs for RE24 but apply them to HEAD, ignoring rejects, and you have the conflict-free changes. Leaves ~20 needing more care.) Wrapper function and macros: int (slap_bi_op)(BackendInfo*, slap_operation_t, Operation*, SlapReply*); #if !SOMETHING #define slap_bi_op(bi,which,op,rs) ((&(bi)->bi_op_bind)[ which ](op,rs)) #endif #define slap_be_op(be,which,op,rs) slap_bi_op((be)->bd_info,which,op,rs) #define SLAP_OP( which,op,rs) slap_be_op((op)->o_bd, which,op,rs) SLAP_OP is uppercase since it evaluates op twice, unlike function calls. My current SOMETHING is (defined(USE_RS_ASSERT) && (USE_RS_ASSERT)), which enables the assert(SlapReply OK) macros from ITS#6758. Maybe in this context it should be a more general SLAPD_DEBUG or (defined(SLAPD_DEBUG) ? (SLAPD_DEBUG) : defined(LDAP_TEST)) ? portable.h #defines LDAP_TEST when LDAP_DEVEL, not in releases. Draft patches: <http://folk.uio.no/hbf/OpenLDAP/wrap_slap_ops.txt>. -- Hallvard

1 0

Re: RE24 testing call #1 (OL 2.4.24)
by Howard Chu 09 Jan '11

09 Jan '11

This thread started on -devel, it does not belong on -technical. Brett Maxfield wrote: > There is a discussion of solaris threads socket read/write locking issues and > some workarounds at: http://omniorb.sourceforge.net/omni40/omnithread.html > > See "6 Threaded I/O shutdown for Unix" None of this applies to OpenLDAP's code. > Cheers > Brett > > On 08/01/2011, at 9:55 AM, Howard Chu <hyc(a)symas.com <mailto:hyc@symas.com>> > wrote: > >> Doug Leavitt wrote: >>> >>> On 01/ 7/11 08:01 AM, Rein Tollevik wrote: >>>> On 06.01.11 22.48, Quanah Gibson-Mount wrote: >>>>> --On Thursday, January 06, 2011 7:40 PM +0100 Rein Tollevik >>>>> <rein(a)OpenLDAP.org <mailto:rein@OpenLDAP.org>> wrote: >>>>> >>>>>> On 04.01.11 23.34, Quanah Gibson-Mount wrote: >>>>>>> Please test RE24 heavily. >>>>>> >>>>>> test039 deadlocks for me on 64bit solaris10, both x86 and sparc :-( It >>>>>> hangs in the monitor, triggered by the new swamp -SS option added to >>>>>> slapd-tester. It works if run with -S or -SSS. It is the third server >>>>>> that hangs, and it does so quite consistently with the same stack trace >>>>>> every time. A gdb trace is at at: >>>>>> >>>>>> ftp://ftp.openldap.org/incoming/rein-test039-gdb-trace.txt >>>>> >>>>> Does this happen on both HEAD and RE24, or RE24 only? >>>> >>>> Both, as well as when running the head tests suite with the 2.4.23 >>>> release. Looks as if the swamp additions have tripped into an >>>> existing problem, not anything new. Leave it out of RE24 until if >>>> have been resolved? >>>> >>>> Btw, any other Solaris test runs out there? I´t like to know if it is >>>> a real Solaris problem or just me.. >> >> I'm seeing a similar failure on 32 bit Sparc Solaris 10. But it actually >> locks up in test036 for me, I never get as far as test039. The gdb trace >> looks much the same as what you posted. >> >> Looks like for some reason threads that are blocked waiting for their >> sockets to become writable are never getting waken up. A regular SIGINT >> shuts down slapd cleanly so it doesn't appear to be a problem with the >> condvars being used to manage the threads. That kinda points to select() >> simply not returning the writable status. >> >> I haven't used this Solaris machine much, but in fact (looking at the >> remnants of other files in my source tree on this box) this appears to have >> been a problem since at least last August. (I.e., it looks like I was >> investigating this same problem back then but dropped it and never got back >> to it.) >> >>>> Rein >> >>> I'm currently testing Solaris11 (Nevada) and not seeing any issues in >>> either 32 or 64 >>> bit builds using both RE24 and HEAD. I have not had any failures on >>> x86 yet. >>> Testing is still underway for sparc and other internal system testing on >>> both platforms. -- -- 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

RE24 testing call #1 (OL 2.4.24)
by Brett Maxfield 09 Jan '11

09 Jan '11

> There is a discussion of solaris threads socket read/write locking issues and some workarounds at: http://omniorb.sourceforge.net/omni40/omnithread.html > > See "6 Threaded I/O shutdown for Unix" > > Cheers > Brett > > On 08/01/2011, at 9:55 AM, Howard Chu <hyc(a)symas.com> wrote: > >> Doug Leavitt wrote: >>> >>> On 01/ 7/11 08:01 AM, Rein Tollevik wrote: >>>> On 06.01.11 22.48, Quanah Gibson-Mount wrote: >>>>> --On Thursday, January 06, 2011 7:40 PM +0100 Rein Tollevik >>>>> <rein(a)OpenLDAP.org> wrote: >>>>> >>>>>> On 04.01.11 23.34, Quanah Gibson-Mount wrote: >>>>>>> Please test RE24 heavily. >>>>>> >>>>>> test039 deadlocks for me on 64bit solaris10, both x86 and sparc :-( It >>>>>> hangs in the monitor, triggered by the new swamp -SS option added to >>>>>> slapd-tester. It works if run with -S or -SSS. It is the third server >>>>>> that hangs, and it does so quite consistently with the same stack trace >>>>>> every time. A gdb trace is at at: >>>>>> >>>>>> ftp://ftp.openldap.org/incoming/rein-test039-gdb-trace.txt >>>>> >>>>> Does this happen on both HEAD and RE24, or RE24 only? >>>> >>>> Both, as well as when running the head tests suite with the 2.4.23 >>>> release. Looks as if the swamp additions have tripped into an >>>> existing problem, not anything new. Leave it out of RE24 until if >>>> have been resolved? >>>> >>>> Btw, any other Solaris test runs out there? I´t like to know if it is >>>> a real Solaris problem or just me.. >> >> I'm seeing a similar failure on 32 bit Sparc Solaris 10. But it actually locks up in test036 for me, I never get as far as test039. The gdb trace looks much the same as what you posted. >> >> Looks like for some reason threads that are blocked waiting for their sockets to become writable are never getting waken up. A regular SIGINT shuts down slapd cleanly so it doesn't appear to be a problem with the condvars being used to manage the threads. That kinda points to select() simply not returning the writable status. >> >> I haven't used this Solaris machine much, but in fact (looking at the remnants of other files in my source tree on this box) this appears to have been a problem since at least last August. (I.e., it looks like I was investigating this same problem back then but dropped it and never got back to it.) >> >>>> Rein >> >>> I'm currently testing Solaris11 (Nevada) and not seeing any issues in >>> either 32 or 64 >>> bit builds using both RE24 and HEAD. I have not had any failures on >>> x86 yet. >>> Testing is still underway for sparc and other internal system testing on >>> both platforms. >> >> -- >> -- 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

RE24 testing call #2 (OL2.4.24)
by Quanah Gibson-Mount 09 Jan '11

09 Jan '11

There have been substantial updates to RE24. Please test! Thanks, 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

6 11

multiple listener threads (was: commit: ldap/servers/slapd bconfig.c daemon.c proto-slap.h)
by Hallvard B Furuseth 07 Jan '11

07 Jan '11

quanah(a)OpenLDAP.org writes: > Tag: OPENLDAP_REL_ENG_2_4 > bconfig.c 1.202.2.88 -> 1.202.2.89 > daemon.c 1.380.2.37 -> 1.380.2.38 > proto-slap.h 1.670.2.63 -> 1.670.2.64 > > Add support for multiple listener threads. Needs fixing, see: ITS#6745 HEAD emfile race condition -> slapd stopping listening? -- Hallvard

1 0

Re: LDAP Verify Credentials operation
by Kurt Zeilenga 05 Jan '11

05 Jan '11

Ando and I have been discussing off-list the need for this op's request and response to carry additional fields. The discussion started with a separate error code to distinguish errors which might be communicated back to authenticating entity (as opposed to the LDAP client submitting the VC request). My current proposal is: /* * LDAP Verify Credentials operation * * The request is an extended request with OID 1.3.6.1.4.1.4203.666.6.5 with value of * the BER encoding of: * * VCRequest ::= SEQUENCE { * cookie [0] OCTET STRING OPTIONAL, * name LDAPDN, * authentication AuthenticationChoice * controls [3] Controls OPTIONAL * } * * where LDAPDN, AuthenticationChoice, and Controls are as defined in RFC 4511. * * The response is an extended response with no OID and a value of the BER encoding of * * VCResponse ::= SEQUENCE { * resultCode ResultCode, * diagnosticMessage LDAPString, * cookie [0] OCTET STRING OPTIONAL, * serverSaslCreds [1] OCTET STRING OPTIONAL * authzid [2] OCTET STRING OPTIONAL * controls [3] Controls OPTIONAL * } * * where ResultCode is the result code enumeration from RFC 4511, and LDAPString and Controls are as * defined in RFC 4511. */ The use of controls here is to allow both the request/return of password policy information to the authenticating entity (as opposed those used on the extended operation itself to request/return password policy information about the LDAP client submitting the VC request). Comments? -- Kurt

3 5

Re: commit: ldap/contrib/slapd-modules/cloak cloak.c
by Hallvard B Furuseth 04 Jan '11

04 Jan '11

ando(a)OpenLDAP.org writes: > fix cloak behavior; plug leak (ITS#6762) Oh, there actually was a leak?:-) What I meant in ITS#6762 was I assumed my workaround would have have introduced a leak. -- Hallvard

2 1

LDIF wrapping (Was: ITS#6645)
by masarati＠aero.polimi.it 01 Jan '11

01 Jan '11

I'd like to resolve the ITS#6645 issue, either by committing or wiping out this patch from my working directory, as it conflicts with ITS#6737. Comments? p.

3 5

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-devel January 2011