openldap-devel

openldap-devel@openldap.org

1418 discussions

Re: thread pools, performance
by Howard Chu 14 Feb '08

14 Feb '08

Rick Jones wrote: > There are definitely interrupt coalescing settings available with tg3-driven > cards, as well as bnx2 driven ones: > > ftp://ftp.cup.hp.com/dist/networking/briefs/nic_latency_vs_tput.txt Yep, that helped. Raising rx-usecs from default 20 to 1000, and rx-frames from default 5 to 100, I'm getting 43k auths/sec with back-null (in 4 separate thread pools) and the core fielding the interrupts is only about 80% busy now instead of 100%. I'm afraid my load generators may be maxed out now, because I can't seem to drive up the load on the server any higher even though there's more idle CPU. The current code in HEAD (with only 1 thread pool) is reaching 36k auths/sec with back-null, so it's actually not far off from my experimental peak rate. Considering that HEAD was at 25k/sec last week (and now in 2.4.6) that's pretty decent. With back-bdb and 1 million users I'm getting 26.1k/sec with plaintext passwords (up from 19.3k/sec last week). With {SSHA} passwords that drops to 25.7k/sec (~1.5% difference). I have to put this tinkering on hold for a bit, to run some authrate tests against ActiveDirectory on this machine (using W2K3sp2 X64). Later on we'll do a W2K3 OpenLDAP build for comparison as well. Should be entertaining... -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

7 22

Re: RE24 testing
by Luca Scamoni 13 Feb '08

13 Feb '08

Passes on CentOS 4.6 and CentoOS 5.1 (i686 and virtual machines) I had only one run in which test050 seemed to have been gone in a sort of loop on a CentOS 4 VM, but I've not been able to reproduce it in more than 20 runs of the test. Ing. Luca Scamoni Responsabile Ricerca e Sviluppo SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 0382 573859 (137) Mobile: +39 347 1014425 Email: luca.scamoni(a)sys-net.it -----------------------------------

1 0

RE24 testing
by Quanah Gibson-Mount 12 Feb '08

12 Feb '08

Please test RE24 in preparation for 2.4.8. Thanks, Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

5 8

Re: commit: ldap/libraries/libldap_r tpool.c
by Hallvard B Furuseth 04 Feb '08

04 Feb '08

Howard, do you remeber if this was a bug fix or an optimization? If the former it was merely triggering some other bug which can presumably still happen due to spurious wakeups. Or if the problem is that the cond can be destroyed at this point if the pool is tearing down, so can the mutex - even though it is locked here. At Thu, 18 Oct 2007, hyc wrote: > tpool.c 1.80 -> 1.81 > > In pool_resume don't touch the condvar if the pool is tearing down. It's this patch to ldap_pvt_thread_pool_resume(), aka "pool_resume fix from HEAD" in the CVS comment for import to RE24: @@ -704,3 +704,4 @@ pool->ltp_pause = 0; - ldap_pvt_thread_cond_broadcast(&pool->ltp_cond); + if (pool->ltp_state == LDAP_INT_THREAD_POOL_RUNNING) + ldap_pvt_thread_cond_broadcast(&pool->ltp_cond); ldap_pvt_thread_mutex_unlock(&pool->ltp_mutex); -- Hallvard

2 2

Overlay question
by luca regini 29 Jan '08

29 Jan '08

Is it possible for an overlay to detect the type of the underlying backend? In the case the answer is affermative and the backend is a bdb is it possible to programmatically force the bdb to save an entry created at runtime? Thanks in advance, Luca Regini

2 1

[Fwd: Re: Likewise has added GSS-SPNEGO support to openldap libraries]
by Howard Chu 28 Jan '08

28 Jan '08

