Re: ITS#6607 to be fixed in 2.4.24?
by Quanah Gibson-Mount
--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
12 years, 2 months
Re: RE24 testing call #2 (OL2.4.24)
by Brett ＠Google
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
>
12 years, 2 months
Wrapping backend operation calls in macros
by Hallvard B Furuseth
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
12 years, 2 months
Re: RE24 testing call #1 (OL 2.4.24)
by Howard Chu
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/
12 years, 2 months
RE24 testing call #1 (OL 2.4.24)
by Brett Maxfield
> 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/
12 years, 2 months
RE24 testing call #2 (OL2.4.24)
by Quanah Gibson-Mount
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
12 years, 2 months
Re: LDAP Verify Credentials operation
by Kurt Zeilenga
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
12 years, 2 months
Re: commit: ldap/contrib/slapd-modules/cloak cloak.c
by Hallvard B Furuseth
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
12 years, 2 months
LDIF wrapping (Was: ITS#6645)
by masarati＠aero.polimi.it
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.
12 years, 2 months
