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