This sounds redundant to me, given that OpenLDAP interfaces to GSS thru SASL. If this code belongs anywhere at all, it's in the SASL library. As for the mechanism itself - we've only recently excised all the other non-standard/obsolete Bind mechanisms from our code base. If Microsoft wants to publish some RFCs/specs for these other mechs, then maybe it'd be OK to incorporate. But until then, to me it just feels like pollution. Anyone else have comments? -------- Original Message -------- Subject: Re: Likewise has added GSS-SPNEGO support to openldap libraries Date: Sat, 26 Jan 2008 23:17:18 +1100 From: Luke Howard <lukeh(a)padl.com> Organization: PADL Software Pty Ltd To: Krishna Ganugapati <krishnag(a)likewisesoftware.com> CC: Howard Chu <HYC(a)symas.com> References: <A4670A1B9F4A714DA683071F29FC5A390C0402B8(a)ms08.mse3.exchange.ms> Hi Krishna, Sounds good! The standard procedure is to file an ITS at: http://www.openldap.org/its and then the OpenLDAP team will review it. I still might have commit access. :-) I think the OpenLDAP team would want to consider how adding LDAP_AUTH_NEGOTIATE (which isn't a new authentication method at the protocol layer) would interact with the existing implementation of ldap_sasl_interactive_bind_s(). I personally have no problem with the MSDN APIs but the team may prefer to keep the existing API usage. regards, -- Luke Krishna Ganugapati wrote: > > Luke, > > I wanted to let you know that we’ve added support for the > LDAP_AUTH_NEGOTIATE option to support GSS-SPNEGO in the open-ldap > libraries. I’d contracted with Sernet to do this work and the work was > done by Stefan Metzmacher of Sernet. We have this support in our own > tree right now and it is super cool. > > See here for details > http://msdn2.microsoft.com/en-us/library/aa366156.aspx > > The advantage is that if you want to make authenticated requests to > Active Directory, it is a piece of cake as opposed to having to > negotiate gss contexts yourself. If you get a tgt from a AD domain > controller, you can seamlessly connect to AD directories. > > I’d like to get this in to the open-ldap source base. I notice that > you (your company) partners with Symas and the open-ldap team. Could I > impose on you to make introductions? I think they will be more > inclined to accept the code when they realize that this work has been > done by Sernet (Volker Lendecke’s company) on contract to Likewise and > we at Likewise are delighted to push this upstream. I completely > understand if you would not be comfortable doing so. > > By the way, our team has ported the dce-rpc libraries to just about > every platform possible and we plan to release it back to the > community very soon. We’re also going to release our libnetapi > libraries which provide a API level compatibility with most of the Net > APIs > > Best regards, > > Krishna > > *Krishna** Ganugapati* > Vice President, Engineering > > *T* 425.378.7887 x241 *F* 425.484.6316 *M* 425.736.1076 *E* > _krishnag(a)likewisesoftware.com <mailto:krishnag@likewisesoftware.com>_ > > > 15395 SE 30th Place, Suite 140 > Bellevue, WA 98007 > *_www.likewisesoftware.com <http://www.likewisesoftware.com/>_**__* > -- www.padl.com |www.fghr.net -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

3 2

Patch: Fix ldap_open debug message
by Michael Adam 24 Jan '08

24 Jan '08

Hi, yes, ldap_open() is deprecated, but the final success/failure message is currently wrong. Attached is a trivial patch against current CVS that fixes this. Cheers, Michael -- Michael Adam <ma(a)sernet.de> <obnox(a)samba.org> SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen phone: +49-551-370000-0, fax: +49-551-370000-9 AG Göttingen, HRB 2816, GF: Dr. Johannes Loxen http://www.SerNet.DE, mailto: Info @ SerNet.DE

2 2

root_dse SASL mech duping
by Quanah Gibson-Mount 23 Jan '08

23 Jan '08

