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/ht...
- 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/ht...
- 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/ht...
- 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/ht...
- 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/ht...
- repl_monitor.pl - should we make it a part of 'healthcheck' too? https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/ht...
Thanks, Simon
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/ht...
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/ht...
Does not need to be ported as its a standalone tool
- 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/ht...
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/ht...
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/ht...
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/ht...
Yes
Thanks, Simon
389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-leave@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....
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/ht...
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/ht...
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/ht...
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/ht...
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/ht...
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/ht...
Yes
Thanks, Simon
389-devel mailing list --389-devel@lists.fedoraproject.org To unsubscribe send an email to389-devel-leave@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....
389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-leave@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....
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/ht...
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/ht...
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...
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/ht...
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/ht...
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/ht...
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/ht...
Yes
Thanks, Simon
389-devel mailing list --389-devel@lists.fedoraproject.org To unsubscribe send an email to389-devel-leave@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....
389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-leave@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....
389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-leave@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....
On 25 Jun 2019, at 02:53, Mark Reynolds mreynolds@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/ht...
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/ht...
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/ht...
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/ht...
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/ht...
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/ht...
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-devel@lists.fedoraproject.org To unsubscribe send an email to389-devel-leave@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....
389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-leave@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....
389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-leave@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....
389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-leave@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....
— Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server SUSE Labs
389-devel@lists.fedoraproject.org