Uyuni 2021.08: tzdata packages for EL8 made available on CentOS 7

Question

Uyuni 2021.08: tzdata packages for EL8 made available on CentOS 7

phibid opened this issue 3 years ago · comments

I have a strange issue that I have already described here uyuni-project/uyuni#4357

I have reproduced this issue on the 2 last Uyuni release 2021-09 and 2021-08.

The issue is simple,, if I synchronize the CentOS 7 and 8 repositories, all is fine. However, when I execute the CentOS errata scripts, I can detect tzdata and tzdata-java CentOS 7 packages in the CentOS 8 repo and vice versa:

spacecmd {SSM:0}> package_details tzdata-2021e-1.el8
Name:      tzdata
Version:   2021e
Release:   1.el8
Epoch:
Arch:      noarch

File:      tzdata-2021e-1.el8.noarch.rpm
Path:      packages/1/6ae/tzdata/2021e-1.el8/noarch/6ae03d640e42eb1057d2438374025587c108a5a5eef91aa0fbca48c530140b78/tzdata-2021e-1.el8.noarch.rpm
Size:      485068
Retracted: No
SHA256:    6ae03d640e42eb1057d2438374025587c108a5a5eef91aa0fbca48c530140b78

Installed Systems: 0

Description
-----------
This package contains data files with rules for various timezones
around the world.

Available From Channels
-----------------------
centos7-x86_64-updates
centos8-x86_64

Name:      tzdata
Version:   2021e
Release:   1.el8
Epoch:
Arch:      noarch

File:      tzdata-2021e-1.el8.noarch.rpm
Path:      packages/1/899/tzdata/2021e-1.el8/noarch/899ab20db41c239eb52b77c78d5713a7d58c0721089d821a30a85876607d27c0/tzdata-2021e-1.el8.noarch.rpm
Size:      483928
Retracted: No
SHA256:    899ab20db41c239eb52b77c78d5713a7d58c0721089d821a30a85876607d27c0

Installed Systems: 0

Description
-----------
This package contains data files with rules for various timezones
around the world.

Available From Channels
-----------------------
almalinux8-x86_64

This is obviously annoying as now the CentOS 7 clients tries (but fortunately fails because of the missing GPG key repo) to install the CentOS 8 tzdata packages.

Steve Meier · Answer 1 · Wed Dec 01 2021 01:27:16 GMT+0800 (China Standard Time)

Hello,

could you provide the log of a run of errata-import.pl with the --debug option enabled?
Spacewalk (and therefore Uyuni) have a habit of copying packages around, which is not caused by my script.
In fact, my script is trying to revert those changes (see the --autopush option).

phibid · Answer 2 · Wed Dec 01 2021 04:36:17 GMT+0800 (China Standard Time)

Hi !

Here it is: centos_erratas.log

What I have done is to remove those 2 erratas from the Uyuni GUI:

		CEBA-2021:4003	CentOS tzdata Update	10/26/21
		CEBA-2021:3790	CentOS tzdata Update	10/12/21

The tzdata package mix-up between CentOS 7/8 repos then disappeared, and reappears again after the import of the erratas.

Steve Meier · Answer 3 · Fri Dec 03 2021 03:24:34 GMT+0800 (China Standard Time)

So after checking the logs, I don't think errata-import.pl is at fault here.

During the run, it only detects the CentOS 7 packages:

% egrep "Package ID" centos_erratas.log | egrep 2021c\|2021e
DEBUG: Package ID 11319 is tzdata-2021c-1.el7.noarch.rpm
DEBUG: Package ID 142032 is tzdata-2021e-1.el7.noarch.rpm
DEBUG: Package ID 11401 is tzdata-java-2021c-1.el7.noarch.rpm
DEBUG: Package ID 142015 is tzdata-java-2021e-1.el7.noarch.rpm

After creating the errata, it also confirms that the channel membership is unchanged:

% grep -i membership centos_erratas.log | egrep 11319\|142032\|11401\|142015
DEBUG: Previous channel membership for 11319: centos7-x86_64-updates
DEBUG: Current channel membership for 11319: centos7-x86_64-updates
DEBUG: Previous channel membership for 11401: centos7-x86_64-updates
DEBUG: Current channel membership for 11401: centos7-x86_64-updates
DEBUG: Previous channel membership for 142015: centos7-x86_64-updates
DEBUG: Current channel membership for 142015: centos7-x86_64-updates
DEBUG: Previous channel membership for 142032: centos7-x86_64-updates
DEBUG: Current channel membership for 142032: centos7-x86_64-updates

This may actually be caused by the Alma Errata import. There is nothing wrong with Alma or their errata data, it is just some annoying built-in function in Spacewalk which causes this.

