search

uyuni-project / uyuni

Source code for Uyuni
https://www.uyuni-project.org/
GNU General Public License v2.0
432 stars 181 forks source link

can't see any ubuntu errata #8134

Closed fritz0011 closed 3 months ago

fritz0011 commented 9 months ago

Problem description

after the ubuntu22 channel has been defined: errata seems to be imported , but still, no patches visible in web interface

image

image

image

image

satellite:~ # grep 6572-1 /var/log/rhn/rhn_taskomatic_daemon.log

2024-01-10 22:32:08,040 [DefaultQuartzScheduler_Worker-5] INFO com.redhat.rhn.manager.content.ubuntu.UbuntuErrataManager - matching packages for 6572-1 took 0.002263735 seconds. 2024-01-10 22:38:34,947 [DefaultQuartzScheduler_Worker-13] INFO com.redhat.rhn.manager.content.ubuntu.UbuntuErrataManager - matching packages for 6572-1 took 0.00213575 seconds.

Steps to reproduce

1. 2. 3. ...

Uyuni version

Information for package Uyuni-Server-release:
---------------------------------------------
Repository     : uyuni-server-stable
Name           : Uyuni-Server-release
Version        : 2023.12-230900.210.2.uyuni3
Arch           : x86_64
Vendor         : obs://build.opensuse.org/systemsmanagement:Uyuni
Support Level  : Level 3
Installed Size : 1.4 KiB
Installed      : Yes
Status         : not installed
Source package : Uyuni-Server-release-2023.12-230900.210.2.uyuni3.src
Summary        : Uyuni Server

Uyuni proxy version (if used)

No response

Useful logs

/usr/share/rhn/classes/log4j2.xml
updated as following... 

        <Logger name="com.redhat.rhn.taskomatic.SchedulerKernel" level="info" />
        <Logger name="com.redhat.rhn.taskomatic.task" level="debug" />

snip
        <!-- this silences ehcache on Fedoras complaining about using default values -->
        <Logger name="org.hibernate.cache.ehcache.AbstractEhcacheRegionFactory" level="error" />
        <Logger name="com.redhat.rhn.manager.content.ubuntu.UbuntuErrataManager" level="debug" />

2024-01-10 22:38:59,291 [DefaultQuartzScheduler_Worker-13] DEBUG com.redhat.rhn.manager.content.ubuntu.UbuntuErrataManager - Skipping errata without matching packages: 4714-1
2024-01-10 22:38:59,294 [DefaultQuartzScheduler_Worker-13] INFO  com.redhat.rhn.manager.content.ubuntu.UbuntuErrataManager - matching packages for 4126-1 took 0.00263124 seconds.
2024-01-10 22:38:59,321 [DefaultQuartzScheduler_Worker-13] INFO  com.redhat.rhn.manager.content.ubuntu.UbuntuErrataManager - matching packages for 4126-2 took 0.00230444 seconds.
2024-01-10 22:38:59,352 [DefaultQuartzScheduler_Worker-13] INFO  com.redhat.rhn.manager.content.ubuntu.UbuntuErrataManager - matching packages for 2533-1 took 0.005662967 seconds.
2024-01-10 22:38:59,379 [DefaultQuartzScheduler_Worker-13] INFO  com.redhat.rhn.manager.content.ubuntu.UbuntuErrataManager - matching packages for 6001-1 took 0.001427489 seconds.
2024-01-10 22:38:59,405 [DefaultQuartzScheduler_Worker-13] DEBUG com.redhat.rhn.manager.content.ubuntu.UbuntuErrataManager - Skipping errata without matching packages: 3957-3
2024-01-10 22:38:59,410 [DefaultQuartzScheduler_Worker-13] INFO  com.redhat.rhn.manager.content.ubuntu.UbuntuErrataManager - matching packages for 3858-1 took 0.0046029 seconds.
2024-01-10 22:38:59,440 [DefaultQuartzScheduler_Worker-13] INFO  com.redhat.rhn.manager.content.ubuntu.UbuntuErrataManager - writing erratas to db took 64.959239509 seconds.
2024-01-10 22:38:59,499 [DefaultQuartzScheduler_Worker-13] DEBUG com.redhat.rhn.manager.content.ubuntu.UbuntuErrataManager - process Ubuntu Errata finished - done, totalMemory:998244352, freeMemory:144422432
2024-01-10 22:39:00,011 [DefaultQuartzScheduler_Worker-20] DEBUG com.redhat.rhn.taskomatic.task.SSHService - Starting run 67869
2024-01-10 22:39:00,012 [DefaultQuartzScheduler_Worker-20] DEBUG com.redhat.rhn.taskomatic.task.SSHService - Queue size (before run): 0
2024-01-10 22:39:00,016 [DefaultQuartzScheduler_Worker-2] DEBUG com.redhat.rhn.taskomatic.task.SystemOverviewUpdateQueue - Starting run 67870
2024-01-10 22:39:00,016 [DefaultQuartzScheduler_Worker-2] DEBUG com.redhat.rhn.taskomatic.task.SystemOverviewUpdateQueue - Queue size (before run): 0
2024-01-10 22:39:00,018 [DefaultQuartzScheduler_Worker-2] DEBUG com.redhat.rhn.taskomatic.task.SystemOverviewUpdateQueue - Finishing run 67870

