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