openldap-bugs February 2008

openldap-bugs@openldap.org

42 participants
207 discussions

Re: (ITS#5341) Invalid TLSCipherSuite causes hang
by vorlon＠debian.org 01 Feb '08

01 Feb '08

Hi Kyle, On Fri, Feb 01, 2008 at 12:15:52AM -0500, Kyle Moffett wrote: > On Jan 29, 2008 2:55 PM, Steve Langasek <vorlon(a)debian.org> wrote: > > On Tue, Jan 29, 2008 at 11:31:43AM -0800, Quanah Gibson-Mount wrote: > > > --On Tuesday, January 29, 2008 11:09 AM -0800 Steve Langasek <vorlon(a)debian.org> wrote: > > > > Anyway, the documented syntax for TLSCipherSuite is "$cipher1:$cipher2", > > > > not "$cipher1 $cipher2"; but setting such values gives me a hang on > > > > startup (which should be investigated). > > > Filed upstream: > > > <http://www.OpenLDAP.org/its/index.cgi?findid=5341> > > Sorry, the description of this ITS is inverted. It's *valid* ciphersuite > > values (i.e., "cipher1:cipher2") that cause the hang; invalid > > space-separated values are merely truncated after the first cipher in the > > list, which doesn't cause a hang, it just prevents the cipher list from > > being useful. > Steve, would you mind testing the patch I posted there? It fixed the > problem for me when I wrote it a month or two ago, hopefully it will > fix the problem for you too. Thanks, I can confirm this fixes the problem here. I'm able to set multiple ciphers in a TLSCipherSuite list, and able to connect appropriately with ldapsearch and gnutls-cli after the change. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slangasek(a)ubuntu.com vorlon(a)debian.org

1 0

Re: (ITS#5342) DN and naming attribute mismatch
by hyc＠symas.com 01 Feb '08

01 Feb '08

Aaron Richton wrote: > OK. I can reproduce in test, but I'm starting to not care due to the > circumstances. > > > My January 29 production database produces err=80s when hit. The important > open question is what caused the *initial* corruption: the hardware (which > I note has been reliable since downgrading to 2.3.39), 2.3.37 (or possibly > even some earlier version), or 2.3.40. I can think of no way to answer > this question at this time, short of additional experimentation/data > collection, and it may be near-impossible to find out. (Unfortunate, > because it is the important question.) > > A perverse side effect is that the same corrupted production database, > loaded against 2.3.39, happily accepts all changes. Now, .39 and .40 would > be expected to produce identical results. Which of the two is wrong in > this case? I find myself saying, again, that expectations during > "impossible situations" are a difficult subject. That makes some degree of sense. 2.3.40 introduced a dn2id_lock which uses the entryDN as the lock object. Since you have some entries with corrupted DNs, that will cause the locking protection to be ineffective. Since there's no problem when you start with a clean database, I'd say the culprit was something older. > Now, why don't I care about figuring out which one of them is right? > Because I can only instigate failure when something is in an "impossible > situation" at t=0. In the test environment, I gained the luxury of a > debugging procedure I couldn't afford in production: a full rm/slapadd of > the entire database. If I rm/slapadd using entirely 2.3.39, things work. > And if I rm/slapadd using entirely 2.3.40, things work: so far I cannot > make an initial corruption with 2.3.40, although corruption at t=0 can be > worsened by it. > > > Given the fact that I observed database issues like #5262 in my own test > environment, I find it plausible that 2.3.37 corrupted my database on the > way out the door. I've also observed, in test, that I can work around this > with slapcat/rm/slapadd. > > While all this has been going on, I've been stressing 2.3.40 with test008, > and it seems to be fine. I will likely try 2.3.40 again next week, but > plan on a slightly abnormal upgrade procedure that includes a > slapcat/rm/slapadd. This way, at least the sins of the past will be fully > purged prior to the first 2.3.40 start, so if any future issues arise > we'll have end-to-end 2.3.40 accountability. > -- -- 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#5332) multimaster replication crash
by ghenry＠suretecsystems.com 01 Feb '08

01 Feb '08

Marcel.Ritter(a)rrze.uni-erlangen.de wrote: > Full_Name: Marcel Ritter > Version: HEAD > OS: Linux (openSUSE 10.3) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (131.188.78.179) > > > When using multimaster replication slapd dies (on x86_64). > > I've used the scripts/test050-syncrepl-multimaster with one simple > modification: I added one ldapadd command at the end of the script, > trying to add some 20000 entries. > Have you tried this on a release, i.e. 2.4.7, not HEAD? -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry(a)suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/

1 0

Re: (ITS#5342) DN and naming attribute mismatch
by richton＠nbcs.rutgers.edu 01 Feb '08

01 Feb '08

OK. I can reproduce in test, but I'm starting to not care due to the circumstances. My January 29 production database produces err=80s when hit. The important open question is what caused the *initial* corruption: the hardware (which I note has been reliable since downgrading to 2.3.39), 2.3.37 (or possibly even some earlier version), or 2.3.40. I can think of no way to answer this question at this time, short of additional experimentation/data collection, and it may be near-impossible to find out. (Unfortunate, because it is the important question.) A perverse side effect is that the same corrupted production database, loaded against 2.3.39, happily accepts all changes. Now, .39 and .40 would be expected to produce identical results. Which of the two is wrong in this case? I find myself saying, again, that expectations during "impossible situations" are a difficult subject. Now, why don't I care about figuring out which one of them is right? Because I can only instigate failure when something is in an "impossible situation" at t=0. In the test environment, I gained the luxury of a debugging procedure I couldn't afford in production: a full rm/slapadd of the entire database. If I rm/slapadd using entirely 2.3.39, things work. And if I rm/slapadd using entirely 2.3.40, things work: so far I cannot make an initial corruption with 2.3.40, although corruption at t=0 can be worsened by it. Given the fact that I observed database issues like #5262 in my own test environment, I find it plausible that 2.3.37 corrupted my database on the way out the door. I've also observed, in test, that I can work around this with slapcat/rm/slapadd. While all this has been going on, I've been stressing 2.3.40 with test008, and it seems to be fine. I will likely try 2.3.40 again next week, but plan on a slightly abnormal upgrade procedure that includes a slapcat/rm/slapadd. This way, at least the sins of the past will be fully purged prior to the first 2.3.40 start, so if any future issues arise we'll have end-to-end 2.3.40 accountability.

1 0

Re: (ITS#5348) slapcat on 2.3.38 to slapadd on 2.4.7 causes abort.
by ghenry＠suretecsystems.com 01 Feb '08

01 Feb '08

<quote who="Pierangelo Masarati"> > Gavin Henry wrote: >> <quote who="ando(a)sys-net.it"> >>> hachi(a)kuiki.net wrote: >>>> Tested against both HEAD and OPENLDAP_REL_ENG_2_4, same error: >>>> >>>> slapadd: schema_init.c:3669: csnNormalize: Assertion `val->bv_len == >>>> (sizeof("YYYYmmddHHMMSS.uuuuuuZ#SSSSSS#SID#ssssss")-1)' failed. >>> That assert() was added to trap incorrect values, since they should >>> never happen run-time. Of course, this is not the case when >>> slapadd'ing, since bulk loading can (and must be able to) include >>> operational attrs like entryCSN. In any case, the value you're trying >>> to slapadd, "2003061105:33:44Z#0x0003#0#0000", is invalid, and >>> (probably, AFAIK) has never been in use with OpenLDAP software. When >>> bulk-adding data, you should make sure it is reasonably acceptable. >>> >> >> But isn't this a slapcat from 2.3.38? > > But that CSN was not CREATED by 2.3.38, only merely stored by it > (probably via slapadd). Ah, yes.

1 0

Re: (ITS#5348) slapcat on 2.3.38 to slapadd on 2.4.7 causes abort.
by h.b.furuseth＠usit.uio.no 01 Feb '08

01 Feb '08

Pierangelo Masarati writes: > Well, AFAIR, normalize should be called AFTER validate; and validate > should reject that CSN. The assert() was to make sure that, during > development, normalize was not called with invalid data. I'm looking at > that. Sounds like we need a macro a la #ifdef LDAP_DEVEL /* for tested non-release versions */ #define ASSERT_DEVEL assert #else #define ASSERT_DEVEL(expr) ((void)0) #endif -- Hallvard

1 0

Re: (ITS#5348) slapcat on 2.3.38 to slapadd on 2.4.7 causes abort.
by ando＠sys-net.it 01 Feb '08

01 Feb '08

Gavin Henry wrote: > <quote who="ando(a)sys-net.it"> >> hachi(a)kuiki.net wrote: >>> Tested against both HEAD and OPENLDAP_REL_ENG_2_4, same error: >>> >>> slapadd: schema_init.c:3669: csnNormalize: Assertion `val->bv_len == >>> (sizeof("YYYYmmddHHMMSS.uuuuuuZ#SSSSSS#SID#ssssss")-1)' failed. >> That assert() was added to trap incorrect values, since they should >> never happen run-time. Of course, this is not the case when >> slapadd'ing, since bulk loading can (and must be able to) include >> operational attrs like entryCSN. In any case, the value you're trying >> to slapadd, "2003061105:33:44Z#0x0003#0#0000", is invalid, and >> (probably, AFAIK) has never been in use with OpenLDAP software. When >> bulk-adding data, you should make sure it is reasonably acceptable. >> > > But isn't this a slapcat from 2.3.38? But that CSN was not CREATED by 2.3.38, only merely stored by it (probably via slapadd). p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5348) slapcat on 2.3.38 to slapadd on 2.4.7 causes abort.
by ando＠sys-net.it 01 Feb '08

01 Feb '08

h.b.furuseth(a)usit.uio.no wrote: > ando(a)sys-net.it writes: >>> slapadd: schema_init.c:3669: csnNormalize: Assertion `val->bv_len == >>> (sizeof("YYYYmmddHHMMSS.uuuuuuZ#SSSSSS#SID#ssssss")-1)' failed. >> That assert() was added to trap incorrect values, since they should >> never happen run-time. > > Bad idea. slapd crashes if you search for "(entryCSN=the csn below)". Well, AFAIR, normalize should be called AFTER validate; and validate should reject that CSN. The assert() was to make sure that, during development, normalize was not called with invalid data. I'm looking at that. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5348) slapcat on 2.3.38 to slapadd on 2.4.7 causes abort.
by h.b.furuseth＠usit.uio.no 01 Feb '08

01 Feb '08

ando(a)sys-net.it writes: >> slapadd: schema_init.c:3669: csnNormalize: Assertion `val->bv_len == >> (sizeof("YYYYmmddHHMMSS.uuuuuuZ#SSSSSS#SID#ssssss")-1)' failed. > > That assert() was added to trap incorrect values, since they should > never happen run-time. Bad idea. slapd crashes if you search for "(entryCSN=the csn below)". > Of course, this is not the case when > slapadd'ing, since bulk loading can (and must be able to) include > operational attrs like entryCSN. In any case, the value you're trying > to slapadd, "2003061105:33:44Z#0x0003#0#0000", is invalid, and -- Hallvard

1 0

Re: (ITS#5348) slapcat on 2.3.38 to slapadd on 2.4.7 causes abort.
by ghenry＠OpenLDAP.org 01 Feb '08

01 Feb '08

<quote who="ando(a)sys-net.it"> > hachi(a)kuiki.net wrote: >> Tested against both HEAD and OPENLDAP_REL_ENG_2_4, same error: >> >> slapadd: schema_init.c:3669: csnNormalize: Assertion `val->bv_len == >> (sizeof("YYYYmmddHHMMSS.uuuuuuZ#SSSSSS#SID#ssssss")-1)' failed. > > That assert() was added to trap incorrect values, since they should > never happen run-time. Of course, this is not the case when > slapadd'ing, since bulk loading can (and must be able to) include > operational attrs like entryCSN. In any case, the value you're trying > to slapadd, "2003061105:33:44Z#0x0003#0#0000", is invalid, and > (probably, AFAIK) has never been in use with OpenLDAP software. When > bulk-adding data, you should make sure it is reasonably acceptable. > But isn't this a slapcat from 2.3.38?

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs February 2008