Additional information

No response

avshiliaev commented 9 months ago

Hey @fritz0011 thanks for the report. Did you look into the /var/log/rhn/reposync/<channel-label>.log log file to check the synchronization process?

fritz0011 commented 9 months ago

Hey @fritz0011 thanks for the report. Did you look into the /var/log/rhn/reposync/<channel-label>.log log file to check the synchronization process?

Here....

2024/01/10 22:30:29 +02:00 Sync of channel started. 2024/01/10 22:30:29 +02:00 Repo URL: http://archive.ubuntu.com/ubuntu/dists/jammy/main/binary-amd64/ 2024/01/10 22:30:29 +02:00 Packages in repo: 6090 2024/01/10 22:30:41 +02:00 Packages already synced: 0 2024/01/10 22:30:41 +02:00 Packages to sync: 6090 2024/01/10 22:30:41 +02:00 New packages to download: 0 2024/01/10 22:30:41 +02:00 Downloading packages: 2024/01/10 22:30:41 +02:00 Filtering packages that failed to download 2024/01/10 22:30:41 +02:00 Importing packages started. 2024/01/10 22:30:41 +02:00 2024/01/10 22:30:41 +02:00 Importing packages to DB: 2024/01/10 22:30:41 +02:00 Package batch #1 of 305 completed... .. .. 2024/01/10 22:30:47 +02:00 Package batch #302 of 305 completed... 2024/01/10 22:30:47 +02:00 Package batch #303 of 305 completed... 2024/01/10 22:30:47 +02:00 Package batch #304 of 305 completed... 2024/01/10 22:30:47 +02:00 Package batch #305 of 305 completed... 2024/01/10 22:30:47 +02:00 Importing packages finished. 2024/01/10 22:30:47 +02:00 2024/01/10 22:30:47 +02:00 Linking packages to the channel. 2024/01/10 22:30:52 +02:00 1000 packages linked 2024/01/10 22:31:09 +02:00 2000 packages linked 2024/01/10 22:31:10 +02:00 3000 packages linked 2024/01/10 22:31:12 +02:00 4000 packages linked 2024/01/10 22:31:14 +02:00 5000 packages linked 2024/01/10 22:31:16 +02:00 6000 packages linked 2024/01/10 22:31:17 +02:00 6090 packages linked 2024/01/10 22:31:17 +02:00 2024/01/10 22:31:17 +02:00 Patches in repo: 0. 2024/01/10 22:31:17 +02:00 Regenerating bootstrap repositories. 2024/01/10 22:31:18 +02:00 Sync completed.

For whatever reasons , the errata is not linked to the channels/packages (see above attached screenshots)

fritz0011 commented 9 months ago

more about

