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?
https://pagure.io/389-ds-base/new_issue
Excellent!
Question 1, in the script, the list of RUVs is retrieved
like so:
$ruv =
$conn->search($replicaroot, "one",
"(&(nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff)(objectClass=nsTombstone))",
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!
Sergei
|
_______________________________________________
389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
