openldap-devel

openldap-devel@openldap.org

1416 discussions

changes to distributed collect.c overlay
by Brett ＠Google 10 Sep '08

10 Sep '08

In the event somebody may find this useful, attached is a patch to HEAD to allow a simple form of attribute inheritance. It has also been contributed as ITS#5659.. (the patch in ftp /incoming is newer than the one in the tarball) If anyone wants to try it out, please do and let me know if there are any issues.. (this is a simple change to a demo overlay Howard Chu did some time ago, which is not built by default)

2 4

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

poll/epoll patch for libldap?
by Nicholas Dronen 28 Aug '08

28 Aug '08

Hi: I work on a commercial server application, a gateway, which uses pam_ldap to authenticate users in some situations. As a server application, it can easily exceed the 1024 default file descriptor limit of select(2), which has bitten us recently. Since the server application ships in an appliance, we can provide a patch in the form of an OpenLDAP RPM that's been recompiled with -DOPENLDAP_FD_SETSIZE. That fixes the immediate problem for us, but would you be willing to accept a patch to libldap that gave developers a programmatic way to use poll or epoll instead of having to recompile? Regards, Nick

5 8

Re: commit: openldap-guide/admin replication.sdf
by ghenry＠OpenLDAP.org 18 Aug '08

18 Aug '08

----- ghenry(a)OpenLDAP.org wrote: > Update of /repo/OpenLDAP/pkg/openldap-guide/admin > > Modified Files: > replication.sdf 1.62 -> 1.63 > > Log Message: > To do list review: small typo quick fix. This means the following list I've just compiled whilst reviewing the current state of the admin guide and my own todos: # OpenLDAP Test suite * Go through Samba stuff again # OpenLDAP contrib scripts for generating LDIF etc. # OpenLDAP Admin Guide - * Intro o Tighten "LDAP vs RDBMS" o Check "What is slapd and what can it do?" o "Replicated Directory Service" - add MultiMaster picture. * "Configuring slapd" - check DIT layout is right * "The slapd Configuration File" - check backends are correct and in above * "Access Control" - Finish "Converting from slapd.conf(5) to a cn=config directory format" * Backends section to finish * Overlays section to finish * Maintenance section to finish * Monitoring section to finish * Tuning section to finish * More in Troubleshooting section * More in Upgrading from 2.3.x section * Check "Recommended OpenLDAP Software Dependency Versions" section * Do some "Real World OpenLDAP Deployments and Examples" * "OpenLDAP Software Contributions" to complete * "Configuration File Examples" to complete Just e-mailing here for reference. If anyone sees any quick grabs they are interested in ;-) Thanks, Gavin. -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

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