On Wednesday 24 June 2009 07:00:06 Dieter Kluenter wrote: This will allow operational attributes to be replicated from the provider to the consumer, but changes to password policy state attributes on consumers will not be replicated to providers or other consumers. I think a more generic solution (that does not require all servers to be masters) is required ... Regards, Buchan

There was a post about this about a month ago, talking about this as a problem and using chaining to solve it, but I'm thinking the chaining idea didn't solve all the problems... My understanding is that if I have a master/slave config with a typical syncrepl setup, and have password policy turned on in the consumer, password policy operational attributes are maintained locally, and are not replicated back to the master/supplier, but operational attributes on a master/supplier will be replicated to a consumer. Given that most clients will talk to a consumer server, that would mean password policy op attrs are not replicated to other consumers. Is that correct? If they are in fact replicated, how does the consumer have permission to write back to the master/supplier, so it can replicate to other consumers? I want to find a way to preserve the idea of directory consistency by writing to a single server from an external client POV, while propogating operational knowledge like password failures across the cluster. I'm thinking there are 2 options (in theory - I don't know if these actually work - at this point, I'm looking for advice on the best direction to go for this in my testing. Hoping to brainstorm possibilities first to limit the number of test cases/situations I have to try before I get something workable): Option 1 Use the chain overlay to forward write operations on a consumer back to the supplier. I think I would have to have different aci's on the consumer (only non-write aci's) so that a client could not write to the consumer and have it chained to the master(?) I.e. to an external client, I still want this to "appear" as a typical single master (well, single master with a hot standby which is hidden by a load balancer), multiple read-only consumers setup. I don't really care if the consumer returns a referral on a write attempt or an error, since most of my clients don't follow referrals anyway. I definitely don't want all my consumers to allow writes directly (I'd actually prefer to firewall my suppliers off so only select apps can even get to them to write, while most apps only have access to a read-only consumer.) But... I think I saw something previously on the list about these operational attributes being written directly to the db, so might not follow a chain rule to write it to the supplier(?) Also, creates a single point of failure (well, not single, but as many suppliers as you have) in that everything has to be channeled through the master server(s). Option 2 Everything is a master/supplier, but aci's on designated "masters" allow read/write operations, while designated "consumers" have aci's that only allow non-write access. I believe this would replicate the operational attributes in a way that chaining may not(?), eliminates single point of failure, since every server can pass its op changes on to every other server(?). Effectively, from an external client, this is a typical one master, many consumer setup, but internally, operational data is shared across the entire cluster (assuming it all works like I think it does). Option 2 has the added benefit that I can promote one of these "consumers" to be a master in a disaster recovery situation very easily by just replacing the aci's. Option 1 would require me to undo all the chaining config, and update all my consumers to point to the "new" supplier (I suppose DNS tricks could be used to resolve some of that, but either way it's more complicated). So.. Am I on the right track? Anything I say completely wrong? Is there another, better option to do what I want?