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(a)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(a)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(a)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(a)ucsc.edu