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

Re: Syncrepl partial replication based on attribute problem

Ok I think I got this to work I didn't add a filter to the syncrepl
parameter so I'm using ACL's as before, however I changed the acls to
allow the replica account access to the attributes entry and entryUUID
only on every item in the directory, now setting attributes to values
so that they no longer match the access to the rest of the acls seem
to do what I wan't however I'm not quite sure how. so in short the
provider looks something like this:

olcAccess: to dn.subtree="dc=example,dc=org"
 attrs=entry,entryUUID
 by dn.base="cn=replica,ou=admins,dc=example,dc=org" ssf=128 read
 by * none break
olcAccess: to dn.subtree="dc=example,dc=org"
 filter="(replicateMe=TRUE)"
 attrs=@inetOrgPerson,@posixAccount,entryCSN,contextCSN,createTimestamp,modifyTimestamp,structuralObjectClass
 by dn.base="cn=replica,ou=admins,dc=example,dc=org" ssf=128 read
 by * none break

And the replicas are configured as so:

dn: olcDatabase={1}hdb,cn=config
changeType: modify
replace: olcSyncrepl
olcSyncrepl: rid=1
  provider=ldap://ldap-!!!!ENV!!!!-1.example.org:1389/
  starttls=critical
  tls_reqcert=never
  bindmethod=simple
  retry="60 10 900 92 86400 3"
  binddn="cn=replica,ou=admins,dc=example,dc=org"
  credentials=!!!!PW!!!!
  schemachecking=off
  searchbase="dc=example,dc=org"
  type=refreshAndPersist
olcSyncrepl: rid=2
  provider=ldap://ldap-!!!!ENV!!!!-2.example.org:1389/
  starttls=critical
  tls_reqcert=never
  bindmethod=simple
  retry="60 10 900 92 86400 3"
  binddn="cn=replica,ou=admins,dc=example,dc=org"
  credentials=!!!!PW!!!!
  schemachecking=off
  searchbase="dc=example,dc=org"
  type=refreshAndPersist

now the following will add a record to the replica:
dn: uid=user,ou=people,dc=example,dc=org
changeType: modify
replace: replicateMe
replicateMe: TRUE

And the following will take it away (delete):
dn: uid=user,ou=people,dc=example,dc=org
changeType: modify
replace: replicateMe
replicateMe: FALSE

However I don't know enough about the underlying code to be sure the
following is working as designed. Meaning I don't want to be relying
on a bug that might get fixed later.

Thanks
Jeffrey

access:

On Fri, Jun 1, 2012 at 9:26 AM, Jeffrey Crawford <jeffreyc@ucsc.edu> wrote:
>
> Humm and taking this one step further I'm guessing that the replication account probably needs to see at least the entryUUID and entryCSN for all accounts to make sure that it can see the records it needs to delete. Okay at least I have some direction to go on now.
>
> Jeffrey
>
>
> On Fri, Jun 1, 2012 at 9:06 AM, Nick Milas <nick@eurobjects.com> wrote:
>>
>> On 1/6/2012 8:54 ÏÎ, Jeffrey Crawford wrote:
>>
>>> Are you saying that syncprov looks at the account that is bound and sends deletes if a record would become invisible after a modification?
>>
>>
>> I understand the opposite: syncprov will only send add/delete message based on base/scope/filter and not on ACL-visibility. So in essence Howard says that ACL-based filtering in replication does not result in proper results to consumers.
>>
>> This is tricky! (I didn't know either.) It means that we should *not* design our replication based on ACL-filtering (which, unfortunately, we have done too), but, on the contrary, that we should design our DIT so that it can cover our replication needs based on consumer base/scope/filter configuration, and we should design/adapt our ACLs with the above rule in mind.
>>
>> Please confirm the above thoughts.
>>
>> Thanks,
>> Nick
>
>
>
>
> --
> I fly because it releases my mind from the tyranny of petty things . . .
>
> â Antoine de Saint-ExupÃry
>
> Jeffrey E. Crawford
> ITS Application Administrator (IDM)
> 831-459-4365
> jeffreyc@ucsc.edu




--
I fly because it releases my mind from the tyranny of petty things . . .

â Antoine de Saint-ExupÃry

Jeffrey E. Crawford
ITS Application Administrator (IDM)
831-459-4365
jeffreyc@ucsc.edu