openldap-devel

openldap-devel@openldap.org

2 participants
1422 discussions

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

What happened to cvs.openldap.org?
by Michael Ströder 16 Aug '08

16 Aug '08

HI! Since yesterday I can't reach the pserver on cvs.OpenLDAP.org anymore. $ cvs up -Rd . cvs [update aborted]: connect to cvs.OpenLDAP.org(204.152.186.56):2401 failed: Connection refused Ciao, Michael.

2 3

Re: commit: ldap/libraries/libldap ldap-tls.h tls2.c tls_g.c tls_m.c tls_o.c ldap-int.h
by Howard Chu 13 Aug '08

13 Aug '08

hyc(a)OpenLDAP.org wrote: > Update of /repo/OpenLDAP/pkg/ldap/libraries/libldap > > Modified Files: > ldap-int.h 1.189 -> 1.190 > Added Files: > ldap-tls.h NONE -> 1.1 > tls2.c NONE -> 1.1 > tls_g.c NONE -> 1.1 > tls_m.c NONE -> 1.1 > tls_o.c NONE -> 1.1 > > Log Message: > Modular TLS support, proof of concept. tls2.c would replace tls.c, > but I'm leaving tls.c intact for now. The GnuTLS and OpenSSL support are working fine; the MozillaNSS support is still pretty broken; it can't initialize itself. (However, it sort of works when linked into a Mozilla app that already does the NSS initialization. See the patch here https://bugzilla.mozilla.org/show_bug.cgi?id=292127 for one example of to accomplish that.) -- -- 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

HEADS UP: tls restructuring
by Howard Chu 13 Aug '08

13 Aug '08

I've split all of the OpenSSL and GnuTLS-specific code into their own separate source files, to clean up some of the #ifdef mess that was in tls.c before. This approach actually allows support for both to be compiled in at the same time. I'll probably add an LDAP_OPT_X option to select which implementation to use at runtime. (It might make sense to make these dynamically loadable modules, but for now I don't want to make libldap dependent on ltdl/dlopen/whatever.) I have not committed these changes yet. Probably will in the next day or two unless there are objections. There's one user-visible change: get_option(LDAP_OPT_X_TLS_SSL_CTX) now returns a pointer to a privately defined structure. For GnuTLS this is in fact the same behavior as before. For OpenSSL this is a change; it used to return the actual (SSL *). If this is going to break something of yours, holler now... -- -- 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 4

reduced DEFAULT_SEARCH_STACK_DEPTH
by Suhel Momin 11 Aug '08

11 Aug '08

Hi, I want to understand what is the impact of changing following #defines #define DEFAULT_SEARCH_STACK_DEPTH 16 #define MINIMUM_SEARCH_STACK_DEPTH 8 I can see that this value is used to allocate search_stack. I modified these values to #define DEFAULT_SEARCH_STACK_DEPTH 4 #define MINIMUM_SEARCH_STACK_DEPTH 2 This helped in reducing memory footprint however I am not sure about the wide range impact. Thanks, Suhel

2 1

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