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

Re: structuralObjectClass issues between master and slave servers

--On Wednesday, July 14, 2004 11:28 AM -0700 Peter Traub <peter@vindicia.com> wrote:

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.

Erm... How does the server know whether or not it is a slave? Or, for that matter, how does it know it is a master?

I can certainly see in the "old" world of slurpd only, that a slave would be any system without a "replica" statement, and a master would be any system with a "replica" statement. But now we have syncRepl in the mix as well -- So you have master's with no "replica" statements, and you have slave's with "syncRepl" statements. Basically, I don't see how any server can tell whether or not it is a master, at least, and the only way it can tell if it is a slave or not is if it has syncRepl statements in it, because otherwise it could be a master. So I would expect that ldapadd's with structural objectClasses should *always* fail, regardless of what system is being talked to (and same for some of the operational attributes, I guess).


Quanah Gibson-Mount
Principal Software Developer
ITSS/Shared Services
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html