openldap-bugs

openldap-bugs@openldap.org

1 participants
20962 discussions

(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

Full_Name: Jonathan Steinert Version: 2.4.7 OS: linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2002:4c0e:3610:b00b:213:ceff:fe56:4659) slapadd: /build/buildd/openldap2.3-2.4.7/servers/slapd/schema_init.c:3669: csnNormalize: Assertion `val->bv_len == (sizeof("YYYYmmddHHMMSS.uuuuuuZ#SSSSSS#SID#ssssss")-1)' failed. Aborted an example of ldif that causes this case is: 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 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 dn: ou=Groups,dc=kuiki,dc=net objectClass: organizationalUnit ou: Groups structuralObjectClass: organizationalUnit entryUUID: a783ec90-5521-1027-8709-a9468010d3e8 creatorsName: cn=admin,dc=kuiki,dc=net createTimestamp: 20030728083139Z entryCSN: 2003072808:31:39Z#0x0001#0#0000 modifiersName: cn=admin,dc=kuiki,dc=net modifyTimestamp: 20030728083139Z

1 0

(ITS#5346) overlay and config backend
by jorge.nevado＠ericsson.com 01 Feb '08

01 Feb '08

Full_Name: Jorge Nevado Version: 2.4.7 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (83.44.184.7) Hello I have seen an extrange behaviour when an overlay is used with the config backend. I developed an overlay and use it over the config backend and over another developed backedend (this last just for testing). (I need to update some backend data when the schema controlled by the config backend changes, so I used an overlay for that purpose) In such situations, the overlay is not added to the config backend in the ldap tree, which look as follows: cn=config - cn= schema - cn={0}core - olcDatabase={-1}frontend - olcDatabase={0}config - olcDatabase={-1}ndb_pl + olcoverlay={0}ndbover But when I run traffic on the config suffix (i.e. LDAP operations on the schema) I see that the overlay is really working, although it is not added to the ldap tree (the overlay is added through the .conf file) Is this a bug? is it the normal behaviour (in file bconfig.c, function config_back_db_open it expects the config backend as the first backend, without overlay)?, but in normal traffic the overlay is invoked, which seems extrange to me. Thanks in advance, Jorge.

1 0

Re: (ITS#5343) cn=config crash when deleting attrs
by rhafer＠suse.de 31 Jan '08

31 Jan '08

On Donnerstag, 31. Januar 2008, rhafer(a)suse.de wrote: > On Mittwoch, 30. Januar 2008, h.b.furuseth(a)usit.uio.no wrote: > > Ralf Haferkamp writes: > > > There are multiple ways to fix this, I guess. I am not sure which > > > one to take: > > > 1. Make slap_mods_opattrs() create a LDAP_MOD_ADD operation, when > > > the attributes don't exist in the entry. > > > > It'd be better to fix bconfig's LDAP_MOD_REPLACE. That should work > > like LDAP_MOD_ADD when the attribute is absent. Haven't looked at > > how easy that would(n't) be though. > > > > > 2. Do not try to modify the attributes (not even add) in > > > slap_mods_opattrs() if they do not exist. > > > > No idea... > > > > I like the consistency it gives as far as it goes - keep the > > presence of the attrs independent of whether they were created over > > the protocol or with slapd -f -F. Except fix #2 doesn't do that > > since it won't know whether to add them when creating an entry. So > > in summary, no opinion:-) > > I am currently testing the 3rd approach, the attributes will be > created even when starting with -f only. I'll commit it as soon as > make test finishes. Done. Please test. -- Ralf

1 0

Re: (ITS#5341) Invalid TLSCipherSuite causes hang
by kyle＠moffetthome.net 31 Jan '08

31 Jan '08

On Jan 31, 2008 7:43 AM, Kyle Moffett <kyle(a)moffetthome.net> wrote: > On Jan 31, 2008 12:29 AM, Kyle Moffett <kyle(a)moffetthome.net> wrote: > > I ran into this problem a little while ago and scribbled up the > > attached patch to fix it. It's trivial enough and it works in my > > testing here. > > Sorry, the patch seems to have gone out MIME-encoded and mostly > useless to people who want to download it from the bug-tracker. Let > me try again... (Sorry, still getting used to a new email client) Well damn, it still didn't work. Hopefully gmail won't mangle a pasted patch. Again, my apologies for the mess. Cheers, Kyle Moffett --- openldap-2.4.7/libraries/libldap/tls.c.orig 2007-12-21 19:24:08.000000000 -0500 +++ openldap-2.4.7/libraries/libldap/tls.c 2007-12-21 19:36:02.000000000 -0500 @@ -300,6 +300,7 @@ for (i=0; i<n_ciphers; i++) { if ( !strncasecmp( ciphers[i].name, ptr, len )) { num++; + ptr = end + 1; break; } } @@ -330,6 +331,7 @@ * only appear once in each list. */ if ( !strncasecmp( ciphers[i].name, ptr, len )) { + ptr = end + 1; for (j=0; j<nkx; j++) if ( kx[j] == ciphers[i].kx ) break;

1 0

Re: (ITS#5341) Invalid TLSCipherSuite causes hang
by kyle＠moffetthome.net 31 Jan '08

31 Jan '08

------=_Part_21408_16591909.1201783413748 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Jan 31, 2008 12:29 AM, Kyle Moffett <kyle(a)moffetthome.net> wrote: > I ran into this problem a little while ago and scribbled up the > attached patch to fix it. It's trivial enough and it works in my > testing here. Sorry, the patch seems to have gone out MIME-encoded and mostly useless to people who want to download it from the bug-tracker. Let me try again... (Sorry, still getting used to a new email client) Cheers, Kyle Moffett ------=_Part_21408_16591909.1201783413748 Content-Type: text/plain; name=tls.patch.txt Content-Transfer-Encoding: base64 X-Attachment-Id: f_fc3apr6s1 Content-Disposition: attachment; filename=tls.patch.txt LS0tIG9wZW5sZGFwLTIuNC43L2xpYnJhcmllcy9saWJsZGFwL3Rscy5jLm9yaWcJMjAwNy0xMi0y MSAxOToyNDowOC4wMDAwMDAwMDAgLTA1MDAKKysrIG9wZW5sZGFwLTIuNC43L2xpYnJhcmllcy9s aWJsZGFwL3Rscy5jCTIwMDctMTItMjEgMTk6MzY6MDIuMDAwMDAwMDAwIC0wNTAwCkBAIC0zMDAs NiArMzAwLDcgQEAKIAkJZm9yIChpPTA7IGk8bl9jaXBoZXJzOyBpKyspIHsKIAkJCWlmICggIXN0 cm5jYXNlY21wKCBjaXBoZXJzW2ldLm5hbWUsIHB0ciwgbGVuICkpIHsKIAkJCQludW0rKzsKKwkJ CQlwdHIgPSBlbmQgKyAxOwogCQkJCWJyZWFrOwogCQkJfQogCQl9CkBAIC0zMzAsNiArMzMxLDcg QEAKIAkJCSAqIG9ubHkgYXBwZWFyIG9uY2UgaW4gZWFjaCBsaXN0LgogCQkJICovCiAJCQlpZiAo ICFzdHJuY2FzZWNtcCggY2lwaGVyc1tpXS5uYW1lLCBwdHIsIGxlbiApKSB7CisJCQkJcHRyID0g ZW5kICsgMTsKIAkJCQlmb3IgKGo9MDsgajxua3g7IGorKykKIAkJCQkJaWYgKCBreFtqXSA9PSBj aXBoZXJzW2ldLmt4ICkKIAkJCQkJCWJyZWFrOwo= ------=_Part_21408_16591909.1201783413748--

1 0

Re: (ITS#5343) cn=config crash when deleting attrs
by rhafer＠suse.de 31 Jan '08

31 Jan '08

On Mittwoch, 30. Januar 2008, h.b.furuseth(a)usit.uio.no wrote: > Ralf Haferkamp writes: > > There are multiple ways to fix this, I guess. I am not sure which > > one to take: > > 1. Make slap_mods_opattrs() create a LDAP_MOD_ADD operation, when > > the attributes don't exist in the entry. > > It'd be better to fix bconfig's LDAP_MOD_REPLACE. That should work > like LDAP_MOD_ADD when the attribute is absent. Haven't looked at > how easy that would(n't) be though. > > > 2. Do not try to modify the attributes (not even add) in > > slap_mods_opattrs() if they do not exist. > > No idea... > > I like the consistency it gives as far as it goes - keep the presence > of the attrs independent of whether they were created over the > protocol or with slapd -f -F. Except fix #2 doesn't do that since it > won't know whether to add them when creating an entry. So in > summary, no opinion:-) I am currently testing the 3rd approach, the attributes will be created even when starting with -f only. I'll commit it as soon as make test finishes. > > 3. Create the opattrs, when reading from slapd.conf > > Doesn't help preexisting cn=config directories. They didn't have the problem. The opattr were only absent, when slapd is started with -f. When started with -f -F the attrs were created during the conversion to back-config. They were at least present on disk. -- Ralf

1 0

Re: (ITS#5341) Invalid TLSCipherSuite causes hang
by kyle＠moffetthome.net 31 Jan '08

31 Jan '08

------=_Part_20332_23395431.1201757372670 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline I ran into this problem a little while ago and scribbled up the attached patch to fix it. It's trivial enough and it works in my testing here. Cheers, Kyle Moffett ------=_Part_20332_23395431.1201757372670 Content-Type: application/octet-stream; name=tls.patch Content-Transfer-Encoding: base64 X-Attachment-Id: f_fc2v9vtn0 Content-Disposition: attachment; filename=tls.patch LS0tIG9wZW5sZGFwLTIuNC43L2xpYnJhcmllcy9saWJsZGFwL3Rscy5jLm9yaWcJMjAwNy0xMi0y MSAxOToyNDowOC4wMDAwMDAwMDAgLTA1MDAKKysrIG9wZW5sZGFwLTIuNC43L2xpYnJhcmllcy9s aWJsZGFwL3Rscy5jCTIwMDctMTItMjEgMTk6MzY6MDIuMDAwMDAwMDAwIC0wNTAwCkBAIC0zMDAs NiArMzAwLDcgQEAKIAkJZm9yIChpPTA7IGk8bl9jaXBoZXJzOyBpKyspIHsKIAkJCWlmICggIXN0 cm5jYXNlY21wKCBjaXBoZXJzW2ldLm5hbWUsIHB0ciwgbGVuICkpIHsKIAkJCQludW0rKzsKKwkJ CQlwdHIgPSBlbmQgKyAxOwogCQkJCWJyZWFrOwogCQkJfQogCQl9CkBAIC0zMzAsNiArMzMxLDcg QEAKIAkJCSAqIG9ubHkgYXBwZWFyIG9uY2UgaW4gZWFjaCBsaXN0LgogCQkJICovCiAJCQlpZiAo ICFzdHJuY2FzZWNtcCggY2lwaGVyc1tpXS5uYW1lLCBwdHIsIGxlbiApKSB7CisJCQkJcHRyID0g ZW5kICsgMTsKIAkJCQlmb3IgKGo9MDsgajxua3g7IGorKykKIAkJCQkJaWYgKCBreFtqXSA9PSBj aXBoZXJzW2ldLmt4ICkKIAkJCQkJCWJyZWFrOwo= ------=_Part_20332_23395431.1201757372670--

1 0

Re: (ITS#5343) cn=config crash when deleting attrs
by h.b.furuseth＠usit.uio.no 30 Jan '08

30 Jan '08

Ralf Haferkamp writes: > There are multiple ways to fix this, I guess. I am not sure which one > to take: > 1. Make slap_mods_opattrs() create a LDAP_MOD_ADD operation, when the > attributes don't exist in the entry. It'd be better to fix bconfig's LDAP_MOD_REPLACE. That should work like LDAP_MOD_ADD when the attribute is absent. Haven't looked at how easy that would(n't) be though. > 2. Do not try to modify the attributes (not even add) in > slap_mods_opattrs() if they do not exist. No idea... I like the consistency it gives as far as it goes - keep the presence of the attrs independent of whether they were created over the protocol or with slapd -f -F. Except fix #2 doesn't do that since it won't know whether to add them when creating an entry. So in summary, no opinion:-) > 3. Create the opattrs, when reading from slapd.conf Doesn't help preexisting cn=config directories. -- Hallvard

1 0

Re: (ITS#5343) cn=config crash when deleting attrs
by rhafer＠suse.de 30 Jan '08

30 Jan '08

On Mittwoch, 30. Januar 2008, h.b.furuseth(a)usit.uio.no wrote: > Ralf Haferkamp writes: > > This should be fixed in HEAD now. > > Yes. Instead test034-translucent fails: > >>>>> Starting test034-translucent ... > > ... > Dynamically configuring local slapd without translucent_no_glue... > ldap_modify: No such attribute (16) > additional info: modify/delete: entryCSN: no such attribute > modifying entry > "olcOverlay={0}translucent,olcDatabase={2}bdb,cn=config" > > ldapmodify of dynamic config failed (16) > > >>>>> scripts/test034-translucent with bdb failed (exit 1) Hm, the config entries do not contain the usual operational Attributes like entrycsn, modifytimestamp, and so on when the config was loaded from slapd.conf, but during modification slapd tries to update them using slap_mods_opattrs(). This function always creates a LDAP_MOD_REPLACE modifcation, even if the attributes do not exist in the original entry. There are multiple ways to fix this, I guess. I am not sure which one to take: 1. Make slap_mods_opattrs() create a LDAP_MOD_ADD operation, when the attributes don't exist in the entry. 2. Do not try to modify the attributes (not even add) in slap_mods_opattrs() if they do not exist. 3. Create the opattrs, when reading from slapd.conf 4. Fix the original Bug differently. Even though I am pretty sure that my fix is correct. 5. ? Any suggestions? -- Ralf

1 0

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

30 Jan '08

> Have you got any servers running 2.3.39, or all 2.3.37? Everything went from 2.3.37 -> 2.3.40. Since I get hosed w/err=80, the slaves don't have corrupt data. I'm thinking about moving the master down to 2.3.39 as a data point. In the meantime, thanks for the db_dump idea; I can now show that the bad commits are definitely (a) 2.3.40 and (b) increasing. Consider: # grep 172.23.93.232 dbdump* dbdump.Jan291845: \80\10cn=172.23.93.232\00cn=172.23.93.232\00\00\00\00\00\00\01\d3\8d dbdump.Jan291845: \00\10cn=172.23.93.232\00cn=172.23.93.232\00\00\00\00\00\00\00\01> dbdump.Jan301043: \80\10cn=172.23.93.232\00cn=1\b72.23.93.232\00\00\00\00\00\00\01\d3\8d dbdump.Jan301043: \00\10cn=172.23.93.232\00cn=172.23.93.232\00\00\00\00\00\00\00\01>

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