Official apt repository (451 Unavailable For Legal Reasons)

Hi! I faced this problem in my VM on the DigitalOcean(Europe region).
I tried to do an apt update in my Debian 9 VM. But I recieved this message:

Ign:1 http://deb.debian.org/debian stretch InRelease
Hit:2 http://security.debian.org stretch/updates InRelease
Hit:3 http://deb.debian.org/debian stretch Release
Hit:4 http://nginx.org/packages/mainline/debian stretch InRelease
Ign:5 https://artifacts.elastic.co/packages/7.x/apt stable InRelease
Ign:6 https://artifacts.elastic.co/packages/oss-7.x/apt stable InRelease
Err:7 https://artifacts.elastic.co/packages/7.x/apt stable Release
  451  Unavailable For Legal Reasons
Err:8 https://artifacts.elastic.co/packages/oss-7.x/apt stable Release
  451  Unavailable For Legal Reasons

Ip: 157.230.23.XXX

1 Like

Hello!

We are aware of the issue and waiting for the CDN provider to resolve a small issue with their geoip filters.
A rough estimate might be end of this week, but cannot confirm 100%.

Please post again if you will still face the issue.

2 Likes

Glad it's not just me. All my nodes are hosted by Vultr, but all within the US.

Same problem with Digitalocean in sfo2 region. Fails with error 451 about 50% of the time when creating a 3 node cluster. Makes deploying IaC basically impossible.

2 Likes

Same here Digital Ocean tor1 region - servers currently DOA after a failed update.

No news yet, I take it? :frowning:

I'm still seeing this, as OE-Eddie had said, in DigitalOcean SFO2. It wouldn't be possible to temporarily disable the geoip while they work through this?

Thank you for reporting.

Our provider shared a date for the fix, which should be the 22nd May.

1 Like

Still happening for me and it's unlikely they will disable it because it's probably part of embargo check. That said, not sure why it's taking so long to fix unless they are using a 3rd party provider instead of local database (maxmind, etc) and need to go through them for a fix. Strange thing is, I looked up the geoip location of several of the IPs that failed and they all showed as Santa Clara, CA which I'm relatively sure isn't on the embargo list.

We have a CDNs to provide faster downloads.

Any update?

3 Likes

Thanks for this information. As of this writing (16:00 CEST on 2020-05-23) the problem is still happening. Do you have any updates from your CDN provider?

2 Likes

Same for me as of today. Digital Ocean droplet in London.

2 Likes

The problem is still happening. Do you have any updates from your CDN provider? Droplet in USA

Same here, Droplet in Toronto

E: Failed to fetch https://artifacts.elastic.co/packages/6.x/apt/dists/stable/InRelease  451  Unavailable For Legal Reasons [IP: 2a04:4e42:1e::734 443]

same issue here in South East Asia

2020-05-26 08:08:12 ERROR 451: Unavailable For Legal Reasons.

Same issue still happening from DigitalOcean instances in Frankfurt and Amsterdam.
I really do not understand why fixing this could be so time consuming.

And besides - if this geo IP check was implemented because of any embargo reasons (which personally I would not really understand anyway), why won't you just add any embargoed (is this a word?) country to you license and exclude them from using it? I don't see how an open source project would be required to implement geo IP filtering (on whose authority).

Best,
Tillman

Still happening from Canada. I can't believe it takes so long to fix this issue

1 Like

from digitalocean VM in LON1 just now

wget https://artifacts.elastic.co/packages/7.x/yum/repodata/repomd.xml
--2020-05-28 10:11:01--  https://artifacts.elastic.co/packages/7.x/yum/repodata/repomd.xml
Resolving artifacts.elastic.co (artifacts.elastic.co)... 151.101.18.222, 2a04:4e42:4::734
Connecting to artifacts.elastic.co (artifacts.elastic.co)|151.101.18.222|:443... connected.
HTTP request sent, awaiting response... 451 Unavailable For Legal Reasons
2020-05-28 10:11:01 ERROR 451: Unavailable For Legal Reasons.

Hello all,

While I'm sharing this thread with Elastic infra team to follow up, they informed me while the geoip databases have been updated, the edge nodes are not still in sync and the provider expects them to be updated tomorrow (29th May).

Hi Luca, should a solution be implemented tomorrow?, I continue with the problem.