1

This a weird case that has me scratching my head. To start with, I found this error originally when I ran a sudo apt-get update, and received

Err https://packagecloud.io jessie/main amd64 Packages                         
  Failed to connect to packagecloud-repositories.s3.dualstack.us-west-1.amazonaws.com port 443: Network is unreachable
Err https://packagecloud.io jessie/main i386 Packages                          
  Failed to connect to packagecloud-repositories.s3.dualstack.us-west-1.amazonaws.com port 443: Network is unreachable
Hit http://ppa.launchpad.net trusty/main i386 Packages                         

[...snipped...]

W: Failed to fetch https://packagecloud.io/slacktechnologies/slack/debian/dists/jessie/main/binary-amd64/Packages  Failed to connect to packagecloud-repositories.s3.dualstack.us-west-1.amazonaws.com port 443: Network is unreachable

W: Failed to fetch https://packagecloud.io/slacktechnologies/slack/debian/dists/jessie/main/binary-i386/Packages  Failed to connect to packagecloud-repositories.s3.dualstack.us-west-1.amazonaws.com port 443: Network is unreachable

E: Some index files failed to download. They have been ignored, or old ones used instead.

Note: I am on Ubuntu 14.04 Trusty, but I have set it to download slack from the Debian Jessie repo. This is NOT the issue.

