openldap-bugs

openldap-bugs@openldap.org

1 participants
20965 discussions

Re: (ITS#5401) slapd crashes in mirrormode
by ali.pouya＠free.fr 25 Mar '08

25 Mar '08

Howard Chu wrote : >A patch for this is now in CVS HEAD. Please test. >I was unable to reproduce the reported crash, so your feedback is important >here. Hi Howard; We tested the HEAD extracted march 18 around 16h GMT. It's OK. Thanks a lot. The ITS can be closed. Best regards Ali

1 0

Re: ACLs broken by ITS#5419
by rein＠basefarm.no 24 Mar '08

24 Mar '08

On Mon, 24 Mar 2008, Howard Chu wrote: > rein(a)basefarm.no wrote: >> >> The change to servers/slapd/backend.c for ITS#5416 seem to have broken the >> ability for group and set statements in access control lines to refer to >> entries >> outside the backend currently being operated on. > > That ability was never intended in the first place. Historically, backends in > slapd have been treated as isolated DSAs with no connection to each other. > They've required special mechanisms (like back-relay or slapo-glue) to be > joined. Yes, I know, the change that allowed this was imo the one that made sets and groups really useful. Our database configuration still has traces of the workarounds the lack of this feature once forced us to make.. But, the latest change also removes this ability for databases subordinate to the same common superior (i.e using the slapo-glue). If I understand you correct it is a bug that glue'ed databases cannot refer to each other, although I still consider it a bug (or at least a huge drawback) if this would no longer be generally possible. Rein

1 0

Re: ACLs broken by ITS#5419
by hyc＠symas.com 24 Mar '08

24 Mar '08

rein(a)basefarm.no wrote: > Full_Name: Rein Tollevik > Version: CVS head > OS: linux, solaris > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (84.215.2.34) > > > The change to servers/slapd/backend.c for ITS#5416 seem to have broken the > ability for group and set statements in access control lines to refer to entries > outside the backend currently being operated on. That ability was never intended in the first place. Historically, backends in slapd have been treated as isolated DSAs with no connection to each other. They've required special mechanisms (like back-relay or slapo-glue) to be joined. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

ACLs broken by ITS#5419
by rein＠basefarm.no 24 Mar '08

24 Mar '08

Full_Name: Rein Tollevik Version: CVS head OS: linux, solaris URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.215.2.34) The change to servers/slapd/backend.c for ITS#5416 seem to have broken the ability for group and set statements in access control lines to refer to entries outside the backend currently being operated on. This is caused by op->op_bd being set back to the backend being operated on when backend_group() was called, not the backend returned by select_backend() for the group being referred to as was always done before this change was made. >From what I can see of the cases where backend_group() is called (i.e in ACLs, limits and the dynlist and dyngroup overlays) I think the correct fix is to back out this changes as far as that function is conserned. But I don't know enough of other consequences, so I haven't tried it. Rein Tollevik Basefarm AS

1 0

