[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: Partial replication
The e-mail thread seems to have wandered a bit, hoping I am replying to the correct one.
I've tested both methods, ACL vs 'syncrepl search filter', both seem to work well for me. I agree with Andrew's point that controlling this via the ACLs on the provider is more secure (in my case).
Thanks for all the help and insight.
Joe
----------------------------------------
> On Thu, Apr 01, 2010 at 09:53:07PM +0200, Zdenek Styblik wrote:
>
>>>> you want to replicate. So, let's say you use cn=mirrorA,dc=domain,dc=tld
>>>> for replication, then allow this cn=mirrorA to read only
>>>> o=support,dc=example,dc=com and o=location_A,dc=example,dc=com, but nowhere
>>>> else.
>>>
>>> I have used that technique for a fairly complex design with a central
>>> office and many small satellites. It works OK *provided* you never change
>>> the list of entries that can be seen by the replicas. The syncrepl
>>> system has no way to evaluate the effect of an ACL change (and probably
>>> no way to know that one has happenned).
>>>
>>
>> Could you please elaborate more on this one?
>
> My design requirements were similar to Joe's: I had a large central
> server holding the master data for a lot of customers. Each customer
> needed a local replica of their own data plus some subset of the
> service-provider data. In my case the subset was not even complete
> subtrees: the customers were allowed to see certain attributes of
> certain entries only. I had to protect against the possibility that
> someone might modify the config on a customer server to obtain data
> that they should not have.
>
> As there was already a comprehensive default-deny access-control
> policy in place, I just factored in the replica servers as principals
> with the right to see all data that should be replicated to that site
> and nothing else. That meant that every replica server could have an
> identical syncrepl clause which just copies everything it can see from
> the entire DIT.
>
> The downside is that if any access permissions change then the
> replicas may not reflect the correct new subset of data.
>
>> Because I'd say if you refuse
>> access later to some DN then it must be like DN has been deleted. Same goes
>> for adding. I mean, syncrepl won't see data. And it checks, well it should
>> check, for changes in some regular intervals, right?
>
> The problem is that syncrepl does not check every entry exhaustively.
> That would be very inefficient (though I would like a way to force it
> periodically). The master server maintains something like a timestamp
> on the whole DIT, and when the replica server connects they just have
> to compare timestamps and transfer things that have changed in the
> interval between the two. (This is a gross simplification of the
> actual protocol, but close enough for the discussion).
>
> Now imagine that I change an ACL which affects the visibility of some
> entries. The entries themselves have not changed, so the timestamps do
> not change and the replication process will not know that the replica
> data should change.
>
> Worse still, I might change the membership of a group that is
> referenced in an ACL. The replication process would transfer the group
> but would not know that some other entries have changed visibility.
>
>> I have no need for nor experience with this, yet it's somewhat interesting.
>
> It is a powerful technique, but the designer *and operators* of such a
> system must be aware of the pitfalls.
>
>> ACLs of anykind in OpenLDAP are kinda ... PITA, no offense to anybody!!! :)
>> It just needs a lot of work to maintain and stuff (please please, no
>> bashing).
>
> ACLs of any kind in any system (LDAP, file system, RDBMS etc) can be
> hard to get right and harder to modify correctly at a later date. It
> all depends on the policy that you are trying to implement. You should
> think of ACLs as programs and expect to need programmer-level skill to
> work on them. You may find this paper helpful:
>
> http://www.skills-1st.co.uk/papers/ldap-acls-jan-2009/
>
> Of all the LDAP servers that I have worked with, I find OpenLDAP's
> ACLs are the easiest for implementing non-trivial policies.
>
> Andrew
> --
_________________________________________________________________
The New Busy is not the old busy. Search, chat and e-mail from your inbox.
http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_3