openldap-devel January 2008

openldap-devel@openldap.org

17 participants
20 discussions

dITStructureRules/nameForms in subschema subentry for informational purpose
by Michael Ströder 21 Mar '09

21 Mar '09

HI! Discussed this very briefly with Howard at LDAPcon 2007 based on an idea of Steve: Support for dITStructureRules and nameForms is still in OpenLDAP's TODO. In the meanwhile slapd could accept definitions for both in slapd.conf and simply pass them on to a schema-aware LDAP client for informational purpose without enforcing them. Same function like rootDSE <file> in slapd.conf. Opinions? Ciao, Michael. -- Michael Ströder E-Mail: michael(a)stroeder.com http://www.stroeder.com

2 4

managing OpenLDAP / back-config
by Ralf Haferkamp 17 Jun '08

17 Jun '08

With the great features that back-config provides to configure OpenLDAP servers at runtime it seems logical to start thinking about providing tools that could help to leverage those features. Currently to manage an OpenLDAP server through back-config you have the option to use either a generic LDAP Browser (JXplorer, Apache LDAP Studio, web2ldap), the OpenLDAP command line tools (ldapsearch, ldapmodify, ...) or homegrown software using one of the available LDAP APIs. I think it would be helpful to have some more sophisticated management tools (Commandline and/or GUI). In order to get there I think it could be helpful to create an API dedicated to provide an easy way to access the OpenLDAP configuration (databases, overlays, schema, access control, ...). This API could then be used to create different flavors of management tools. I have not yet spend too much time thinking about the design of such an API. Neither about the programming language that I'd use to implement something like this (Python, C, C++, ?). I first like to get a feeling how others think about this and if anybody is interested in collaborating on such an API. So please feel free to reply with your comments and suggestions :) -- regards, Ralf

7 24

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

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

slapo-constraint type uri: Constrained attribute used in LDAP URL
by Michael Ströder 17 Jan '08

17 Jan '08

HI! Consider the following config for slapo-constraint in slapd.conf: constraint_attribute ou uri ldap:///o=Test Company?ou?sub?(objectClass=organizationalUnit) With this example the constrained attribute is the same like the one used in the LDAP URL. Now how are entries handled which are search results of the LDAP URL? In this example how to deal with new values of attribute 'ou' in case of adding a new entry with object class 'organizationalUnit'? Ciao, Michael.

2 6

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-devel January 2008