To verify, please clean up and then only trigger the Alma sync.

phibid · Answer 4 · Fri Dec 03 2021 16:49:14 GMT+0800 (China Standard Time)

I don't think that the issue is coming from the Alma erratas. In Uyuni, they are actually natively populated, no external script needed anymore.

What is happening is that this errata brings updated packages for EL7 and EL8 distributions, as confirmed by the RHBA (https://access.redhat.com/errata/RHBA-2021:4003) and by the metadata you generate from it:

<CEBA-2021--4003 description="Not available" from="email@steve-meier.de" issue_date="2021-10-26 00:00:00" manual="1" multirelease="1" notes="Not available" product="CentOS Linux" references="https://access.redhat.com/errata/RHBA-2021:4003 https://lists.centos.org/pipermail/centos-announce/2021-November/048389.html" release="2" solution="Not available" synopsis="CentOS tzdata Update" topic="Not available" type="Bug Fix Advisory">
<os_release>7</os_release>
<os_release>8</os_release>
<packages>tzdata-2021e-1.el7.noarch.rpm</packages>
<packages>tzdata-2021e-1.el7.src.rpm</packages>
<packages>tzdata-2021e-1.el8.noarch.rpm</packages>
<packages>tzdata-java-2021e-1.el7.noarch.rpm</packages>
<packages>tzdata-java-2021e-1.el8.noarch.rpm</packages>
</CEBA-2021--4003>

From there, the errata import script links this errata with the 3 repos centos7-x86_64-updates, centos8-x86_64-apstream, centos8-x86_64 where the affected packages are located:

[2021-12-03 04:36:25,269] INFO  - REQUESTED FROM: 127.0.0.1 CALL: errata.create(admin, {advisory_name=CEBA-2021:4003, product=CentOS Linux, notes=Not available, references=https://access.redhat.com/errata/RHBA-2021:4003 https://lists.centos.org/pipermail/centos-announce/2021-November/048389.html, solution=Not available, advisory_type=Bug Fix Advisory, advisory_release=2, description=Not available, topic=Not available, synopsis=CentOS tzdata Update}, [], [], [142015, 146208, 143171, 142032], [centos7-x86_64-updates, centos8-x86_64-appstream, centos8-x86_64]) CALLER: (admin) TIME: 4.901 seconds

So is this issue because that you don't contemplate the fact that a RHBA can affect packages from different repos ? It can't be the case as I guest (could not find another example) that this is not the first RHBA affecting packages located in different RH/CentOS distributions no?

Stefan Bogner · Answer 5 · Mon Dec 06 2021 14:52:40 GMT+0800 (China Standard Time)

Hi, I can confirm that the issue doesn't have to do with Alma Sync, I have CentOS7 and CentOS8 only and see the same problem.

Steve Meier · Answer 6 · Mon Dec 06 2021 18:09:53 GMT+0800 (China Standard Time)

[2021-12-03 04:36:25,269] INFO  - REQUESTED FROM: 127.0.0.1 CALL: errata.create(admin, {advisory_name=CEBA-2021:4003, product=CentOS Linux, notes=Not available, references=https://access.redhat.com/errata/RHBA-2021:4003 https://lists.centos.org/pipermail/centos-announce/2021-November/048389.html, solution=Not available, advisory_type=Bug Fix Advisory, advisory_release=2, description=Not available, topic=Not available, synopsis=CentOS tzdata Update}, [], [], [142015, 146208, 143171, 142032], [centos7-x86_64-updates, centos8-x86_64-appstream, centos8-x86_64]) CALLER: (admin) TIME: 4.901 seconds

The package IDs in this log output are not the same as in the log you provided.
The IDs 146208 and 143171 do not show up in the log.
But regardless, that API call is correct.

There are two possible fixes:

use the --autopush option
run errata-import.pl twice, once for only the C7 channels and once for only the C8 channels

greinick · Answer 7 · Mon Dec 13 2021 18:57:49 GMT+0800 (China Standard Time)

Hello, I'm faced with the same issue. If running the import script twice, once for each channel, that's ok for me.

To check that, I'd like to "clean" the fault, but don't know how. Is it possible to remove the package and errate etc from the channels? Or how would you proceed? Thanks & regards

Steve Meier · Answer 8 · Tue Dec 14 2021 00:05:01 GMT+0800 (China Standard Time)

Hello,

my suggestion would be to take the following steps:

Remove all packages from the relevant errata
Delete the errata
Delete the copied packages from the channel(s) they should not be in
Re-run errata-import.pl separately for C7/C8

Please note that if you delete an errata without removing its packages first, these packages will be deleted from the underlying channel. That's probably not what you want.