openldap-bugs

openldap-bugs@openldap.org

1 participants
20965 discussions

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

Re: (ITS#5436) htons() expects an unsigned short
by h.b.furuseth＠usit.uio.no 19 Mar '08

19 Mar '08

Rein Tollevik writes: >On Tue, 18 Mar 2008, Hallvard B Furuseth wrote: >> (...) >> short is signed by definition. > > More the good reason why it should be cast to an unsigned then, as > that is what htons() expects. Yup. > No, I don't have a test case. This is a fairly insignificant bugfix I > commited to our copy of the source six years ago and has never gotten > around to report back (sorry for that). Right, then I'll not bother try to figure out how it broke. Maybe it's an incomplete cleanup after some other error which has been fixed. -- Hallvard

1 0

Re: (ITS#5436) htons() expects an unsigned short
by rein＠basefarm.no 19 Mar '08

19 Mar '08

On Tue, 18 Mar 2008, Hallvard B Furuseth wrote: > Thanks. Fixed os-ip.c in CVS HEAD (but see below). > > rein(a)basefarm.no writes: >> libraries/libldap/os-ip.c casts the argument to htons() to a short, it >> should be an explicit unsigned short. This causes the use of high >> port numbers to fail on systems where shorts are signed by default. > > short is signed by definition. More the good reason why it should be cast to an unsigned then, as that is what htons() expects. > Do you have a test case? As far as I can tell it broke if the caller > had the same error: storing a port number in a short, and passing that > short to ldap_init() & co. And it broke on systems with 16-bit int, if > there are such system around where OpenLDAP compiles in the first place. > > If we care about systems with 16-bit int, the proper fix is to also make > LDAPURLDesc.lud_port and various 'port' function parameters unsigned. I > have no idea if there is such a system which can even compile OpenLDAP > though. No, I don't have a test case. This is a fairly insignificant bugfix I commited to our copy of the source six years ago and has never gotten around to report back (sorry for that). The exact details I'm afraid I have forgotten a long time ago, and I generally find that figuring too much about the gory storage details of signed vs. unsigned, and big/little-endianness only gives me a slight headache ;-) But it definitely wasn't any 16-bit systems, and I can't see any reason why anyone should worry about those anymore.. It was most likely on a 64bit sparc system using sun's compiler, but it might have been linux/gcc on a 32bit i686 for all I remember now. Rein

1 0

Re: (ITS#5435) Seg. fault due to dereference of NULL ConfigReply * arguments.
by rein＠basefarm.no 19 Mar '08

19 Mar '08

On Tue, 18 Mar 2008, Howard Chu wrote: > 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) >> >> >> Functions in servers/slapd/back-bdb/init.c dereference their ConfigReply * >> arguments without testing that they are non-NULL first, which causes seg. >> faults. > > Obviously this should never happen. Please provide the stack trace from such > an occurrence. It happens if the glue overlay is used, backend_startup_one() is called with a NULL ConfigReply * in glue_open() as the stack frame below shows. This might be the real bug, but testing that the ConfigReply * is non-NULL (as is done in other backend modules) sounds as the right ting to do anyhow. Some of the overlay modules also calls backend_startup_one() with a NULL second argument, and back-bdb/config.c calls bi_db_open() the same way. Rein (gdb) where #0 bdb_db_open (be=0x7f86a0, cr=0x0) at init.c:106 #1 0x00000000004bfe0a in over_db_func (be=0x7f86a0, cr=0x0, which=db_open) at backover.c:55 #2 0x00000000004c030a in over_db_open (be=0x7f86a0, cr=0x0) at backover.c:176 #3 0x000000000044a479 in backend_startup_one (be=0x7f86a0, cr=0x0) at backend.c:224 #4 0x00000000004beaf5 in glue_open (bi=0x7e8850) at backglue.c:653 #5 0x000000000044a62f in backend_startup (be=0x7f8100) at backend.c:255 #6 0x000000000047660c in slap_startup (be=0x7f8100) at init.c:225 #7 0x00000000004c728f in slap_tool_init (progname=0x53fca8 "slapcat", tool=2, argc=5, argv=0x7fbffffb78) at slapcommon.c:725 #8 0x00000000004c5836 in slapcat (argc=5, argv=0x7fbffffb78) at slapcat.c:51 #9 0x0000000000417641 in main (argc=5, argv=0x7fbffffb78) at main.c:640

1 0

Re: (ITS#5435) Seg. fault due to dereference of NULL ConfigReply * arguments.
by hyc＠symas.com 18 Mar '08

18 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) > > > Functions in servers/slapd/back-bdb/init.c dereference their ConfigReply * > arguments without testing that they are non-NULL first, which causes seg. > faults. Obviously this should never happen. Please provide the stack trace from such an occurrence. > I have only seen this happen when I tried to slapcat a database that > hadn't had its directory created or some other stupidity, but anyhow... > > I don't include my patch to this, as it is probably easier to fix it again in > your source than to apply a patch. > > Rein Tollevik > Basefarm AS > > > -- -- 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

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