After 2023-03-28 http://yum.oracle.com/repo/OracleLinux/ fails Artifactory testremote via API and Admin UI

Question

Problem

We seem to have a replication problem on a remote rpm/yum repo. We replicate http://yum.oracle.com/repo/OracleLinux/ as rpm-oraclelinux-remote and up until 28-03-23 15:29:41 +00:00 it worked fine but now it is failing it's Artifactory /ui/api/v1/ui/admin/repositories/testremote repository check with a 404. This check can be run via XMLHttpRequest or directly from the Artifactory Admin UI

When I look at a syncing or passing yum repo I see the following for repomd.xml

• created: 09-06-22 20:07:12 +00:00
• last modified: 30-03-23 13:24:26 +00:00
• last download: 30-03-23 18:40:43 +00:00

When I look at oraclelinux's I see

• created: 30-03-23 18:37:16 +00:00
• last modified: 28-03-23 15:29:41 +00:00
• last download: 30-03-23 18:37:16 +00:00

I also did some testing and it does seem like we have what is cached by Artifactory but cannot pull additional content.

So, anyone have any ideas as to if Oracle changed their repo policy for http://yum.oracle.com/

My guess is that I'll need to make one remote repo per OL* version as in

• rpm-oraclelinux-ol7-remote pointing to https://yum.oracle.com/repo/OracleLinux/OL7
• rpm-oraclelinux-ol8-remote pointing to https://yum.oracle.com/repo/OracleLinux/OL8
• etc

Answer 1

It turns out that the test button in Jfrog artifactory failures cannot be trusted in Artifactory 7.33 at least. Here's the evidence

• remote repo test button still report failure 404
• 2023-04-04 16:13:23 UTC metadata updated, new kernel + associated packages auto cached into the repo

So, my guess is that in our version and perhaps in the most recent that the test api naively attempts to access the root of the external url and does not do so via an appropriate repo type. For instance the yum/dnf or repoquery approach would seek out the repo metadata below an additional path whereas maven could look at the root.

At any rate, if you get a fail, you really want 2ndry confirmation that the failure is real and not a phantom

Answer 2

[Note: I am in the Oracle Linux development group and work with the ULN/yum team.]

We've actually never supported syncing a top-level URL (not pointing to an individual repository) via HTTP(S) as a use case, because historically we've had problems trying to keep those stub HTML files with "directory listings" working.

yum.oracle.com is hosted on the Akamai CDN (you'll see this if you look up its DNS), and Akamai doesn't actually have a concept of directory trees as such. And those stub HTML files didn't even exist on all mirrors, so you were basically just Lucky that it worked up to this point.

You'll also note that each of the "directory listing" HTML files of individual repos actually inject a /getPackage/ pseudo-subdirectory into the URL of the RPMs; this is to deal with how Akamai distributes these files.

So, via HTTP, we only support mirroring one repo at a time, ideally via the repodata/repomd.xml file used by yum/dnf/reposync. If Artifactory supports mirroring one repo at a time, that's how you'll have to do it via HTTP.

Now, if you already have a mirror tree and Artifactory is erroring out because an upper level directory is 404'ing, even though the repomd.xml is still accessible (as it is), that sounds like a reportable Artifactory bug to me. Just because one directory level returns 404 doesn't mean everything under it will; that's not how URIs work :)

All that said, there is an officially supported bulk-sync operation available now too, by rsync. That and the other official mirroring methods are described in this documentation:

https://docs.oracle.com/en/operating-systems/oracle-linux/software-management/sfw-mgmt-UseSoftwareDistributionMirrors.html