Re: (ITS#5434) syncprov in a glue'ed environment must search through the glue overlay
by rein＠basefarm.no 23 Mar '08

23 Mar '08

On Wed, 19 Mar 2008, Howard Chu wrote: > rein(a)basefarm.no wrote: >> >> When the syncprov overlay is stacked on top of other overlays (notably the >> glue >> overlay) it must search through the next overlay, not the original backend >> DB. >> Otherwise it will not find any entries from the subordinate databases and >> consumers will remove those entries when they enters the refresh phase of >> the >> syncrepl protocol. >> >> The attached patch fixes this problem. > > Thanks, fixed in HEAD It looks as if my fix to this bug was utterly wrong :-( It probably only works when syncprov is stacked on top of the glue overlay. not with other overlays. First, searching through the next overlay looses the overlay semantics (i.e to return SLAP_CB_CONTINUE etc.) Even worse, a seg. fault will occur if the bi_op_search() method is not implement by the next overlay. I don't know whether that is actually allowed or not, but it is not done in at least the auditlog overlay. The correct fix should (I hope...) be to use the original overinst structure as the bd_info, as the patch at the end (which is relative to the current cvs head) implements. Since o_sync_mode appear to always have been cleared before be_search() is called it should be ignored by syncprov_op_search(). Sorry for the inconvenience! Rein Index: OpenLDAP/servers/slapd/overlays/syncprov.c diff -u OpenLDAP/servers/slapd/overlays/syncprov.c:1.1.1.12 OpenLDAP/servers/slapd/overlays/syncprov.c:1.9 --- OpenLDAP/servers/slapd/overlays/syncprov.c:1.1.1.12 Sat Mar 22 16:48:20 2008 +++ OpenLDAP/servers/slapd/overlays/syncprov.c Sun Mar 23 14:06:03 2008 @@ -696,10 +696,7 @@ break; } - if ( on->on_next ) - fop.o_bd->bd_info = (BackendInfo *)on->on_next; - else - fop.o_bd->bd_info = on->on_info->oi_orig; + fop.o_bd->bd_info = (BackendInfo *)on->on_info; fop.o_bd->be_search( &fop, &frs ); fop.o_bd->bd_info = (BackendInfo *)on; @@ -1531,10 +1528,7 @@ fop.ors_filter = ⁡ cb.sc_response = playlog_cb; - if ( on->on_next ) - fop.o_bd->bd_info = (BackendInfo *)on->on_next; - else - fop.o_bd->bd_info = on->on_info->oi_orig; + fop.o_bd->bd_info = (BackendInfo *)on->on_info; for ( i=ndel; i<num; i++ ) { if ( uuids[i].bv_len == 0 ) continue;

1 0

Re: (ITS#5340) REP_ENTRY_MODIFIABLE bug in dynlist
by h.b.furuseth＠usit.uio.no 22 Mar '08

22 Mar '08

h.b.furuseth(a)usit.uio.no writes: > overlays/dynlist.c lines 371-376 sets REP_ENTRY_MUSTBEFREED in rs->sr_flags > without duplicating the entry, if REP_ENTRY_MODIFIABLE was set. > Thus the entry gets freed twice. Breaks test044-dynlist with back-ldif. Actually obeying rs->sr_flags seems to be a more general problem - but I don't know what are bugs and what are my lacking understanding of the flags. I.e. when can an overlay change REP_ENTRY_MUSTBEFREED, REP_ENTRY_MUSTRELEASE? Usually backends/overlays that do not set these flags, don't seem to expect them to change either. -- Hallvard

1 0

Re: (ITS#5437) Fix to servers/slapd/overlays/syncprov.c
by hyc＠symas.com 21 Mar '08

21 Mar '08

c.hoover(a)its.utexas.edu wrote: > Full_Name: Clyde Hoover > Version: 2.4.8 > OS: Solaris 10 SPARC > URL: > Submission from: (NULL) (128.83.93.7) > > > The bug is around line 2015 of servers/slapd/overlays/syncprov.c > > } else if ( rs->sr_type == REP_RESULT&& rs->sr_err == LDAP_SUCCESS ) { > struct berval cookie; > > // The cookie is never initialized so if SS_CHANGED is not set > // this can cause an internal assertion failure downstream from > // syncprov_done_ctrl() (depending upon what is on the stack) > // Nulling out the cookie fixes this > memset((void *)&cookie, 0, sizeof(cookie)); // Add this > if ( ss->ss_flags& SS_CHANGED ) { > slap_compose_sync_cookie( op,&cookie, ss->ss_ctxcsn, > srs->sr_state.rid, > srs->sr_state.srs->sr_state.sid ); Please provide a stack trace from such a failure. The syncprov_done_ctrl() function should never be invoked at that point without SS_CHANGED being set, since in a normal Refresh the search will hit the shortcut and never reach that code. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#5437) Fix to servers/slapd/overlays/syncprov.c
by c.hoover＠its.utexas.edu 21 Mar '08

21 Mar '08

Full_Name: Clyde Hoover Version: 2.4.8 OS: Solaris 10 SPARC URL: Submission from: (NULL) (128.83.93.7) The bug is around line 2015 of servers/slapd/overlays/syncprov.c } else if ( rs->sr_type == REP_RESULT && rs->sr_err == LDAP_SUCCESS ) { struct berval cookie; // The cookie is never initialized so if SS_CHANGED is not set // this can cause an internal assertion failure downstream from // syncprov_done_ctrl() (depending upon what is on the stack) // Nulling out the cookie fixes this memset((void *)&cookie, 0, sizeof(cookie)); // Add this if ( ss->ss_flags & SS_CHANGED ) { slap_compose_sync_cookie( op, &cookie, ss->ss_ctxcsn, srs->sr_state.rid, srs->sr_state.srs->sr_state.sid );

1 0

Re: (ITS#5432) syncrepl seg. faults if received a sync cookie with an empty csn= value
by hyc＠symas.com 20 Mar '08

20 Mar '08

Rein Tollevik wrote: > On Wed, 19 Mar 2008, Howard Chu wrote: > >>> syncprov_playlog() in syncprov.c generates such invalid cookies when >>> replaying a >>> sessionlog where no entries has been deleted. The patch also fixes this >>> bug. >> This should never happen, since the cookie is not generated if there were no >> deletes recorded. > > Well, it do happen anyhow. Using the 2.4.8 release this can easily be > reproduced with a configuration where the syncrepl provider (with > sessionlogs enabled) is on a glue backend, the consumer replicates the > entire glue subtree. Assuming both servers are in sync and stopped, > start the producer, modify an entry in the subordinate db and then start > the consumer. The producer will send a cookie with an empty csn= value > as in this sync debug output: > slapd starting > slap_queue_csn: queing 0x418001a0 20080320125116.487494Z#000000#000#000000 > slap_graduate_commit_csn: removing 0x8d6ae0 20080320125116.487494Z#000000#000#000000 > srs csn 20080320124421.642686Z#000000#000#000000 > log csn 20080320125116.487494Z#000000#000#000000 > syncprov_playlog: cookie=rid=007,csn= > syncprov_search_response: cookie=rid=007,csn=20080320125116.487494Z#000000#000#000000 > > I have also tested it using the cvs head source, and the good news is > that this was accidentally fixed (at least partly) by the ITS#5434 > change. I.e it was caused by the be_search() in syncprov_playlog() not > being propagated to the subordinate database and thereby not finding the > entry that was modified. > > The bad news is that there is still a race condition that would have the > same effect. If someone deletes the entry that was modified just before > be_search() is done it will return the same empty cookie. I was able to > reproduce this in a debugger by setting a break point before be_search(), > deleting the entry with ldapdelete and in the debugger run next over the > be_search() call before continuing. > > So, I still think it is best to keep delcsn[0].bv_val NULL until an > actual cookie has been written to it, as slap_compose_sync_cookie() will > create a cookie with an empty csn= if passed a csn array where bv_len is > zero but bv_val is non-NULL. Although an alternative and maybe more > correct fix could be to change slap_compose_sync_cookie() instead? No. Thanks for your explanation of what you observed. The actual bug is in the mods processing, when it decides that a modified entry should be treated as a delete instead. It increments ndel then but doesn't set delcsn in that case. That's what actually needs to be fixed. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: Segfault in slapd 2.4.8 - syncrepl and glue (ITS#5430)
by ghenry＠suretecsystems.com 20 Mar '08

20 Mar '08

<quote who="hyc(a)symas.com"> > Duncan Gibb wrote: >> Howard Chu wrote: >> HYC> Most notably, in template 1, you explicitly configured >> HYC> syncprov on top of glue instead of taking the default >> HYC> behavior of syncprov under glue. As documented in >> HYC> slapd.conf(5), you should only do that when you want a >> HYC> single syncprov overlay to be master of the entire tree. >> HYC> In this case, you clearly want syncprov to only master >> HYC> one portion of the tree, with the subordinate being >> HYC> taken care of by its own syncprov overlay. >> >> That's a legacy of several previous iterations of the real project. >> Ideally each box would have at most two backends - one holding >> everything for which it's a consumer, and on the relevant machines a >> second backend holding the data for which it's master, then glue, then a >> single syncprov making the whole tree available. My colleague who >> implemented the first iteration did it that way and it should have >> worked, but the syncprov-glue interactions in 2.3.x were such that that >> resulted in sections of the tree not replicating and/or disappearing in >> various ill-defined situations. > > The whole-tree approach may have some snags. > 1) it's intended to work with a single syncprov over the entire glued > tree > 2) it requires a unique serverID for each master > 3) it probably won't work to start from a completely empty DB - the > root > entry needs to exist on each server. It's probably worth while for us and others to start a new thread on -software or -technical? Gavin.

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs