[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Syncrepl partial replication based on attribute problem
- To: OpenLDAP technical list <openldap-technical@openldap.org>
- Subject: Syncrepl partial replication based on attribute problem
- From: Jeffrey Crawford <jeffreyc@ucsc.edu>
- Date: Thu, 31 May 2012 15:54:55 -0700
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ucsc.edu; s=ucsc-google; h=mime-version:date:message-id:subject:from:to:content-type; bh=Dj/vWEobuBdlVvIHhsFsH8pKuAEQ1g7p21OkpOeXqD4=; b=lZEcY3RBC9CorSqG0ZBO1CR800fX0k1yzi1O4NKjR33GCqvSeRW0DGuKllNe45Mk67 FjOqKhfyy+jBq+KbRit8dlquTX7nHxTOr8EQlps17ttcqNsJsA4mLIRN3VzDV2ALUOjQ zvquIPaymU/pFvuNX9T0GPNeORiZQPU2XqHY8=
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?
Thanks