openldap-bugs March 2008

openldap-bugs@openldap.org

34 participants
162 discussions

Start a nNew thread

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

20 Mar '08

1 0

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

20 Mar '08

duncan.gibb(a)siriusit.co.uk wrote: > Duncan.Gibb(a)siriusit.co.uk wrote: > > DG> Can anyone else reproduce this, or do we need to work on more examples? > > After more experimentation, I believe this crash only happens if > replication between servers 1 and 2 (master of the main tree and > subordinate master respectively) has completed before server 3 (consumer > of 1) is started. > > We've scripted a test which works for me against 2.4.8 and did work > against CVS HEAD until Howard committed What does "work" mean? Please use more precise terminology. Did it reproduce the crash, or did it all replicate correctly? (The latter being the only thing that I would define as "working".) > openldap-src/servers/slapd/syncrepl.c 2008-03-19 23:26:40 +0000. Use revision numbers, that's what they're for. There is nothing in CVS with the above timestamp. > That > changes the syncrepl<-->glue interaction such that the data from server > 2 is never replicated to server 1 (a pre-requisite for this crash). > Maybe our config wrongly depends on the old behaviour. I'll look at > that tomorrow. > > Test rig (3.7K) is at > > http://pastebin.siriusit.co.uk/openldap-its5430-scripted-test-2008-03-19.ta… > > tar xzf openldap-its5430-scripted-test-2008-03-19.tar.gz > cd openldap-its5430-scripted-test-2008-03-19 > ./build.sh > ./test.sh > > Optionally copy CVS openldap-src from before the above commit into the > directory before invoking build.sh. > > Probably only works on Linux. Reproducible with bdb and hdb backends > using BDB 4.4 on Debian Lenny/i386 (bare metal). Not reproducible with > the ldif backend because replication from 2 to 1 never happens. -- -- 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 duncan.gibb＠siriusit.co.uk 19 Mar '08

19 Mar '08

Duncan.Gibb(a)siriusit.co.uk wrote: DG> Can anyone else reproduce this, or do we need to work on more examples? After more experimentation, I believe this crash only happens if replication between servers 1 and 2 (master of the main tree and subordinate master respectively) has completed before server 3 (consumer of 1) is started. We've scripted a test which works for me against 2.4.8 and did work against CVS HEAD until Howard committed openldap-src/servers/slapd/syncrepl.c 2008-03-19 23:26:40 +0000. That changes the syncrepl<-->glue interaction such that the data from server 2 is never replicated to server 1 (a pre-requisite for this crash). Maybe our config wrongly depends on the old behaviour. I'll look at that tomorrow. Test rig (3.7K) is at http://pastebin.siriusit.co.uk/openldap-its5430-scripted-test-2008-03-19.ta… tar xzf openldap-its5430-scripted-test-2008-03-19.tar.gz cd openldap-its5430-scripted-test-2008-03-19 ./build.sh ./test.sh Optionally copy CVS openldap-src from before the above commit into the directory before invoking build.sh. Probably only works on Linux. Reproducible with bdb and hdb backends using BDB 4.4 on Debian Lenny/i386 (bare metal). Not reproducible with the ldif backend because replication from 2 to 1 never happens. Cheers Duncan

1 0