/var/log/rhn/rhn_taskomatic_daemon-2.log:2024-01-10 22:32:08,756 [DefaultQuartzScheduler_Worker-5] INFO com.redhat.rhn.manager.content.ubuntu.UbuntuErrataManager - matching packages for 4591-1 took 0.010669691 seconds.

However....

image

/var/log/rhn/rhn_taskomatic_daemon-2.log:2024-01-10 22:38:59,352 [DefaultQuartzScheduler_Worker-13] INFO com.redhat.rhn.manager.content.ubuntu.UbuntuErrataManager - matching packages for 2533-1 took 0.005662967 seconds.

/var/log/rhn/rhn_taskomatic_daemon-2.log:2024-01-11 04:36:00,434 [DefaultQuartzScheduler_Worker-15] INFO com.redhat.rhn.manager.content.ubuntu.UbuntuErrataManager - No deb packages to process in channels:

fritz0011 commented 9 months ago

new update: So, uyuni is downloading the errata info from:

https://usn.ubuntu.com/usn-db/database.json

Have a look at those 2 patches::

Patch: 4658-2 (this patch does not affect jammy, still uyuni dld this errata) 5898-1 (this patch does affect jammy, still uyuni doesn't dld this errata)

image

image

image

image

jay2theb commented 8 months ago

I can confirm the same behavior on Uyuni version 2024.01

gabira2003 commented 8 months ago

I second that. We running Uyuni version 2024.01 Software channel that we syncing = Ubuntu22 (Jammy) After enabling debugging (/usr/share/rhn/classes/log4j2.xml) , we can observe in logs that errata fetched.

ubuntu.UbuntuErrataManager - matching packages for 4126-2 took 0.00230444 seconds

But in GUI [Software->ChannelList->All ] the 'Patches' number is always zero.

It used to work in correctly in previous version .

jay2theb commented 8 months ago

I can also confirm that it was working as of Uyuni version 2023.09. I made the jump from 2023.09 to 2024.01, so I cannot say when it broke exactly.

@gabira2003 can you comment on what version it was last working for you?

gabira2003 commented 8 months ago

I can also confirm that it was working as of Uyuni version 2023.09. I made the jump from 2023.09 to 2024.01, so I cannot say when it broke exactly.

@gabira2003 can you comment on what version it was last working for you?

For us errata/patches feature used to work just fine in 2023.10. And then we jumped from 2023.10 to 2024.01.

jay2theb commented 8 months ago

Okay, thanks @gabira2003, so @fritz0011 initially reported the issue on 2023.12, so it could? be safe to assume that something pushed or changed in 2023.11 may have caused the issue. My environment is mostly ubuntu 22.04 with some RHEL. I can say that the RHEL errata seems to still be working in 2024.01

gabira2003 commented 8 months ago

Okay, thanks @gabira2003, so @fritz0011 initially reported the issue on 2023.12, so it could? be safe to assume that something pushed or changed in 2023.11 may have caused the issue. My environment is mostly ubuntu 22.04 with some RHEL. I can say that the RHEL errata seems to still be working in 2024.01

Release 2023.11 does not exists. AFAIK , something was already broken in 2023.12.

fritz0011 commented 8 months ago

Correct , version 2023.12 and 2024.1 are plagued by this issue, RHEL/ORACLE are working flawless...

jay2theb commented 8 months ago

Trying to help move this along by possibly identifying changes made to anything related to errata between Uyuni releases 2023.10 and 2023.12, as this is where the issue seems to have been introduced.

'try to download compressed ubuntu usn database' <-- looks promising https://github.com/uyuni-project/uyuni/commit/34a26b6d6a94d4aa549205f202e086a5f84bb0e9

'filter errata without package matches': https://github.com/uyuni-project/uyuni/commit/98accf1618bad20ea260f7f12e411f9d261033a3

'fix errata search' https://github.com/uyuni-project/uyuni/commit/02e3d79a1dd4075bcb4cae62c8df50f74e71f0eb

jay2theb commented 8 months ago

Would I be out of line to ask @mcalmer to take a second look at https://github.com/uyuni-project/uyuni/commit/34a26b6d6a94d4aa549205f202e086a5f84bb0e9 ?

mcalmer commented 8 months ago

Any logs available?

jay2theb commented 8 months ago

@mcalmer Could you suggest where else to look?

mcalmer commented 8 months ago

/var/log/rhn/rhn_web_ui.log and /var/log/rhn/rhn_taskomatic_daemon.log You can try to increase the log level. Look for log4j2.xml https://github.com/uyuni-project/uyuni/wiki/Java-Logging

The tomcat log config could also be in /srv/tomcat/webapps/rhn/WEB-INF/classes/log4j2.xml if the installation is older

jay2theb commented 8 months ago

@mcalmer I see nothing in my logs (turned all the way up to debug) that indicates to me an issue with errata import failing.

[DefaultQuartzScheduler_Worker-15] INFO com.redhat.rhn.taskomatic.task.ReportDbUpdateTask - Refreshing table SystemErrata took 0.002507251 seconds. 2024-02-22 00:00:57,428 [DefaultQuartzScheduler_Worker-15] INFO com.redhat.rhn.taskomatic.task.ReportDbUpdateTask - Refreshing table ChannelErrata took 0.191465697 seconds. 2024-02-22 00:01:27,985 [DefaultQuartzScheduler_Worker-15] INFO com.redhat.rhn.taskomatic.task.ReportDbUpdateTask - Refreshing table Errata took 0.698889839 seconds. 2024-02-22 01:13:00,061 [DefaultQuartzScheduler_Worker-20] INFO com.redhat.rhn.taskomatic.task.ErrataCacheTask - In the queue: 1 2024-02-22 01:14:00,065 [DefaultQuartzScheduler_Worker-18] INFO com.redhat.rhn.taskomatic.task.ErrataCacheTask - In the queue: 8 2024-02-22 01:16:00,041 [DefaultQuartzScheduler_Worker-9] INFO com.redhat.rhn.taskomatic.task.ErrataCacheTask - In the queue: 1

But alas, no patches of any kind show (This uyuni instance has nothing but ubuntu 22.04 clients)

image

mcalmer commented 8 months ago

You need to set the UbuntuErrataManager to info loglevel. Modify /usr/share/rhn/classes/log4j2.xml and add:

<Logger name="com.redhat.rhn.manager.content.ubuntu.UbuntuErrataManager" level="info" />

after the <Logger name="com.redhat.rhn.taskomatic.task" level="info" /> line. Restart taskomatic.

The job should be triggered from the reposync job when the ubuntu channel is mirrored.

jay2theb commented 8 months ago

Thank you @mcalmer, after doing so and starting a reposync, in the /var/log/rhn/rhn_taskomatic_daemon.log I see several iterations of this as it goes through all of the errata

2024-02-26 15:32:49,321 [DefaultQuartzScheduler_Worker-8] INFO com.redhat.rhn.manager.content.ubuntu.UbuntuErrataManager - matching packages for 4714-1 took 0.028402793 seconds. 2024-02-26 15:32:49,387 [DefaultQuartzScheduler_Worker-8] INFO com.redhat.rhn.manager.content.ubuntu.UbuntuErrataManager - matching packages for 2533-1 took 0.056103571 seconds. 2024-02-26 15:32:49,412 [DefaultQuartzScheduler_Worker-8] INFO com.redhat.rhn.manager.content.ubuntu.UbuntuErrataManager - matching packages for 3957-3 took 0.014937067 seconds. 2024-02-26 15:32:49,422 [DefaultQuartzScheduler_Worker-8] INFO And ultimately ending with: com.redhat.rhn.manager.content.ubuntu.UbuntuErrataManager - writing erratas to db took 70.230811139 seconds. I can find nothing that seems to be of interest in the /var/log/rhn/rhn_web_ui.log

For fun I turned it up to debug, and caught more of the same, but no errors to report:

2024-02-26 15:46:03,468 [DefaultQuartzScheduler_Worker-1] DEBUG com.redhat.rhn.manager.content.ubuntu.UbuntuErrataManager - sync starte d - check deb packages in channels, totalMemory:511705088, freeMemory:389539840 2024-02-26 15:46:12,084 [DefaultQuartzScheduler_Worker-1] DEBUG com.redhat.rhn.manager.content.ubuntu.UbuntuErrataManager - check deb packages in channels finished - get and parse errata 2024-02-26 15:46:12,104 [DefaultQuartzScheduler_Worker-1] INFO com.redhat.rhn.manager.content.ubuntu.UbuntuErrataManager - download ubuntu errata start 2024-02-26 15:46:21,238 [DefaultQuartzScheduler_Worker-1] INFO com.redhat.rhn.manager.content.ubuntu.UbuntuErrataManager - download ubuntu errata end 2024-02-26 15:46:21,239 [DefaultQuartzScheduler_Worker-1] DEBUG com.redhat.rhn.manager.content.ubuntu.UbuntuErrataManager - get and parse errata finished - process Ubuntu Errata 2024-02-26 15:46:21,244 [DefaultQuartzScheduler_Worker-1] DEBUG com.redhat.rhn.manager.content.ubuntu.UbuntuErrataManager - matching packages for 6431-3 took 0.065230664 seconds. 2024-02-26 15:46:21,322 [DefaultQuartzScheduler_Worker-1] DEBUG com.redhat.rhn.manager.content.ubuntu.UbuntuErrataManager - Skipping errata without matching packages: 2818-1 2024-02-26 15:46:21,369 [DefaultQuartzScheduler_Worker-1] INFO com.redhat.rhn.manager.content.ubuntu.UbuntuErrataManager - matching packages for 6431-1 took 0.046025914 seconds. 2024-02-26 15:47:35,892 [DefaultQuartzScheduler_Worker-1] INFO com.redhat.rhn.manager.content.ubuntu.UbuntuErrataManager - writing erratas to db took 74.652254236 seconds. 2024-02-26 15:47:35,915 [DefaultQuartzScheduler_Worker-1] DEBUG com.redhat.rhn.manager.content.ubuntu.UbuntuErrataManager - process Ubuntu Errata finished - done, totalMemory:3720347648, freeMemory:1887981968

mcalmer commented 7 months ago

Maybe you just have no errata which are relevant to your system? Do you see errata when you select "All" in the left sidebar?

fritz0011 commented 7 months ago

Maybe you just have no errata which are relevant to your system? Do you see errata when you select "All" in the left sidebar?

I did a clean install of everything and registered a new ubuntu22 client machine uyuni shows 90+ available packages.... but still no patches visible... So far everything points out an issue about how parsed json db is processed... Normally, I wouldn't bother too much about this , but we need to implement a kind of quarterly patching procedure, and this one relays on the available patches for each systems...

jay2theb commented 7 months ago

So far everything points out an issue about how parsed json db is processed... Normally, I wouldn't bother too much about this , but we need to implement a kind of quarterly patching procedure, and this one relays on the available patches for each systems...

+1 to this, as we also rely on this functionality for the same purpose

jay2theb commented 7 months ago

For what it's worth, since this issue began we also stopped receiving Uyuni Patch Alert emails for any relevant errata.

I suspect changes in https://github.com/uyuni-project/uyuni/commit/98accf1618bad20ea260f7f12e411f9d261033a3 seem to have something to do with this

mcalmer commented 7 months ago

A fix is merged in git. Should be available with the next Uyuni release.

sorquan commented 6 months ago

When will a patch that fixes this problem be available?

mcalmer commented 6 months ago

The plan is somewhen this month.

fritz0011 commented 6 months ago

This is great news, if any RH is watching this forum, watch and learn what SUSE managed to do from satellite 5 :)

