> On 25 Jun 2019, at 02:53, Mark Reynolds <mreyno...@redhat.com> wrote: > > > On 6/24/19 12:28 PM, Rich Megginson wrote: >> On 6/24/19 10:00 AM, Mark Reynolds wrote: >>> >>> >>> On 6/24/19 11:46 AM, Simon Pichugin wrote: >>>> Hi team, >>>> I am working on porting our admin Perl scripts to Python CLI. >>>> Please, check the list and share your opinion: >>>> >>>> - cl-dump.pl - dumps and decodes changelog. Is it used often (if at all)? >>>> https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html-single/configuration_command_and_file_reference/index#cl_dump.pl_Dump_and_decode_changelog >>>> >>> This is used often actually, and is a good debugging tool. I think it >>> just creates a task, so it should be ported to CLI (added to replication >>> CLI sub commands) >>>> - logconv.pl - parse and analise the access logs. Pretty big one, is it >>>> priority? How much people use it? >>>> issue is created -https://pagure.io/389-ds-base/issue/50283 >>>> https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html-single/configuration_command_and_file_reference/index#logconv_pl >>>> >>> Does not need to be ported as its a standalone tool >> >> >> Would be great to eliminate perl altogether . . . but this one will be >> tricky to port to python . . . > > Yes it would be nice to port this script, but it will be a lot of work > (especially with the database implementation). There was a ticket open to > track this effort: https://pagure.io/389-ds-base/issue/50283 > > Now what I really meant though is that this is a lower priority effort since > it's not actually interacting with DS. Basically it's just looking at text > files so there is no lib389 porting involved. Maybe we can target this work > for 389-ds-base-1.4.3? > > Or build these stats into DS and make it a new monitor entry? Not sure if > this is feasible, and it would only report stats from the last server > startup. Something to think about though...
For now, I'd rather target just the "configuration" style perl scripts. Things like logconv can stay for now. > > Mark > >> >> >>>> - migrate.pl - which migration scenarios do we plan to support? >>>> Do we depricate old ones? Do we need the script? >>>> https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html-single/configuration_command_and_file_reference/index#migrate-ds.pl >>>> >>> This script is obsolete IMHO >>>> - ns_accountstatus.pl, ns_inactivate.pl, ns_activate.pl - the issue is >>>> discussed here -https://pagure.io/389-ds-base/issue/50206 >>>> I think we should extend status at least. Also, William put there some >>>> of his thoughts. What do you think, guys? Will we refactor >>>> (kinda depricate) some "account lock" as William proposing? >>>> https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html-single/configuration_command_and_file_reference/index#ldif2db.pl_Import-ns_accountstatus.pl_Establish_account_status >>>> >>> I will update the ticket, but we need the same functionality of the ns_* >>> tools, especially the new status work that went into ns_accountstatus.pl - >>> that all came from customer escalations so we must not lose that >>> functionality. >>>> - syntax-validate.pl - it probably will go to 'healthcheck' tool >>>> issue is created -https://pagure.io/389-ds-base/issue/50173 >>>> https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html-single/configuration_command_and_file_reference/index#syntax-validate.pl >>>> >>> Yes >>>> - repl_monitor.pl - should we make it a part of 'healthcheck' too? >>>> https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html-single/configuration_command_and_file_reference/index#repl_monitor.pl_Monitor_replication_status >>>> >>> Yes >>>> Thanks, >>>> Simon On all other points I agree, and work has already gone into a lot of these places :) A good way to test this is "--disable-perl" which should eliminate these scripts for you in a build, then you can see what is missing in test cases. >>>> >>>> _______________________________________________ >>>> 389-devel mailing list --389-de...@lists.fedoraproject.org >>>> To unsubscribe send an email to389-devel-le...@lists.fedoraproject.org >>>> Fedora Code of >>>> Conduct:https://docs.fedoraproject.org/en-US/project/code-of-conduct/ >>>> List Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines >>>> List >>>> Archives:https://lists.fedoraproject.org/archives/list/389-de...@lists.fedoraproject.org >>> >>> _______________________________________________ >>> 389-devel mailing list -- 389-de...@lists.fedoraproject.org >>> To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org >>> Fedora Code of Conduct: >>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ >>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines >>> List Archives: >>> https://lists.fedoraproject.org/archives/list/389-de...@lists.fedoraproject.org >> >> _______________________________________________ >> 389-devel mailing list -- 389-de...@lists.fedoraproject.org >> To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org >> Fedora Code of Conduct: >> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ >> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines >> List Archives: >> https://lists.fedoraproject.org/archives/list/389-de...@lists.fedoraproject.org > _______________________________________________ > 389-devel mailing list -- 389-de...@lists.fedoraproject.org > To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/389-de...@lists.fedoraproject.org — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs _______________________________________________ 389-devel mailing list -- 389-de...@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-de...@lists.fedoraproject.org
