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!