[389-users] replication with some attributes excluded leads to schema violation

[Petr Spacek]

On 11.1.2013 15:54, Rich Megginson wrote:
> On 01/11/2013 06:26 AM, Petr Spacek wrote:
>> Hello 389 users and developers,
>>
>> I would be very happy if somebody could give me any advice about "the right
>> way" to solve this problem:
>>
>> I have following objectClass in the schema:
>> objectClasses: ( 2.16.840.1.113730.3.8.6.1 NAME 'idnsZone' DESC 'Zone class'
>> SUP idnsRecord STRUCTURAL MUST ( idnsName $ idnsZoneActive $ idnsSOAmName $
>> idnsSOArName $ idnsSOAserial $ idnsSOArefresh $ idnsSOAretry $ idnsSOAexpire
>> $ idnsSOAminimum ) MAY ( idnsUpdatePolicy $ idnsAllowQuery $
>> idnsAllowTransfer $ idnsAllowSyncPTR $ idnsForwardPolicy $ idnsForwarders ) )
>>
>> Please note MUST attribute idnsSOAserial.
>>
>> I have two 389 servers on RHEL 6.4 with the same schema:
>> 389-ds-base-1.2.11.15-10.el6.x86_64
>>
>> There is multi master replication agreement between machines vm-115<->vm-042.
>>
>> Attribute idnsSOAserial is excluded from incremental replication (export
>> from vm-042):
>> cn=meTovm-115,cn=replica,cn=dc\3Dexample,cn=mapping tree,cn=config
>>
>> idnsSOAserial: (objectclass=*) $ EXCLUDE memberof idnssoaserial entryusn
>> krblastsuccessfulauth krblastfailedauth krbloginfailedcount

The list above with proper attribute name looks like:

nsDS5ReplicatedAttributeList: (objectclass=*) $ EXCLUDE memberof idnssoaserial 
entryusn krblastsuccessfulauth krblastfailedauth krbloginfailedcount

>> nsDS5ReplicatedAttributeListTotal: (objectclass=*) $ EXCLUDE entryusn
>> krblastsuccessfulauth krblastfailedauth krbloginfailedcount
>>
>>
>> Now I create a new object with objectClass idnsZone on vm-042. The new
>> object is replicated to vm-115, but the attribute idnsSOAserial is missing -
>> and this fact violates the schema.
>>
>>
>> Is it expected behaviour?
>
> Yes.  Since idnssoaserial is excluded from incremental (I think there is a
> typo above - idnsSOAserial: (objectclass=*) $ EXCLUDE is not correct), it is
> excluded from the replicated ADD operation.
Heh, that is my copy & paste fail :-)

>> What I misunderstood?
>
> Nothing?
>
>>
>> Which approach you recommend to application developers for dealing with such
>> situation?
>
> So you would like idnsSOAserial to be included for replicated ADD operations
> but excluded for replicated MOD operations?

It seems like best option to me, but I'm open to any other proposal which 
solves this problem.

Petr^2 Spacek

>> I don't like the approach where application have to go to *all* DS to
>> initialize the excluded attribute, because:
>> What the application should do if it's unable to connect to one of DSs?
>>
>> What if rollback is impossible? (E.g. attribute was initialized on replica1
>> and replica2 but the link from application to the world failed before
>> replica3 was initialized.)
>>
>> Would it be possible to configure DS to replicate the attribute when object
>> is created but not replicate further changes? It would defer all problems
>> above to DS replication mechanism and simplify applications :-)
>>
>> Thank you for your time!
>>
>>
>> I'm not subscribed to this list, please include me in Cc explicitly.