On 10/30/2017 12:37 PM, Sergei Gerasenko wrote:
>> 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
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