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

On Nov 1, 2018, at 13:27, Manuela Mandache manuela.mandache.mm@gmail.com wrote:

Le mer. 31 oct. 2018 03:20, Frank Swasey Francis.Swasey@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

On Nov 3, 2018, at 01:23, Manuela Mandache manuela.mandache.mm@gmail.com wrote:

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

It actually turns out that it is best to leave the objectClass values there (I've discovered I have customers who are using the presence of the objectClass value as an indicator of eligibility for some service).

- Frank

On Nov 6, 2018, at 21:56, Lucio De Re lucio.dere@gmail.com wrote:

I thought you said that this caused breakage. If I understood correctly, keeping the objectclass without the deleted non-optional matching attribute(s) caused an erroneous situation.

How did you address that or am I remembering incorrectly?

The breakage I reported was that I needed to set schemachecking off instead of on. I was looking to have the objectClass attribute to have those names removed so I could leave schemachecking on since all of them were auxiliary objectclasses and not having them would not have made the whole entry illegal.

With schemachecking off, the only problem is inside my head.

- Frank

On Nov 7, 2018, at 10:33, Lucio De Re lucio.dere@gmail.com wrote:

On 11/7/18, Frank Swasey Francis.Swasey@uvm.edu wrote:

...

[ ... ] With schemachecking off, the only problem is inside my head.

But also in mine, as I would assume that turning schemachecking off should be reserved for short burst of special purpose (recovery, for example) activities, not for production operation.

I think you are between a rock and a hard place and you should give some thought on how to get out of that situation :-).

I'm justifying it to myself by saying that schemachecking is on on the producer, and as long as the consumer works correctly (and has no local writes), the data being valid on the producer is more important than the schema being valid on the replica.

- Frank