In looking at a back trace of a core file, I noticed: (gdb) thread 7 [Switching to thread 7 (core thread 6)] #0 0x90003ba8 in szone_malloc () (gdb) bt #0 0x90003ba8 in szone_malloc () #1 0x28302c31 in ?? () #2 0x90003a00 in szone_malloc () #3 0x00105d78 in ber_memalloc_x (s=33554488, ctx=0x28302c31) at memory.c:226 #4 0x001064bc in ber_strdup_x (s=0x23d536e0 "OTP,OTP,OTPOTP,OTP,OTP,GSSAPI,GSSAPI,GSSAPI,DIGEST-MD5,DIGEST-MD5,DIGEST-MD5,CRAM-MD5,CRAM-MD5,CRAM-MD5,GSSAPI,GSSAPI,GSSAPI,DIGEST-MD5,DIGEST-MD5,DIGEST-MD5,CRAM-MD5,CRAM-MD5,CRAM-MD5", ctx=0x0) at memory.c:642 #5 0x000e3ff0 in ldap_str2charray (str_in=0x2000038 "ï¿½ï¿½ï¿½ï¿½", brkstr=0x19d9a8 ",") at charray.c:188 #6 0x0005af4c in slap_sasl_mechs (conn=0x0) at sasl.c:1277 #7 0x00059264 in root_dse_info (conn=0x1aadeca0, entry=0xf18058c8, text=0x3e8) at root_dse.c:197 #8 0x00018d54 in fe_op_search (op=0x1b28ca0, rs=0xf1805bc4) at search.c:265 #9 0x00018bf8 in do_search (op=0x1b28ca0, rs=0xf1805bc4) at search.c:217 #10 0x00016cac in connection_operation (ctx=0x235778, arg_v=0x1b28ca0) at connection.c:1133 #11 0x000eaa1c in ldap_int_thread_pool_wrapper (xpool=0x190c420) at tpool.c:478 #12 0x9002bd08 in _pthread_body () Short of the duping of the SASL mechanisms (which seems somewhat silly for root_dse), I notice how the generated string seems to be incorrect, i.e., notice how it has "OTPOTP" with a missing comma. Also in #5, there seems to be some issue with a corrupted string getting introduced? There is one other thread in this same function stack: [Switching to thread 4 (core thread 3)] #0 0xffff85d8 in ___spin_lock_relinquish () at /System/Library/Frameworks/System.framework/PrivateHeaders/ppc/cpu_capabilities.h:186 186 in /System/Library/Frameworks/System.framework/PrivateHeaders/ppc/cpu_capabilities.h (gdb) bt #0 0xffff85d8 in ___spin_lock_relinquish () at /System/Library/Frameworks/System.framework/PrivateHeaders/ppc/cpu_capabilities.h:186 #1 0x90003a00 in szone_malloc () #2 0x90003600 in malloc () #3 0x00105d78 in ber_memalloc_x (s=0, ctx=0xffffffc3) at memory.c:226 #4 0x001064bc in ber_strdup_x (s=0x23d536e0 "OTP,OTP,OTPOTP,OTP,OTP,GSSAPI,GSSAPI,GSSAPI,DIGEST-MD5,DIGEST-MD5,DIGEST-MD5,CRAM-MD5,CRAM-MD5,CRAM-MD5,GSSAPI,GSSAPI,GSSAPI,DIGEST-MD5,DIGEST-MD5,DIGEST-MD5,CRAM-MD5,CRAM-MD5,CRAM-MD5", ctx=0x0) at memory.c:642 #5 0x000e3ff0 in ldap_str2charray (str_in=0x0, brkstr=0x19d9a8 ",") at charray.c:188 #6 0x0005af4c in slap_sasl_mechs (conn=0xa0001fac) at sasl.c:1277 #7 0x00059264 in root_dse_info (conn=0x1aadeca0, entry=0xf0c028c8, text=0x1) at root_dse.c:197 #8 0x00018d54 in fe_op_search (op=0x1bdf380, rs=0xf0c02bc4) at search.c:265 #9 0x00018bf8 in do_search (op=0x1bdf380, rs=0xf0c02bc4) at search.c:217 #10 0x00016cac in connection_operation (ctx=0x235778, arg_v=0x1bdf380) at connection.c:1133 #11 0x000eaa1c in ldap_int_thread_pool_wrapper (xpool=0x190c420) at tpool.c:478 #12 0x9002bd08 in _pthread_body () that exhibits the same issue of the SALS mech being OTPOTP. It seems to have a relatively normal string however in #5. Any ideas? --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

2 3

Re: commit: ldap/servers/slapd/back-relay op.c
by Hallvard B Furuseth 19 Jan '08

19 Jan '08

