lima-vm
Add `limactl ssh` as alias to `limactl shell`
Description
The common way to run commands and get a shell on a vm is ssh. Common tools provide ssh command to make this easier:
- minikube ssh
- virtctl ssh
But in lima this is called shell. Maybe it is more correct, since we can theoretically interact with the vm by other means, but practically this is always ssh.
I try to use limactl ssh by mistake many times.
This should be a trivial change in the Cobra command.
Downside: we will not be able to use ssh for another command in the future.
Discussed in #3608
I disagree with this. The proper alias for shell should be sh (just like ls for list, rm for remove, cp for copy, etc).
Maybe it is more correct
Yes, because SSH is an implementation detail, and not a description of what the command does. There are a gazillion other aliases we could add, including:
telnet
terminal
term
execute
exec
run
If we say ssh is acceptable because it is the common implementation, should we add scp to copy? How about qemu to start? Where do we draw the line?
Maybe it is more correct, since we can theoretically interact with the vm by other means, but practically this is always ssh.
It is not theoretical. It is really driver-specific. If we were to support shell for the wsl2 driver, the implementation would be based on wsl -d $INSTANCE and not ssh.
The common way to run commands and get a shell on a vm is ssh. Common tools provide ssh command to make this easier:
- minikube ssh
- virtctl ssh
This is the most compelling argument to me, but you can make the same argument for aliasing ps to list because docker and nerdctl use it to list containers (only running ones, unless you specify --all, but that is a minor difference).
To me the same arguments that discourage us from aliasing scp to copy and ps to list apply to aliasing ssh to shell as well.
I'm fine with adding an sh alias, but that would be a separate issue.
I think we had this discussion before, when comparing with docker-machine ssh and podman machine ssh
The real short command is lima, but then you need to juggle the LIMA_INSTANCE environment variable...
I think the outcome last time was that you should use ssh directly in that case, instead of shell (or show-ssh)
As in: ssh lima-default
I think we had this discussion before, when comparing with
docker-machine sshandpodman machine ssh
Right, I forgot about podman machine, another example of a popular tool.
The real short command is
lima, but then you need to juggle the LIMA_INSTANCE environment variable...
This is really not usable for use case of non-default machine.
I think the outcome last time was that you should use
sshdirectly in that case, instead of shell (or show-ssh)As in:
ssh lima-default
This is also not usable since you need the lima ssh config to use the right identity file and ssh options.
As in:
ssh lima-default
Do we document this anywhere? Afaik this only works if you add an Include to your ~/.ssh/config file:
Include /Users/jan/.lima/*/ssh.config
This is also not usable since you need the lima ssh config to use the right identity file and ssh options.
"Not usable" is kind of strong; it takes a one-time setup (per user/host) to make it work (see above).
I disagree with this. The proper alias for
shellshould besh(just likelsforlist,rmforremove,cpforcopy, etc).Maybe it is more correct
Yes, because SSH is an implementation detail, and not a description of what the command does.
This is exactly the issue. Using the most correct term is not a goal. The goal is to make the tool easy to use. This usually means use the terms used by other applications to do the same thing.
But if we cannot agree on this then #3608 is an easy way to resolve this.
This is also not usable since you need the lima ssh config to use the right identity file and ssh options.
"Not usable" is kind of strong; it takes a one-time setup (per user/host) to make it work (see above).
I was not aware that we can include all configs like this, with this ssh is a good way. I need to test this.
Having to patch your local config is an issue for people using multiple machines since you have to remember to configure it. This is why I try to avoid such configurations.
I was not aware that we can include all configs like this, with this ssh is a good way. I need to test this.
The advantage of using ssh directly is that you have control over additional ssh options. So instead of setting ssh.forwardAgent: true in lima.yaml and have the agent forwarded on every connection, you can just forward it the one time you need to pull from a private repo:
ssh -A lima-default git pull ...
Having to patch your local config is an issue for people using multiple machines since you have to remember to configure it.
Just think of it as being part of installing Lima. 😄
This is really not usable for use case of non-default machine.
How so? As mentioned, you do need to configure LIMA_INSTANCE
Maybe we don't really use it for creating a shell to the machine, but for wrapping single commands it is the preferred way.
But a lot of our examples do wrap "foo.lima" to "lima foo", with whatever other environment setup is needed for it to run.
This is really not usable for use case of non-default machine.
How so? As mentioned, you do need to configure LIMA_INSTANCE
Yes, but that is awkward for interactive use. I only ever use lima when I want to connect to default. Otherwise I use l shell INST (so having a sh alias would work for me).
Maybe we don't really use it for creating a shell to the machine, but for wrapping single commands it is the preferred way.
But a lot of our examples do wrap "foo.lima" to "lima foo", with whatever other environment setup is needed for it to run.
The main reason the foo.lima scripts call lima foo instead of limactl shell $LIMA_INSTANCE foo is that we inherit the logic for LIMA_WORKDIR (and the MSYS stuff).
Theoretically also LIMA_SHELL, but that makes no difference because we are just running foo.
Yeah, lima is more for wrapping single commands or so. Like when staying in the shell on the host.
Just saying it's not that bad...
limactl shell almalinux-10
LIMA_INSTANCE=almalinux-10 lima
FYI: host-user (tentative) driver may implement limactl shell without using SSH:
- https://github.com/lima-vm/lima/issues/3618
Probably limactl ssh should print a warning when the underlying implementation of limactl shell does not really use SSH.
Probably
limactl sshshould print a warning
I'm still not convinced that we should add this alias (and the need for a warning is just another argument against it).
If we do add the "plugin via PATH" mechanism from #3608 then users can trivially add it themselves, if they really want to.