> 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 > <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)); 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? Thank you! Sergei
_______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
