*the local snapd On Jan 23, 2017 8:04 PM, "Gustavo Niemeyer" <[email protected]> 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" <[email protected]> > 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 < >> [email protected]> wrote: >> >>> This should work fine across reboots. >>> >>> On Jan 23, 2017 4:49 PM, "Max Brustkern" <[email protected]> >>> 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 < >>>> [email protected]> wrote: >>>> >>>>> >>>>> >>>>> On 13 January 2017 at 08:14, Max Brustkern < >>>>> [email protected]> 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 < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On 12 January 2017 at 01:44, Max Brustkern < >>>>>>> [email protected]> 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 <[email protected]> >>>>>>> >>>>>>> -- >>>>>>> Snapcraft mailing list >>>>>>> [email protected] >>>>>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm >>>>>>> an/listinfo/snapcraft >>>>>>> >>>>>>> >>>>>> >>>>>> -- >>>>>> Snapcraft mailing list >>>>>> [email protected] >>>>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm >>>>>> an/listinfo/snapcraft >>>>>> >>>>>> >>>>> >>>>> -- >>>>> Snapcraft mailing list >>>>> [email protected] >>>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm >>>>> an/listinfo/snapcraft >>>>> >>>>> >>>> >>>> -- >>>> Snapcraft mailing list >>>> [email protected] >>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm >>>> an/listinfo/snapcraft >>>> >>>> >>> -- >>> Snapcraft mailing list >>> [email protected] >>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm >>> an/listinfo/snapcraft >>> >>> >> >> -- >> Snapcraft mailing list >> [email protected] >> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm >> an/listinfo/snapcraft >> >>
-- Snapcraft mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
