On 10/30/2017 01:03 PM, Sergei Gerasenko wrote:
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.

Got it.

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?


Question 1, in the script, the list of RUVs is retrieved like so:

    $ruv = $conn->search($replicaroot, "one",
               0, qw(nsds50ruv nsruvReplicaLastModified nsds5AgmtMaxCSN));

So the RUV entry of the database is just a special entry, and the short story is that this is the only way to search for it.

For the life of me I don’t understand what nsTombstone records have to do with querying for RUVs. What am I missing? I might be not understanding the ldapsearch syntax there.

Question 2:

The Last Modify Time column in the report has 1/1/1970 for a consumer. What could be the reason for that?
Maybe that replica/consumer was never directly updated?  That value comes from the database ruv maxcsn.

Thank you!