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.
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!
--
389 users mailing list
389-users@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-users
