#50545 Port remaining legacy tools to new python CLI
Opened 6 months ago by mreynolds. Modified 2 months ago

Issue Description

We still have to port these legacy tools:

  • dbmon.sh
  • dbverify
  • dbgen
  • rsearch(?)
  • validate-syntax.pl
  • fixup-memberuid.pl
  • repl-monitor.pl
    • We have this working on the agreement level, but not like the full report that repl-monitor.pl can do

I think that dbgen is already implemented in lib389, we just need the cli for it (probably in dsconf?). Similar, fixup memberuid should already have a fixup task.

I don't even know what rsearch does ....

Metadata Update from @firstyear:
- Custom field origin adjusted to None
- Custom field reviewstatus adjusted to None

6 months ago

Just a note - for validate-syntax.pl, we have an opened issue - https://pagure.io/389-ds-base/issue/50173 (also, there is an ongoing discussion, so it is probably will go as a part of health check tool).

Oh, okay, I haven't found fixup-memberuid.pl because, by some reason, we don't have it...
The only thing we have isadmin/src/scripts/template-fixup-memberuid.pl...
Other scripts available in both fixup-memberuid.pl and template-fixup-memberuid.pl forms

rsearch(?)

This is a repeated search tool, similar to ldclt. It's not written in perl, but in C.

Oh, okay, I haven't found fixup-memberuid.pl because, by some reason, we don't have it...

It's installed as part of instance specific scripts under /usr/lib64/dirsrv/slapd-instance_name. Hence it's present only as a template. I remember we were making these scripts instance agnostic, but this one is not installed under /usr/sbin/

https://pagure.io/389-ds-base/pull-request/50614

cherry-pick repl-monitor to 1.4.1

f6c7e2c..8c896dc 389-ds-base-1.4.1 -> 389-ds-base-1.4.1

@spichugi, could you please cherry pick 761dd65 to 1.4.0? The build fails because of missing DSRC_HOME var in _constants.py (comes from 3798137).
Thanks!

@spichugi, could you please cherry pick 761dd65 to 1.4.0? The build fails because of missing DSRC_HOME var in _constants.py (comes from 3798137).
Thanks!

Cherry-picked to 1.4.0 - dbb8992
Thanks for the reporting!

Metadata Update from @spichugi:
- Issue assigned to spichugi

3 months ago

The report has two duplicate Supplier headers

Screenshot_from_2019-12-06_15-08-22.png

Well things are still not right

Looking at the new report, the supplier reports are very different from one another, and its hard to tell what I'm looking at

Screenshot_from_2019-12-07_11-45-50.png

For the local instance (slapd-replica) in this case on port 5555 looks good, but the report on localhost:389 is much different. There is only a status and reason, but there is no status and reason fields for the first/local instance.

Also in this case I am getting "Invalid credentials" for the reason. So we default the bind dn to "cn=directory manager", but I use "cn=dm". Even though I entered cn=dm in the interactive modal, it still used "cn=directory manager" to authenticate:

[07/Dec/2019:11:45:03.662868474 -0500] conn=60 fd=64 slot=64 connection from ::1 to ::1
[07/Dec/2019:11:45:03.662996984 -0500] conn=60 op=0 BIND dn="cn=Directory Manager" method=128 version=3
[07/Dec/2019:11:45:03.663043800 -0500] conn=60 op=0 RESULT err=49 tag=97 nentries=0 etime=0.000137342 - No suffix for bind dn found
[07/Dec/2019:11:45:03.672857072 -0500] conn=60 op=1 UNBIND
[07/Dec/2019:11:45:03.672870996 -0500] conn=60 op=1 fd=64 closed - U1

If manually set the bind dn and password in the credential table, then it works. Then I get a very different report than before, but it matches what I would expect:

Screenshot_from_2019-12-07_11-56-58.png

So when we can not connect to a replica, I think the report should have a more obvious message:

Can not get replication information from Replica

Status: Unavailable
Reason: Invalid credentials

Sorry to nit pick, but this report is very important and I want to get it perfect (Replication Reports for Dummy's). The report should be easy to understand for people who don't understand replication.

Also it would be nice to have the report set up in a way where you can sort all the agreements/replicas by lag time. It would be nice to quickly find what agreements are way behind the others. This is what my old "Lag Report" did. The Lag Time is probably the most important stat from the report, so we should be able to use it effectively to find troubled replicas. I'm not sure if that breaks your existing model, but it is important to be able to sort based on Lag Time. Maybe we need multiple reports?

Maybe just add an additional "simple/short" table at the end of the report with all the agreements so we can sort by lag time?

Repl report UI work complete:

commit 3054205

02fdfa7..32c1505 389-ds-base-1.4.2 -> 389-ds-base-1.4.2

903a41f..dbfa7a1 389-ds-base-1.4.1 -> 389-ds-base-1.4.1

Login to comment on this ticket.

Metadata