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/
> mailman/listinfo/snapcraft
>
>
-- 
Snapcraft mailing list
[email protected]
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Reply via email to