hdb -- moving olc* objects -- expected behavior?

[Carlo Contavalli <ccontavalli@commedia.it>]

Hello,
  up until yesterday I used openldap 2.2 directories. 
Now, I've updated to 2.3. While working on testing
it, it seems like I'm getting a strange error.

In practice, by running a moddn on an object like: 

dn: olcModuleLoad=kvFQPFTF2yTT5zmFNlC,dc=test,dc=it
olcModuleLoad: kvFQPFTF2yTT5zmFNlC
objectclass: olcModuleList

to change the dn into:

olcModuleLoad=kvFQPFTF2yTT5zmFNlC,cn=avW4TP,dc=test,dc=it

I get the error:

"64 value of naming attribute 'olcModuleLoad' is not present in entry"

The same thing seems to happen to objects containing olc* attributes, 
but not to other, simple objects. 

You can reproduce the error by:
  # slapadd < failing.ldiff
  $ ldapmodify -x -f failing.modify.ldiff
    error!

the error does not appear with
  # slapadd < working.ldiff
  $ ldapmodify -x -f working.modify.ldiff
    done!

where no olc* attribute is being used... all the files
are attached. Beside that, objects containing olc* attributes
seems to behave exactly like other objects... children can
be added, removed, deleted...

if the behavior is expected, is there any way to detect
from the schema returned by the ldapserver that the attribute/object
has a different behavior?

Thanks,
Cheers,
Carlo

-- 
  GPG Fingerprint: 2383 7B14 4D08 53A4 2C1A CA29 9E98 5431 1A68 6975
                        -------------
In vino veritas.
	[In wine there is truth.]
		-- Pliny

dn: dc=test,dc=it
objectClass: top
objectClass: dcObject
objectClass: organization
o: nodomain
dc: test
structuralObjectClass: organization
entryUUID: 10d5367e-c6c4-102a-8604-5d7a7c90d75b
creatorsName:
modifiersName:
createTimestamp: 20060823072349Z
modifyTimestamp: 20060823072349Z
entryCSN: 20060823072349Z#000000#00#000000

dn: cn=avW4TP,dc=test,dc=it
cn: avW4TP
ipServicePort: 3299579525
ipServiceProtocol: nzFmzajrDc0WoNsYA3CsK22MLF
description: iEqkFYqYfh4x87i2MxfqK6
objectClass: ipService
structuralObjectClass: ipService
entryUUID: 1d103aa6-c6c4-102a-82ac-89db3dd68896
creatorsName:
createTimestamp: 20060823072410Z
entryCSN: 20060823072410Z#000000#00#000000
modifiersName:
modifyTimestamp: 20060823072410Z

dn: olcModuleLoad=kvFQPFTF2yTT5zmFNlC,dc=test,dc=it
olcModuleLoad: kvFQPFTF2yTT5zmFNlC
objectClass: olcModuleList
structuralObjectClass: olcModuleList
entryUUID: 1d111c96-c6c4-102a-82ad-89db3dd68896
creatorsName:
createTimestamp: 20060823072410Z
entryCSN: 20060823072410Z#000001#00#000000
modifiersName:
modifyTimestamp: 20060823072410Z

dn: olcModuleLoad=kvFQPFTF2yTT5zmFNlC,dc=test,dc=it
changetype: moddn
newrdn: olcModuleLoad=kvFQPFTF2yTT5zmFNlC
deleteoldrdn: 1
newsuperior: cn=avW4TP,dc=test,dc=it

dn: dc=test,dc=it
objectClass: top
objectClass: dcObject
objectClass: organization
o: nodomain
dc: test
structuralObjectClass: organization
entryUUID: 6b832daa-c6c5-102a-8084-877f6d192033
creatorsName:
modifiersName:
createTimestamp: 20060823073331Z
modifyTimestamp: 20060823073331Z
entryCSN: 20060823073331Z#000000#00#000000

dn: cn=avW4TP,dc=test,dc=it
cn: avW4TP
ipServicePort: 3299579525
ipServiceProtocol: nzFmzajrDc0WoNsYA3CsK22MLF
description: iEqkFYqYfh4x87i2MxfqK6
objectClass: ipService
structuralObjectClass: ipService
entryUUID: 6c56cea8-c6c5-102a-929b-e9664d352c9f
creatorsName:
createTimestamp: 20060823073332Z
entryCSN: 20060823073332Z#000000#00#000000
modifiersName:
modifyTimestamp: 20060823073332Z

dn: ou=argh,dc=test,dc=it
ou: argh
objectClass: organizationalUnit
structuralObjectClass: organizationalUnit
entryUUID: 6c57bcb4-c6c5-102a-929c-e9664d352c9f
creatorsName:
createTimestamp: 20060823073332Z
entryCSN: 20060823073332Z#000001#00#000000
modifiersName:
modifyTimestamp: 20060823073332Z

dn: ou=argh,dc=test,dc=it
changetype: moddn
newrdn: ou=kvFQPFTF2yTT5zmFNlC
deleteoldrdn: 1
newsuperior: cn=avW4TP,dc=test,dc=it