-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Designing new command line interface (hilbert) #28
Comments
DRAFT (v.0.5): General design ideas for
|
Some comments:
|
@elondaits, i am almost ready with my draft. Please wait a bit. |
Let me know... but consider I get an email message when new things are posted and none when you edit your previous messages. |
@elondaits Ok, i am mostly done. I suggest we start discussing the use cases and usage scenarios. |
To make implementation in bash simpler the following looks promising: The global subcommand utility: http://people.tuebingen.mpg.de/maan/gsu/ gsu is a small library of bash functions intended to ease the task of writing and documenting large shell scripts with multiple subcommands, each providing different functionality. gsu is known to work on Linux, FreeBSD, NetBSD and MacOS. |
General coments
Security
If I understand this right this suggests placing the ssh key to the remote station somewhere it can be fetched through ftp so the system can then issue ssh commands. If that's the idea... This is a crazy backdoor! It's possible that I misunderstood but then the text should be clarified because that's what I read now.
I don't think it's a good idea to have a generic backdoor. Our system should, if possible, only allow remote execution of "safe" commands. ssh already does this, as well.
allowed args should be explicitly documented, validated and never ever sent directly from the hilbert invocation to the sudoed command. Otherwise one could do something like
(or some smarter / trickier way of escaping things in bash) and piggyback a command. All user input is evil and should be treated as such.
Semantics
Syntax / aesthetics
when the description of the command says something different than the name it's a good indication that the name should be changed (list_remote_systems in this case, for instance)
Other
Not covered
|
Minimal The purpose of actions that replace current scripts is the same as that of the superseded scripts. Same with semantics for now... |
@elondaits Could you please move your comments to the shared Google Document and attach them to relevant places in the draft design. Let us continue the discussion there. |
I added them. Some were general comments that might be relevant to several parts or the document as a whole... so consider what they say and not only the place where I added them. |
Has to be moved to https://github.com/hilbert/hilbert-cli/issues |
I updates the google document:
|
See also "Configuration Design (super issue)": hilbert/hilbert-cli#13 |
More specifics on
Note: prior to starting some services/applications For instance: auto-detection of variables for using some currently running native services or device configurations: Note: services started by Of course IMO in general NOTE: It has to be attached to service/application definition in general YAML configuration: Suggestion: |
This issue is a super-issue again that needs to be split up. I already modified the issue description. @malex984 Please prepare the individual issues and add them to the list. A summary of the results should be added and updated on a regular basis, e.g. each time a sub-issue is closed (you can add commit-like comments to this issue and reference them in the description to make clear with state is reflected in the description). |
Note: this one is in @porst17 Q: What about using hilbert/hilbert-cli#14 as a super issue instead of this one? |
Please let me elaborate on the operation of According to #28 (comment)
|
Let me extend #28 (comment) wrt Server specifics:
|
I missed that this issue is still listed under |
For reference: command aliases |
CLI server/client tools were initially implemented within hilbert/hilbert-cli#34 Corresponding design is in the "Management Back-end" Document. Current CLI: |
Further implementation will be due to hilbert/hilbert-cli#14 |
Please use this issue to create and discuss a specification for the new unified command line interface.
Never reference anything below this line in the comments. It may change at any time.
Sub-issues to solve:
Hilbert-CLI-Server
Design (works with the general YAML config, communicates with CMS)Hilbert-CLI-Station
Design (e.g. Designing new command line interface (hilbert) #28 (comment), written in BASH, sourced local config)The text was updated successfully, but these errors were encountered: