On closer examination of the doc, it appears that chaining updates is only possible when using database links.
However, as I infer, using database links removes the possibility of replication, because the link would pass any modification back to the remote database.
Thus, if you had a consumer configured with a database link back to a supplier, and then set up a replication agreement from the supplier to the consumer, it would be replicating to its own database!
Am I understanding this correctly?
Is there a way to achieve our desired scenario: where no clients can directly access a read-write supplier (i.e. referrals are disabled, because network access is blocked); but they're still able to change their passwords, because the read-only consumer chains the update request back to a supplier?
From: firstname.lastname@example.org [mailto:email@example.com] On Behalf Of Gerrard Geldenhuis
Sent: 29 July 2010 13:04
Subject: [389-users] Sanity check for install approach
I would appreciate anyone just giving the tasks below a sanity check.
We will have a multimaster setup with various consumers from which clients will be authenticating off. Clients can not reach the masters directly and can only reach the consumer servers.
To enable password policies to work correctly I will configure the consumer servers to chain requests back to the masters and enable chaining for the Password policy component. My understanding is thus that when a client tries to authenticate against the consumer server and fails, the password policy configured on the consumer will activate and the counter incremented for failed logins. This incremented counter change will then be chained back to the master which will replicate it back to the consumer and any other consumers.
To rephrase the above... in a user story.
User authenticates against consumer01
Consumer01 has password policy configured and replication from master01.
What happens next?
Does the consumer automatically communicate this failure back to master01, or do you need to setup chaining for this to happen?
In order to protect our email recipients, Betfair Group use SkyScan from MessageLabs to scan all Incoming and Outgoing mail for viruses.
389 users mailing list
In order to protect our email recipients, Betfair Group use SkyScan from
MessageLabs to scan all Incoming and Outgoing mail for viruses.
389 users mailing list