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 Sent: 20 May 2021 09:06 To: users@lists.uyuni-project.org Subject: Client Package List updating problems with Ubuntu 20.04 and Uyuni CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. 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 mailto:paul-andre.panon@avigilon.com> Sent: Tuesday, January 26, 2021 4:02 PM To: 'Pau Garcia' mailto:pau.garcia@suse.com>; 'users@lists.uyuni-project.orgmailto:users@lists.uyuni-project.org' mailto:users@lists.uyuni-project.org> Subject: RE: Registration problems with Ubuntu 20.04 and Uyuni Well, it’s a definite improvement. I’ve rolled that into the template customization scripts and I can now see more than 1 system registered. Thank you. I’m now seeing a different problem. W: Failed to fetch https://myuniserver.mydomain:443/rhn/manager/download/dists/ubuntu-2004-amd6... Undetermined Error [IP: AA.BB.CC.DD 443] If I try to go to that URL from a browser, I get You need a token to access /manager/download/ubuntu-2004-amd64-main-security-uyuni/repodata/InRelease The only reference I’ve found in google for that appears to be in Spanish and CentOS related on a capa9.nethttp://capa9.net forum. From: Pau Garcia mailto:pau.garcia@suse.com> Sent: Tuesday, January 26, 2021 1:18 AM To: Paul-Andre Panon mailto:paul-andre.panon@avigilon.com>; users@lists.uyuni-project.orgmailto:users@lists.uyuni-project.org Subject: Re: Registration problems with Ubuntu 20.04 and Uyuni Hello Have you checked this? https://www.uyuni-project.org/uyuni-docs/uyuni/administration/tshoot-registe...https://urldefense.proofpoint.com/v2/url?u=https-3A__www.uyuni-2Dproject.org_uyuni-2Ddocs_uyuni_administration_tshoot-2Dregisterclones.html&d=DwMF-g&c=q3cDpHe1hF8lXU5EFjNM_A&r=2sQoWEMcncSKL5kWoc_nrZbhUyhuj8tJfA91_lDSglQ&m=1eukOzzSEjOtVn2k1EHN31r5jyNgS5MGJsmhyH8zORk&s=f_jplxDISPWHgOxPvgeHoTERl7TEsIFO6RV6bBD8GIU&e= Troubleshooting Registering Cloned Clients :: Uyuni Documentationhttps://urldefense.proofpoint.com/v2/url?u=https-3A__www.uyuni-2Dproject.org_uyuni-2Ddocs_uyuni_administration_tshoot-2Dregisterclones.html&d=DwMF-g&c=q3cDpHe1hF8lXU5EFjNM_A&r=2sQoWEMcncSKL5kWoc_nrZbhUyhuj8tJfA91_lDSglQ&m=1eukOzzSEjOtVn2k1EHN31r5jyNgS5MGJsmhyH8zORk&s=f_jplxDISPWHgOxPvgeHoTERl7TEsIFO6RV6bBD8GIU&e= If you are using Uyuni to manage virtual machines, you might find it useful to create clones of your VMs. A clone is a VM that uses a primary disk that is an exact copy of an existing disk. www.uyuni-project.orghttp://www.uyuni-project.org Thank you Pau Garcia Quiles SUSE Manager Product Owner & Technical Project Manager SUSE Software Solutions Spain ________________________________ From: Paul-Andre Panon mailto:paul-andre.panon@avigilon.com> Sent: Tuesday, January 26, 2021 8:30 AM To: users@lists.uyuni-project.orgmailto:users@lists.uyuni-project.org mailto:users@lists.uyuni-project.org> Subject: Registration problems with Ubuntu 20.04 and Uyuni Hi, I’m trying to set up an Uyuni server to replace a Spacewalk server, starting with setting up support for Ubuntu 20.04. Ideally we would like to be able to use a vSphere VM template that we can use to generate/clone new VMs, and then run a script on that new VM to customize it with the specific desired hostname, AD domain registration, and Uyuni registration. For the Uyuni registration, I started with the generated bootstrap script and customized it with an Activation Key and the Ubuntu GPG keys (ubuntu-gpg-pubkey-871920D1991BC93C.key,uyuni-gpg-pubkey-0d20833e.key) . The registration script appears to work. If I look in Uyuni’s Salt->Keys page, I see the key, can approve it and the system shows up in the system list…. the first time. On subsequent VMs however, I see the key in the Salt->Keys page, can approve them, and then after some time I only see one of the two VMs in the system list, usually the last one added. While setting up the Uyuni server and VM template, it took me a while to figure out I was supposed to use the modified bootstrap script, so I had first tried to install salt packages on the template and thought that might be the problem. I took a hint from the bootstrap script and tried to run apt-get purge salt-minion apt-get purge salt-common rm -rf /etc/salt/minion.d/ on the template to clear any salt state, cleared systems and keys on the Uyuni server, and started over creating new VMs,… with the same result. Any suggestions on what could be going wrong? Thanks, Paul-Andre Panon, B.Sc. Senior Systems Administrator Video Security & Analytics [https://www.motorolasolutions.com/content/dam/msi/images/logos/corporate/msi...] o: +1.604.629.5182 ext 2190 m: +1.604.787.4547 For more information on how and why we collect your personal information, please visit our Privacy Policyhttps://www.motorolasolutions.com/en_us/about/privacy-policy.html?elqTrackId=8980d888905940e39a2613a7a3dcb0a7&elqaid=2786&elqat=2#privacystatement. For more information on how and why we collect your personal information, please visit our Privacy Policyhttps://www.motorolasolutions.com/en_us/about/privacy-policy.html?elqTrackId=8980d888905940e39a2613a7a3dcb0a7&elqaid=2786&elqat=2#privacystatement.