sorquan commented 6 months ago

Updated to the latest release 2024.03, nothing has changed, Ubuntu patches are still not mapped to Ubuntu channels. What needs to be done to correct the situation?

jay2theb commented 6 months ago

Updated to the latest release 2024.03, nothing has changed, Ubuntu patches are still not mapped to Ubuntu channels. What needs to be done to correct the situation?

I can also confirm this, perhaps @mcalmer could comment?

sorquan commented 6 months ago

A fix is merged in git. Should be available with the next Uyuni release.

Still not working

admd commented 6 months ago

based on the feedback, I am re-opening the issue.

mcalmer commented 5 months ago

I don't think we have a bug. Maybe it is a missunderstanding how things work.

On our reference server I can mirror the channels and it also show patches available in these channels. I had now a look at this comment

It is correct, that these patches list binaries for Ubuntu 22. But they are very old and I had a look if I have the packages. I have not.

A patch will only be created in Uyuni when the packages, which fix the bug, are available. Both, kernel and openjdk packages are not available in my sync so the patch is also not available. The openjdk for example is openjdk-8, while Ubuntu 22.04 come with openjdk-11 .

Maybe these package might be available when you mirror universe or multiverse or another not default repository. But in the default these packages do not exist and so the patch is also not created.

When I check what patches I have, I can see:

