evolix/evobackup
21
0
Fork 1
Code Issues 32 Pull requests 4 Releases 26 Activity

WIP: fix the command line interface #39

Draft
jlecour wants to merge 2 commits from fix-cli into master
pull from: fix-cli
merge into: evolix:master
Conversation 4 Commits 2 Files changed 14 +204 -97
jlecour commented 2020-04-19 11:54:28 +02:00
Owner
Copy link

The main idea is to improve the command line interface by adding new subcommands with much clearer semantics.

For example:

  • bkctld add-ip <JAIL> <IP> : add <IP> to the existing list of ips for <JAIL>
  • bkctld reset-ip <JAIL> <IP> : replace the existing list of ips for <JAIL> with <IP>
  • bkctld list-ips <JAIL> : print the existing list of ips for <JAIL>
  • bkctld add-key <JAIL> <KEY_FILE> : add the key from <KEY_FILE> to the list of authorized keys for <JAIL>
  • bkctld reset-key <JAIL> <KEY_FILE> : replace the list of authorized keys for <JAIL> with the key from <KEY_FILE>
  • bkctld list-keys <JAIL> : print the list of authorized keys for <JAIL>
  • bkctld create-incs : create daily incs
  • bkctld prune-incs : delete incs according to incs policy
  • bkctld list-incs <JAIL> : print the list of incs for <JAIL>
  • bkctld report-incs [all|last] : report incs status
  • bkctld nrpe : NRPE-compatible check (mounted partition, jails last log…)
  • bkctld archive <JAIL> : archive <JAIL>
  • …
The main idea is to improve the command line interface by adding new subcommands with much clearer semantics. For example: * `bkctld add-ip <JAIL> <IP>` : add \<IP\> to the existing list of ips for \<JAIL\> * `bkctld reset-ip <JAIL> <IP>` : replace the existing list of ips for \<JAIL\> with \<IP\> * `bkctld list-ips <JAIL>` : print the existing list of ips for \<JAIL\> * `bkctld add-key <JAIL> <KEY_FILE>` : add the key from \<KEY_FILE\> to the list of authorized keys for \<JAIL\> * `bkctld reset-key <JAIL> <KEY_FILE>` : replace the list of authorized keys for \<JAIL\> with the key from \<KEY_FILE\> * `bkctld list-keys <JAIL>` : print the list of authorized keys for \<JAIL\> * `bkctld create-incs` : create daily incs * `bkctld prune-incs` : delete incs according to incs policy * `bkctld list-incs <JAIL>` : print the list of incs for \<JAIL\> * `bkctld report-incs [all|last]` : report incs status * `bkctld nrpe` : NRPE-compatible check (mounted partition, jails last log…) * `bkctld archive <JAIL>` : archive \<JAIL\> * …
👍 1 🎉 1
jlecour added the
bkctld
 label 2020-04-19 11:54:28 +02:00
jdubois commented 2020-04-20 10:54:26 +02:00
Member
Copy link

I would rather have thought of commands like "command subcommand action", as it is used in many commands : systemctl, rcctl, bgpctl, ospfctl, …

That would give :

  • bkctl ip add / bkctl ip reset / bkctl ip list
  • bkctl key …
  • bkctl incs …

And I don't know if this belongs here, but it would be perfect with auto completion.

I would rather have thought of commands like "command subcommand action", as it is used in many commands : systemctl, rcctl, bgpctl, ospfctl, … That would give : - bkctl ip add / bkctl ip reset / bkctl ip list - bkctl key … - bkctl incs … And I don't know if this belongs here, but it would be perfect with auto completion.
👍 2
lpoujol commented 2020-04-20 14:59:49 +02:00
Owner
Copy link

I agreed with @jdubois here.

I'm also in favor of the command subcommand action pattern here.
Also, maybe use the word replace instead of reset for IP/Key change.

I agreed with @jdubois here. I'm also in favor of the *command subcommand action* pattern here. Also, maybe use the word `replace` instead of `reset` for IP/Key change.
jlecour commented 2020-04-20 18:29:23 +02:00
Author
Owner
Copy link

I really like the pattern bkctld <subcommand> <action> [<option>]. It looks a bit like the "ip" command. But it's a bit more difficult to implement.

