openldap-devel October 2010

openldap-devel@openldap.org

6 participants
8 discussions

OpenLDAP git repo?
by Volker Lendecke 29 Mar '11

29 Mar '11

Hi! Out of several rumors I've heard that OpenLDAP converted it source repo to git. Is that true? www.openldap.org still speaks about cvs. If you changed to git, is the repo publically available? Thanks, Volker

5 12

Info about statically compiled overlays and backends
by Ralf Haferkamp 01 Nov '10

01 Nov '10

Hi, I'd like slapd to be able to report the overlays and backends that are statically compiled into the binary. I am currently thinking about adding that to the -V option, e.g. if slapd is called with -VVV (-VV is already taken it seem) it lists the statically included overlays and backends additionally to the Version Information. Does that make sense or should be introduce another argument for that? Ralf

3 3

overlay development: getting a segfault in over_op_func() [backover.c file]
by Lucas Brasilino 21 Oct '10

21 Oct '10

Hi I'm developing an overlay that intercepts 'modify' operation on an object's userPassword attribute and passes it away to an external helper daemon. This helper daemon does some operations in many places and also does a modification on the sambe object in openldap database. It means that my 'modify' callback at overlay is called twice: the second time is called before the first one completes. I think this behaviour is addressed quite well. I'm using OpenLDAP 2.4.21 to develop and test the overlay. The problem is that slapd is getting a segfault within over_op_func() at line 722 (the 'for' statement): rc = overlay_op_walk( op, rs, which, oi, on ); for ( sc = &op->o_callback; *sc; sc = &(*sc)->sc_next ) { if ( *sc == &cb ) { *sc = cb.sc_next; break; } } Debugging with gdb over_op_func() arguments, either 'op', 'rs' and 'which' are invalids, pointing to invalid locations. The problem occur may hours after slapd is started. Taking a careful looking to overlay, it is doing a few things with op... nothing means it is getting corrupted... It just do: slap_overinst *on = (slap_overinst *) op->o_bd->bd_info; op->o_bd->bd_info = (BackendInfo *)on->on_info; ret = be_entry_get_rw( op, &op->o_req_ndn, NULL, NULL, 0, &e ); op->o_bd->bd_info = (BackendInfo *)on; ... get some attributes with attr_find().... op->o_bd->bd_info = (BackendInfo *)on->on_info; be_entry_release_r(op, e); .... send attributes to helper daemon .... Maybe is happening: 1. op is getting corrupted 2. some function is doing a illegal call to over_op_func() Is there any advice how can I investigate/address this issue? I'll submit this overlay to contrib as it gets stable :) Thanks a lot in advance!! regards Lucas Brasilino

1 0

How to generate a notification?
by CARRE Yann 21 Oct '10

21 Oct '10

Hello I have implemented the RFC 5805 (Transaction) In the RFC, it is required to notify the client in case of transaction abort. Is there any specific OpenLdap API to do it? Is there any example available ? Thanks Yann

1 0

OpenLDAP testing on linuxtesting.org
by Howard Chu 16 Oct '10

16 Oct '10

I just found out about this after seeing a similar note on the libcurl mailing list. It sounds like linuxtesting.org is providing a terrific service, but the test programs need a bit of help. We'd be happy to provide that help, but obviously we can't help anyone who doesn't actually talk to us; it was only pure chance that led me to find these reports. I see from here http://linuxtesting.org/upstream-tracker/test_results/openldap/current/test… 46 tests marked as failed, and 50 warnings. Just looking at the first couple failures, they're complete misuses of the API. #1 ber_bvarray_free() SEGVs because BVarrays must be NULL-terminated, and your test function is just passing in a single BerVal, not a BVarray. #2 ber_decode_oid() SEGVs because as the comment indicates, the outupt BerVal must be initialized with both a buffer pointer and the size of that buffer, and your test function passes an uninit'd BerVal. #3 ber_memvfree() SEGVs because your vector is allocated on the stack, so naturally it cannot be freed. etc... For the warnings #1 you pass a NULL entry pointer, which is of course invalid. Proper code would have checked the return value from ldap_result() first, note that it didn't return any message, and stopped at that point. #50 of course the result is useless because the input is not a proper BER-encoded datum. etc... -- -- 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

Re commit: ldap/libraries/libldap sasl.c
by Howard Chu 15 Oct '10

15 Oct '10

hyc(a)OpenLDAP.org wrote: > Update of /repo/OpenLDAP/pkg/ldap/libraries/libldap > > Modified Files: > sasl.c 1.82 -> 1.83 > > Log Message: > More for prev commit. What about ldap_pvt_sasl_getmechs() ? > > > CVS Web URLs: > http://www.openldap.org/devel/cvsweb.cgi/libraries/libldap/ > http://www.openldap.org/devel/cvsweb.cgi/libraries/libldap/sasl.c > > Changes are generally available on cvs.openldap.org (and CVSweb) > within 30 minutes of being committed. > Please review and comment, thanks. -- -- 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

New plugin: slapd-kinit
by Ralf Haferkamp 14 Oct '10

14 Oct '10

Hi, I am currently coding a small slapd plugin named kinit. All it does is requesting a Kerberos TGT for a configurable principal (default: ldap/<hostname>@REALM) and renews/reinits it when needed using slapd's runqueue. I'd like to submit it to HEAD soon. Where should it go? contrib/slapd- modules/kinit ? -- regards, Ralf

2 1

(Round 3) Proposed patch to support: draft-zeilenga-ldap-c-api-concurrency
by Doug Leavitt 11 Oct '10

11 Oct '10

Since my last patch submission (Round2) I spent a considerable amount of time performing performance analysis of my proposed both client side and server side. The client side testing primarily consisted of running parallel copies of slapd-mtread and monitoring in real time with dtrace to monitor the behavior of all the concurrent threads in clients looking for signs of thread starvation. I was not able to find any. On the server side I performed similar testing while using modified versions of the test036-meta-concurrency and test020-proxycache test cases. Again looking for thread starvation. Additionally, on the server side I setup single server and proxy cache server environments, in combination with slamd to perform head to head comparisons of HEAD (most recently as of 10/7/10) vs. HEAD (most recently as of 10/7/10) and the round 3 MT patches to see if there was any performance degradations or other performance issues, especially related to situations where slapd was using libldap_r as part of various backends. The results of the head to head comparisons, especially in the proxycache situation, show a 3% performance improvement with the MT patches over the HEAD without the patches. The reason according to dtrace outputs is that there are now cases, especially in ldap_result where my proposed patch has up to 50% less calls to thread_lock/unlock than are performed in the current HEAD. All of the head to head dslam/dtrace results are included along with the other patch materials. The proposed patch details are located here: http://cr.opensolaris.org/~djl/openldap-codereview-r3/ Details about the contents of http://cr.opensolaris.org/~djl/openldap-codereview-r3/dtrace is located here: http://cr.opensolaris.org/~djl/openldap-codereview-r3/README.txt Doug.

3 4

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-devel October 2010