openldap-bugs

openldap-bugs@openldap.org

1 participants
20962 discussions

Re: (ITS#5332) multimaster replication crash
by Marcel.Ritter＠rrze.uni-erlangen.de 03 Feb '08

03 Feb '08

Gavin Henry schrieb: > 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? Yes - I tried with 2.4.7 first. Then I asked Ralf Haferkamp from SuSE/Novell (he build's openldap 2.4 packages on the openSUSE Build Service) wether he had run some tests on this topic, but he declined and suggested to test with HEAD version. I tried this too, but to the same result. I've run my tests both on SuSE Linux Enterprise Server 10 and openSUSE 10.3. As far as I tested, this occurs only on x86_64 systems (i386 seems to get into an endless loop instead - but this may be for a different reason ...) Please let me know if you need a login on a test system, the sample ldif or if I can test something for you. Bye, Marcel -- ---- Dipl.-Inf. Marcel Ritter Linux/Novell Regionales Rechenzentrum Erlangen Tel: 09131 / 85-27808 E-Mail: Marcel.Ritter(a)rrze.uni-erlangen.de ---- Unix _IS_ user friendly... It's just selective about who its friends are.

1 0

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

02 Feb '08

hachi wrote: > This is the direct output from slapcat on my 2.3.38 openldap setup, I > haven't changed it in any way (apart from cutting off later entries so > that I'm not supplying you with a few thousand examples) Please try the patch resulting from diffing cvs diff -u -r 1.440 -r 1.442 servers/slapd/schema_init.c it should apply straightforwardly to 2.4.7. It prevents slapd from assert'ing in case of unrecognized input, and tolerates OpenLDAP 2.1 CSN syntax. Note that a slapcat | slapadd with (patched) 2.4.7 will re-format CSN values according to the current format. 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 hyc＠symas.com 01 Feb '08

01 Feb '08

ando(a)sys-net.it wrote: > hachi wrote: >> This is the direct output from slapcat on my 2.3.38 openldap setup, I >> haven't changed it in any way (apart from cutting off later entries so >> that I'm not supplying you with a few thousand examples) > > I trust you. But I believe that specific data was either generated by a > much earlier version, or came from somewhere else. >> dn: ou=People,dc=kuiki,dc=net >> objectClass: organizationalUnit >> ou: People >> structuralObjectClass: organizationalUnit >> entryUUID: 031994e2-301a-1027-968d-e97431722845 >> creatorsName: cn=anonymous >> modifiersName: cn=anonymous >> createTimestamp: 20030611053344Z >> modifyTimestamp: 20030611053344Z >> entryCSN: 2003061105:33:44Z#0x0003#0#0000 > > ^^^ this is nonsense to me; note it was generated in 2003, and 2.3.38 > did not exist at that time (but, apparently, it allows bulk loading of > this CSN form). That's OpenLDAP 2.1's format. Which fits the 2003 timeframe. -- -- 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#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

hachi wrote: > This is the direct output from slapcat on my 2.3.38 openldap setup, I > haven't changed it in any way (apart from cutting off later entries so > that I'm not supplying you with a few thousand examples) I trust you. But I believe that specific data was either generated by a much earlier version, or came from somewhere else. If you look at your original posting,> dn: dc=kuiki,dc=net > objectClass: dcObject > objectClass: organization > dc: kuiki > o: kuiki.net > structuralObjectClass: organization > entryUUID: 03182abc-301a-1027-968b-e97431722845 > creatorsName: cn=anonymous > createTimestamp: 20030611053344Z > entryCSN: 20060925002534Z#000000#00#000000 > modifiersName: cn=admin,dc=kuiki,dc=net > modifyTimestamp: 20060925002534Z > contextCSN: 20071231014551Z#000000#00#000000 ^^^ this is an "old" OpenLDAP format (no fractions of seconds, 2-digit SID); note the entryCSN was generated in 2006 and the contextCSN in 2007 > > dn: ou=People,dc=kuiki,dc=net > objectClass: organizationalUnit > ou: People > structuralObjectClass: organizationalUnit > entryUUID: 031994e2-301a-1027-968d-e97431722845 > creatorsName: cn=anonymous > modifiersName: cn=anonymous > createTimestamp: 20030611053344Z > modifyTimestamp: 20030611053344Z > entryCSN: 2003061105:33:44Z#0x0003#0#0000 ^^^ this is nonsense to me; note it was generated in 2003, and 2.3.38 did not exist at that time (but, apparently, it allows bulk loading of this CSN form). 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 hachi＠kuiki.net 01 Feb '08

01 Feb '08

This is the direct output from slapcat on my 2.3.38 openldap setup, I haven't changed it in any way (apart from cutting off later entries so that I'm not supplying you with a few thousand examples) Pierangelo Masarati wrote: > 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. > > 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#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

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