openldap-devel

openldap-devel@openldap.org

1416 discussions

Plans for 2.4.24?
by Michael Ströder 06 Dec '10

06 Dec '10

HI! Given the stability-related fixes in HEAD recently I wonder what the plans for releasing 2.4.24 are. When will backporting to OPENLDAP_REL_ENG_2_4 start? Sorry, I'm not a C programmer. I can only help testing. Ciao, Michael.

3 2

Re: (ITS#6710) Mods already refreshed on a forwarding server is lost by its consumer
by Rein Tollevik 22 Nov '10

22 Nov '10

[I have switched this thread from -its to -devel] On 11/22/10 1:31 , Howard Chu wrote: > rein(a)OpenLDAP.org wrote: >> On 11/15/10 16:39 , rein(a)OpenLDAP.org wrote: >>> New syncprov consumers connecting to a forwarding server and >>> presenting an >>> apperently up-to-date cookie will loose any mods that have already >>> taken place >>> on the forwarding server if it itself is refreshing from its >>> provider. This >>> should not be a problem if the forwarding server have a sufficiently >>> large >>> syncprov log, but a fix for servers without is coming. >> The currently committed fix for this its leaves one problem open. If a >> forwarding server restarts in the middle of the refresh phase, after >> making some changes but before updating the csn, new consumers >> connecting with an apparently up to date csn set after the server comes >> up again will not know that the context is dirty and will loose these >> changes. The same problem arise if the server restarts between the time >> a locally initiated delete operation is performed in the database and >> the accompanying csn set is saved. >> >> A fix could be to always assume the context is dirty after start up, and >> thereby forcing all clients to undergo the refresh phase even if they >> are in sync until some operation that updates the csn set is performed. >> An unnecessary refresh is probably better than loosing changes.. > > I haven't had the opportunity to review these patches yet, but the bug > description sounds a little flaky to me. This ITS as well as the previous should probably have mentioned that they are related to refreshAndPersist replication. > The original design is this: when a consumer requests a refresh from the > provider, the provider uses a snapshot of its current contextCSN. All > changes from the consumer's cookie to this snapshot (inclusive) are sent > to the consumer. Any changes currently in progress that have not yet > been committed will be skipped until the next refresh. Nothing is lost, > it's simply delayed, and that's in accordance with syncrepl's "eventual > convergence" model. This is true for the refresh only configuration, I guess these problems don't show up there as they will be fixed during the next refresh. But if the persist phase is entered without a proper refresh first then the consumer have forever lost the missing changes. Or well, until the admin forces a full refresh that is. > Likewise, the provider only updates its contextCSN when a change is > fully committed. syncprov should NOT need to defer any consumer while it > has outstanding mods. There is no reason that would be needed by the > sync protocol. This ITS does not delay the consumer, it forces a refresh even if the consumer appear to be in sync with the provider (from looking at the CSNs of the provider and consumer). ITS#6709 introduce a delay, this is not dictated by the protocol but by the implementation. syncprov_matchops() decide which consumers the change should be sent to before the change is actually made to the db. This leaves a window where a consumer may connect and apparently be in sync, enter its persistent phase but not receive the changes that was active when it connected. Waiting for this active change to complete before deciding whether the consumer is in sync or not closes this window. > Servers only update their contextCSN after an entire refresh has > completed. If a downstream consumer connects while a forwarder is still > refreshing, the consumer should receive nothing. (Or, it should only > receive the changes between its cookie and the server's committed > contextCSN, if any.) The consumer connects and appear to be in sync with the provider, therefore the provider initiates the persistent phase immediately without any refresh first. Without the fix in this ITS syncprov had no idea that there was uncommitted changes (i.e changes not accompanied by a CSN update) within its context, changes that requires the refresh phase to be performed even when an consumer that appear to be in sync connects. And an restart of the provider at the inappropriate time can make it loose this knowledge again as I outlined in my first reply. Yes, in refresh only mode the server sends the changes between the cookie the consumer presented and the servers committed csn. But in the refresh phase of refreshAndPersistent mode it sends all changes newer than the consumers csn. Which opens the windows where the ITS#6709 and ITS#6710 cases can loose modifications. > You may very well have found bugs in the implementation, but it sounds > to me like you've changed the overall behavior to something outside of > the original design. No, I don't think I have changed the design, if it was changed then it was the persistent mode that did it.. Rein

1 0

tab-width 4 and line length < 80, please
by Hallvard B Furuseth 22 Nov '10

22 Nov '10

A reminder: The OpenLDAP source code uses tab-width 4 and generally lines < 80 chars. Please commit code written the same way, except in files that are already written with tab-width 8. Some people have been committing with tab-width 8, so the code now contains a mixture of tab-width 4 and 8, but it still mostly looks better with the original setting. Maybe we'll reformat the entire source tree someday, but that's not happened yet. To take a simple example, look at #defines and structs in ldap.h. At the top, someone has been using tab-width 8, but further down we get: [Displayed with tab-width 8] typedef struct ldapcontrol { char * ldctl_oid; /* numericoid of control */ struct berval ldctl_value; /* encoded value of control */ char ldctl_iscritical; /* criticality */ } LDAPControl; [Displayed with tab-width 4] typedef struct ldapcontrol { char * ldctl_oid; /* numericoid of control */ struct berval ldctl_value; /* encoded value of control */ char ldctl_iscritical; /* criticality */ } LDAPControl; One can write code which displays OK both ways, if anyone prefers that: * Do not use tabs after non-whitespace. - Put comments above instead of to the right of code. - Do not line up variables in declarations, use a single space. * Or: Align with with spaces instead of tabs. But in that case, only align on lines that have the same indentation. I.e. not if (foo) /* hi there */ bar(); /* ho there */ -- Hallvard

1 0

test061
by Rein Tollevik 21 Nov '10

21 Nov '10

I have finally found some time to look at openldap stuff again, and have been implementing the changes required to fix the final failures in test058. But to my annoyance the race tests continued to fail :-( It turns out that in addition to exercise the race condition outlined in test058 it managed to fall into a stream of other race conditions. These races are not related to the test058 configuration but to the initiation of the syncrepl refresh phase. The new test061 runs an extended version of the race test from test058, but in a simplified configuration. So far I have found and (hopefully) fixed 4 race conditions, and seen the glimpse of 2 or 3 more problems. ITSes and fixes are coming, but as of now you should expect test061 to fail occasionally. Rein

3 2

use of alloca()
by Howard Chu 05 Nov '10

05 Nov '10

A lot of what sl_malloc() is used for was really intended for a function that behaves like alloca(). What problems are we signing up for by allowing use of alloca()? -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

3 3

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

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-devel