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...
Revision #3 0001-Ticket-47538-RFE-repl-monitor.pl-plain-text-output-c.patch
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!
Fix regression is color coded lag time 0001-Ticket-47538-repl-monitor.pl-not-displaying-correct-.patch
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. ;)
revision 0001-Ticket-47538-Fix-repl-monitor-color-and-lag-times.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
Legend was not sorted correctly 0001-Ticket-47538-repl-monitor.pl-legend-not-properly-sor.patch
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
389-ds-base is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in 389-ds-base's github repository.
This issue has been cloned to Github and is available here: - https://github.com/389ds/389-ds-base/issues/875
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @spichugi: - Issue close_status updated to: wontfix (was: Fixed)
Login to comment on this ticket.