Hello,
On Oct 30, 2009, at 2:15 PM, masarati@aero.polimi.it wrote:
You hit a limitation of chaining as it is implemented today: chaining of chained operations (namely, using idassert with proxied authorization, as when mode=self) is explicitly disallowed, as back-ldap refuses to add an instance of the proxied authorization control when one is already present. This is the case of chained requests. This limitation would be eliminated by the implementation of distributed procedures, currently a 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 have shadow databases that are exact replicas of the producer, then each shadow 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 should 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 question.
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,