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

[Rich Megginson]

On 01/11/2013 08:13 AM, Petr Spacek wrote:
> 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.

Why don't you want idnsSOAserial to be replicated for MOD operations?

>
> 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.
>