On 10/30/2017 02:06 PM, Sergei
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
but you don't need any "special filter" to search for entries under
Question 1, in the script, the list of
RUVs is retrieved like so:
= $conn->search($replicaroot, "one",
0, qw(nsds50ruv nsruvReplicaLastModified
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:
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
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).
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?