[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Syncrepl partial replication based on attribute problem

Thanks Howard,

Let me make sure I understand your response. I'm not changing any ACL's, they are staying the same. Just the attributes in the record are changing. Are you saying that syncprov looks at the account that is bound and sends deletes if a record would become invisible after a modification? If that's the case it doesn't seem to be working right.

If syncprov is being used and looks at which user is bound would it have trouble if there are multiple replicas and replica accounts binding to get replication data? we have two distinct downstream replicas that each have different criteria for which records get replicated to them.

Jeffrey

On Thu, May 31, 2012 at 6:38 PM, Howard Chu <hyc@symas.com> wrote:
Jeffrey Crawford wrote:
Hello,

I had thought I tested this beforehand but I seem to be able to reliably
reproduce the following situation:

We have an installation where the provider server has information that is
replicated to downstream replicas using the syncrepl protocol. The account
used to replicate is allowed to see records where certain attributes meet
specific values, a silly example is an attribute is set

dn: uid=somerecord,ou=people,dc=ucsc,dc=edu
replicateMe: TRUE
...

When an account has that attribute set it then replicates to the downstream
replica, however if later we set replicateMe to FALSE so that the account used
for replication can no longer see the entry, it seems to be orphaned and is
not removed in the replica.

We are using OpenLDAP 2.4.26 and I have the syncprov sessionlog set to 500 and
the replica is set to refreshAndPersist.

Is this something that is simply not supported? or would a case like this be
expected to work and I've either got a configuration issue or a bug?

Visibility changes due to ACL rules are not detected. syncprov only checks an entry against the search parameters of the original sync search operation, i.e., the base, scope, and filter. If an entry matches these params before the modification, and no longer matches after the operation, syncprov will send a delete message for that entry. (Likewise if an entry doesn't match before, but matches after, syncprov will send an Add for the entry.)

--
 -- Howard Chu
 CTO, Symas Corp.           http://www.symas.com
 Director, Highland Sun     http://highlandsun.com/hyc/
 Chief Architect, OpenLDAP  http://www.openldap.org/project/