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

Petr Spacek pspacek at redhat.com
Fri Jan 11 17:07:20 UTC 2013


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

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



More information about the 389-users mailing list