February 2008 - openldap-bugs

Re: (ITS#5348) slapcat on 2.3.38 to slapadd on 2.4.7 causes abort.

by ando＠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. 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 ---------------------------------------

15 years, 8 months

1
0
0 / 0

Re: (ITS#5346) overlay and config backend

by h.b.furuseth＠usit.uio.no

Well, it's not your overlay's fault. The same happens with overlay unique: It works, but does not show up in ldapsearch. Nor in the config directory written with slapd -f ... -F ... $cat slapd.conf include servers/slapd/schema/core.schema database config rootdn cn=config rootpw secret overlay unique unique_uri ldap:///?olcAccess?sub access to * by * read $ ldapmodify -xHldap://:3890 -D cn=config -w secret dn: olcDatabase={-1}frontend,cn=config changetype: modify add: olcAccess olcAccess: to * by * read - modifying entry "olcDatabase={-1}frontend,cn=config" ldap_modify: Constraint violation (19) additional info: some attributes not unique On the other hand, this is strange: > cn=config > - cn= schema > - cn={0}core > - olcDatabase={-1}frontend > - olcDatabase={0}config > - olcDatabase={-1}ndb_pl > + olcoverlay={0}ndbover Two different databases should not have the same number. ndb_pl should get {1}. Possibly your backend or overlay messes up something in that regard. -- Hallvard

15 years, 8 months

1
0
0 / 0

(ITS#5350) Request: ITS links in mailinglist archives

by h.b.furuseth＠usit.uio.no

Full_Name: Hallvard B Furuseth Version: OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard Could the mailinglist->web archiver put <a href="/its/?findid=(number)"></a> around "ITS#(number)" in the messages? Links for RFCs would be useful too.

15 years, 8 months

1
0
0 / 0

Re: (ITS#5342) DN and naming attribute mismatch

by h.b.furuseth＠usit.uio.no

Aaron Richton writes: > 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. Can db->set_flags(db, DB_CHKSUM) help narrow it down? It's not a database environment flag, for some reason. http://www.oracle.com/technology/documentation/berkeley-db/db/api_c/db_se... Not relevant for this ITS, but if it's made a slapd.conf option instead of just a hack for this occasion it would likely be useful to offer a way to say "turn it on if DB page size differs from filesystem block size", since that's one case when Berkeley DB can't guarantee that data remains correct: http://www.oracle.com/technology/documentation/berkeley-db/db/ref/transap... -- Hallvard

15 years, 8 months

1
0
0 / 0

Re: (ITS#5348) slapcat on 2.3.38 to slapadd on 2.4.7 causes abort.

by hachi＠kuiki.net

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. Aborted

15 years, 8 months

1
0
0 / 0

(ITS#5348) slapcat on 2.3.38 to slapadd on 2.4.7 causes abort.

by hachi＠kuiki.net

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

15 years, 8 months

1
0
0 / 0

(ITS#5346) overlay and config backend

by jorge.nevado＠ericsson.com

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.

15 years, 8 months

1
0
0 / 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs February 2008