Re: structuralObjectClass issues between master and slave servers

[Aaron Richton <richton@nbcs.rutgers.edu>]

If there's an "updatedn" definition, slapd "knows" it's a slurpd slave and
requires structuralObjectClass (presumably from the master) on ADD
operations (and possibly others?) If there's no "updatedn", it's a slurpd
master (or standalone) and the internal attributes aren't required.

A glance through the source shows that (in 2.2) either updatedn or
syncrepl statements make the slapd think it's a "shadow". As for knowing
it's a master, I'd guess the logic is that if it's not a slave (ie no
updatedn and no syncrepl), it's a master.

On Wed, 14 Jul 2004, Quanah Gibson-Mount wrote:

> 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
>
> --
> Quanah Gibson-Mount
> Principal Software Developer
> ITSS/Shared Services
> Stanford University
> GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html
>