[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Partial and Fractional Replication Details
- To: openldap-technical@openldap.org
- Subject: Partial and Fractional Replication Details
- From: Jeffrey Crawford <jeffreyc@ucsc.edu>
- Date: Tue, 11 Oct 2011 13:02:25 -0700
- User-agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100722 Lightning/1.0b1 Eudora/3.0.4
I've been playing around with replication trying to prepare a deployment
into our enterprise so I've been trying to put syncrepl through it's paces.
As such I've been discovering some behaviors that may be intended but
have me scratching my head a little.
Since Openldap is using replication accounts and we have some pretty
specific security models it's desirable to have partial and fractional
replication restrictions placed on the replication account itself and
the syncrepl filter simply use the default 'objectClass=*'.
The "scratching my head" part shows up if I want to try to modify the
permissions of the replication account to see more or less of the
supplier database. There doesn't seem to be a way to get the replica to
just ignore session/accesslogs and perform a comparative sync to match
it's data to the view it has of the source. Process intensive I know but
would only need to be done when we make those kinds of changes
I then assumed since syncrepl is on the "client" side of things, it
might try to re-sync if the syncrepl filter was updated. However that
also didn't bring the replication accounts view of thing in sync with
it's local database. even starting slapd with -c "rid=##,csn=0" didn't work.
Furthermore when I took permissions away from the replication account so
it could no longer see record(s), if that record was still present from
it's earlier sync it would receive changes (presumibly from the
accesslog delta-syncrepl access) and apply them to the replica. That
means that there is no way to really restrict a replication accounts
access to sensitive data if it needs read access to cn=accesslog. Does
the synclog act in a simmilar manner? (I didn't seem like it but I
didn't get all the details yet about how that works).
If the sessionlog and accesslog are not configured then everything falls
back to present and delete states which can be a lot of traffic if we
have a batch job run that only changes a few attributes. however it
looks like that may be the safest way to proceed.
Any other ideas about what to try or to clarify my understanding of this
system would be appreciated.
Sorry to be so long winded but I want to make sure that I'm considering
all the variables in this project since we may be stuck with it for a
while ;)
Thanks Jeffrey