openldap-bugs

openldap-bugs@openldap.org

1 participants
20959 discussions

Re: (ITS#6299) Support for RFC 4529 in slapo-allowed
by michael＠stroeder.com 23 Sep '09

23 Sep '09

masarati(a)aero.polimi.it wrote: >> If the client wants to request via slapo-allowed which attributes are >> readable/writeable before adding another object class then object classes >> not >> yet part of the entry could be used if the client adds the object class >> name >> prefixed with @. This is an extension to the semantics but should not >> cause any >> problem with existing clients. > > with the current implementation of slapo-allowed, the client does not do > anything specific but requesting those special operational attributes. Yes. That's what I've implemented. Well, what slapo-allowed and MS AD implement is limited anyway. E.g. no way to determine writeable attrs when adding new entries. > It is not clear to me how the semantics you propose should be activated. > If you mean that having some "@" + <objectClass> in the requested attrs > should populate the allowedAttributes and allowedAttributesEffective > attributes, I think it would be a significant distortion of the meaning of > the requested attributes. Yes, my suggestion was that slapo-allowed looks at the attr list in the search request for occurences of "@" + <objectClass>. And then use each <objectClass> (if not yet in the set of current object classes of the entry) to evaluate the accompanying attrs and put them into allowedAttributes and/or allowedAttributesEffective. Yes, that's a change in the current semantics. I now partially worked around the problem with new object classes in web2ldap by determining which attrs would be really new when adding a set of object classes enabling all the input fields for these new attrs. But off course that's not nice. > I'd rather favor defining a specific control request, that sort of > "mimics" adding some attributes, including objectClass values, to an > existing entry, so that allowedAttributes and allowedAttributesEffective > are populated accordingly. There are some implementations of the Get Effective Rights control but they seem to slightly differ. Ciao, Michael.

1 0

Re: (ITS#6302) second-guessing of libsasl ABI is incorrect for Linux distributions
by vorlon＠debian.org 23 Sep '09

23 Sep '09

--BXVAT5kNtrzKuDFl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Patch attached. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slangasek(a)ubuntu.com vorlon(a)debian.org --BXVAT5kNtrzKuDFl Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=do-not-second-guess-sonames Rip out code that second-guesses the libsasl soname / Debian shlibs. If cyrus sasl upstream is breaking the ABI, this needs to be fixed upstream there, not kludged around upstream here! Debian bug #546885 Upstream ITS #6302 filed. Index: trunk/libraries/libldap/cyrus.c =================================================================== --- trunk.orig/libraries/libldap/cyrus.c +++ trunk/libraries/libldap/cyrus.c @@ -78,28 +78,6 @@ /* XXX not threadsafe */ static int sasl_initialized = 0; -#ifdef HAVE_SASL_VERSION - /* stringify the version number, sasl.h doesn't do it for us */ -#define VSTR0(maj, min, pat) #maj "." #min "." #pat -#define VSTR(maj, min, pat) VSTR0(maj, min, pat) -#define SASL_VERSION_STRING VSTR(SASL_VERSION_MAJOR, SASL_VERSION_MINOR, \ - SASL_VERSION_STEP) - { int rc; - sasl_version( NULL, &rc ); - if ( ((rc >> 16) != ((SASL_VERSION_MAJOR << 8)|SASL_VERSION_MINOR)) || - (rc & 0xffff) < SASL_VERSION_STEP) { - char version[sizeof("xxx.xxx.xxxxx")]; - sprintf( version, "%u.%d.%d", (unsigned)rc >> 24, (rc >> 16) & 0xff, - rc & 0xffff ); - - Debug( LDAP_DEBUG_ANY, - "ldap_int_sasl_init: SASL library version mismatch:" - " expected " SASL_VERSION_STRING "," - " got %s\n", version, 0, 0 ); - return -1; - } - } -#endif if ( sasl_initialized ) { return 0; } Index: trunk/servers/slapd/sasl.c =================================================================== --- trunk.orig/servers/slapd/sasl.c +++ trunk/servers/slapd/sasl.c @@ -1135,26 +1135,6 @@ #endif #ifdef HAVE_CYRUS_SASL -#ifdef HAVE_SASL_VERSION - /* stringify the version number, sasl.h doesn't do it for us */ -#define VSTR0(maj, min, pat) #maj "." #min "." #pat -#define VSTR(maj, min, pat) VSTR0(maj, min, pat) -#define SASL_VERSION_STRING VSTR(SASL_VERSION_MAJOR, SASL_VERSION_MINOR, \ - SASL_VERSION_STEP) - - sasl_version( NULL, &rc ); - if ( ((rc >> 16) != ((SASL_VERSION_MAJOR << 8)|SASL_VERSION_MINOR)) || - (rc & 0xffff) < SASL_VERSION_STEP) - { - char version[sizeof("xxx.xxx.xxxxx")]; - sprintf( version, "%u.%d.%d", (unsigned)rc >> 24, (rc >> 16) & 0xff, - rc & 0xffff ); - Debug( LDAP_DEBUG_ANY, "slap_sasl_init: SASL library version mismatch:" - " expected %s, got %s\n", - SASL_VERSION_STRING, version, 0 ); - return -1; - } -#endif sasl_set_mutex( ldap_pvt_sasl_mutex_new, --BXVAT5kNtrzKuDFl--

1 0

(ITS#6302) second-guessing of libsasl ABI is incorrect for Linux distributions
by vorlon＠debian.org 23 Sep '09

23 Sep '09

Full_Name: Steve Langasek Version: 2.4.17 OS: Debian URL: http://bugs.debian.org/546885 Submission from: (NULL) (66.93.39.86) Debian bug #546885 reports a problem with the Debian package of slapd aborting because it's running against an older version of libsasl than the one it was built against. Distribution packaging systems have provisions for declaring versioned dependencies when necessary, slapd should not have a blanket rule that assumes preceding versions of libsasl are incompatible: - if two versions of libsasl are incompatible but this has not been declared by way of an soname change, this is a bug in the library that should be forwarded to the libsasl upstream, not papered over in slapd - the version check assumes that running against an *older* libsasl than the one built against is a problem, but running against a *newer* libsasl is not, when I don't see any reason that should be the case. patch to remove this version check follows; it has been applied to the Debian openldap package.

1 0

Re: (ITS#6301) PATCH - used red-black tree for response messages
by hyc＠symas.com 23 Sep '09

23 Sep '09

bduncan(a)apple.com wrote: > Full_Name: Bryan Duncan > Version: 2.4.16 > OS: Mac OS X 10.6 > URL: ftp://ftp.openldap.org/incoming/bryan-duncan-rbtree-090922.patch > Submission from: (NULL) (17.224.21.109) > > > Uploaded patch that replaces the linked-list of response messages with a > red-black tree. This improves performance since random access to the response > messages is needed. > Hmm, there is no such file at the above URL. Also, while I don't doubt that a tree structure beats a linked list for performance, could you please describe the analysis that led you to writing this patch? What problem were you tracking, and what situation caused it? Why did you use a red-black tree, rather than just using the AVL code that's already in the source? In the future it would be a good idea to raise these topics on the openldap-devel mailing list before diving in, since this is core functionality and performance-related. Performance patches don't get committed without test results showing a clear before/after gain. -- -- 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

Re: (ITS#6299) Support for RFC 4529 in slapo-allowed
by masarati＠aero.polimi.it 22 Sep '09

22 Sep '09

> If the client wants to request via slapo-allowed which attributes are > readable/writeable before adding another object class then object classes > not > yet part of the entry could be used if the client adds the object class > name > prefixed with @. This is an extension to the semantics but should not > cause any > problem with existing clients. with the current implementation of slapo-allowed, the client does not do anything specific but requesting those special operational attributes. It is not clear to me how the semantics you propose should be activated. If you mean that having some "@" + <objectClass> in the requested attrs should populate the allowedAttributes and allowedAttributesEffective attributes, I think it would be a significant distortion of the meaning of the requested attributes. I'd rather favor defining a specific control request, that sort of "mimics" adding some attributes, including objectClass values, to an existing entry, so that allowedAttributes and allowedAttributesEffective are populated accordingly. p.

1 0

Re: (ITS#6300) Add kqueue support to slapd
by bduncan＠apple.com 22 Sep '09

22 Sep '09

On Sep 22, 2009, at 1:02 PM, Quanah Gibson-Mount wrote: > --On Tuesday, September 22, 2009 7:23 PM +0000 bduncan(a)apple.com > wrote: > >> Subject should have been: "PATCH - Added kqueue support to slapd" to >> make clear this ITS tracks a patch that has been submitted. > > What OS(es) has this kqueue support been tested with? For example, > the last time I looked at kqueue on OSX 10.5, it was very marginal, > and missing most of the important pieces, which meant it wouldn't > work for OpenLDAP or Postfix, etc. It was tested on OS X 10.6. Should work on all BSDs; nothing OSX- specific about the kqueue usage in the patch. As far as kqueue support in OS X 10.5, from what I see, most everything is there. Certainly all of the kqueue features in this patch are supported in OS X 10.5. -- Bryan Duncan

1 0

Re: (ITS#6300) Add kqueue support to slapd
by quanah＠zimbra.com 22 Sep '09

22 Sep '09

--On Tuesday, September 22, 2009 7:23 PM +0000 bduncan(a)apple.com wrote: > Subject should have been: "PATCH - Added kqueue support to slapd" to > make clear this ITS tracks a patch that has been submitted. What OS(es) has this kqueue support been tested with? For example, the last time I looked at kqueue on OSX 10.5, it was very marginal, and missing most of the important pieces, which meant it wouldn't work for OpenLDAP or Postfix, etc. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6300) Add kqueue support to slapd
by bduncan＠apple.com 22 Sep '09

22 Sep '09

Subject should have been: "PATCH - Added kqueue support to slapd" to make clear this ITS tracks a patch that has been submitted. -- Bryan

1 0

(ITS#6301) PATCH - used red-black tree for response messages
by bduncan＠apple.com 22 Sep '09

22 Sep '09

Full_Name: Bryan Duncan Version: 2.4.16 OS: Mac OS X 10.6 URL: ftp://ftp.openldap.org/incoming/bryan-duncan-rbtree-090922.patch Submission from: (NULL) (17.224.21.109) Uploaded patch that replaces the linked-list of response messages with a red-black tree. This improves performance since random access to the response messages is needed.

1 0

(ITS#6300) Add kqueue support to slapd
by bduncan＠apple.com 22 Sep '09

22 Sep '09

Full_Name: Bryan Duncan Version: 2.4.16 OS: Mac OS X 10.6 URL: ftp://ftp.openldap.org/incoming/bryan-duncan-kqueue-090922.patch Submission from: (NULL) (17.224.21.109) Added support for using kqueue in slapd (for systems that support kqueue(2).

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