10:23 p.m.
Le ven. 2 nov. 2018 à 13:34, Frank Swasey <Francis.Swasey(a)uvm.edu> a écrit :
Perhaps it is best if I lead with an example.
Let's say that I have a local objectclass defined (uvmEduPII) and because
it really has PII in it, I am being asked not to send that data anywhere
the public could possibly see it. Therefore, I set up my delta-syncrepl
consumer with the following exattrs:
exattrs=@uvmEduPII
That brings over all my entries and drops all the attributes that belong
to the uvmEduPII objectClass. However, all of those entries do still have
objectClass: uvmEduPII
when I print them out, and that violates schema checking because the
uvmEduPII objectClass does have a couple MUST attributes and they've been
stripped out because of the exattrs.
Specifically what I am asking to do is to remove the objectClass
attribute's "uvmEduPII" value in the delta-syncrepl process. The only
benefit of doing that is I can set schemachecking=on instead of
schemachecking=off in the syncrepl statement (or olcSyncrepl attribute).
Perhaps, that's just not advisable with a non-complete replication?
- Frank
What you want then is selective replication of a multivalued attribute.
AFAIK, this can't be done in your olcSyncrepl directive, you need to use
ACLs on your provider to restrict your replication account's access. If you
don't want to check how this interferes with your other ACL rules, it would
be something like that:
olcAccess: to dn.subtree=<your branch> attrs=objectClass
val.exact=uvmEduPII by dn.exact=<your replication account> none by * break
early enough in the ACL list to be evaluated before any other rule
concerning the targeted entries.
Either you define one of these rules for each of your four objectClass
values, or you change val.exact=... to val.regex=<regex identifying exactly
what you want> (guess there is some performance difference, evaluating
regex is usually rather expensive).
I actually tried something like that some time ago, with slurpd
replication, and it did not work properly when the multivalued attribute
was modified on the provider, I don't know how syncrepl manages it. Also,
your restriction concerns a schema attribute, there might be dependencies
forbidding this - your excluded objectClasses must be AUXILIARY to start
with.
Cheers,
Manuela
> On Nov 1, 2018, at 13:27, Manuela Mandache <
manuela.mandache.mm(a)gmail.com> wrote:
>
>
>
> Le mer. 31 oct. 2018 03:20, Frank Swasey <Francis.Swasey(a)uvm.edu> a
écrit :
> I am attempting to set up a replication using delta-syncrepl that will
ignore four objectClasses. I am able to prevent the attributes of those
objectClasses from being sent, by using @objectClassName in the exattrs
value of the statement. However, I also have to set schemachecking off
because the objectClass: objectClassName value is still coming over.
>
> I was not able to find any examples of using the exattrs option in the
tests/data directory. And, I have failed to find anything relevant from
google.
>
> Is there a way to prevent the four possible objectClass values that I
don't want to see from being sent so I can leave schemachecking turned on?
>
> Thanks,
> - Frank
>
>
> Hi Frank,
>
> In your olcSyncrepl directive you can set the search filter for the
entries to be replicated. The default filter is
> '(objectClass=*)'
> Replace it by
> '(&(! (objectClass=class1))(! (objectClass=class2))(!
(objectClass=class3))(! (objectClass=class4)))'
> Or add this to whatever filter you have (hope I got the paranthesis
right).
>
> Cheers,
>
> Manuela
>
> Sorry, I misclicked for the reply and didn't send it to the list. And
what I said prevents all entries using any of the four classes from being
replicated and concerns the olcSyncrepl statement of your actual data. The
exattrs is no longer needed if you use this filter - and you might want to
let it out, if any of your four classes' attributes are used by some other
class.
>
> But I wonder if I didn't misunderstand your question. The values of
objectClass are not in your data, they belong to the schema,
cn=schema,cn=config. Do you replicate your cn=config and want to have a
different schema on your consumer with respect to the provider ?
>
> Cheers,
>
> Manuela
>