[Date Prev][Date Next] [Chronological] [Thread] [Top]

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

Carlo Contavalli wrote:
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?
The reason is quite simple, although subtle: olcModuleLoad has X-ORDERED 'VALUES' schema extension, an OpenLDAP reserved extension that is used for internal purposes. As a consequence, your rename operation results in removing the distinguished value "kvFQPFTF2yTT5zmFNlC" from the entry, then re-adding it as the new distinguished value. However, because of the X-ORDERED extension, the value is changed into "{0}kvFQPFTF2yTT5zmFNlC" which no longer matches the value in the RDN, and the entry no longer passes sanity checks.

The real point is that olc* stuff shouldn't be used for any purpose other than built-in configuration via back-config. I note that attributes with X-ORDERED 'VALUES' extension should not be allowed in RDN; another option would be to remove the ordering portion when checking for DN /entry consistency, but I'd regard this as a flawed entry naming design rather than a feature.

To summarize, the code seems fine; you should change your entry naming design.

p.


   SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497