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
Gesendet: Thu May 20 09:05:57 GMT+02:00 2021
An: users@lists.uyuni-project.org
Betreff: 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
*Sent:* Tuesday, January 26, 2021 4:02 PM
*To:* 'Pau Garcia' ; 'users@lists.uyuni-project.org' <
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.net forum.
*From:* Pau Garcia
*Sent:* Tuesday, January 26, 2021 1:18 AM
*To:* Paul-Andre Panon ;
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 Documentation
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=
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.org
Thank you
Pau Garcia Quiles
SUSE Manager Product Owner & Technical Project Manager
SUSE Software Solutions Spain
------------------------------
*From:* Paul-Andre Panon
*Sent:* Tuesday, January 26, 2021 8:30 AM
*To:* 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
*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 Policy
https://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 Policy
https://www.motorolasolutions.com/en_us/about/privacy-policy.html?elqTrackId=8980d888905940e39a2613a7a3dcb0a7&elqaid=2786&elqat=2#privacystatement.*