openldap-devel

openldap-devel@openldap.org

1418 discussions

Re: RE24 connection code reworking
by William Jojo 23 Jan '09

23 Jan '09

---- Original message ---- >Date: Fri, 23 Jan 2009 09:43:18 -0800 >From: Quanah Gibson-Mount <quanah(a)zimbra.com> >Subject: RE24 connection code reworking >To: openldap-devel(a)openldap.org > >RE24 has had some code reworking in the connections area, due to some race >conditions that were being triggered. It would be useful if people could >test current RE24 to see if they encounter issues. There are still a >number of outstanding issues that need to be resolved before 2.4.14 will be >released, but I'd appreciate a head start on making sure that at least make >test is passing for folks with this new code in place. So far, it does for >both Howard and I, but Michael Ströder has reported failures in his >OpenSuSE builds that we can't reproduce. > Not used to testing from OpenLDAP active tree, but I can do some work for testing on AIX. Do you have a quick link for pulling a copy of the active tree (rsync, cvs, git?) Cheers, Bill >Thanks, >Quanah > >-- > >Quanah Gibson-Mount >Principal Software Engineer >Zimbra, Inc >-------------------- >Zimbra :: the leader in open source messaging and collaboration >

2 1

Re: commit: openldap-guide/admin replication.sdf
by Howard Chu 22 Jan '09

22 Jan '09

