One topic that came up during the sprint is that there is no easy way to set the proxy for snapd. On a classic system this is easy via editing /etc/environment. However on an ubuntu-core system this file is read-only. Providing an easy way to set the proxy on core this way would be beneficial.
Sounds reasonable. Perhaps something like proxy.http for the option name, so we group all system proxies under the same document?
On the one hand, we probably want
/etc/environment to be writable anyway.
On the other hand, while it might not be easy, copying
/etc/systemd/system and adding the appropriate
Environment= line is not exactly hard.
On the other hand, yeah we probably want it to be a setting anyway.
It depends a little bit what we want, if we limit the option to only snapd, we could easily create a /etc/systemd/system/snapd.service.d/proxy.conf with just Environment=http_proxy://thing. However if we want the proxy to be system-wide, then /etc/environment is the place to go. I think we want the later but I’m open for discussion.
Yeah. Having something that just works for
snapd but not for, say,
snap download, would suck.
I’ve been working on the console-conf side of this but I was assuming that /etc/environment would be editable. If not, then we need something else… (creating a drop-in file would be easy but as @chipaca says, not necessarily the most complete fix)
lets ask @jdstrand if he thinks that adds any additional attack vector, we can surely make it writable if there are no concerns from the security team.
how will we deal with that on classic installs though ? does snapd already pick up a global proxy setting without fiddling with the systemd unit manually today ?
I don’t think we provide any particularly nice experience for people who
need to use proxies on classic either, just editing /etc/environment or
systemd drop in files.
there is a setting in the control-center on desktops that makes it rather easy to set (on servers you need to edit /etc/environment though), my question was rather if snapd picks that up without having to add an additional Environment= line to the snapd systemd unit.
Well the snapd service file has EvironmentFile=/etc/environment, I don’t
know what setting the proxy “system wide” in control-center actually does,
if it’s edit /etc/environment then I guess we’re sorted.
Feel free to mark this as writable. I agree that using this file for system-wide proxy makes a ton of sense-- if we only put it in the snapd service files, then we’ll just get another request to allow managing /etc/environment for everything else. I’m not sure if there are use cases for having both /etc/environment editable and having snapd use a different proxy, but that would be an easy enough change in snapd to ignore environ if configured to use something else via ‘snap set core …’ or similar.
The security policy for snaps currently does not allow writing /etc/environment. It being readonly now doesn’t provide a ton of security protection: only root can edit it, and if you are root on the system (including in a devmode snap) you could adjust systemd units for proxy, perform a bind mount on /etc/environment, etc.
Are there still plans to make this configurable via ‘snap set core proxy.http=…’ per the original thread subject? Doing so would allow the proxy to be configured via an agent that’s allowed to talk to snapd via the snapd-control interface.
@mvo Anything else there or can we merge this? Two +1s and other comments there seem to be on the positive side.
Nothing on my side pending, we may improve it later via asking snapctl for a json doc with all the settings but that can be done in a followup (its the same as the current shellscript).
Does this work on classic systems? It appears to have no effect:
I’m using snap/snapd 2.32.6.
I gave up on using these variables, and used this, which seems to work:
Could you please support socks proxy???
I can’t install any packages with snap because of the networking in China.
I tried to use http_proxy in /etc/environment but not working.
The issue @jhobbs mentioned is valid:
Currently this prevents our deployments from using new Juju snap-related model-configs.
Could this be triaged and given a priority?