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 . . .


- 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

_______________________________________________
389-devel mailing list --389-devel@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-devel@lists.fedoraproject.org

_______________________________________________
389-devel mailing list -- 389-devel@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-devel@lists.fedoraproject.org

_______________________________________________
389-devel mailing list -- 389-devel@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-devel@lists.fedoraproject.org

Reply via email to