Improve proxy configuration for snapd

The proxy configuration for snapd is currently taken from the environment (via {http,https}_proxy). This works fine with ubuntu which writes the system-wide proxy configuration from gnome-control-center to /etc/environment (which is read by the snapd.service files).

However other distros like Fedora do not use this mechanism. The proxy is configured via network-manager (or nmcli) here.

In order to support systems like Fedora better we should look into supporting libproxy from snapd. We probably do not want to link to it directly in snapd to avoid that we depend on cgo, instead we can use the proxy helper that is part of libproxy-bin or we could write a tiny helper ourself. We will also need to ensure that the store package in snapd creates new http.Client with the right proxy transports because libproxy supports different proxies for different URLs so for each URL we need to call libproxy to check what proxy to use.

It’s hard to believe that every single server running in Fedora is directly communicating with network-manager to ask for proxy settings. There must be a more trivial way to consume that from an old school daemon.

@Conan_Kudo Any suggestions here?

Well, the simplest way would be to just drop in a file into /etc/profile.d that exports the variable.

But all Fedora servers run NetworkManager by default for networking, and proxy information is available via PACrunner, libproxy, and a few other mechanisms.

AFAIK, even libcurl queries PACrunner if it’s offering proxy configuration…

I’m really wondering about how old school daemons being shipped in Fedora consume the information from network-manager. Were all of them changed to use libproxy?

I don’t really know. I know that we don’t typically have things looking in /etc/environment. Usually, they have their own file (e.g. /etc/sysconfig/foo).

Yeah, that’s usual across distributions, but it doesn’t make much sense for something global like a proxy setting. Generally this is written into a system-wide file that contains environment settings or a shell script, so that daemons and applications expecting the typical http_proxy style of variables will just work.

I suppose one way to do that would be to just drop in the variables into a file in /etc/profile.d, so that they get exported to the global shell environment. However, we don’t typically do this.

Another thing is that rh-ifcfg files support declaring the proxy (unlike debian network interfaces files) by pointing to a PAC file which provides that information.

Both of those cases are stlil looking at an administrator doing something by hand. If that’s the common thing to do, there must be a proper file that is recommended for the change and that will affect the daemon automatically. If that’s not common and network-manager is used, we should look at a few trivial old school daemons to see how they are organized in terms of the proxy setting.

that wont really help for services etc … only for login shells

That’s true. But nothing can see /etc/environment either unless it’s specifically pulled into the systemd unit.

There is the new /etc/environment.d thing supported in systemd 233, but that’s only in Fedora 26 and newer.

Does this impact the prior proposal(s) to have proxy configuration handled by core snap config or is this just a discussion of the internal implementation details?

FYI, I asked this question, as I have a customer asking about the proper way to configure snapd for proxy support, and was wondering if the prior proposal is still plan of record, so I can set their expectations for if/when this will land.

On our production server deployments, we cannot set the http_proxy environment variable because this sends everything though the proxy (including apt traffic, which should go to our internal repos rather than through a less trusted web cache with external connectivity).

So this is also to support Ubuntu better :slight_smile: We need a config file where we can set the proxy for snapd, and not require the overloaded {http,https}_proxy environment variables.

Currently we are hacking systemd service files and snapd deploy time to do what we need, which only affects snapd (and not ‘snap download’), which has got things working for now on our and other restricted networks.

It is about to go in. It’s taking a while because we had holidays and a few events in the past month or so, but this should be in master pretty soon now.