Uyuni 2023-09 upgrade made Debian client failing with 403 error when accessing to Uyuni repositories

marmau06 commented 1 year ago

Problem description

Hello, since we upgraded Uyuni server to 2023-09 level, our Debian clients can not access to Uyuni repositories, failing with 403 (forbidden) error code. Nothing has changed in our infrastructure... Still investigating, but may be the solution will be an evidence for any of you ? :)

Steps to reproduce

Upgrade Uyuni server to 2023-09 2.apt-get dist-upgrade on debian client...
...

Uyuni version

2023-09

Uyuni proxy version (if used)

No response

Useful logs

No response

Additional information

No response

marmau06 commented 1 year ago

Found this in /var/log/rhn/rhn_web_ui.log:

2023-11-02 14:23:23,379 [ajp-nio-0:0:0:0:0:0:0:1-8009-exec-4] INFO com.suse.manager.webui.controllers.DownloadController - Forbidden: You need a token to access /manager/download/debian-10-amd64-main-security-uyuni/getPackage/libx11-data_2:1.6.7-1 deb10u4.all-deb.deb 2023-11-02 14:23:23,383 [ajp-nio-0:0:0:0:0:0:0:1-8009-exec-6] INFO com.suse.manager.webui.controllers.DownloadController - Forbidden: You need a token to access /manager/download/debian-10-amd64-main-security-uyuni/getPackage/libx11-6_2:1.6.7-1 deb10u4.amd64-deb.deb 2023-11-02 14:23:23,387 [ajp-nio-0:0:0:0:0:0:0:1-8009-exec-3] INFO com.suse.manager.webui.controllers.DownloadController - Forbidden: You need a token to access /manager/download/debian-10-amd64-main-security-uyuni/getPackage/linux-image-4.19.0-25-amd64_4.19.289-2.amd64-deb.deb 2023-11-02 14:23:23,392 [ajp-nio-0:0:0:0:0:0:0:1-8009-exec-2] INFO com.suse.manager.webui.controllers.DownloadController - Forbidden: You need a token to access /manager/download/debian-10-amd64-main-security-uyuni/getPackage/linux-image-amd64_4.19 105 deb10u20-X.amd64-deb.deb 2023-11-02 14:23:23,395 [ajp-nio-0:0:0:0:0:0:0:1-8009-exec-5] INFO com.suse.manager.webui.controllers.DownloadController - Forbidden: You need a token to access /manager/download/debian-10-amd64-main-security-uyuni/getPackage/openssl_1.1.1n-0 deb10u6.amd64-deb.deb 2023-11-02 14:23:23,398 [ajp-nio-0:0:0:0:0:0:0:1-8009-exec-9] INFO com.suse.manager.webui.controllers.DownloadController - Forbidden: You need a token to access /manager/download/debian-10-amd64-main-security-uyuni/getPackage/zabbix-agent_1:4.0.4 dfsg-1 deb10u2.amd64-deb.deb 2023-11-02 14:23:23,402 [ajp-nio-0:0:0:0:0:0:0:1-8009-exec-7] INFO com.suse.manager.webui.controllers.DownloadController - Forbidden: You need a token to access /manager/download/debian-10-amd64-main-security-uyuni/getPackage/open-vm-tools_2:10.3.10-1 deb10u5.amd64-deb.deb

tom-mes commented 1 year ago

Same problem on debian 10.

Patching in general fails:

Err:1 https://uyuni.:443/rhn/manager/download debian_10-debian_10_dev_qa-debian-10-amd64-main-security-uyuni/ python3.7-dev 3.7.3-2+deb10u6 ........... E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missin

ateel-dxs commented 1 year ago

This looks related to #7671 which has been resolved but needs a release. For the record, I have Ubuntu systems that are all having the exact same issue. I get a 403 from apt when it attempts to retrieve packages and that forbidden access token message is present in my logs on 2023.09 as well.

avshiliaev commented 1 year ago

Hey everyone, thanks for reporting it. It's worth investigating in general, but I would start here by trying to apply the highstate on the client to see if it solves the token issue.

tom-mes commented 1 year ago

Hey everyone, thanks for reporting it. It's worth investigating in general, but I would start here by trying to apply the highstate on the client to see if it solves the token issue.

I just trying to set the highstate - nothing changed. Still the same error.

But how should it change - it worked before.

cFabij commented 1 year ago

By chance, before the 403 error, did any one of you changed software channels or linked new software channels to already existing repositories?

I did and encountered the 403 afterwards on my Ubuntu machines (the clients still try to download packages from now defunct paths). RedHat based distros do not suffer from the same fate.

Still trying to figure a way out of this mess... So far I tried:

applying highstate,
deleting and rebuilding repo cache
spacewalk-data-fsck -r -S -C -O,
deleting all corresponding channels and repositories and building them up anew with only partially success (some repos work, some still point to defunct paths),

Still to be tried: deleting everything once more and creating the repositories with different names, maybe that will do it

marmau06 commented 1 year ago

Hello, I already put this in (https://github.com/uyuni-project/uyuni/issues/7671)

Hello, This morning, I updated Uyuni server to 2023.10, Debain do not work, again... I upgraded venv-salt-minion to last version venv-salt-minion_3006.0-21.8.uyuni_amd64.deb on uyuni Debian 11 client. Do not work again... I removed and re-registered the client, the same...

I still have this kind of message in rhn_web_ui.log:

2023-11-30 11:42:33,192 [ajp-nio-0:0:0:0:0:0:0:1-8009-exec-4] INFO com.suse.manager.webui.controllers.DownloadController - Forbidden: You need a token to access /manager/download/debian-11-amd64-main-security-uyuni/getPackage/libxml2_2.9.10 dfsg-6.7 deb11u4.amd64-deb.deb 2023-11-30 11:42:33,202 [ajp-nio-0:0:0:0:0:0:0:1-8009-exec-6] INFO com.suse.manager.webui.controllers.DownloadController - Forbidden: You need a token to access /manager/download/debian-11-amd64-main-security-uyuni/getPackage/bind9-dnsutils_1:9.16.44-1deb11u1.amd64-deb.deb 2023-11-30 11:42:33,206 [ajp-nio-0:0:0:0:0:0:0:1-8009-exec-9] INFO com.suse.manager.webui.controllers.DownloadController - Forbidden: You need a token to access /manager/download/debian-11-amd64-main-security-uyuni/getPackage/bind9-libs_1:9.16.44-1deb11u1.amd64-deb.deb 2023-11-30 11:42:33,211 [ajp-nio-0:0:0:0:0:0:0:1-8009-exec-5] INFO com.suse.manager.webui.controllers.DownloadController - Forbidden: You need a token to access /manager/download/debian-11-amd64-main-security-uyuni/getPackage/bind9-host_1:9.16.44-1deb11u1.amd64-deb.deb 2023-11-30 11:42:33,215 [ajp-nio-0:0:0:0:0:0:0:1-8009-exec-10] INFO com.suse.manager.webui.controllers.DownloadController - Forbidden: You need a token to access /manager/download/debian-11-amd64-main-security-uyuni/getPackage/file_1:5.39-3 deb11u1.amd64-deb.deb 2023-11-30 11:42:33,220 [ajp-nio-0:0:0:0:0:0:0:1-8009-exec-7] INFO com.suse.manager.webui.controllers.DownloadController - Forbidden: You need a token to access /manager/download/debian-11-amd64-main-security-uyuni/getPackage/libmagic1_1:5.39-3 deb11u1.amd64-deb.deb 2023-11-30 11:42:33,225 [ajp-nio-0:0:0:0:0:0:0:1-8009-exec-8] INFO com.suse.manager.webui.controllers.DownloadController - Forbidden: You need a token to access /manager/download/debian-11-amd64-main-security-uyuni/getPackage/libmagic-mgc_1:5.39-3 deb11u1.amd64-deb.deb 2023-11-30 11:42:33,228 [ajp-nio-0:0:0:0:0:0:0:1-8009-exec-1] INFO com.suse.manager.webui.controllers.DownloadController - Forbidden: You need a token to access /manager/download/debian-11-amd64-main-security-uyuni/getPackage/dnsutils_1:9.16.44-1deb11u1.all-deb.deb 2023-11-30 11:42:33,233 [ajp-nio-0:0:0:0:0:0:0:1-8009-exec-2] INFO com.suse.manager.webui.controllers.DownloadController - Forbidden: You need a token to access /manager/download/debian-11-amd64-main-security-uyuni/getPackage/libaprutil1_1.6.1-5 deb11u1.amd64-deb.deb 2023-11-30 11:42:33,237 [ajp-nio-0:0:0:0:0:0:0:1-8009-exec-3] INFO com.suse.manager.webui.controllers.DownloadController - Forbidden: You need a token to access /manager/download/debian-11-amd64-main-security-uyuni/getPackage/libapr1_1.7.0-6 deb11u2.amd64-deb.deb 2023-11-30 11:42:33,242 [ajp-nio-0:0:0:0:0:0:0:1-8009-exec-4] INFO com.suse.manager.webui.controllers.DownloadController - Forbidden: You need a token to access /manager/download/debian-11-amd64-main-security-uyuni/getPackage/libnss3_2:3.61-1 deb11u3.amd64-deb.deb

Does any body fixed this issue with 2023.10? What did I forget ?

Thanks in advance, it's getting more urgent for us now, we are supposed to patch servers once a month... And we are already two monthes late....

marmau06 commented 1 year ago

If this can help, "wget" do not work on a simple package, we get 403 error...

wget https://myserver.france.mydomain:443/rhn/manager/download/debian-11-pool-amd64-uyuni/getPackage/shim-helpers-amd64-signed_1%2b15.7%2b1%7edeb11u1-X.amd64-deb.deb --2023-11-30 14:19:48-- https://myserver.france.mydomain/rhn/manager/download/debian-11-pool-amd64-uyuni/getPackage/shim-helpers-amd64-signed_1%2b15.7%2b1%7edeb11u1-X.amd64-deb.deb Resolving proxy.france.mydomain (proxymop.france.rexel)... 10.3.204.8 Connecting to proxy.france.mydomain (proxy.france.mydomain)|10.3.204.8|:8080... connected. Proxy request sent, awaiting response... 403 403 2023-11-30 14:19:48 ERROR 403: 403.

But "curl" works fine on the same package...

curl -o /tmp/herve https://myserver.france.mydomain/rhn/manager/download/debian-11-pool-amd64-uyuni/getPackage/shim-helpers-amd64-signed_1%2b15.7%2b1%7edeb11u1-X.amd64-deb.deb % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 4089 100 4089 0 0 159k 0 --:--:-- --:--:-- --:--:-- 159k

santeri3700 commented 1 year ago

Looks like Taskomatic is generating partially invalid repodata for DEB channels/repos. Some of the packages in the Packages file are pointing to a wrong channel and clients will get Error 403 unless they are subscribed to the wrong channel as well.

Example (see the difference between the directory channel label and the Filename channel label):

uyuni-server:~ # grep 'mariadb106-ubuntu2204_amd64' /var/cache/rhn/repodata/mariadb1011-ubuntu2004_amd64/Packages
Filename: mariadb106-ubuntu2204_amd64/getPackage/mariadb-columnstore-cmapi_22.08.2-X.amd64-deb.deb

I've confirmed this on two separate Uyuni Servers running 2023.09 and 2023.10 with Ubuntu 20.04 and 22.04 clients.

Validating repodata

I wrote a small Python 3 script to list all of the channels and packages which have invalid repodata. I've successfully confirmed that the packages listed by my script will fail to download on DEB based clients which are NOT subscribed to the channels which the repodata is incorrectly pointing to.

uyuni_repodata_packages_filename_validator.py: https://gist.github.com/santeri3700/bbac7ea46018411c7b2b629a04c68e26

Workaround

For just a few independent clients facing this issue, fixing the channel labels from the apt cache works although the issue will return on the next package list refresh / apt update. \ The locally cached Packages file on the client can be found from /var/lib/apt/lists/UYUNI-SERVER-FQDN:443_rhn_manager_download_CHANNEL-LABEL_Packages.

A global workaround could be to temporarily disable the repo-sync schedules and the "channel-repodata-default" task schedule from Taskomatic and manually fixing the channel labels from the Packages files on the Uyuni Server (/var/cache/rhn/repodata/CHANNEL-LABEL/Packages). \ This way the fixes wouldn't be overwritten hourly (at least in theory) and the apt cache of independent clients wouldn't have to be modified manually. NOTE: I have NOT tested this. This would also somewhat break repository synchronizations etc..

Possible cause

I suspect that this issue was possibly caused by commit https://github.com/uyuni-project/uyuni/commit/72c888148e8828a7813a6f5881b83238f2f0c19d which was merged before 2023.09 release with https://github.com/uyuni-project/uyuni/pull/7566.

cFabij commented 1 year ago

Thanks @santeri3700, I can confirm that your local workaround (editing the "*_Packages" file) works.

Unfortunately on my installation your python script reveals over 150.000 packages which are pointing to wrong channels.

Until Taskomatic is fixed I guess I need to build a second script that (on the client side) loops over every "Filename" entry in "*_Packages" and changes it to the actual name of the channel...

Ripper66Six commented 12 months ago

Good morning,

we found the same issue on Ubuntu 20.04 in ubuntu-2004-amd64-uyuni-client repository. The clients should get the _venv-salt-minion3006.0-21.2 package from the uyuni tools channel but redirect to the uyuni tools devel:

Error message:

       ID: pkg_installed
    Function: pkg.installed
        Name: pkg_installed
      Result: false
     Comment: Problem encountered installing package(s). Additional info follows:

errors:
    - Running scope as unit: run-re3be694482884f218ae1dff429e87ee4.scope
      E: Failed to fetch https://*_uyuni_*:443/rhn/manager/download/ubuntu-2004-amd64-uyuni-client-devel/getPackage/venv-salt-minion_3006.0-21.2.uyuni.amd64-deb.deb  403  403 [IP: *.*.*.* 8080]
      E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing?
     Started: 09:04:07.945658
    Duration: 1616.229
         SLS: packages.pkginstall
     Changed: {}

Steps to reproduce

Client in Base-Channel Ubuntu 20.04
Software -> Packages -> Upgrade
ERROR: Failed to fetch https://*_uyuni_*:443/rhn/manager/download/ubuntu-2004-amd64-uyuni-client-devel/getPackage/venv-salt-minion_3006.0-21.2.uyuni.amd64-deb.deb 403 403 [IP: ... 8080]

Uyuni version

zypper info Uyuni-Server-release
Loading repository data...
Reading installed packages...

Information for package Uyuni-Server-release:
---------------------------------------------
Repository     : Uyuni Server Stable
Name           : Uyuni-Server-release
Version        : 2023.10-230900.209.1.uyuni3
Arch           : x86_64
Vendor         : obs://build.opensuse.org/systemsmanagement:Uyuni
Support Level  : Level 3
Installed Size : 1.4 KiB
Installed      : Yes (automatically)
Status         : up-to-date
Source package : Uyuni-Server-release-2023.10-230900.209.1.uyuni3.src
Summary        : Uyuni Server
Description    :
    Uyuni lets you efficiently manage physical, virtual,
    and cloud-based Linux systems. It provides automated and cost-effective
    configuration and software management, asset management, and system
    provisioning.

Uyuni proxy version (if used):

zypper info Uyuni-Server-release
Retrieving repository 'openSUSE-SLE-15.5-Updates for x86_64' metadata .........................................................................................................................................................[done]
Building repository 'openSUSE-SLE-15.5-Updates for x86_64' cache ..............................................................................................................................................................[done]
Loading repository data...
Reading installed packages...

Information for package Uyuni-Server-release:
---------------------------------------------
Repository     : Uyuni Proxy Stable for openSUSE Leap 15.5 (x86_64)
Name           : Uyuni-Server-release
Version        : 2023.10-230900.209.1.uyuni3
Arch           : x86_64
Vendor         : obs://build.opensuse.org/systemsmanagement:Uyuni
Installed Size : 1.4 KiB
Installed      : Yes
Status         : up-to-date
Source package : Uyuni-Server-release-2023.10-230900.209.1.uyuni3.src
Summary        : Uyuni Server
Description    :
    Uyuni lets you efficiently manage physical, virtual,
    and cloud-based Linux systems. It provides automated and cost-effective
    configuration and software management, asset management, and system
    provisioning.

j-kihet commented 11 months ago

Also having this issue on 2023.09.

marmau06 commented 11 months ago

Hi All, Hope you've got a nice Christmas.. No link I think, but our issue has been solved for Debian stuff. Uyuni server has been upgraded to 2023.10, and the trick was to rebuild the CLM/Projects....

Not sure of translation from french to english, but it felt in running mode :-) .....

santeri3700 commented 10 months ago

Looks like this issue has partially resolved itself on my environments. There are still some channels with incorrect Packages files and they seem to have not been updated for a very long time (e.g. last modified time was mid Nov 2023) because some of the upstream repositories haven't been updated for a while.

uyuni-server:~ # ls -la /var/cache/rhn/repodata/mariadb1011-ubuntu2004_amd64/Packages*
-rw-r--r-- 1 root root 33957 Nov 14 22:40 /var/cache/rhn/repodata/mariadb1011-ubuntu2004_amd64/Packages.gz
-rw-r--r-- 1 root root 284347 Nov 14 22:40 /var/cache/rhn/repodata/mariadb1011-ubuntu2004_amd64/Packages

uyuni-server:~ # curl -sIL http://mirror.mariadb.org/repo/10.11/ubuntu/dists/focal/main/binary-amd64/Packages | grep -i 'Last-Modified'
Last-Modified: Sat, 11 Nov 2023 00:57:14 GMT
uyuni-server:~ # curl -sIL http://mirror.mariadb.org/repo/10.11/ubuntu/dists/focal/main/binary-amd64/Packages.gz | grep -i 'Last-Modified'
last-modified: Sat, 11 Nov 2023 00:57:14 GMT

I double checked and repo-syncs are still happening but it seems Uyuni might not be executing the ChannelRepodataWorker and/or DebRepositoryWriter on those channels. Maybe this is because there are no new packages to be synchronized (since Nov 14 in this case)?

2023/11/14 22:39:11 +03:00 Sync of channel started.
2023/11/14 22:39:11 +03:00 Repo URL: http://mirror.mariadb.org/repo/10.11/ubuntu/dists/focal/main/binary-amd64/
2023/11/14 22:39:11 +03:00     Packages in repo:               111
2023/11/14 22:39:12 +03:00     Packages already synced:         74
2023/11/14 22:39:12 +03:00     Packages to sync:                37
2023/11/14 22:39:12 +03:00     New packages to download:        37
...
2023/11/14 22:39:20 +03:00 Sync completed.
...
2023/11/15 20:16:40 +03:00     No new packages to sync.
***** Daily repo-syncs for months *****
2024/01/07 12:40:01 +03:00     No new packages to sync.

Repodata staleness check seems to be implemented here:

So I tried updating the timestamp of the Packages.gz file:

uyuni-server:~ # touch /var/cache/rhn/repodata/mariadb1011-ubuntu2004_amd64/Packages.gz 
uyuni-server:~ # ls -la /var/cache/rhn/repodata/mariadb1011-ubuntu2004_amd64/Packages*
-rw-r--r-- 1 root root 284347 Nov 14 22:40 /var/cache/rhn/repodata/mariadb1011-ubuntu2004_amd64/Packages
-rw-r--r-- 1 root root  33957 Jan  8 10:11 /var/cache/rhn/repodata/mariadb1011-ubuntu2004_amd64/Packages.gz

But DebRepositoryWriter still does not seem to run after the timestamp modification or after trying to do the following:

Executing a manual reposync (spacecmd softwarechannel_syncrepos 'mariadb1011-ubuntu2004_amd64')
Executing 'channel-repodata' manually via Uyuni Web UI (Admin -> Task Schedules -> channel-repodata-bunch -> Single Run Schedule)
Restarting Taskomatic

Does anyone have any ideas how I could force repodata regeneration without having to completely remove and recreate a channel? I'd like to avoid manually editing the Packages files too in case the upstream repository gets updated. EDIT: I figured it out. Will write more about the solution in a new comment.

santeri3700 commented 10 months ago

I found out a way to force repodata regeneration and created another script to make it more convenient to automatically fix DEB channels with invalid repodata (without the previously mentioned workaround).

I tested this script with two Uyuni 2023.10 servers and it fixed all DEB channels with invalid repodata after Taskomatic was done running the 'channel-repodata' task(s). \ Not sure how permanent this is (it should be) but I'll report here if I see repodata going invalid again (especially after upgrading to 2023.12 in the near future).

I'm still not sure about the reason why this invalid data came to be. Perhaps it was not directly caused by the pull request I mentioned earlier.

Invalid DEB repodata regeneration script

uyuni_invalid_deb_repodata_regen.py: https://gist.github.com/santeri3700/89766bd3bc4ea6af618f697c04e7689b

santeri3700 commented 10 months ago

This problem hasn't reappeared in my environments after the repodata regen and upgrade to Uyuni 2023.12 so I think this issue could be closed.

cFabij commented 10 months ago

I don't think this issue should be closed.

Your work and research notwithstanding, you almost single-handedly kept this issue alive and delivered an after the fact Third-Party-Fix (though I have not tested it) - but this can only be a band aid in my opinion.

What interests me is how this problem could occur in the first place?

