Re: structuralObjectClass issues between master and slave servers

[Matthew Backes <mbackes@symas.com>]

> I'm encountering an odd issue, whereby if I add an LDAP entry to our
> master LDAP server and the entry contains an attribute specifying
> which objectClass is the structuralObjectClass, then the server
> won't add it, and exits with an error. Yet the exact opposite
> happens when adding the test entry to any slave or standalone
> server.

> ldap_add: Constraint violation (19)
>         additional info: structuralObjectClass: no user modification allowed

> ldap_add: Internal (implementation specific) error (80)
>         additional info: no structuralObjectClass operational attribute

This is normal good, expected behavior.  The only thing that should
write to the slaves is the master, which will include the Operational
attributes.  (including structuralObjectClass) Clients writing to the
master should not include structuralObjectClass for that same reason;
it is an internal-use attribute that client software should not touch.

If you need to play special games like having external software write
to a slave, you'll need to understand what these operational
attributes are and what semantics are associated with them.

If you need to replicate via slurpd to a slapd that believes itself to
be a master, you'll need to strip these attributes out.  The
slapd.conf(5) manpage has the details on how to specify a list of
attributes to include or exclude for each replica...

If you are loading LDIF via ldapadd that was dumped via slapcat or
similar, you'll also need to strip these attributes out or load via
the offline tool slapadd.

Matthew Backes
mbackes@symas.com