openldap-devel

openldap-devel@openldap.org

1416 discussions

RE24 test008 - invalid credentials
by Hallvard B Furuseth 02 Dec '07

02 Dec '07

RE24 passes all tests on RedHat x86_64, but should test008 spew out 'slapd-bind PID=xxxx: ldap_sasl_bind_s: Invalid credentials (49)'? testrun/ and typescript: <http://folk.uio.no/hbf/test008out.tbz>. Configured: --with-tls --with-cyrus-sasl --enable-crypt --enable-aci --enable-unique --enable-null CPPFLAGS=-DLDAP_REL_ENG -- Regards, Hallvard

2 1

Re: Please test RE_24
by Gavin Henry 30 Nov '07

30 Nov '07

<quote who="Quanah Gibson-Mount"> > I've sync'd it up with everything I'm aware of as being pending in > preparation for getting 2.4.7 out this week. Please test. Passes ok on F8 i386. > > Thanks! > > --Quanah > > >

4 12

Re:
by Quanah Gibson-Mount 28 Nov '07

28 Nov '07

--On November 28, 2007 2:34:55 PM -0600 "HORSTMAN, MARK A (ATTSI)" <mh2620(a)att.com> wrote: > I apologize for mailing your directly, but I didn't think this belonged > on the openldap-devel(a)openldap.org list. I read the 'Subject: Please > test RE_24' thread. Is there a place where one might read release notes > for 2.4.7? Please don't email me off the list. There are no release notes currently for OpenLDAP 2.4.7, as it hasn't been released. That's the point of asking for people to test RE24. If you are asking about the CHANGES, you can read them out of CVS for the branch, either via the online CVSWeb at http://www.openldap.org, or by using cvs to check them out from the repository. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: ldapsearch on local attributes with slapo-translucent
by Gavin Henry 28 Nov '07

28 Nov '07

<quote who="Howard Chu"> > Gavin Henry wrote: >> Julien Garnier wrote: >>> Gavin Henry a écrit : >>>> Yes, as I thought. Translucent doesn't return searches on local >>>> attributes. >>>> >>>> One for the to do list then. > > Yes... The original spec for this overlay only required the ability to > search > the remote DB. Searching both requires quite a lot more work. I agree, after poking at the code with my beginner skills. > > One sticking point is that search filters need to be munged; if you send a > filter to the remote server and it mentions attributes that are only known > on > the local server, then you may not get any results back at all. (And vice > versa.) Right. > > E.g., if you have a remote entry containing > uid=foo > and the local translucent entry containing > cn=bar > > and you search for (&(uid=foo)(cn=bar)) then the search will return no > results > unless you rewrite the filter on both the local side and the remote side. > > A solution here would be to add config keywords to control how filters > should > be handled. For any attribute used in a filter, it may be remote only, > local > only, or both local and remote. That could work, as long as you have the correct indexes on local and remote so as not to be a complete hog. > > The processing would go something like - > for the remote search, walk through the filter and nullify any clauses > that > aren't in the list of remote attributes. If the filter collapses down to > nothing, skip the remote search. Otherwise, execute the search and keep a > list > of the results. Right. > for the local search, process the filter as above; if the filter > collapses, > skip the local search. Otherwise, execute the search and keep a list of > the > results. Right. > for each entry in the remote list, look for a corresponding entry in the > local list and the local DB. Merge the entries. > for each entry in the local list, do likewise. > merge the lists > reprocess the list using the original filter. > > Quite a lot of steps. Agreed. My original plan was to merge a remote with a local *and* use rwm to setup different ou etc. for Asterisk Voip accounts to try and map these users to any foreign Directory ;-) Stick rwm in the overlay stack somewhere for a laugh. Gavin.

1 0

Re: ldapsearch on local attributes with slapo-translucent
by Howard Chu 28 Nov '07

28 Nov '07

Gavin Henry wrote: > Julien Garnier wrote: >> Gavin Henry a écrit : >>> Yes, as I thought. Translucent doesn't return searches on local >>> attributes. >>> >>> One for the to do list then. Yes... The original spec for this overlay only required the ability to search the remote DB. Searching both requires quite a lot more work. One sticking point is that search filters need to be munged; if you send a filter to the remote server and it mentions attributes that are only known on the local server, then you may not get any results back at all. (And vice versa.) E.g., if you have a remote entry containing uid=foo and the local translucent entry containing cn=bar and you search for (&(uid=foo)(cn=bar)) then the search will return no results unless you rewrite the filter on both the local side and the remote side. A solution here would be to add config keywords to control how filters should be handled. For any attribute used in a filter, it may be remote only, local only, or both local and remote. The processing would go something like - for the remote search, walk through the filter and nullify any clauses that aren't in the list of remote attributes. If the filter collapses down to nothing, skip the remote search. Otherwise, execute the search and keep a list of the results. for the local search, process the filter as above; if the filter collapses, skip the local search. Otherwise, execute the search and keep a list of the results. for each entry in the remote list, look for a corresponding entry in the local list and the local DB. Merge the entries. for each entry in the local list, do likewise. merge the lists reprocess the list using the original filter. Quite a lot of steps. -- -- 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/

