Launchpad itself

Launchpad's snap builder can't access dl.google.com

Asked by Johannah Sprinz

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://launchpad.net/~build.snapcraft.io/+snap/6517c4c96419aec36a515073661a1f50/+build/1137536
And here's the failing part of the log:

[03/Oct/2020:16:43:07 +0000] "GET https://heimdall.free-droid.com/heimdall-linux.zip HTTP/1.1" 200 57470 "-" "axios/0.20.0"
[03/Oct/2020:16:43:09 +0000] "GET https://dl.google.com/android/repository/platform-tools-latest-linux.zip HTTP/1.1" 302 96 "-" "axios/0.20.0"
Error: Error: Download Error: Error: getaddrinfo ENOTFOUND dl.google.com dl.google.com:443
    at /build/ubports-installer/parts/ubports-installer/build/node_modules/progressive-downloader/lib/module.cjs:222:14
    at process._tickCallback (internal/process/next_tick.js:68:7)
Failed to run 'override-build': Exit code was 1.
Build failed

Question information

Language:
English Edit question
Status:
Solved
For:
Launchpad itself Edit question
Assignee:
No assignee Edit question
Solved by:
Colin Watson
Solved:
Last query:
Last reply:
Revision history for this message
Johannah Sprinz (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://launchpad.net/~build.snapcraft.io/+snap/6517c4c96419aec36a515073661a1f50/+build/1138153:

[04/Oct/2020:08:04:58 +0000] "GET http://people.ubuntu.com/~neothethird/adb-fastboot.zip HTTP/1.1" 403 1927 "-" "axios/0.20.0"
[04/Oct/2020:08:04:58 +0000] "GET http://people.ubuntu.com/~neothethird/heimdall-linux.zip HTTP/1.1" 403 1933 "-" "axios/0.20.0"
Error: Error: Download Error: Error: Request failed with status code 403
    at /build/ubports-installer/parts/ubports-installer/build/node_modules/progressive-downloader/lib/module.cjs:222:14
    at process._tickCallback (internal/process/next_tick.js:68:7)

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?

Revision history for this message
Best Colin Watson (cjwatson) said : 		#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/2020:16:43:09 +0000] "GET https://dl.google.com/android/repository/platform-tools-latest-linux.zip HTTP/1.1" 302 96 "-" "axios/0.20.0"

But then you have the progressive-downloader failure immediately after that. I think this axios library you're using has buggy proxy handling and fails to pass redirects through the proxy correctly. I'm not sure if it's quite the same thing, but there's a long-standing bug about axios proxy/redirect handling (https://github.com/axios/axios/issues/1207). Maybe consider if there's some more robust alternative?

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://dl.google.com/android/repository/platform-tools-latest-linux.zip, and instead temporarily set the URL to (currently) https://dl.google.com/android/repository/platform-tools_r30.0.4-linux.zip until you can get your HTTP client library fixed.

Revision history for this message
Johannah Sprinz (neothethird) said : 		#3

Thanks Colin Watson, that solved my question.