6757-2  Several security issues were fixed in PHP.  5/2/24

as the latest in "Ubuntu 22.04 LTS AMD64 Main Updates for Uyuni"

image

image

I am not sure if Ubuntu remove packages when they are obsoleted by a newer version. That could explain another reason why patches are not available. If a newer patch or a simple package update cause that packages gets removed which are part of a patch, such a patch would not be created when you sync after that point.

Please check your installation and when you miss a patch, check the packages which are listed to fix the problem. Verify, that these packages are available in your channel. If they are not, you found the reason why the patch is not there.

sorquan commented 5 months ago

The problem is that not some patches are missing, but all of them. After updating to 2023.03, all patches stopped being associated with the packages related to them.

fritz0011 commented 5 months ago

@mcalmer ,

maybe it helps to identify the issue ?

spacecmd {SSM:0}> package_details linux-image-5.15.0-92-generic-5.15.0-92.102 Name: linux-image-5.15.0-92-generic Version: 5.15.0 Release: 92.102 Epoch: Arch: amd64-deb

File: linux-image-5.15.0-92-generic-5.15.0-92.102.amd64-deb.deb Path: packages/1/a97/linux-image-5.15.0-92-generic/5.15.0-92.102/amd64-deb/a97b8419267a7c31f752d032120d419a2b76db8c3f86ff66db99c4592c7878ff/linux-image-5.15.0-92-generic-5.15.0-92.102.amd64-deb.deb Size: 11459044 Retracted: No SHA256: a97b8419267a7c31f752d032120d419a2b76db8c3f86ff66db99c4592c7878ff

