- openldap-bugs - openldap.org

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

04 Feb '08

Ralf Haferkamp writes: >> 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. Works fine, and passes "make test". One quirk, don't know if it's worth bothering with: If I define "attributeOptions foo" in slapd.conf and delete olcAttributeOptions with ldapmodify, the slapd log gets a line slapd: line 0: option "foo" is already defined The message disapperas if I have no "attributeOptions" in slapd.conf, which means cn=config gets the default "olcAttributeOptions: lang-". slapd.conf: include servers/slapd/schema/core.schema attributeOptions foo database config rootdn cn=config rootpw secret ldapmodify: dn: cn=config changetype: modify delete: olcAttributeOptions - output: conn=2 op=1 MOD dn="cn=config" conn=1 op=1 MOD attr=olcAttributeOptions slapd: line 0: option "foo" is already defined conn=1 op=1 RESULT tag=103 err=80 text= -- Hallvard

1 0

Re: (ITS#5332) multimaster replication crash
by ghenry＠suretecsystems.com 04 Feb '08

04 Feb '08

<quote who="Marcel Ritter"> > 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. > If you can upload a tar of all config etc. that would be good: http://www.openldap.org/doc/admin24/troubleshooting.html#OpenLDAP%20Bugs Gavin.

1 0

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

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

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(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#5346) overlay and config backend
by h.b.furuseth＠usit.uio.no 01 Feb '08

01 Feb '08

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

1 0

(ITS#5350) Request: ITS links in mailinglist archives
by h.b.furuseth＠usit.uio.no 01 Feb '08

01 Feb '08

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.

1 0

Re: (ITS#5342) DN and naming attribute mismatch
by h.b.furuseth＠usit.uio.no 01 Feb '08

01 Feb '08

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_set_… 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/transapp/… -- Hallvard

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

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

1 0

(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 31 Jan '08

31 Jan '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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs