[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
entry has multiple objectClass attributes
Hello,
After a few years of not working with OpenLDAP I'm back working on
another LDAP project. The source has changed significantly since I last
dove in (back on version 1), and I'm not so sure of my footing at this
stage, but I'm hitting what seems to me to be a bug in slapd (and/or
slurpd).
I'm using OpenLDAP 2.1.10 on Linux.
I've written a shell backend which uses a second directory with an ldbm
backend (the datastore) to answer queries. One query to the front
directory results in multiple queries on the datastore, plus the
retrieval of some attributes from some other data sources. Sometimes
the front directory needs to add new records to the datastore, which it
does by creating a replog file, which is then processed by slurpd
(which replicates to the datastore and the aforementioned other data
sources, which have a directory front end for provisioning).
The problem is that when slurpd attempts to replicate an add operation
from the replog to the datastore it gets an Object Class Violation
error. However, if I grab the LDIF for the operation from the *.rej
file and apply it to the same directory using ldapadd (binding with the
same credentials) the add proceeds as expected.
The LDIF looks a bit like:
dn: the=name,for=the,ent=ry
associatedName: the=name,for=another,entr=ry,which=is,somehow=related
the: name
objectClass: customSchemaOC1
objectClass: customSchemaOC2
att1: val1
att2: val2
att3: val3
etc..
the error (according to debug=256 on the datastore directory) is
conn=4 op=3 RESULT tag=105 err=65 text=entry has multiple objectClass
attributes
which indeed it does, but since when was that an objectClass violation?
see servers/slapd/schema_check.c line 794 in mods_structural_class()
I tried turning schemacheck off on the datastore as a temporary
workaround, but that changes the error message to "attribute
'objectClass' provided more than once" - unless I also set updateDN to
the DN that slurpd is binding as (in which case it actually works, but
worries me). Setting updatedn but leaving schemacheck on results in an
"Internal (implementation specific) error" which is I suspect the most
honest response of the lot.
conn=1 op=1 RESULT tag=105 err=80 text=no structuralObjectClass
operational attribute
Can someone please either help me to understand what I'm doing wrong
here, or confirm my suspicion that this is a nasty little nest of bugs?
Bernard.