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
>