Re: structuralObjectClass issues between master and slave servers

[Peter Traub <peter@vindicia.com>]

Hi Matthew,

Thanks for the reply. That does explain it. However, I do have one 
question. How come I still need to specify the structuralObjectClass 
attribute for the entry when adding it to my development test server? 
That server is a standalone server and does not take replication updates 
or give them. Its slapd.conf is almost identical to the master server, 
except without the replication directives. So in that case, shouldn't 
its behavior be the same as the master LDAP server, in that it should 
refuse the structuralObjectClass attribute? Or is that attribute 
necessary for any server that does not have a replication directive in 
its conf file? Thanks again.

Best,

Peter

Matthew Backes wrote:

> > 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
>
>