Installed Systems: 1

Description

Signed kernel image generic A kernel image for generic. This version of it is signed with Canonical's signing key.

Available From Channels

ubuntu-2204-amd64-main-security-uyuni ubuntu-2204-amd64-main-updates-uyuni

spacecmd {SSM:0}> repo_details "External - Ubuntu 22.04 LTS AMD64 Main Security for Uyuni" Repository Label: External - Ubuntu 22.04 LTS AMD64 Main Security for Uyuni Repository URL: http://archive.ubuntu.com/ubuntu/dists/jammy-security/main/binary-amd64/ Repository Type: deb

spacecmd {SSM:0}> repo_details "External - Ubuntu 22.04 LTS AMD64 Main Updates for Uyuni" Repository Label: External - Ubuntu 22.04 LTS AMD64 Main Updates for Uyuni Repository URL: http://archive.ubuntu.com/ubuntu/dists/jammy-updates/main/binary-amd64/ Repository Type: deb

According to patch database:: "http://security.ubuntu.com/ubuntu/pool/main/l/linux-signed/linux-image-5.15.0-92-generic_5.15.0-92.102_amd64.deb": { "md5": "a17ecf23c9b103d08c5467380dceaa7c", "size": 11459044 }

package size/md5sum matches in Uyuni, but still no patch associate with that package !!

cFabij commented 5 months ago

I updated to 2024.3 yesterday and since today at around 4 am 38 patches are shown as applicable for my old, not updated Ubuntu 20.04 machine.

mcalmer commented 3 months ago

I think this is fixed. Remember not all updates are security updates and have an USN.

sorquan commented 3 months ago

Fixed after i removed all OS repos and recreated it again.