#47538 RFE: repl-monitor.pl plain text output, cmdline config options
Closed: Fixed None Opened 6 years ago by rmeggins.

repl-monitor.pl only outputs HTML - need a text based output that is easy to read on a dumb 80x24 terminal. Also need an output that is easy to parse by cmd line tools such as awk/sed/perl to produce reports.

Also need a way to pass in all config on the cmd line - need to be able to run without a config file.


Linked to Bugzilla bug: https://bugzilla.redhat.com/show_bug.cgi?id=1014111 (''Red Hat Enterprise Linux 6'')

typo?
{{{
328 # process the con=mand line config params
}}}
otherwise, looks good.

Also, can you give an example of how to run it, and what the output looks like?

Now, you have can use a config file, command line directives, or both. Previously you had to use a config file.

If you skip the config file, you must enter at least one connection(-c). The other new arguments are: alias(-a), it's just a way to give an instance a name, nothing more. The color arg(-k) only applies to the HTML report. The syntax for these args is the same as the config file:

https://access.redhat.com/site/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Configuration_Command_and_File_Reference/Perl_Scripts.html#template_repl_monitor.pl_Monitor_replication_status-Configuration_File_Format

Here is an example of using just command line args on a single master & single consumer:

repl-monitor.pl -a M1=localhost.localdomain:389 -c "localhost.localdomain:389:cn=directory manager:password:" --text
Directory Server Replication Status (Version 1.1)

Time: Fri Oct 11 2013 19:15:55

Master: M1 ldap://localhost.localdomain:389/
Replica ID: 1
Replica Root: dc=example,dc=com
Max CSN: 52583d80000000010000 (10/11/2013 14:03:44)
Receiver: localhost.localdomain:5103 ldap://localhost.localdomain:5103/
Type: consumer
Time Lag: 0:00:00
Max CSN: 52583d80000000010000 (10/11/2013 14:03:44)
Last Modify Time: 10/11/2013 14:03:44
Supplier: M1
Sent/Skipped: 1 / 0
Update Status: 0 Replica acquired successfully: Incremental update succeeded
Update Started: 10/11/2013 14:08:46
Update Ended: 10/11/2013 14:08:46
Schedule: always in sync
SSL: n

Replying to [comment:6 rmeggins]:

typo?
{{{
328 # process the con=mand line config params
}}}
otherwise, looks good.

Also, can you give an example of how to run it, and what the output looks like?

New patch is attached...

Replying to [comment:7 mreynolds]:

Here is an example of using just command line args on a single master & single consumer:

repl-monitor.pl -a M1=localhost.localdomain:389 -c "localhost.localdomain:389:cn=directory manager:password:" --text
Directory Server Replication Status (Version 1.1)

Could we have an option to prompt for the password? Having the password on the command line isn't ideal since it can be seen with 'ps' as well as being stored in the shell history.

Replying to [comment:9 nkinder]:

Replying to [comment:7 mreynolds]:

Here is an example of using just command line args on a single master & single consumer:

repl-monitor.pl -a M1=localhost.localdomain:389 -c "localhost.localdomain:389:cn=directory manager:password:" --text
Directory Server Replication Status (Version 1.1)

Could we have an option to prompt for the password? Having the password on the command line isn't ideal since it can be seen with 'ps' as well as being stored in the shell history.

New password prompt option added. The new prompt feature also stores the previous password to make handling multiple connections, with the same password, more efficient.

New patch attached...

Looks like the formatting is off in the new bindpwd handling code.

passwdPrompt needs to set the terminal to no echo, as is done in the other perl scripts that prompt for a password, in DSUtil::get_password_from_file

Replying to [comment:11 rmeggins]:

Looks like the formatting is off in the new bindpwd handling code.

passwdPrompt needs to set the terminal to no echo, as is done in the other perl scripts that prompt for a password, in DSUtil::get_password_from_file

Good catch, new patch attached...

git merge ticket47538
Updating 7045c2e..76abd73
Fast-forward
ldap/admin/src/scripts/repl-monitor.pl.in | 576 +++++++++++++++++++----------
man/man1/repl-monitor.1 | 35 ++-
2 files changed, 415 insertions(+), 196 deletions(-)

git push origin master
Counting objects: 19, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (9/9), done.
Writing objects: 100% (10/10), 4.86 KiB, done.
Total 10 (delta 7), reused 0 (delta 0)
To ssh://git.fedorahosted.org/git/389/ds.git
7045c2e..76abd73 master -> master

commit 76abd73
Author: Mark Reynolds mreynolds@redhat.com
Date: Mon Oct 14 13:13:24 2013 -0400

Backport

836ee43..5b4ca6d 389-ds-base-1.3.2 -> 389-ds-base-1.3.2

e592de0..6f90450 389-ds-base-1.3.1 -> 389-ds-base-1.3.1

53d7326..d10e5e3 389-ds-base-1.3.0 -> 389-ds-base-1.3.0

ea59c06..dae03f0 389-ds-base-1.2.11 -> 389-ds-base-1.2.11

Hi Mark,

