openldap-devel September 2008

openldap-devel@openldap.org

16 participants
27 discussions

Re: commit: ldap/tests/data slapd.conf
by Howard Chu 10 Sep '08

10 Sep '08

> * From: ando(a)OpenLDAP.org > * Date: Sat, 19 Jul 2008 09:54:38 GMT > * Auto-submitted: auto-generated (OpenLDAP-CVS) > > Update of /repo/OpenLDAP/pkg/ldap/tests/data > > Modified Files: > slapd.conf 1.43 -> 1.44 > > Log Message: > add checkpoint as required What was the motivation for this change? It's pummeling the hell out of my laptop hard drive... -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

2 2

Re: commit: ldap/build db.4.2.52.patch
by Kurt Zeilenga 09 Sep '08

09 Sep '08

On Sep 8, 2008, at 2:32 PM, quanah(a)openldap.org wrote: > Update of /repo/OpenLDAP/pkg/ldap/build > > Removed Files: > Tag: OPENLDAP_REL_ENG_2_4 > db.4.2.52.patch 1.1.2.1 -> NONE > > Log Message: > bdb 4.2 no longer supported by OL 2.4. Will keep the file in HEAD > for posterity In the past, we would delete any file not currently in use from HEAD as well. It will be in the Attic for posterity. > > > > CVS Web URLs: > http://www.openldap.org/devel/cvsweb.cgi/build/ > http://www.openldap.org/devel/cvsweb.cgi/build/db.4.2.52.patch > > Changes are generally available on cvs.openldap.org (and CVSweb) > within 30 minutes of being committed.

1 0

malloc without check
by andreas moroder 09 Sep '08

09 Sep '08

Hello, in servers/slapd/add.c int the function slap_entry2mods() malloc() is called three times and the result is not checked against NULL. Bye Andreas

2 1

collective attributes (the hard way)
by Brett ＠Google 07 Sep '08

07 Sep '08

Having worked on the simple / practical way of getting collective attributes, my next task is to investigate and possibly fix ? the more complex but ultimately more complete, collective attribute scheme, which is used when you declare an object in the schema with COLLECTIVE (eg. in collective.schema). So far, i have worked out how to create a collective definition, but it has no effect as i'm presuming *subtreeSpecification* is currently unimplemented. Can somebody please check i have the below correct at least. I have declared the following : dn: cn=template1,o=openldap,c=AU *objectClass: collectiveAttributeSubentry objectClass: subentry objectClass: top* cn: template1 *subtreeSpecification: { base "ou=test1,o=openldap,c=AU" }* createTimestamp: 20080906145020Z creatorsName: cn=Manager,c=AU entryCSN: 20080906145740.998417Z#000000#000#000000 entryDN: cn=template1,o=openldap,c=AU entryUUID: df2317c6-106e-102d-82e5-ffce2194e1a8 hasSubordinates: FALSE modifiersName: cn=Manager,c=AU modifyTimestamp: 20080906145740Z structuralObjectClass: subentry subschemaSubentry: cn=Subschema This appears to set up the collective attributes, and where they should apply but has no effect. Presumably this is because c-PostalAddress and/or c-PostalCode (as defined in collective.schema) are not present. Well there are no suplimentary objectclases that allow these attributes, so i tried adding the extensibleObject objectclass, and then added the c-PostalCode and c-PostalAddress attributes. This gave me : dn: cn=template1,o=openldap,c=AU objectClass: collectiveAttributeSubentry *objectClass: extensibleObject* objectClass: subentry objectClass: top cn: template1 subtreeSpecification: { base "ou=test1,o=openldap,c=AU" } *c-PostalAddress: 123 Someplace St c-PostalCode: 9999* createTimestamp: 20080906145020Z creatorsName: cn=Manager,c=AU entryCSN: 20080906145740.998417Z#000000#000#000000 entryDN: cn=template1,o=openldap,c=AU entryUUID: df2317c6-106e-102d-82e5-ffce2194e1a8 hasSubordinates: FALSE modifiersName: cn=Manager,c=AU modifyTimestamp: 20080906145740Z structuralObjectClass: subentry subschemaSubentry: cn=Subschema (Incidentally very impressed that Apache Directory Studio can handle the above subschema stuff quite competently) So although the configuration information is now present, i assume there is nothing actually using or applying this data. If i understand the above correctly, the intent is to apply the above values in c-PostalAddress and c-PostalCode, to the matching attributes postalAddress and postalCode for all entries under base "ou=test1,o=openldap,c=AU", with no exclusions I'm thinking that it is a requirement to efficiently keep a list of objects matching (objectClass=collectiveAttributeSubentry) and then applying the specifications therein to search results. The existing collect overlay is a simple demonstration overlay, which keeps only a simple static definition which never changes, so does not implement collective attributes in the more complex dynamic form. To implement collective attributes fully (and as declared in collective.schema) this meta data would need to be dynamic, but without the overhead of continually searching for new things matching (objectClass=collectiveAttributeSubentry) which would trash performance. Any thoughts on how to go about implementing this ? Cheers Brett

2 3

line numbers in openldap debugging
by Brett ＠Google 05 Sep '08

05 Sep '08

Is there any special magic to get source line numbers in gdb (bt or bt full) ? I tried : CFLAGS="-g -g3 -ggdb -ggdb3" --enable-slapd --enable-shared --enable-overlays --disable-ipv6 --with-threads --enable-ssl --enable-collect --enable-debug The CFLAGS added the gdb options when compiling, but did not provide any line numbers for openldap source when doing backtraces under gdb.. Cheers Brett

2 1

postalAddress matching rule
by Brett ＠Google 05 Sep '08

05 Sep '08

Hello, I've just submitted a patch to help make the collect overlay (attribute inheritance) a bit more useful (ITS#5659). As part of my testing work for the above i once accidentally created a postalAddress attribute with two values. When i tried to remove the extra attribute value it failed, the error i got was something like that there is no matching rule for postalAddress, which if there really isn't then it's probably a reasonable thing for slapd to complain about, as it wont be able to tell the individual values of postalAddress apart. So to put it in a nutshell, i'm willing to have a go implementing a postalAddress matching rule, but i was wondering if anyone has any thoughts where i might begin, and/or any pointers as to which file(s) implement the matching rules. Cheers Brett

4 13

Re: commit: ldap/servers/slapd/back-bdb id2entry.c
by Howard Chu 02 Sep '08

02 Sep '08

ando(a)OpenLDAP.org wrote: > Update of /repo/OpenLDAP/pkg/ldap/servers/slapd/back-bdb > > Modified Files: > id2entry.c 1.87 -> 1.88 > > Log Message: > don't dereference NULL pointers (ITS#5676) > Nice catch. But, since txn's are always being used now, you should simply have changed the outer "if (txn)" to "if (boi)". -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-devel September 2008