Launchpad's snap builder can't access dl.google.com
I'm building the ubports-installer snap through the snap builder, which uses launchpad. For a couple days now it has had problems accessing dl.google.com, which i need to download additional files.
Here's a build: https:/
And here's the failing part of the log:
[03/Oct/
[03/Oct/
Error: Error: Download Error: Error: getaddrinfo ENOTFOUND dl.google.com dl.google.com:443
at /build/
at process.
Failed to run 'override-build': Exit code was 1.
Build failed
Question information
- Language:
- English Edit question
- Status:
- Solved
- Assignee:
- No assignee Edit question
- Solved by:
- Colin Watson
- Solved:
- 2020-10-05
- Last query:
- 2020-10-05
- Last reply:
- 2020-10-05
| NeoTheThird (neothethird) said : | #1 |
Huh!? I tried to exchange the target url to my people.ubuntu.com sftp, because i figured that'd be in-house so it shouldn't be a problem. Turns out downloads just fail, period. From https:/
[04/Oct/
[04/Oct/
Error: Error: Download Error: Error: Request failed with status code 403
at /build/
at process.
I *really* don't want to have to re-work my snap build to be different from the others. Any chance we can get this addressed?
That being said, i did recently switch to a new download library that uses the npm package axios rather than the deprecated request package, but it works EVERYWHERE else, so i still think this is a problem with launchpad. Any weird proxy configs in http_proxy or https_proxy going on, maybe?
|
|
#2 |
Launchpad snap builds are required to go through a proxy, yes, and we set http_proxy and https_proxy accordingly; they have a limited DNS view, so if they fail to use the proxy correctly then things will go wrong. This is because many of the build types that share the same build farm are by policy not allowed to use the general internet at all; the proxy setup allows us to make internet access available only for certain build types, while also making it harder for it to be used as e.g. a botnet host.
In fact, we can see in your build log that the proxy itself is working fine, because it logged a 302 response:
[03/Oct/
But then you have the progressive-
Your attempt to use people.ubuntu.com failed because the proxy generally forbids access to resources within Canonical's datacentre unless they've been specifically allowed (to avoid potential problems with old internal sites that might assume that requests from within our datacentre are implicitly OK, which would obviously be bad design but we'd rather not find out the hard way). We can certainly add a rule allowing people.ubuntu.com, but it wouldn't help - you'd still run into the same problem with your HTTP client library failing to handle redirects properly. And there was absolutely no point in changing the URL for heimdall, because the log indicates that the proxy returned a 200 response for that already.
On the other hand, a workaround that should actually work would be to manually chase the redirect returned by https:/
| NeoTheThird (neothethird) said : | #3 |
Thanks Colin Watson, that solved my question.
