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

entry has multiple objectClass attributes


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

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?