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

[Petr Spacek]

On 11.1.2013 22:00, Rich Megginson wrote:
> On 01/11/2013 10:07 AM, Petr Spacek wrote:
>> On 11.1.2013 17:05, Petr Spacek wrote:
>>> On 11.1.2013 16:22, Rich Megginson wrote:
>>>> 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?
>>>
>>> There could potentially be a high update traffic (from more servers) and we
>>> want to avoid replication conflicts. I will dig design document for the
>>> feature using this attribute.
>>
>> "Design e-mails" follow, hopefully they are complete enough to illustrate
>> what is going on:
>>
>> The problem statement:
>> https://www.redhat.com/archives/freeipa-devel/2012-April/msg00222.html
>>
>> Last proposed solution with non-replicated idnsSOAserial attribute:
>> https://www.redhat.com/archives/freeipa-devel/2012-May/msg00047.html
>
> So idnsSOAserial is a "local only" attribute that lives in a "global" entry.
>
> I agree that this is an attribute that should be managed internally by the
> directory server, like the entryusn attribute.
>
> Unfortunately, since it is a required attribute, you must specify it in an
> LDAP ADD operation.
>
> I don't really see an easy way to do this without the ability to allow
> replication for ADD operations and disallow for MOD operations.  Please file a
> 389 ticket.

Thank you for information! We will investigate entryUSN properties and file 
the ticket if we consider entryUSN as insufficient replacement.

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