*the local snapd On Jan 23, 2017 8:04 PM, "Gustavo Niemeyer" <gust...@niemeyer.net> wrote:
Indeed, that smells like a bug, certainly because snap download doesn't use the local snaps to actually download the file. That should be transparent to the CLI though. Can you please file an issue? Thanks! On Jan 23, 2017 5:26 PM, "Max Brustkern" <max.brustk...@canonical.com> wrote: > Okay, you're right. I was testing with snap download, which doesn't seem > to use to proxy, whereas snap refresh does. Is that intended behavior, or > should I report it somewhere? > > Thanks, > Max > > On Mon, Jan 23, 2017 at 2:04 PM, Gustavo Niemeyer < > gustavo.nieme...@canonical.com> wrote: > >> This should work fine across reboots. >> >> On Jan 23, 2017 4:49 PM, "Max Brustkern" <max.brustk...@canonical.com> >> wrote: >> >>> So I've been able to get it to work by creating >>> /etc/systemd/system/snapd.service.d/proxy.conf >>> with the correct settings. Any suggestions on getting that to persist >>> across reboots? >>> >>> Thanks, >>> Max >>> >>> On Thu, Jan 12, 2017 at 2:28 PM, Michael Hudson-Doyle < >>> michael.hud...@canonical.com> wrote: >>> >>>> >>>> >>>> On 13 January 2017 at 08:14, Max Brustkern <max.brustk...@canonical.com >>>> > wrote: >>>> >>>>> So I created a system directory with the contents of >>>>> /lib/systemd/system. I edited that file to contain the environment >>>>> variables: >>>>> nuclearbob@localhost:~$ cat /lib/systemd/system/snapd.service >>>>> [Unit] >>>>> Description=Snappy daemon >>>>> Requires=snapd.socket >>>>> >>>>> [Service] >>>>> ExecStart=/usr/lib/snapd/snapd >>>>> EnvironmentFile=/etc/environment >>>>> Restart=always >>>>> http_proxy=http://squid.internal:3128 >>>>> https_proxy=https://squid.internal:3128 >>>>> >>>> >>>> That's not the right syntax, it should be >>>> >>>> Environment=http_proxy=http://squid.internal:3128 https_proxy= >>>> https://squid.internal:3128 >>>> >>>> See man systemd.exec for more details on this. >>>> >>>> Cheers, >>>> mwh >>>> >>>> >>>>> [Install] >>>>> WantedBy=multi-user.target >>>>> >>>>> I then did: >>>>> nuclearbob@localhost:~$ sudo systemctl daemon-reload >>>>> nuclearbob@localhost:~$ sudo service snapd restart >>>>> >>>>> I still don't seem to see snapd picking up on the proxy. I tried: >>>>> sudo systemctl edit snapd >>>>> I pasted in the file contents to there, but after that I get: >>>>> nuclearbob@localhost:~$ sudo service snapd restart >>>>> Failed to restart snapd.service: Unit snapd.service is not loaded >>>>> properly: Invalid argument. >>>>> See system logs and 'systemctl status snapd.service' for details. >>>>> nuclearbob@localhost:~$ systemctl status snapd.service >>>>> ● snapd.service - Snappy daemon >>>>> Loaded: error (Reason: Invalid argument) >>>>> Drop-In: /etc/systemd/system/snapd.service.d >>>>> └─override.conf >>>>> Active: active (running) since Thu 2017-01-12 19:11:46 UTC; 2min >>>>> 26s ago >>>>> Main PID: 1339 (snapd) >>>>> CGroup: /system.slice/snapd.service >>>>> └─1339 /usr/lib/snapd/snapd >>>>> >>>>> Any additional tips to get snapd running on ubuntu core in the lab? >>>>> >>>>> On Wed, Jan 11, 2017 at 11:49 PM, Stuart Bishop < >>>>> stuart.bis...@canonical.com> wrote: >>>>> >>>>>> >>>>>> >>>>>> On 12 January 2017 at 01:44, Max Brustkern < >>>>>> max.brustk...@canonical.com> wrote: >>>>>> >>>>>>> I'm trying to run ubuntu core 16 in a kvm instance in an internal >>>>>>> lab that requires a web proxy. This bug: >>>>>>> https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1579652 >>>>>>> seems to cover how to do this on classic ubuntu, but the files that >>>>>>> hold the environment variables used by snapd on an ubuntu core system >>>>>>> are >>>>>>> all on read-only filesystems. How do I set HTTPS_PROXY in a persistent >>>>>>> way >>>>>>> for snapd on that system? >>>>>>> >>>>>> >>>>>> https://bugs.launchpad.net/snappy/+bug/1533899 is similar, but about >>>>>> adding support for proxies to snapd (rather than have it use the system >>>>>> environment variables, which is one implementation option but not always >>>>>> what you want since that affects everything on the system). But that >>>>>> doesn't help with your read-only filesystem sorry :-( >>>>>> >>>>>> (Hmm... disgusting hack idea.... since you can't create >>>>>> /etc/systemd/system/snapd.service.d/ on your read-only filesystem, >>>>>> try mounting that directory from somewhere. Extra points for using >>>>>> systemd >>>>>> to mount the systemd service file overrides and setting up dependencies >>>>>> so >>>>>> it does everything in the right order :-) ) >>>>>> >>>>>> >>>>>> -- >>>>>> Stuart Bishop <stuart.bis...@canonical.com> >>>>>> >>>>>> -- >>>>>> Snapcraft mailing list >>>>>> Snapcraft@lists.snapcraft.io >>>>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm >>>>>> an/listinfo/snapcraft >>>>>> >>>>>> >>>>> >>>>> -- >>>>> Snapcraft mailing list >>>>> Snapcraft@lists.snapcraft.io >>>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm >>>>> an/listinfo/snapcraft >>>>> >>>>> >>>> >>>> -- >>>> Snapcraft mailing list >>>> Snapcraft@lists.snapcraft.io >>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm >>>> an/listinfo/snapcraft >>>> >>>> >>> >>> -- >>> Snapcraft mailing list >>> Snapcraft@lists.snapcraft.io >>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm >>> an/listinfo/snapcraft >>> >>> >> -- >> Snapcraft mailing list >> Snapcraft@lists.snapcraft.io >> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm >> an/listinfo/snapcraft >> >> > > -- > Snapcraft mailing list > Snapcraft@lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm > an/listinfo/snapcraft > >
-- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
