Apt repo change? "E: Repository 'https://artifacts.elastic.co/packages/8.x/apt stable InRelease' changed its 'Origin' value from 'elastic' to 'Artifactory'"

# apt update
Get:2 http://nova.clouds.archive.ubuntu.com/ubuntu jammy InRelease [270 kB]                                                                     
Hit:3 http://security.ubuntu.com/ubuntu jammy-security InRelease                                                                                
[...]
Get:7 https://artifacts.elastic.co/packages/8.x/apt stable InRelease [3,255 B]                                                                  
Hit:8 http://nova.clouds.archive.ubuntu.com/ubuntu jammy-backports InRelease                                                                    
[...]
E: Repository 'https://artifacts.elastic.co/packages/8.x/apt stable InRelease' changed its 'Origin' value from 'elastic' to 'Artifactory'       
E: Repository 'https://artifacts.elastic.co/packages/8.x/apt stable InRelease' changed its 'Label' value from '. stable' to 'Artifactory'
N: This must be accepted explicitly before updates for this repository can be applied. See apt-secure(8) manpage for details.
Do you want to accept these changes and continue updating from this repository? [y/N] 

is this expected? backend change?
don't see any information or communication on Repositories for APT and YUM | Filebeat Reference [8.17] | Elastic or Announcements - Discuss the Elastic Stack

for now commented in sources.list
similar to similar repository changed its 'Origin' value [SOLVED] / Installation / Dev1 Galaxy Forum, Apt repository changes, dist upgrade fails - #2 by Gsmitt - General Feedback - OpenSearch

Thanks

5 Likes

You're not alone in seeing this issue. Something definitely changed in the repo.

Seeing the same here, and it's breaking all my ansible plays.. would be good to get clarification on whether this change is here to stay or if it's an accident.

this is causing us a customer-facing outage since we run apt-get update in userdata scripts and are using the elastic apt repo. c'mon guys, fix your stuff.

I guess we just have to fix this on our end :\

same, this broke puppet on our 5000+ servers, and idk whether to accept the change or not :grimacing:

Same here. This ansible issue contains some workarounds, once verified if this change was on purpose or not.

Thanks for raising this! I'll try to chase this down on our side...

Thanks for raising the issue. We're investigating. You can follow along at ESS (Public) Status - Ubuntu/Debian and Fedora package repositories disruption

1 Like

I still have issues, My Satellite is pointing to https://artifacts.elastic.co/packages/8.x/yum

The version 7 repo is correctly updated (though very slow), but this version 8 repo keeps failing

The error returned by the subtask:
XML file(s): filelists not found

Can you share more about your setup. We did do changes to the yum repo metadata too, but our validation did not pick up on any issues.

I can,

RH Satellite 6.16.1 with the repo's added for Elastic 7 and Elastic 8. Both with the same key I got from the docs this morning.
The Elastic7 repo is syncing OK, while the Elastic 8 repo fails, so the key is OK too afaik.

The upstream URL points to: https://artifacts.elastic.co/packages/8.x/yum

Literally the only difference between these 2 repo's I see is the upstream url

Thanks. Incident marked resolved ESS (Public) Status - Ubuntu/Debian and Fedora package repositories disruption

Restored elastic repo in sources.list and work as expected without question/change acceptance.

as you read above, I disagree

I'm afraid Rhel 6 is not supported starting with 8.0.0 see Support Matrix | Elastic so we are not testing the repos against this version. I'll double check that we have no issues with a pre-configured repository for a newer version just to be sure

Sorry, but we are not using rhel 6. We are using RH Satellite 6.16.1 on RHEL 9.

To be more clear, I have an older satellite 6.11 on rhel 7 which also had problems with this repo today. However, the last attempt, a few mins ago succeeded. The newer satellite I am building still does not, but since the older satellite succeed,, I will consider it my problem now :wink:

Thnx for the replies.

As for the confusion, Satellite is widely know with companies as the primairy way to maintain and provision their RedHat systems. It currently is on version 6.16 which is not to be confused with rhel6 .

It seems to still be a problem with the upstream repositories. We have the same issue from Satellite 6.15 on RHEL8 and Satellite 6.16 on RHEL9. The following URLs all return 404 (Not Found):

https://artifacts.elastic.co/packages/8.x/yum
https://artifacts.elastic.co/packages/oss-8.x/yum
https://artifacts.elastic.co/packages/8.x/apt

Testing the URLs with cURL gives the same 404 error code.

Similar issue with salt/saltstack was solved by enabling the "Enable File List Indexing" option on the upstream Artifactory rpm repo: Unable to create local mirror of saltstack repo, due to filelists.xml not being available · Issue #67032 · saltstack/salt · GitHub
Not sure if it is the issue here, but seems to be very similar.

1 Like

The following URL works via cURL:
https://artifacts.elastic.co/packages/8.x/yum/repodata/repomd.xml

But: The repomd.xml file has no entry for data type="filelists" which seems to be expected by Red Hat Satellite server.

1 Like

Also note that we have had the 8.x yum repo working with Satellite 6.16 until a week or two ago, so there must have been some changes to the upstream repository that causes the repository sync to fail now.