I am trying to figure out this one. I searched this forum with no immediate result.
My understanding is that in most cases you can run
snap install SNAPNAME
However, if the Linux distribution is running inside KVM (multipass) or some other virtualization environment (even an LXD container), you need
sudo snap install SNAPNAME
Is there some background in understanding this?
The sudo command runs the command that follows it as the root user. So the question to ask is this: is the shell at hand being run by the root user already? If so, there’s no need to use sudo. If not, then you need sudo so the process becomes root before running the command. That’s true whether the system is native or running inside a VM.
On my desktop computer, I can run
$ snap install hello-world
hello-world 6.3 from ‘canonical’ installed
It gets installed without sudo. Is that supposed to happen? I hope I did not do intrusive changes to the system that somehow does not require sudo in snap install.
That implies you are running it as root, which perhaps means you are running your whole session as root, which is generally not advised. Running the command whoami will confirm which user is running the shell at the moment.
I get this,
$ id
uid=1000(ubuntu) gid=1000(ubuntu) groups=1000(ubuntu),4(adm),20(dialout),24(cdrom),27(sudo),30(dip),46(plugdev),113(lpadmin),128(sambashare),129(vboxusers),130(lxd),135(libvirtd)
On your system (non-virtualized), does it work when you run snap install hello-world as a non-root user?
What do you get with snap version?
Once you authenticate yourself to the store (i.e. sudo snap login) you can then install snaps on your system without needing root privileges.
You can check your current authenticated user with snap whoami and it will show the email address associated with your device. An unauthenticated user would see an empty email, like:
email: -
and will then need root privileges to install a snap.
All of this is true if you’re installing snaps on bare metal, KVM or a LXD container.
Thanks.
Such information are essential to even simple snap usage. I searched around the Internet and did not find something that mentioned this. Such info is important to get out there if snaps are to become core to Ubuntu.
Thanks for the feedback, I’ll put that into the getting started document as well.
And yes, I completely forgot about login.
Is the corollary that if you do not snap login, then /snap/bin does not get automatically in the $PATH of non-root users?
It looks it is a big more complicated than that.
$ multipass launch -c 1 -d 2G -m 2G -n go 16.04
Launched: go
$ multipass exec go bash
To run a command as administrator (user "root"), use "sudo <command>".
See "man sudo_root" for details.
ubuntu@go:~$ sudo snap login
Email address: me@gmail.com
Password of "me@gmail.com":
Login successful
ubuntu@go:~$ snap install hello-world
hello-world 6.3 from 'canonical' installed
ubuntu@go:~$ echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games
ubuntu@go:~$ sudo --login
root@go:~# echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin
root@go:~#
Two questions.
root user gets /snap/bin in their $PATH. It is not from ~/.profile or ~/.bashrc. Where then?/snap/bin in their $PATH?the path entry is set by /etc/profile.d/apps-bin-path.sh which is shipped by snapd and should be executed on fresh login … what you did there is to not spawn the bash you call as login shell, so it wont process any global profile.d defaults “multipass exec go bash -l” should have worked …
Thanks.
It looks to me that both multipass and lxc need a login (or shell) subcommand, and normalize the way you obtain a shell.
Currently, it’s
$ multipass exec myvm bash --login
$ lxc exec mycontainer -- sudo --user ubuntu --login
Ideally, it should be
$ multipass login myvm
$ lxc login mycontainer
or
$ multipass shell myvm
$ lxc shell mycontainer
For root, they can have a --root parameter, as in multipass shell --root myvm.
A sane default would be to get a shell to a non-root user. That’s easy for the Ubuntu images that have the ubuntu non-root account.
Whilst that has the allure of a nicer experience, LXD can be used for many, many other Linux distributions, most of which won’t have the ubuntu user.
It’s a two-step decision. First, is there really a usability issue? Second, what options are there to solve this?
I filed these reports,