Following this URL (i.e. https://packagecloud.io/slacktechnologies/slack/debian/dists/jessie/main/binary-i386/Packages) in the browser shows that it is perfectly browsable. Hence I wanted to check if it is something wrong with my apt. Hence, I used curl and wget, and got different results:

For curl:

$ curl -v https://packagecloud.io/slacktechnologies/slack/debian/dists/jessie/main/binary-i386/Packages
* Hostname was NOT found in DNS cache
*   Trying 50.97.198.58...
*   Trying 2607:f0d0:2101:270::2...
* connect to 2607:f0d0:2101:270::2 port 443 failed: Network is unreachable
* Failed to connect to packagecloud.io port 443: Network is unreachable
* Closing connection 0
curl: (7) Failed to connect to packagecloud.io port 443: Network is unreachable

For wget:

wget -d https://packagecloud.io/slacktechnologies/slack/debian/dists/jessie/main/binary-i386/Packages
DEBUG output created by Wget 1.15 on linux-gnu.

URI encoding = ‘UTF-8’
--2017-07-21 18:11:10--  https://packagecloud.io/slacktechnologies/slack/debian/dists/jessie/main/binary-i386/Packages
Resolving packagecloud.io (packagecloud.io)... 50.97.198.58, 2607:f0d0:2101:270::2
Caching packagecloud.io => 50.97.198.58 2607:f0d0:2101:270::2
Connecting to packagecloud.io (packagecloud.io)|50.97.198.58|:443... connected.
Created socket 3.
Releasing 0x00000000018412b0 (new refcount 1).
Initiating SSL handshake.
Handshake successful; connected socket 3 to SSL handle 0x00000000018415e0
certificate:
  subject: /OU=Domain Control Validated/OU=EssentialSSL/CN=packagecloud.io
  issuer:  /C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Domain Validation Secure Server CA
X509 certificate successfully verified and matches host packagecloud.io

---request begin---
GET /slacktechnologies/slack/debian/dists/jessie/main/binary-i386/Packages HTTP/1.1
User-Agent: Wget/1.15 (linux-gnu)
Accept: */*
Host: packagecloud.io
Connection: Keep-Alive

---request end---
HTTP request sent, awaiting response... 
---response begin---
HTTP/1.1 302 Found
Server: nginx
Date: Fri, 21 Jul 2017 12:41:17 GMT
Content-Type: text/html;charset=utf-8
Content-Length: 0
Connection: keep-alive
Status: 302 Found
Strict-Transport-Security: max-age=31536000
Location: https://packagecloud-repositories.s3.dualstack.us-west-1.amazonaws.com/925/1150/debian/dists/jessie/main/binary-i386/Packages?AWSAccessKeyId=AKIAI44QGWC7C5WEV4XA&Signature=Vltn5Ghi49icZIN7Ho5DphMEbRE%3D&Expires=1500641185
X-XSS-Protection: 1; mode=block
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
Cache-Control: no-cache
X-Request-Id: 571637cb-6a78-47b1-8558-45a67c428064
X-Runtime: 0.018935

---response end---
302 Found
Registered socket 3 for persistent reuse.
URI content encoding = ‘utf-8’
Location: https://packagecloud-repositories.s3.dualstack.us-west-1.amazonaws.com/925/1150/debian/dists/jessie/main/binary-i386/Packages?AWSAccessKeyId=AKIAI44QGWC7C5WEV4XA&Signature=Vltn5Ghi49icZIN7Ho5DphMEbRE%3D&Expires=1500641185 [following]
] done.
URI content encoding = None
--2017-07-21 18:11:11--  https://packagecloud-repositories.s3.dualstack.us-west-1.amazonaws.com/925/1150/debian/dists/jessie/main/binary-i386/Packages?AWSAccessKeyId=AKIAI44QGWC7C5WEV4XA&Signature=Vltn5Ghi49icZIN7Ho5DphMEbRE%3D&Expires=1500641185
Resolving packagecloud-repositories.s3.dualstack.us-west-1.amazonaws.com (packagecloud-repositories.s3.dualstack.us-west-1.amazonaws.com)... 52.219.20.25, 2600:1fa0:c040:80:36e7:ec1c::
Caching packagecloud-repositories.s3.dualstack.us-west-1.amazonaws.com => 52.219.20.25 2600:1fa0:c040:80:36e7:ec1c::
Connecting to packagecloud-repositories.s3.dualstack.us-west-1.amazonaws.com (packagecloud-repositories.s3.dualstack.us-west-1.amazonaws.com)|52.219.20.25|:443... connected.
Created socket 4.
Releasing 0x000000000185a150 (new refcount 1).
Initiating SSL handshake.
Handshake successful; connected socket 4 to SSL handle 0x0000000001860bc0
certificate:
  subject: /C=US/ST=Washington/L=Seattle/O=Amazon.com Inc./CN=*.s3-us-west-1.amazonaws.com
  issuer:  /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Baltimore CA-2 G2
X509 certificate successfully verified and matches host packagecloud-repositories.s3.dualstack.us-west-1.amazonaws.com

---request begin---
GET /925/1150/debian/dists/jessie/main/binary-i386/Packages?AWSAccessKeyId=AKIAI44QGWC7C5WEV4XA&Signature=Vltn5Ghi49icZIN7Ho5DphMEbRE%3D&Expires=1500641185 HTTP/1.1
User-Agent: Wget/1.15 (linux-gnu)
Accept: */*
Host: packagecloud-repositories.s3.dualstack.us-west-1.amazonaws.com
Connection: Keep-Alive

---request end---
HTTP request sent, awaiting response... 
---response begin---
HTTP/1.1 200 OK
x-amz-id-2: cDzrsyunzEU7POUHrPqzqAV+oPLWkeRrMPgDQeKATtgenMpv2EUbCQjy+88AKQ6rp8FTO2shkv0=
x-amz-request-id: 76F0FF5E248DAFDE
Date: Fri, 21 Jul 2017 12:41:19 GMT
Last-Modified: Thu, 08 Jun 2017 00:13:11 GMT
ETag: "857ccd845e08a3963199ffbb587a0f4f"
Cache-Control: max-age=31536000
Accept-Ranges: bytes
Content-Type: text/plain
Content-Length: 20053
Server: AmazonS3

---response end---
200 OK
Disabling further reuse of socket 3.
Closed 3/SSL 0x00000000018415e0
Registered socket 4 for persistent reuse.
Length: 20053 (20K) [text/plain]
Saving to: ‘Packages’

100%[====================================================================================================================================================================>] 20,053      46.6KB/s   in 0.4s   

2017-07-21 18:11:12 (46.6 KB/s) - ‘Packages’ saved [20053/20053]

Basically, the URL seems to work through wget and the browser, but not through apt-get or curl.

I do NOT have any proxy installed, nor have I messed around with any network related configuration recently. However, this problem has cropped up over the past month+, and I would love to hear of possible things I might try to debug/fix this.

3

Note the HTTP 302 status code. This is a redirect, meaning that the URL provided maps to another URL. Wget by default follows redirects, curl does not. Browsers also usually follow redirects by default. In order to make curl follow redirects, use the option -L or --location.

Quoting from the man page,

-L, --location
(HTTP) If the server reports that the requested page has moved to a different location (indicated with a Location: header and a 3XX response code), this option will make curl redo the request on the new place.

Unfortunately, I cannot help with the apt-get part, as I am no Ubuntu expert. Just thought of it, could you possibly change the location of the update site to

packagecloud-repositories.s3.dualstack.us-west-1.amazonaws.com/925/1150/debian/dists/jessie/main/binary-i386/Packages?AWSAccessKeyId=AKIAI44QGWC7C5WEV4XA&Signature=Vltn5Ghi49icZIN7Ho5DphMEbRE%3D&Expires=1500641185

instead of

packagecloud.io/slacktechnologies/slack/debian/dists/jessie/main/binary-i386/Packages

?

Hope this helps!

3
  • Ah nice, the 302 definitely explains away the curl difference :) I must've forgotten that curl doesn't do redirects by default. I'll try to look into how I could change the apt-get part, though I am pretty sure that the GET parameters won't make that easy. Nevertheless, thanks a lot :) Marking as accepted (though I will update with a new comment here if I can figure out the apt-get part, for anyone else who might stumble upon the same issue) Jul 22 '17 at 20:47
  • @JayBosamiya What I'm wondering is why an update site uses a 302 redirect if apt doesn't support it. Or maybe it was configured wrong on their server... Jul 23 '17 at 4:31
  • I agree that it should probably not be used that way, and it is either a misconfiguration on their side (during recent times) or on my side (that is preventing the 302 redirect). Just need to figure out which. Jul 24 '17 at 14:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.