Emmanuel Dreyfus wrote: Let me elaborate a bit. The scenario is an authentication procedure that involves modifications to the account. These modifications need to be done on the real data, cannot be local (much like many fields related to password policy, for instance). The "right" approach would be to propagate the modifications to the master, wait for their replication and continue with the bind. The real right approach would be to centralize binds, basically defeating the purpose of having replicas (with respect to authentication, at least). I'm not a fan of OTP, but I believe this problem is worth being discussed not only with respect to OTP, but also because it may share issues with other auth methods where the directory stores auth-related data (like SASL auxprops). When everything is set up correctly, a client should not direct binds with this type of mech to a replica. When clients do not know that a DSA is in fact a shadow, the shadow DSA should be able to handle this type of requests seamlessly, although possibly not as efficiently as the master would. In this latter case, the auth procedure should be able to understand that the request will modify centrally administered info, and refuse to proceed. The frontend should be able to intercept this (much like when it receives a write request, or a request with the dontUseCopy control), and either give up or perform the write to the master, wait for success, and continue. Note that "continue" might imply waiting for replication to finalize, otherwise a subsequent request for stored auxprops would return invalid values. The above could be implemented at minimal cost using the chain mechanism already available to support writes to shadow databases, but binds do not return referrals by design. In short, I believe this really messes up with the mess involved with distributed procedures. Either we solve it consistently (at the cost of performances) or consistently prevent things from messing up (like it is now); the latter might be the only viable solution if fixing things consistently is not worth because of excessive performance penalties. p.

On Fri, Feb 19, 2010 at 07:53:09AM +0100, Emmanuel Dreyfus wrote: Perhaps slapo-rwm can do that? Is there a way of matching OTP binds? -- Emmanuel Dreyfus manu(a)netbsd.org

Pierangelo Masarati <masarati(a)aero.polimi.it&gt; wrote: One problem: If we do that, authentication cannot take place if the master or a replica is down. That defeats the purpose of setting up replicas to prevent failures. IMO there is a trade off between reliability and security here. We can either (1) redirect the client to the master (lower availability, better security since no replay can happen at any time), or (2) accept the authentication locally and send the update to the master afterwards (more reliable. less secure) -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz manu(a)netbsd.org

I have an "easy" fix in this direction; however, I stumbled into another issue: if slapo-chain(5) gets involved in an internal operation, it does not honor custom callbacks registered for the internal operation, and rather attempts to return the result to the caller. As a consequence, I need to address this issue first, before solving the original one. p.