I’m in a very confined network. Not only behind a proxy, but also without a proper DNS resolver.
That is, since no remote connection exists that doesn’t go through the proxy, then there is no name resolution at all (there is a name server, but only resolves internal names).
Apparently, snapd insists on resolving something before connecting through the proxy, because all I get in the logs is NXDOMAIN errors:
Oct 30 19:26:15 mabsatz-Standard-PC-i440FX-PIIX-1996 systemd-resolved[466]: message repeated 61 times: [ Server returned error NXDOMAIN, mitigating potential DNS violation DVE-2018-0001, retrying transaction with reduced feature level UDP.]
Oct 30 19:26:41 mabsatz-Standard-PC-i440FX-PIIX-1996 snapd[496]: api.go:999: Installing snap "chromium" revision unset
Oct 30 19:26:45 mabsatz-Standard-PC-i440FX-PIIX-1996 systemd-resolved[466]: Server returned error NXDOMAIN, mitigating potential DNS violation DVE-2018-0001, retrying transaction with reduced feature level UDP.
Oct 30 19:27:16 mabsatz-Standard-PC-i440FX-PIIX-1996 systemd-resolved[466]: message repeated 39 times: [ Server returned error NXDOMAIN, mitigating potential DNS violation DVE-2018-0001, retrying transaction with reduced feature level UDP.]
I have the proxy configured in environment variables in /etc/environment.d/10proxy and it works OK. I can fetch pages using curl via http and https with no problem.
However, when I try to install a snap, it times out saying it couldn’t connect to the snap store:
# time snap install chromium
error: unable to contact snap store
real 0m40.025s
user 0m0.037s
sys 0m0.009s
AFAIK, this is a plain vanilla ubuntu 20.04 (it’s a VDI and I didn’t install it).
Indeed, it does not pull snaps down from hard-coded IP addresses name resolution is a core Networking feature snapd depends upon.
Here’s a list of host names snapd uses and expects to be able to resolve. You might be able to hack things into working by providing resolution for these in /etc/hosts or some such but I think a functionally busted DNS will preclude snapd from working properly.
I certainly don’t expect snapd to use hard-coded IP addresses however, since (I think) it uses http/https to connect and retrieve stuff, I’d expected it leaved the name resolution to the proxy, since it should connect through it, like, for instance, curl does:
$ curl https://api.snapcraft.io/api/v1/snaps/sections -o /tmp/snap-api.json
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 558 100 558 0 0 478 0 0:00:01 0:00:01 --:--:-- 478
Anyway, I’ll look into the addresses in the link you sent me and I’ll try to fool it adding entries in /etc/hosts to see if I can make it work.
I can confirm that it is not possible to use the latest snapcraft behind a corporate proxy since our internal NS does not resolve external addresses. They are resolved by the proxy.
Tinkering with the /etc/hosts is not an option for productive usage of snapcraft. Its always a bad idea.
So basically, snapcraft (and thus, snap-based distros, like ubuntu 20.04) is not usable in a corporte environment that mandates that all http trafic, including the name resolution of this trafic, goes through a proxy.
when set up properly on the proxy machine by your IT dept.
it would make snapd on the devices talk to the proxy only, not doing any external requests … dns resolution would be handled between the store proxy and the proxy server (typically on the the same machine)
Just to make sure, we are talking about developing and building snaps using snapcraft 4. We are not talking about ubuntu core devices running behind a proxy.
I’m sorry if I mistagged the question, @mapero, but I wasn’t talking about building snaps, but rather, about plain ubuntu workstations running behind a proxy (not even ubuntu core devices).
Maybe my newbieism to the community, added to English not being my native language generated some confusion.
But, to rephrase my problem. I work in an environment where the only way out of the local networks is through a proxy.
Most users use windows. The IT dept is testing a new VDI environment and since I use linux in my desktop, they’re using me as a kind of guinea pig to test it.
They gave me access to a plain ubuntu 20.04 desktop installed on the VDI and I started to struggle to configure the proxy for everything. After properly configuring it in APT and successfully installing and upgrading packages, it failed to install the chromium browser. Looking at the error messages, I notice that the official chromium “.deb” package in ubuntu 20.04, actually installs a script that actually tries to install the chromium snap. I don’t think that was a very smart decision from Canonical, but it’s the one they made.
Now, reading more on the error messages I see complains about access to DNS resolution. I tried to manually install a snap and discovered that, even when the proxy is configured and used by command line commands, snap insists on resolving names locally. Maybe there’s some place where I can convince it to use an (https) proxy and that solves the problem.
Otherwise, as @ogra says, the IT guys would have to install, configure and operate a specialized snap-store proxy, or only support non-snap-dependent desktop linux distros.
Thank you both for all your help making me understand my problem.
name resolution is a core Networking feature snapd depends upon.
however, since (I think) it uses http/https to connect and retrieve stuff, I’d expected it leaved the name resolution to the proxy, since it should connect through it, like, for instance,