ando(a)OpenLDAP.org writes: > Modified Files: > op.c 1.24 -> 1.25 > rework back-relay internals along Hallvard's suggestions (ITS#5328) Looking closer... The code to handle RB_REFERRAL is unused, since RB_REFERRAL is never passed. Nitpicks: RB_UNWILLING (and its code) can be factored as (LDAP_UNWILLING_TO_PERFORM | RB_ERR | <set sr_text>). Eliminates the RB_UNWILLING case in relay_back_select_backend(). The code looks clearer with the RB_SEND-handling inside the blocks handling RB_ERR. (The code supports sending a result without setting sr_err first, which looks strange. If you used RB_SEND without RB_ERR/RB_REFERRAL.) I'll commit something like this for the two latter, unless you have other plans. (And maybe rename RB_UNWILLING* to RB_UNAVAIL* since it's the <set sr_text to "unavailable in this context> part which differs from what other flags do.) Index: op.c =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/servers/slapd/back-relay/op.c,v retrieving revision 1.26 diff -u -2 -r1.26 op.c --- op.c 16 Jan 2008 21:00:57 -0000 1.26 +++ op.c 18 Jan 2008 14:15:12 -0000 @@ -28,7 +28,8 @@ #define RB_ERR_MASK (0x00FFU) #define RB_ERR (0x1000U) -#define RB_UNWILLING (0x2000U) +#define RB_UNAVAIL_FLAG (0x2000U) #define RB_REFERRAL (0x4000U) #define RB_SEND (0x8000U) +#define RB_UNWILLING (LDAP_UNWILLING_TO_PERFORM|RB_ERR|RB_UNAVAIL_FLAG) #define RB_UNWILLING_SEND (RB_UNWILLING|RB_SEND) #define RB_REFERRAL_SEND (RB_REFERRAL|RB_SEND) @@ -76,13 +77,9 @@ "%s: back-relay for DN=\"%s\" would call self.\n", op->o_log_prefix, op->o_req_dn.bv_val, 0 ); - if ( fail_mode & RB_UNWILLING ) { - rs->sr_err = LDAP_UNWILLING_TO_PERFORM; - - } else if ( fail_mode & RB_ERR ) { + if ( fail_mode & RB_ERR ) { rs->sr_err = rc; - } - - if ( fail_mode & RB_SEND ) { - send_ldap_result( op, rs ); + if ( fail_mode & RB_SEND ) { + send_ldap_result( op, rs ); + } } @@ -148,10 +145,7 @@ } - } else { - if ( fail_mode & RB_ERR ) { - rs->sr_err = rc; - - } else if ( fail_mode & RB_UNWILLING ) { - rc = rs->sr_err = LDAP_UNWILLING_TO_PERFORM; + } else if ( fail_mode & RB_ERR ) { + rs->sr_err = rc; + if ( fail_mode & RB_UNAVAIL_FLAG ) { rs->sr_text = "operation not supported within naming context"; } -- Regards, Hallvard

2 2

ISO C99 features and compatibility
by Matthew Backes 17 Jan '08

17 Jan '08

We've recently stopped pretending to support building slapd with a K&R C compiler; it makes some sense to apply that to the libraries as well. They are designed to be build-able in more places but it makes sense to require at least an ANSI C, considering the amount header cleanup we could do. I'm also interested in potentially requiring some ISO C99 features; in particular variadic macros are very very attractive. In addition to simplifying internal macro design, it allows for a great deal of cleanup and more flexibile macro use in the rest of OpenLDAP. Consider Debug() and Statslog(); currently they are mostly the same, with the idea that Statslog takes two extra dedicated args (for connid and opid), and that Statslog() should appear even in a non- LDAP_DEBUG build. As it sits, they don't share code and are implemented separately. Worse, we have lots of Debug( LDAP_DEBUG_FOO, "foo\n", 0, 0, 0 ); Where the 0's should not be necessary. Consider the case of adding a new compile-optional logging type; one currently needs to extend the macros for Debug() and Statslog() separately, and maintain large and separate ifdef trees for each build-option permutation. A more elegant solution involves using a set of common macros to implement Debug and Statslog internally, but without variadic macros there must be separate implementations for each argument count, which defeats the purpose of unifying them in the first place. Or we could preprocess all of the .c with m4... But really, it seems reasonable to borrow a few features from a standard from 1999. Is anyone actively maintaining OpenLDAP on platforms with no C99ish compiler available? Matthew Backes Symas Corporation mbackes(a)symas.com

3 3

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-devel