OpenLDAP git repo?
by Volker Lendecke
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
12 years, 8 months
Info about statically compiled overlays and backends
by Ralf Haferkamp
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
13 years
overlay development: getting a segfault in over_op_func() [backover.c file]
by Lucas Brasilino
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
13 years, 1 month
How to generate a notification?
by CARRE Yann
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
13 years, 1 month
OpenLDAP testing on linuxtesting.org
by Howard Chu
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/te...
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/
13 years, 1 month
New plugin: slapd-kinit
by Ralf Haferkamp
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
13 years, 1 month
(Round 3) Proposed patch to support: draft-zeilenga-ldap-c-api-concurrency
by Doug Leavitt
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.
13 years, 1 month
