On 10/30/2017 12:37 PM, Sergei
Gerasenko wrote:
Hi Mark,
The replication is working. I wrote a
script that makes a change on each
member of the topology and verifies that it got to all
the other members. So, it appears that all is good.
Yup, the monitor output looks good
Cool!
Okay, so
FreeIPA uses fractional replication and stripped
attributes. In a freeipa deployment not all updates are
replicated, and this is probably why the maxcsn's tend to
drift (until you do an update that is replicated). For
example, in FreeIPA each kerberos login updates the database
(and its RUV), but these updates not replicated via the
fractional replication configuration - so the agmt maxcsn
will not be incremented for such operations.
Anyway it all
looks correct to me.
That’s VERY useful information. Thanks a ton. What are other
examples of the events that could increment the local RUV?
Examples of the agmt maxcsn not getting updated are based on the
your replication configuration. You need to look at your
replication agreements under cn=config.
Look for: nsDS5ReplicatedAttributeList
nsDS5ReplicatedAttributeList: (objectclass=*) $ EXCLUDE memberof
idnssoaserial
entryusn krblastsuccessfulauth krblastfailedauth
krbloginfailedcount
In this case any update to any one of these attributes is NOT
replicated. So if you update "memberOf", the agmt maxcsn will not
advance while the database RUV did.
I think I found a small bug in the repl-monitor script, which
however doesn’t affect its operation (miraculously). Is there a
place to submit a patch for that?
https://pagure.io/389-ds-base/new_issue
Thanks,
Mark
Thanks again,
Sergei
|
_______________________________________________
389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx