英文:
After 2023-03-28 http://yum.oracle.com/repo/OracleLinux/ fails Artifactory testremote via API and Admin UI
问题
问题
我们似乎在远程的rpm/yum仓库上出现了复制问题。我们将http://yum.oracle.com/repo/OracleLinux/
复制为rpm-oraclelinux-remote,直到 28-03-23 15:29:41 +00:00
之前一切正常,但现在它在Artifactory的/ui/api/v1/ui/admin/repositories/testremote
仓库检查时返回404错误。此检查可以通过XMLHttpRequest运行,也可以直接从Artifactory管理界面运行。
当我查看同步或正常的yum仓库时,对于repomd.xml,我看到以下内容:
- 创建时间: 09-06-22 20:07:12 +00:00
- 最后修改时间: 30-03-23 13:24:26 +00:00
- 最后下载时间: 30-03-23 18:40:43 +00:00
当我查看oraclelinux的情况时,我看到:
- 创建时间: 30-03-23 18:37:16 +00:00
- 最后修改时间: 28-03-23 15:29:41 +00:00
- 最后下载时间: 30-03-23 18:37:16 +00:00
我还进行了一些测试,似乎我们已经在Artifactory中缓存了内容,但无法获取其他内容。
那么,有人有任何关于Oracle是否更改了他们的仓库政策的想法吗?
我猜我需要为每个OL*版本创建一个远程仓库,如
- rpm-oraclelinux-ol7-remote 指向 https://yum.oracle.com/repo/OracleLinux/OL7
- rpm-oraclelinux-ol8-remote 指向 https://yum.oracle.com/repo/OracleLinux/OL8
- 等等
英文:
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
答案1
得分: 1
"原来,在至少 Artifactory 7.33 版本中,Jfrog artifactory 中的测试按钮是不可信的。以下是证据:
- 远程存储库测试按钮仍然报告 404 错误
- 2023-04-04 16:13:23 UTC 元数据已更新,新的内核和相关软件包自动缓存到存储库中
所以,我猜测在我们的版本中,以及最近的版本中,测试 API 试图通过不合适的存储库类型来访问外部 URL 的根目录。例如,yum/dnf 或 repoquery 方法会在附加路径下查找存储库元数据,而 maven 可能会查看根目录。
无论如何,如果您遇到失败,您确实希望获得第二次确认,以确定故障是真实的,而不是虚幻的。"
英文:
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
答案2
得分: 1
I will provide the translated text without any additional content:
[注意:我在Oracle Linux开发组工作,与ULN/yum团队合作。]
事实上,我们从历史上来看,从未支持通过HTTP(S)同步顶层URL(不指向单个存储库)作为用例,因为我们一直试图保持那些带有“目录列表”的存根HTML文件正常运行,存在问题。
yum.oracle.com托管在Akamai CDN上(如果查看其DNS,您会看到这一点),而Akamai实际上没有目录树的概念。而且这些存根HTML文件甚至并不在所有镜像上存在,所以在这一点上,您基本上只是幸运的,因为它能够工作。
您还会注意到每个单独的存储库的“目录列表”HTML文件实际上会将/getPackage/
伪子目录注入到RPM的URL中;这是为了处理Akamai如何分发这些文件。
因此,通过HTTP,我们只支持一次镜像一个存储库,理想情况下通过yum/dnf/reposync使用的repodata/repomd.xml
文件。如果Artifactory支持一次镜像一个存储库,那就是您必须通过HTTP执行的方式。
现在,如果您已经有一个镜像树,而Artifactory因为上层目录返回404而报错,尽管repomd.xml
仍然可访问(因为它是可访问的),那对我来说听起来像是一个可报告的Artifactory错误。只因为一个目录级别返回404并不意味着其下的所有内容都会返回404;这不是URI的工作方式
总之,现在还有一种官方支持的批量同步操作,通过rsync
可用。这些以及其他官方镜像方法在以下文档中有描述:
英文:
[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:
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库,让每个人都能够通过互相帮助和分享经验来进步。
评论