Re: (ITS#5410) Patch for contrib smbk5pwd.c to use gcrypt
by pogma＠thewrittenword.com 19 Mar '08

19 Mar '08

On Wed, Mar 19, 2008 at 05:46:28PM -0700, Howard Chu wrote: >> >> This patch allows the smbk5pwd slapd module to build with gcrypt instead of >> openssl. > > In your version of nthash, is the result in binary (and therefore a call to > hexify is missing) or is it already in hex? Looks like the call to hexify is missing, it does not copy anything into the output buffer. Peter

1 0

Re: (ITS#5410) Patch for contrib smbk5pwd.c to use gcrypt
by hyc＠symas.com 19 Mar '08

19 Mar '08

pogma(a)thewrittenword.com wrote: > Full_Name: Peter O'Gorman > Version: 2.4.8 > OS: > URL: ftp://ftp.openldap.org/incoming/the-written-word-smbk5pwd-080310.patch > Submission from: (NULL) (24.76.165.223) > > > This patch allows the smbk5pwd slapd module to build with gcrypt instead of > openssl. In your version of nthash, is the result in binary (and therefore a call to hexify is missing) or is it already in hex? -- -- 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: (ITS#5434) syncprov in a glue'ed environment must search through the glue overlay
by hyc＠symas.com 19 Mar '08

19 Mar '08

rein(a)basefarm.no wrote: > Full_Name: Rein Tollevik > Version: 2.4.8 > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (84.215.2.34) > > > 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 -- -- 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: (ITS#5433) syncprov in a glue'ed environment write contextCSN to random subordinate DB
by hyc＠symas.com 19 Mar '08

19 Mar '08

rein(a)basefarm.no wrote: > Full_Name: Rein Tollevik > Version: 2.4.8 > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (84.215.2.34) > > > syncprov_checkpoint() writes the contextCSN attribute to the suffix of the > backend DB that is currently being written when it is triggered. When syncprov > is stacked on top of a set of glue'ed databases this can be any of the > subordinate backend DBs. The attached patch fixes this problem. > > Rein Tollevik > Basefarm AS Thanks for the report. An alternate fix is in HEAD. -- -- 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: (ITS#5432) syncrepl seg. faults if received a sync cookie with an empty csn= value
by hyc＠symas.com 19 Mar '08

19 Mar '08

rein(a)basefarm.no wrote: > Full_Name: Rein Tollevik > Version: 2.4.8 > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (84.215.2.34) > > > The attached patch fixes a seg. fault in compare_csns() in syncrepl.c if it > receives a sync cookie with an empty "csn=" value. This has been fixed in HEAD. > 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. > diff -u OpenLDAP/servers/slapd/overlays/syncprov.c:1.5 > OpenLDAP/servers/slapd/overlays/syncprov.c:1.6 > --- OpenLDAP/servers/slapd/overlays/syncprov.c:1.5 Fri Mar 14 16:23:48 2008 > +++ OpenLDAP/servers/slapd/overlays/syncprov.c Tue Mar 18 17:22:41 2008 > @@ -1413,8 +1413,7 @@ > num * UUID_LEN, op->o_tmpmemctx ); > uuids[0].bv_val = (char *)(uuids + num + 1); > > - delcsn[0].bv_len = 0; > - delcsn[0].bv_val = cbuf; > + BER_BVZERO(&delcsn[0]); > BER_BVZERO(&delcsn[1]); > > /* Make a copy of the relevant UUIDs. Put the Deletes up front > @@ -1453,6 +1452,7 @@ > i++; > AC_MEMCPY( cbuf, se->se_csn.bv_val, se->se_csn.bv_len ); > delcsn[0].bv_len = se->se_csn.bv_len; > + delcsn[0].bv_val = cbuf; > delcsn[0].bv_val[delcsn[0].bv_len] = '\0'; > } else { > nmods++; > > > -- -- 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: (ITS#5431) syncrepl on a subordinate DB writes contextCSN to suffix of parent DB
by hyc＠symas.com 19 Mar '08

19 Mar '08

Rein Tollevik wrote: > On Tue, 18 Mar 2008, Howard Chu wrote: > >> rein(a)basefarm.no wrote: >>> syncrepl_updateCookie() writes the contextCSN to the suffix of si->si_wbe >>> (assigned to op->o_bd). >> Yes. >> >>> In a subordinate database this is the parent DB, it >>> should be written to the suffix of si->si_be instead as the attached patch >>> fixes. >> No. It works as designed. > > Hm, that sounds as a bit odd design to me. I find it most natural that > the contextCSN should be stored in the suffix of the backendDB where > syncrepl is used. Then it doesn't interfere with the contextCSN of > other neighboring databases replicated below the same common superior, > nor with the contextCSN a syncprov overlay on the superior glue database > maintains. But I will not claim to have understood more than a tiny > fraction of the syncrepl protocol and code, so I might be complete lost > on this one. If I'm wrong this raises a few other questions though. > Upon startup syncrepl reads (in do_syncrep1()) its initial contextCSN > value from the suffix of the backend where it is used. If it is correct > that it in a glue'ed environment should write it to the suffix of the > superior glue DB, shouldn't it be read from there as well? Yes. This code is still being reworked. > My experience from the 2.4.8 release is that syncrepl and syncprov tends > to interfere with each other when they both try to maintain the > contextCSN of the same backend DB. I.e if they are both used on the > same database or if syncrepl writes its contextCSN to the suffix of a > superior glue database where syncprov is used. I realize that using > both on the same backend may be necessary in many configurations, but > luckily we was able to avoid it. I see that the syncrepl code that uses > delete/add to update the attribute (which would fail after syncprov has > replaced all values) has been rewritten in cvs, so I guess this would > not be a problem in an upcoming release. That's ITS#5426. It's also one of the reasons that our contributing guidelines state that you should submit patches against HEAD, not the released code. These fixes will be in 2.4.9 but it's likely that the patches you've created against 2.4.8 are already obsolete. -- -- 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: (ITS#5431) syncrepl on a subordinate DB writes contextCSN to suffix of parent DB
by rein＠basefarm.no 19 Mar '08

19 Mar '08

On Tue, 18 Mar 2008, Howard Chu wrote: > rein(a)basefarm.no wrote: >> >> syncrepl_updateCookie() writes the contextCSN to the suffix of si->si_wbe >> (assigned to op->o_bd). > > Yes. > >> In a subordinate database this is the parent DB, it >> should be written to the suffix of si->si_be instead as the attached patch >> fixes. > > No. It works as designed. Hm, that sounds as a bit odd design to me. I find it most natural that the contextCSN should be stored in the suffix of the backendDB where syncrepl is used. Then it doesn't interfere with the contextCSN of other neighboring databases replicated below the same common superior, nor with the contextCSN a syncprov overlay on the superior glue database maintains. But I will not claim to have understood more than a tiny fraction of the syncrepl protocol and code, so I might be complete lost on this one. If I'm wrong this raises a few other questions though. Upon startup syncrepl reads (in do_syncrep1()) its initial contextCSN value from the suffix of the backend where it is used. If it is correct that it in a glue'ed environment should write it to the suffix of the superior glue DB, shouldn't it be read from there as well? My experience from the 2.4.8 release is that syncrepl and syncprov tends to interfere with each other when they both try to maintain the contextCSN of the same backend DB. I.e if they are both used on the same database or if syncrepl writes its contextCSN to the suffix of a superior glue database where syncprov is used. I realize that using both on the same backend may be necessary in many configurations, but luckily we was able to avoid it. I see that the syncrepl code that uses delete/add to update the attribute (which would fail after syncprov has replaced all values) has been rewritten in cvs, so I guess this would not be a problem in an upcoming release. Rein

1 0

← Newer
1
2
3
4
5
6
7
8
9
...
17
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs March 2008