[Date Prev][Date Next]
Re: Chain Overlay and SASL Proxy Auth with Multiple Referrals.
On Oct 30, 2009, at 2:15 PM, email@example.com wrote:
You hit a limitation of chaining as it is implemented today:
chained operations (namely, using idassert with proxied
when mode=self) is explicitly disallowed, as back-ldap refuses to
instance of the proxied authorization control when one is already
This is the case of chained requests. This limitation would be
eliminated by the implementation of distributed procedures,
work in progress (stalled, I believe).
OK, thanks, this is the sort of input I was looking for. I won't
waste any more time trying to get it to work.
Let me add that I find your setup a little bit nonsensical: if you
shadow databases that are exact replicas of the producer, then each
should be able to answer read requests. As a consequence, there is no
need to chain a shadow to another shadow. As a consequence, you
rather chain all shadow servers to the producer.
Each shadow can (and will) answer read requests; I am concerned with
writes. The configuration is actually more complex than I described.
I simplified the overall layout to be as simple as necessary to ask my
I have 5 sites, each with a writable copy of the data usually used for
that site (in its own OU), and a read-only version of all the other
sites' data. All replication goes through a central hub to simplify
configuration. This way, I only have to modify the configuration of
the central hub and a single site's server when a new site comes
online, and all the other servers automatically get the new data.
The purpose of this layout is that each site should function
independently if cut off from the other sites (which does happen) and
will still have read-only access to the other sites' data, which is
also necessary for normal operation.
Everything is working well with respect to replication. I was hoping
to add the chain overlay as a convenience but I don't mind dropping it.
Thanks for the assistance,