If we decide to keep a simpler syntax with just a list of subcommands, we can still compose the subcommand with a prefix and an action, like this :

  • bkctld ip-add <JAIL> <IP> : add <IP> to the existing list of ips for <JAIL>
  • bkctld ip-replace <JAIL> <IP> : replace the existing list of ips for <JAIL> with <IP>
  • bkctld ip-list <JAIL> : print the existing list of ips for <JAIL>
  • bkctld key-add <JAIL> <KEY_FILE> : add the key from <KEY_FILE> to the list of authorized keys for <JAIL>
  • bkctld key-replace <JAIL> <KEY_FILE> : replace the list of authorized keys for <JAIL> with the key from <KEY_FILE>
  • bkctld key-list <JAIL> : print the list of authorized keys for <JAIL>
  • bkctld inc-create : create daily incs
  • bkctld inc-prune : delete incs according to incs policy
  • bkctld inc-list <JAIL> : print the list of incs for <JAIL>
  • bkctld inc-report [all|last|<JAIL>] : report incs status
  • bkctld nrpe : NRPE-compatible check (mounted partition, jails last log…)
  • bkctld archive <JAIL> : archive <JAIL>
  • …
I really like the pattern `bkctld <subcommand> <action> [<option>]`. It looks a bit like the "ip" command. But it's a bit more difficult to implement. If we decide to keep a simpler syntax with just a list of subcommands, we can still compose the subcommand with a prefix and an action, like this : * `bkctld ip-add <JAIL> <IP>` : add \<IP\> to the existing list of ips for \<JAIL\> * `bkctld ip-replace <JAIL> <IP>` : replace the existing list of ips for \<JAIL\> with \<IP\> * `bkctld ip-list <JAIL>` : print the existing list of ips for \<JAIL\> * `bkctld key-add <JAIL> <KEY_FILE>` : add the key from \<KEY_FILE\> to the list of authorized keys for \<JAIL\> * `bkctld key-replace <JAIL> <KEY_FILE>` : replace the list of authorized keys for \<JAIL\> with the key from \<KEY_FILE\> * `bkctld key-list <JAIL>` : print the list of authorized keys for \<JAIL\> * `bkctld inc-create` : create daily incs * `bkctld inc-prune` : delete incs according to incs policy * `bkctld inc-list <JAIL>` : print the list of incs for \<JAIL\> * `bkctld inc-report [all|last|<JAIL>]` : report incs status * `bkctld nrpe` : NRPE-compatible check (mounted partition, jails last log…) * `bkctld archive <JAIL>` : archive \<JAIL\> * …
lpoujol commented 2025-01-10 10:47:51 +01:00
Owner
Copy link

This PR is 5years old :o

@jlecour Shall we update it so we can merge it ?
Or do we give-up ?

This PR is 5years old :o @jlecour Shall we update it so we can merge it ? Or do we give-up ?
This pull request has changes conflicting with the target branch.
  • README.md
  • bkctld
  • bkctld.8
  • bkctld.conf.5
  • docs/configuration.md
  • docs/incrementals.md
  • docs/install.md
  • docs/usage.md
  • lib/includes
  • test/incs.bats
View command line instructions

Checkout

From your project repository, check out a new branch and test the changes.
git fetch -u origin fix-cli:fix-cli
git checkout fix-cli

Merge

Merge the changes and update on Forgejo.

Warning: The "Autodetect manual merge" setting is not enabled for this repository, you will have to mark this pull request as manually merged afterwards.

git checkout master
git merge --no-ff fix-cli
git checkout fix-cli
git rebase master
git checkout master
git merge --ff-only fix-cli
git checkout fix-cli
git rebase master
git checkout master
git merge --no-ff fix-cli
git checkout master
git merge --squash fix-cli
git checkout master
git merge --ff-only fix-cli
git checkout master
git merge fix-cli
git push origin master
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels   
bkctld

   
bug

Something is not working

  
duplicate

This issue or pull request already exists

  
enhancement

New feature

  
invalid

Something is wrong

  
question

More information is needed

  
wontfix

This won't be fixed

  
zzz_evobackup
No labels
bkctld
bug
duplicate
enhancement
invalid
question
wontfix
zzz_evobackup
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
3 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: evolix/evobackup#39
No description provided.
Delete branch "fix-cli"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?