-
Notifications
You must be signed in to change notification settings - Fork 161
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
Dissociate SSH key import from form submission #1895
Dissociate SSH key import from form submission #1895
Conversation
Pushed a change to fix the CI issue on focal: EDIT: dropped this change after rebasing on main since we removed focal test enforcement. |
2dd26a7
to
1f47914
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was sure I reviewed this last week but apparently not! I'm super happy to see this, and pleasantly surprised that it can all be done client side.
I have a few quibbles about widget enabling/disabling and a few pre-existing oddities I spotted when reviewing this. The former should probably be fixed (sorry, it'll be annoying) but feel free to ignore the latter for now.
subiquity/client/controllers/ssh.py
Outdated
else: | ||
if isinstance(confirm_overlay, ConfirmSSHKeys): | ||
break | ||
await asyncio.sleep(0.1) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Heh this is pretty gross. But well, all honest answers code is a bit gross.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's a bit bikesheddy, but do we need the .1 portion of the sleep or are we just trying to allow other tasks to run? could asyncio.sleep(0)
if it's just about the other tasks.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed.. I'll move this to a function in view_helpers which will wait for an overlay to show up. I think that should make the answers code easier to write/read.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, asyncio.sleep(0) will cause high CPU load while fetching a key over the network. Maybe 0.01 if we want to speed things up ? @dbungert wdyt?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
WFM
id_.to_authorized_key() for id_ in identities | ||
] | ||
self.done(ssh_data) | ||
if isinstance(self.ui.body, SSHView): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Again, it's not your fault but we do we only do this check in the success case?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Super nice to get answers-handling code out of the "production" workflow though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Again, it's not your fault but we do we only do this check in the success case?
Actually, no, we have the same check for IMPORT_ERROR and FINGERPRINT_ERROR:
subiquity/subiquity/client/controllers/ssh.py
Lines 77 to 81 in 3964014
if isinstance(self.ui.body, SSHView): | |
self.ui.body.fetching_ssh_keys_failed( | |
_("Importing keys failed:"), response.error | |
) | |
return |
subiquity/subiquity/client/controllers/ssh.py
Lines 83 to 88 in 3964014
if isinstance(self.ui.body, SSHView): | |
self.ui.body.fetching_ssh_keys_failed( | |
_("ssh-keygen failed to show fingerprint of downloaded keys:"), | |
response.error, | |
) | |
return |
1f47914
to
f60679e
Compare
Previously, on the SSH screen, the ability to enable/disable the SSH server and the ability to import a SSH identity were both covered by a single form. Therefore, there was no way to import multiple identities. This change adds a button "Import SSH key" which opens a new form to import an identity. The button can be pressed multiple times and the resulting identities are all submitted when the user clicks on Done. Furthermore, navigating back to the SSH screen does not "forget" already imported identities. Signed-off-by: Olivier Gayot <[email protected]>
f60679e
to
2465373
Compare
2465373
to
af5fb7f
Compare
When running answers-based automation, the SSH controller looks into more than one section to find ssh-import-id directives. If the "SSH" section exists, then it is where the ssh-import-id directives must be placed. However, if the section does not exist, the controller will also look for ssh-import-id directives in the "Identity" section. The answers.yaml file used this special mechanism. This is fine. However, if one adds a SSH section to customize other settings (e.g., install_server, pwauth), then the ssh-import-id directives in the Identity section suddently get ignored ; which is confusing and looks as if there is a bug. Let's move ssh-import-id directives to the SSH section. Signed-off-by: Olivier Gayot <[email protected]>
A new table shows all the SSH identities/keys that are currently imported. The user can select one and delete it from the list if he wants to. Signed-off-by: Olivier Gayot <[email protected]>
When selecting a SSH identity, the user can open a dialog showing the contents of the key. Signed-off-by: Olivier Gayot <[email protected]>
Signed-off-by: Olivier Gayot <[email protected]>
Signed-off-by: Olivier Gayot <[email protected]>
Signed-off-by: Olivier Gayot <[email protected]>
Signed-off-by: Olivier Gayot <[email protected]>
af5fb7f
to
3f3bb29
Compare
I started this work a year ago and never got a chance to finish it.
I spent some time today to clean it up and fix the tets. It looks correct now.
It brings several benefits over the existing implementation:
ssh: authorized-keys:
directives.