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


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?


Thanks again,