I "solved" the problem by wiping the whole database and building everything from the ground up (I'm on Uyuni Server 2023.09 right now). Solved is in quotes because even after setting up everything anew a lot of packages are still in multiple channels (Ubuntu 22.04 LTS). This works because all the channels are subscribed to but this is still very much ugly.

How can this be?

rjmateus commented 10 months ago

@cFabij can you update your uyuni server to the latest version. After that re-run repo-sync, and if you are using CLM, then make any change to the project then build promote (this will force metadata re-generate)

cFabij commented 9 months ago

@rjmateus I updated to 2024.01 right now and run spacewalk-repo-sync on both my Ubuntu LTS (20.04 and 22.04). I also built and promoted my Content Lifecycle Project.

Afterwards I had over 8k packages in no channels. I deleted those.

I still have packages in multiple channels though (e.g.):

But I think there are less of those instances now.

santeri3700 commented 9 months ago

@cFabij that is probably intentional for some of the packages you see belonging to multiple channels at once.

If you inspect the Ubuntu upstream repositories you can see that the specific package is present in both Main Updates and Universe repos. Same package in multiple channels shouldn't normally be an issue.

curl -s 'http://archive.ubuntu.com/ubuntu/dists/focal-updates/main/binary-amd64/Packages.gz' | zgrep -A8 'python-ironicclient-doc'
curl -s 'http://archive.ubuntu.com/ubuntu/dists/focal/universe/binary-amd64/Packages.gz' | zgrep -A8 'python-ironicclient-doc'

Ripper66Six commented 9 months ago

3. ubuntu-2004-amd64-uyuni-client-devel

Good morning,

I agree that normally there is no problem to find packages in multiple channels. But with the current configuration, the packages should be taken from the ubuntu-2004-amd64-uyuni-client repository. Currently the packages are taken from ubuntu-2004-amd64-uyuni-client-devel repository.

In this case we don´t understand why the venv-salt-minion_3006.0 packages are located to the ubuntu-2004-amd64-uyuni-client-devel repository.

In November 2023 there was no problem and the only change was the installation of release 2023.10-230900.209.1.uyuni3.

Kind regards

santeri3700 commented 9 months ago

@Ripper66Six not sure if I understand you correctly but it seems that it is the same case as with the previously mentioned packages and repos.

Some packages happen to be identical (see checksums) in both repositories and that's why it may seem that the packages are coming from the wrong channel/repository.

ubuntu-2004-amd64-uyuni-client (Stable):

$ curl -s 'https://download.opensuse.org/repositories/systemsmanagement:/Uyuni:/Stable:/Ubuntu2004-Uyuni-Client-Tools/xUbuntu_20.04/Packages.gz' | zgrep -A4 'venv-salt-minion'
Package: venv-salt-minion
Version: 3006.0-24.2.uyuni
Architecture: amd64
Maintainer: Uyuni packagers <devel@lists.uyuni-project.org>
Installed-Size: 115578
--
Filename: amd64/venv-salt-minion_3006.0-24.2.uyuni_amd64.deb
Size: 23919496
MD5sum: 2041aa8a50ba511e46d39e8026ac8c87
SHA1: d30a6136a212f25a8db908a3036400a5fabbdd4f
SHA256: 75a55e7a180e4c1ca9822497f7b9acbb720eb593eb37892b80b0d2a65517b9c9

ubuntu-2004-amd64-uyuni-client-devel (Master):

$ curl -s 'https://download.opensuse.org/repositories/systemsmanagement:/Uyuni:/Master:/Ubuntu2004-Uyuni-Client-Tools/xUbuntu_20.04/Packages.gz' | zgrep -A4 'venv-salt-minion'
Package: venv-salt-minion
Version: 3006.0-24.2.uyuni
Architecture: amd64
Maintainer: Uyuni packagers <devel@lists.uyuni-project.org>
Installed-Size: 115578
--
Filename: amd64/venv-salt-minion_3006.0-24.2.uyuni_amd64.deb
Size: 23919496
MD5sum: 2041aa8a50ba511e46d39e8026ac8c87
SHA1: d30a6136a212f25a8db908a3036400a5fabbdd4f
SHA256: 75a55e7a180e4c1ca9822497f7b9acbb720eb593eb37892b80b0d2a65517b9c9

I personally don't even use or sync the devel client tools repos as I don't have any need for them. The stable client tools repos should be sufficient for non-development environments.

EthanB11 commented 6 months ago

I just ran into what looks to be the same issue 2024.05 after upgrading a host from Rocky Linux 8 to Rocky Linux 9. It was working on the upgraded hosts then suddenly stopped and the server logs contain You need a token to access /manager/download/rockylinux9-x86_64-extras/repodata/repomd.xml I've confirmed a Rocky Linux 8 instance is still working properly.

uyuni-project / uyuni