ghenry(a)OpenLDAP.org wrote: > Update of /repo/OpenLDAP/pkg/openldap-guide/admin > > Modified Files: > replication.sdf 1.71 -> 1.72 > > Log Message: > (ITS#5843) N-way Multi-master doesn't replicate deletes under certain circumstances. See #5874. MMR is required to work in this circumstance, and the bug needs to be fixed. -- -- 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

back-ldif in HEAD with test011
by Quanah Gibson-Mount 20 Jan '09

20 Jan '09

I got failure because the entries were in a different order: [quanah@freelancer testrun]$ diff -u ldapsearch.flt ldif.flt --- ldapsearch.flt 2009-01-20 13:50:56.000000000 -0800 +++ ldif.flt 2009-01-20 13:50:56.000000000 -0800 @@ -14,15 +14,6 @@ telephoneNumber: +1 313 555 1817 associatedDomain: example.com -dn: cn=Manager,dc=example,dc=com -objectClass: person -cn: Manager -cn: Directory Manager -cn: Dir Man -sn: Manager -description: Manager of the directory -userPassword:: c2VjcmV0 - dn: ou=People,dc=example,dc=com objectClass: organizationalUnit objectClass: extensibleObject @@ -105,6 +96,15 @@ facsimileTelephoneNumber: +1 313 555 2756 telephoneNumber: +1 313 555 8232 +dn: cn=Manager,dc=example,dc=com +objectClass: person +cn: Manager +cn: Directory Manager +cn: Dir Man +sn: Manager +description: Manager of the directory +userPassword:: c2VjcmV0 + dn: cn=Mark Elliot,ou=Alumni Association,ou=People,dc=example,dc=com objectClass: OpenLDAPperson cn: Mark Elliot We may need to change the expectations for this test if ldif is the database. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 1

Re: commit: ldap/servers/slapd connection.c
by Howard Chu 12 Jan '09

12 Jan '09

hyc(a)OpenLDAP.org wrote: > Update of /repo/OpenLDAP/pkg/ldap/servers/slapd > > Modified Files: > connection.c 1.421 -> 1.422 > > Log Message: > ITS#5835 tentative fix - remove bogus call to connection_close(). > Note that with this change, all calls to connection_closing() and > connection_close() always occur in pairs - probably the two > functions should be collapsed into one. Ugh, no, that's not true. connection_closing() is also called by itself in result.c if a write fails, and connection_resched() probably was supposed to catch that too. Need to study this a bit more. -- -- 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

slapd.conf vs slapd.d in the docs
by Gavin Henry 12 Jan '09

12 Jan '09

Hi all, I'm just wondering how we move forward with the docs and the config backend. Should we document examples with both, or only slapd.d or move example config to the appendix and have an appendix for each format so it doesn't clutter the guide. My feeling is the last option is best. Thoughts? Gavin. -- Sent from my mobile device http://www.suretecsystems.com/services/openldap/

5 5

Language bindings
by Lorenzo Pastrana 09 Jan '09

09 Jan '09

Hi, I'm planning to make a v8(http://code.google.com/p/v8/) - ldap binding/extension Trying to do it well, I'd be glad to hear any recommendation ( musts / pitfalls / post mortem / etc. ), as well as any useful documentation / reference / previous works etc. Thanks. Lo. Lorenzo Pastrana - Happy End Vision -------------------------- Web Shop Multimédia Design Visual Communication & Publishing -------------------------- Tél.: +33 1 42 47 83 09 Fax.: +33 1 47 70 70 19 E-mail : lorenzo.pastrana(a)happyend.fr

1 0

Re: commit: ldap/servers/slapd syncrepl.c
by Rein Tollevik 29 Dec '08

29 Dec '08

hyc(a)OpenLDAP.org wrote: > Update of /repo/OpenLDAP/pkg/ldap/servers/slapd > > Modified Files: > syncrepl.c 1.434 -> 1.435 > > Log Message: > ITS#5866 skip CSN check for glue entries > > > CVS Web URLs: > http://www.openldap.org/devel/cvsweb.cgi/servers/slapd/ > http://www.openldap.org/devel/cvsweb.cgi/servers/slapd/syncrepl.c This patch adds test for "!is_entry_glue( rs->sr_entry )" twice, both in the outer and the inner if condition. A suspect it should only have been in the inner condition? Rein

2 1

ITS#5875: build fix for sparc64/gcc-3.3
by manu＠netbsd.org 28 Dec '08

28 Dec '08

Hello If it does not raise any concern, I will commit this patch, which fixes the build on sparc64/gcc-3.3. It has been tested in NetBSD package system for 5 years, so that looks quite safe... -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz manu(a)netbsd.org

2 1

hide attribute
by manu＠netbsd.org 25 Dec '08

25 Dec '08

Hello Many badly designed software fetch all attribute when looking up an user in the directory, instead of just fetching the one they are interested in. My user objects have jpegPhoto attribute, which get fetched with the whole user object. jpegPhoto are big, so this cause unnescesary load on the network and LDAP servers and it slows down login process on the bad software. Setting up ACL to deny read access to jpegPhoto is not always feasible, nor it is easily maintainable. A nicer approach would probably to have a hidden jpegPhoto: it would not be sent to a client requesting all attributes, but a client explicitely requesting a set of attribute including jpegPhoto would get it. AFAIK, there is no way to do that for now. Am I right? I suspect an overlay would be the right way of implementing it (slapo-cloak?). Would it be of enough interest to go into server/slapd/overlays ? If it does, I will contribute it. -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz manu(a)netbsd.org

3 10

Syntax/matching rule implementation - floating point numbers
by Hallvard B Furuseth 17 Dec '08

17 Dec '08

Here are some notes about how slapd implements a syntax/matching rule. I'm moving this to openldap-devel, it seems to belong there by now. A slapd search first uses any indexes to reduce the number of entries to examine, and then it checks these entries against the filter. An index entry contains the indexed value translated to a string which can be compared with simple memcmp(), and a list of entry IDs for the entries that contain that value. So e.g. caseIgnoreMatch translates upper- and lowercase characters to the same character in the index. If (x < y) implies (memcmp(indexed(x), indexed(y)) < 0), then ORDERING match can use indexing - the 'eq' index. Examples include the 'integer' indexing format since OpenLDAP 2.4.7, and 'generalizedTime'. Index keys should not be large, so string indexing stores a hash of the indexed value while integer and generalizedTime use binary formats. The integer index format is quite different from normal binary integer formats, to make ORDERING (i.e. memcmp()) work. You may want to normalize or prettify values received over the protocol before storing them, e.g. store incoming "nan" as "NaN". For syntax/matching rule examples see schema_init.c - for syntax 'foo': syntax_defs[] DESC 'Foo', mrule_defs[] NAME 'fooMatch','fooOrderingMatch'. fooValidate() checks the syntax of an attribute value. fooMatch() implements the EQUALITY and ORDERING rules. fooIndexer(), fooFilter() make the syntax indexable. fooNormalize() normalizes values, so they can be compared just with memcmp(). fooPretty() translates to a nicer to deal with but not normalized value, e.g. with DN syntax CN=foo\,bar ==> cn=foo\2Cbar. For a non-normalized syntax, look at 'foo'='integer'. For a normalized index, look at 'foo'='generalizedTime'. Note that having normalized the value, the 'generalizedTimeMatch' rule in mrule_defs[] simply uses octetStringMatch to compare instead of a more complex rule. 'generalizedTimeOrderingMatch' cannot do that though. If you go for a binary attribute syntax like some IEEE format, ask someone else for advise:-) There is also a distinction between whether such a syntax is transferred with the ";binary" option. (I think certificates must and are transferred as ASN.1 BER values. OTOH Octet String can contain any set of bytes, but is not ;binary.) Regarding a syntax for 'Real': Look at ITS#745 <http://www.openldap.org/its/?findid=745>. Nothing came of it, but maybe the author is around. NaN is a problem. NaN in math does not compare equal to itself, but such behavior would be messy for LDAP values. I haven't tested, but I think you could not have a multi-valued real attribute which contains NaN and some other number: When storing a value, LDAP uses the equality matching rule to check if you are trying to store a duplicate of an existing value. OTOH I expect realOrderingMatch(NaN, anything)=Undefined is OK, but I haven't tested that either. (Remember that LDAP filters have three-valued logic: A compare can return True, False, Undefined. Or an error, which isn't quite the same.) If you make it defined, and if current math practice doesn't say anything, I guess NaN should be larger than other values (except Inf?) to match Server Side Sorting (RFC 2891)'s treatment of absent values. OpenLDAP doesn't implement server side sorting, but people keep asking so maybe it will someday. -- Hallvard

2 5

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