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?
What I misunderstood?
Which approach you recommend to application developers for dealing with such
situation?
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.
--
Petr Spacek
Software engineer
Red Hat Czech, BRQ
--
389 users mailing list
389-users@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-users
