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