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.