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

[Rich Megginson]

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

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

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