Could you please take a look at bz1346043?

Additional info:
It seems that it was introduced by ticket 47538.
If it is not a bug, please feel free to close this ticket and the bug with the comments.
Thanks!

cc6e1f0..7ada2e2 master -> master
commit 7ada2e2
Author: Mark Reynolds mreynolds@redhat.com
Date: Fri Jun 17 20:58:16 2016 -0400

8d8f7e8..769b1b2 389-ds-base-1.3.4 -> 389-ds-base-1.3.4
commit 769b1b2

fd96d1b..62052f7 389-ds-base-1.3.3 -> 389-ds-base-1.3.3
commit 62052f7

d45d040..68166d4 389-ds-base-1.2.11 -> 389-ds-base-1.2.11
commit 68166d4

You have my ack. But this is just from my curiosity...

The colour apple green is used for "both unknown". Is it ok? For instance, could there be "no color" or white for such a case?
{{{
$allcolors {0} = "#ccffcc"; #apple green
$allcolors {5} = "#ffffcc"; #cream yellow
$allcolors {60} = "#ffcccc"; #pale pink
}}}
{{{
969 if ((!$s_maxcsn || $s_maxcsn eq "Unavailable") &&
970 (!$c_maxcsn || $c_maxcsn eq "Unavailable")) {
971 $lag_str = "?:??:??";
972 $markcolor = &get_color (0); # Both unknown
}}}
(This is a minor comment. If it does not sound reasonable, please feel free to push your patch. ;)

Replying to [comment:24 nhosoi]:

You have my ack. But this is just from my curiosity...

The colour apple green is used for "both unknown". Is it ok? For instance, could there be "no color" or white for such a case?
{{{
$allcolors {0} = "#ccffcc"; #apple green
$allcolors {5} = "#ffffcc"; #cream yellow
$allcolors {60} = "#ffcccc"; #pale pink
}}}
{{{
969 if ((!$s_maxcsn || $s_maxcsn eq "Unavailable") &&
970 (!$c_maxcsn || $c_maxcsn eq "Unavailable")) {
971 $lag_str = "?:??:??";
972 $markcolor = &get_color (0); # Both unknown
}}}
(This is a minor comment. If it does not sound reasonable, please feel free to push your patch. ;)

Good idea. I've changed it, updated the legend key, and did a much needed update to the man page.

New patch attached.

Very nice! Thanks a lot, Mark!!

6beeb75..34c9293 master -> master
commit 34c9293
Author: Mark Reynolds mreynolds@redhat.com
Date: Tue Jun 28 15:41:42 2016 -0400

987481c..0fe8f37 389-ds-base-1.3.4 -> 389-ds-base-1.3.4
commit 0fe8f37

c66ba8c..ad8ba51 389-ds-base-1.3.3 -> 389-ds-base-1.3.3
commit ad8ba51

e16b83b..66aed16 389-ds-base-1.2.11 -> 389-ds-base-1.2.11
commit 66aed16

Although I also think making "unknown" color should be a good thing, I'm wondering keeping this distinction would be useful for the debugging purpose?
{{{
973 973 $lag_str = "?:??:??";
977 $lag_str = "- ?:??:??";
981 $lag_str = "+ ?:??:??";
}}}

{{{
973 973 $lag_str = "?:??:??";
974 $markcolor = "white"; # Both unknown
975 }
976 elsif ($s_maxcsn && (!$c_maxcsn || $c_maxcsn eq "Unavailable")) {
977 $lag_str = "- ?:??:??";
978 $markcolor = &get_color (36000); # assume consumer has big latency
979 }
980 elsif ((!$s_maxcsn || $s_maxcsn eq "Unavailable") && $c_maxcsn) {
981 $lag_str = "+ ?:??:??";
982 $markcolor = &get_color (1); # consumer is ahead of supplier
974 $markcolor = "white"; # True status unknown
}}}

Replying to [comment:29 nhosoi]:

Although I also think making "unknown" color should be a good thing, I'm wondering keeping this distinction would be useful for the debugging purpose?

Well adding the "everything is fine" color to an unknown state seems wrong to me, even if we know where one of the replicas status is. In fact, we really don't know what state the two replicas are in, so because of that we can not assume the "+" or "-" is even correct. I like what that code was trying to do, but it is just not accurate - it's a guess at what the state is. If anything it can be harmful, and that's why I removed it.

Ok! Thanks for the explanation. I agree if we should not trust it, it's safer not to put it.

a20111b..14fcac3 master -> master
commit 14fcac3
Author: Mark Reynolds mreynolds@redhat.com
Date: Wed Jun 29 10:06:03 2016 -0400

ec15a75..be608a2 389-ds-base-1.3.4 -> 389-ds-base-1.3.4
commit be608a2

ad8ba51..ae73aad 389-ds-base-1.3.3 -> 389-ds-base-1.3.3
commit ae73aad

Metadata Update from @nhosoi:
- Issue assigned to mreynolds
- Issue set to the milestone: 1.2.11.33

2 years ago

Login to comment on this ticket.

Metadata