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

Well, curiously I can do it like this:

attrs="nsds50ruv nsruvReplicaLastModified nsds5AgmtMaxCSN"
ldapsearch -xLLL -h $HOST -D "cn=directory manager” -W -b cn=config cn=replica $attrs -o ldif-wrap=no


Is that not a correct way to search for RUVs (both local and agreements’)? I get the same results as in the code
Right, entries under cn=config are not "special entries".  Only the database tombstone/RUV entry is.  So to see a backend database RUV you need to use "(&(nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff)(objectClass=nsTombstone))", but you don't need any "special filter" to search for entries under cn=config.

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.

Ok, I don’t think that’s a concern right now.

One final question…

When I connect to any of the masters with a graphical LDAP browser (JXplorer for example), I can’t find all the RUV information. But ldapsearch can do it no problem. Why?
I know nothing about JXplorer and why it doesn't work as expected.  It is probably NOT doing the correct searches.  You'd have to look at the DS access log to see what its really doing (or not doing).

Regards,
Mark