1 0

Re: commit: ldap/servers/slapd connection.c daemon.c proto-slap.h syncrepl.c
by Howard Chu 28 Nov '07

28 Nov '07

hyc(a)OpenLDAP.org wrote: > Update of /repo/OpenLDAP/pkg/ldap/servers/slapd > > Modified Files: > connection.c 1.410 -> 1.411 > daemon.c 1.414 -> 1.415 > proto-slap.h 1.743 -> 1.744 > syncrepl.c 1.370 -> 1.371 > > Log Message: > Streamlined Winsock connection management This patch eliminates all the #ifdef WINSOCK special cases in connection.c, and hides most of the dependencies in daemon.c. Winsock's select() implementation is pretty non-optimal. Unfortunately using the Microsoft-recommended asynchronous functions would implicitly set all the sockets to non-blocking, and stuff like OpenSSL doesn't behave well with non-blocking sockets. For reference, the peak throughput with back-null on the previous code was only 7,800 auths/sec (with 8 client threads). With this patch it's 11,140 auths/sec. In both cases the throughput declines as more client threads are used. (Compare to 35,553 auths/sec for the same machine running Linux, and no drop in throughput all the way up to hundreds/thousands of connections.) Peak throughput on the new code with back-hdb is 7,972 auths/sec (with 12 client threads). With the previous code it was 6,252 auths/sec (with 8 client threads). (The 7,972 figure is also after setting processor affinities for the threads, forcing the listener to use core #0 and forcing the worker threads to use cores #1-7. Without that tweak, the peak is only 7,717/sec.) -- -- 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 6

Please test RE_24
by Quanah Gibson-Mount 27 Nov '07

27 Nov '07

I've sync'd it up with everything I'm aware of as being pending in preparation for getting 2.4.7 out this week. Please test. Thanks! --Quanah

3 2

Re: Empty DN ("") String Value?
by Marc Boorshtein 27 Nov '07

27 Nov '07

Well, based on the discussion I am going to change toString() to return an empty String (""). I think its bad form for an instantiated object to have 'null' for its string representation anyway. Marc

1 0

Dynamic syntax support
by Howard Chu 27 Nov '07

27 Nov '07

Here's a project for someone fairly ambitious: The goal is to be able to dynamically add support for new syntaxes to slapd simply by feeding in their specifications. Typically this would mean feeding in an ABNF description from an IETF document, though it may also mean feeding in ASN.1 documents. E.g., we want to be able to insert (using ldapmodify) the ABNF into an LDAP entry somewhere and have it automatically converted into an executable parser. There are a couple of tools out there for working with ABNF. The IETF actually uses this one http://www.coasttocoastresearch.com/Apg5_0/Apg5_0_description.htm for validating IETF drafts. There's also this one http://www.2p.cz/en/abnf_gen I don't think either of these are suitable as they exist, because they don't generate output that is embeddable and directly executable. I guess you could feed the generated C code into an embedded C interpreter, but that seems like a ridiculously wasteful solution. Most of these existing tools will analyze a grammar and spit out source code to recognize it, but we don't want the source code, we just want the recognition action. I think a more practical route will involve embedding a Forth engine into the OpenLDAP code. There's already been a fair amount of work done with BNF in Forth, so it shouldn't be too hard to get started: http://www.zetetics.com/bj/papers/bnfparse.htm http://www-personal.umich.edu/~williams/archive/forth/strings/index.html http://www-personal.umich.edu/~williams/archive/forth/strings/expr.html The nice thing about Forth is that the core language is tiny, it's extremely portable, it's extremely extensible, and any implementation is inherently both an interpreter and a compiler. As interpreted languages goes, it beats pretty much every other common scripting language for memory and CPU efficiency. It ought to be straightforward to convert a grammar into a set of Forth words to recognize the grammar, for a slapd syntax validator. I'm not sure yet what we would do for Prettifiers or Normalizers, nor what to do for Matching rules. We could simply accept them as Forth source code. Personally I haven't written Forth in over 20 years but it seems to me that a TIL is the most suitable type of language for the job. On the whole it doesn't seem like new syntaxes pop up in LDAP specs very often. Some may say this is because they're not really needed. I believe they've been sorely needed, and people have just avoided them because they required too much work to properly support in existing implementations. We can fix that. -- -- 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 5

Re: Empty DN ("") String Value?
by Hallvard B Furuseth 26 Nov '07

26 Nov '07

Emmanuel Lecharny wrote: > This is starting to be confusing. The initial question was : Uh, right... I was halfway answering the question which is too short, halfway Michael. > "Should the toString() method of a class that represents a DN return > null or an empty string?" If a class represents a DN, toString() sounds like it should return that DN's string representation as described in RFC 4514. If you mean to ask what to return when a class instance represents an _empty_ DN, then the string representation is "". toString() not returning a string sounds strange to me whatever the object represents, but maybe that's because I don't know java. But NULL ought to mean "no dn", not "the empty dn". -- Regards, Hallvard

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-devel