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

Re: Determining the master server



Is that mean that we could not know the suffix of the master or any information to read the root of the master db.


Pierangelo Masarati wrote:

Pierangelo Masarati wrote:



Is there any way than an OpenLDAP client can tell whether a particular
server is a master or a slave for a particular suffix, without actually
trying to update it and seeing what comes back?




I think the referral mechanism resulting from performing a write
operation
on a slave is the intended mech.  In 2.3 (actually, in HEAD; scheduled
for
2.3) you may browse the configuration in back-config ("cn=config") and
see
if a server is a master or a slave;



Only the directory administrator has access to cn=config, so clients in
general cannot do this.



right; in any case, "cn=Monitor" would be the appropriate place to detect such info; "cn=Config" would be more appropriate to manage it.



or you may ask for a feature like
registering this info into back-monitor ("cn=monitor").



Let me elaborate a bit on this: a client may need this info for two different reasons:

1) to send a modification to appropriate server
2) to know who is the master

as you see, the difference may appear limited, but it's substantial.  In
case (1), the referral is all one needs; a list of referrals is even
better, so the master can change over time without the need to reconfigure
the slaves.  In case (2), a direct approach might be better, otherwise one
should try to perform a modification, see if it returns a referral and
infer that since a referral was returned, the DSA was a slave and the
referral points to the master.  Both assumptions may be incorrect, because
the inability to write may be related to other causes, and the referral
merely points to the superior knowledge of the DSA, which may be another
slave.  So, if you clarify what your need is, you can pick the "right"
answer.

Let me note once more that back-monitor should be seen as a work in
progress, i.e. it has been essentially set up as a framework that can hold
(dynamically generated) information on the status and the functionality of
slapd.  Filing a request to implement such discovery feature is definitely
appropriate, and since we're on the move to 2.3 it is very likely that
even non-trivial changes to its layout are accepted.

p.