Client Package List updating problems with Ubuntu 20.04 and Uyuni
After those changes you suggested for changing the machine-id of cloned
VMs and enabling the repo signing, we’ve now added a few servers as
clients, gone through two package patching cycles, and have noticed that
the package list for at least some clients doesn’t appear to be updating.
I currently have nine Ubuntu 20.04 clients registered with Uyuni. Two show
outstanding package updates (even though they’ve been updated from the
client side with apt-get upgrade) and apt-get upgrade command shows no
outstanding patches. Some of the others show no outstanding
upgrades/patches from the Uyuni client pages, but an apt-get upgrade shows
multiple outstanding packages.
The clients appear to be updating some info though. None show up in the
Inactive systems list, and the last reboot parameter appears to be updated.
For the two where Uyuni shows updatable packages and apt reports none, the
UUID in the System Info is the same for both systems. However since the Web
UI reference documentation doesn’t say much about the UUID field (beyond
“The universally unique identifier”) it’s hard to tell if that’s an
internal Uyuni number, or something like the machine-id that hasn’t been
properly updated .
I tried looking at the possibly relevant Troubleshooting guides but didn’t
find anything that appeared relevant.
/var/log/rhn/rhn_taskomatic_daemon.log has some 401 and 403 errors that
appear to be for the SLES for SAP product/channels that we haven’t started
using yet. mgr-sync list credentials reports a primary credentials entry
but there’s this error in the taskomatic log file
2021-02-01 00:26:08,950 [DefaultQuartzScheduler_Worker-12] WARN
com.redhat.rhn.manager.content.ContentSyncManager - Error reading UUID:
/etc/zypp/credentials.d/SCCcredentials (No such file or directory)
While I don’t think that ‘s relevant to the Ubuntu package list, it’s
something I’ll have to figure out fairly soon.
Cheers,
Paul-Andre
*From:* Paul-Andre Panon
Hi Paul-Andre,
In my case the servers are registered by using the Salt ssh-push method (no salt-minion though) and unfortunately when you patch a server, package information is not getting refreshed into the GUI.
I opened an issue last year regarding this: https://github.com/uyuni-project/uyuni/issues/1938
This is not really a bug, but rather a missing feature:
“On .deb operating systems, this is unfortunately expected since we do have zyppnotify and yumnotify but there is no debnotify notifier beacon yet. Writing one is in our backlog.”
Regarding yumnotify, it not seems to work in my case as CentOS packages status is not refreshed after a patch in the GUI.
The only workaround I have found is to force a package refresh via system_schedulepackagerefresh api call of all the registered servers every night with this cron script:
# We begin to clear the cache to be sure to have an updated list
spacecmd -q -- clear_caches
# We now loop over all the systems and force a refresh
for i in `spacecmd -q -- system_list | awk '{print $1}'`; do
spacecmd -q -- system_schedulepackagerefresh $i
sleep 30
done
The Uyuni proxies and registered Suse/OpenSuse servers can be removed from the loop as not being affecting by this package refresh issue.
Hope this help !
Regards,
Philippe.
Philippe Bidault | Unix Engineer | Getronics
________________________________
M. 34617301667 | E. Philippe.Bidault@Getronics.com | W. www.getronics.comhttps://www.getronics.com
Getronics CMC Service Desk Iberia S.L - VAT No:S.L.: B66686262.
Registered Office - Getronics CMC Service Desk Iberia S.L, C/Rosselloi, Porcel, 21 planta 11, 08016 Barcelona, Spain.
The information transmitted is intended only for use by the addressee and may contain confidential and/or privileged material. Any review, re-transmission, dissemination or other use of it, or the taking of any action in reliance upon this information by persons and/or entities other than the intended recipient is prohibited. If you received this in error, please inform the sender and/or addressee immediately and delete the material. Thank you.
Legal disclaimer: http://www.getronics.com/legal/
From: Paul-Andre Panon
Hi Paul,
please check, if the package list of a client gets updated if you run a high state on the clients.
client:$ salt-call -l info state.apply
This should call the highstate. Please check after some minutes on uyuni to give it time to run its background tasks.
Because I had such issues in another project, where we recognized, that no salt states have been applied on the clients automatically on a regular basis, I created a "pillar" for all clients and defined a scheduler to run a highstate every 60 minutes.
So in case you have configuration settings on salt, that those also get applied on a regular basis.
Hope this helps.
Robert
sent from my mobile device
-------- Originale Nachricht --------
Von: Paul-Andre Panon
On 5/20/21 8:31 AM, Bidault, Philippe wrote:
Hi Paul-Andre,
In my case the servers are registered by using the Salt ssh-push method (no salt-minion though) and unfortunately when you patch a server, package information is not getting refreshed into the GUI.
I opened an issue last year regarding this: https://github.com/uyuni-project/uyuni/issues/1938 https://github.com/uyuni-project/uyuni/issues/1938
This is not really a bug, but rather a missing feature:
“On .deb operating systems, this is unfortunately expected since we do have |zyppnotify| and |yumnotify| but there is no |debnotify| notifier beacon yet. Writing one is in our backlog.”
Hey Bidault, This missing feature should be present in next UYUNI release, since it is laready implemented [0] However, ubuntu/deb machines need to run reactivation key[1] [0] https://github.com/uyuni-project/uyuni/pull/3489 [1] https://www.uyuni-project.org/uyuni-docs/uyuni/client-configuration/activati... Cheers, -- Ricard Mateus SUSE Manager Development Team
Hello Robert, Phillipe, and Ricardo,
No, Robert, forcing the high state update didn't refresh the package list.
Phillipe's script did work however, so I'll be queuing that to run
periodically while waiting for the PR mentioned by Ricardo to make it into
the
next release. Thanks for fixing this Ricardo!
Cheers,
Paul-Andre Panon
-----Original Message-----
From: Ricardo Mateus
Hi Paul-Andre,
In my case the servers are registered by using the Salt ssh-push method (no salt-minion though) and unfortunately when you patch a server, package information is not getting refreshed into the GUI.
I opened an issue last year regarding this: https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_uyuni- 2Dproject_uyuni_issues_1938&d=DwIGaQ&c=q3cDpHe1hF8lXU5EFjNM_A&r=2sQoWE McncSKL5kWoc_nrZbhUyhuj8tJfA91_lDSglQ&m=fQOWvl2WpCEteEbOm-3BKDEvkrTcKo IdQ6heNwXBauM&s=9CBx1mIiEBVqx-WTl88dbylASAlsEzxlw_D0v6hdtP8&e= <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_uyuni -2Dproject_uyuni_issues_1938&d=DwIGaQ&c=q3cDpHe1hF8lXU5EFjNM_A&r=2sQoW EMcncSKL5kWoc_nrZbhUyhuj8tJfA91_lDSglQ&m=fQOWvl2WpCEteEbOm-3BKDEvkrTcK oIdQ6heNwXBauM&s=9CBx1mIiEBVqx-WTl88dbylASAlsEzxlw_D0v6hdtP8&e= >
This is not really a bug, but rather a missing feature:
“On .deb operating systems, this is unfortunately expected since we do have |zyppnotify| and |yumnotify| but there is no |debnotify| notifier beacon yet. Writing one is in our backlog.”
Hey Bidault, This missing feature should be present in next UYUNI release, since it is laready implemented [0] However, ubuntu/deb machines need to run reactivation key[1] [0] https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_uyuni-2Dproject_uyuni_pull_3489&d=DwIGaQ&c=q3cDpHe1hF8lXU5EFjNM_A&r=2sQoWEMcncSKL5kWoc_nrZbhUyhuj8tJfA91_lDSglQ&m=fQOWvl2WpCEteEbOm-3BKDEvkrTcKoIdQ6heNwXBauM&s=TIqX5_UeyUJNzvO0n8bXKbFf4d6kpT9TK3Cc3QUtutY&e= [1] https://urldefense.proofpoint.com/v2/url?u=https-3A__www.uyuni-2Dproject.org_uyuni-2Ddocs_uyuni_client-2Dconfiguration_activation-2Dkeys.html-23-5Freactivation-5Fkeys&d=DwIGaQ&c=q3cDpHe1hF8lXU5EFjNM_A&r=2sQoWEMcncSKL5kWoc_nrZbhUyhuj8tJfA91_lDSglQ&m=fQOWvl2WpCEteEbOm-3BKDEvkrTcKoIdQ6heNwXBauM&s=sZnvywMBodkWhI6vlsDMCEtNUEw4hSFN613T55xsm-A&e= Cheers, -- Ricard Mateus SUSE Manager Development Team -- *For more information on how and why we collect your personal information, please visit our Privacy Policy https://www.motorolasolutions.com/en_us/about/privacy-policy.html?elqTrackId=8980d888905940e39a2613a7a3dcb0a7&elqaid=2786&elqat=2#privacystatement.*
participants (4)
-
Bidault, Philippe
-
Paul-Andre Panon
-
Ricardo Mateus
-
Robert Paschedag