Comment 6 for bug 1737332

It's usually one proxy but could be that a local snap store would be used
which would then use that proxy itself. The store URL would be a separate
setting like apt mirror though.

MAAS provides a squid proxy so the flow would be:

Machine -> MAAS proxy -> local snap store -> corporate proxy

Machine -> MAAS proxy -> corporate proxy -> public store

On Mon, Mar 26, 2018, 03:41 John A Meinel <email address hidden> wrote:

> In practice, is it common to use the same proxy for APT and Snap?
> Certainly I only have an APT proxy set up on my local network (for
> caching between multiple machine downloads), but I suppose if I wanted
> to start caching Snap downloads then I'd probably adapt my proxy rather
> than running a second one.
>
> Juju could either grow an "archive proxy" which would then be used for:
> 1) apt
> 2) snap
> 3) lxd
> 4) juju itself hitting streams.canonical.com for agent binaries?
>
> For some of these we currently also allow you to instead change the
> target of image-stream/agent-stream/apt-mirror.
>
> It seems like we could have a meta setting, but it may be better to just
> add individual settings for all the other ones.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1737332
>
> Title:
> [2.3.1] snapd proxy settings are not set on deployed machines or
> containers
>
> Status in juju:
> Triaged
> Status in snapd:
> Triaged
>
> Bug description:
> Currently Juju doesn't propagate proxy settings for snapd from model-
> config to either hosts or LXD containers.
>
> It is quite easy to do so though:
>
> sudo mkdir -p /etc/systemd/system/snapd.service.d/
> sudo cat <<EOF | sudo tee -a
> /etc/systemd/system/snapd.service.d/proxy.conf
> [Service]
> Environment=http_proxy=$http_proxy
> Environment=https_proxy=$http_proxy
> EOF
> sudo systemctl daemon-reload
> sudo systemctl restart snapd # <- mandatory
>
> https://bugs.launchpad.net/snapcraft/+bug/1533899
> https://bugs.launchpad.net/snapcraft/+bug/1533899/comments/1
>
>
> Seems to me snapd reacts to environment variables just because of how
> golang runtime handles that:
>
> https://github.com/golang/go/blob/release-
> branch.go1.9/src/net/http/transport.go#L250-L266
>
> snapd *MUST* be restarted though after proxy.conf is created as
> naturally there is no sane way to "reload" environment variables and
> make a process react to that without some effort on the process side
> itself.
>
> Note that this is not about using core snap to set proxy settings -
> initially you have **no snaps at all** which means you cannot use a
> core snap to set some settings. `snap install core` will obviously
> fail at this point so this is not interesting
> https://github.com/snapcore/snapd/pull/3594
>
> /etc/environment isn't good for this too because no_proxy variable has
> to be populated with a list of ip addresses and hostnames which
> becomes quite large if you use a /24 or a /16 network (a /16 would
> even cause your programs to run out of stack memory due to an 8MiB
> RLIMIT_STACK default).
>
> pam_env has certain limits which is why we should not use this file:
>
> https://github.com/linux-pam/linux-pam/blob/master/modules/pam_env/pam_env.c#L541
> /* No unexpanded variable can be bigger than BUF_SIZE */
> char type, tmpval[BUF_SIZE];
>
> How private snap stores would fit into that should be evaluated but my
> primary concern is proxy settings for this bug.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/juju/+bug/1737332/+subscriptions
>