On 10/30/2017 01:03 PM, Sergei Gerasenko wrote:
> 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?
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
do with querying for RUVs. What am I missing? I might be not
understanding the ldapsearch syntax there.
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.