- ARCHIVED: Uyuni Users

Uyuni support for Ubuntu 22.04?
by Paul-Andre Panon 13 Jun '22

13 Jun '22

Hi, Any idea when we can expect Uyuni client packages for Ubuntu 22.04? Has there been sufficiently few changes to the apt interfaces that the Ubuntu 20.04 packages can still be used? Thanks, Paul-Andre

4 5

lldp information within uyuni
by Heiner Wulfhorst 28 May '22

28 May '22

Dear uyuni users, how do you query uyuni-managed systems for lldp information like connected switch/ports, etc? We are about to install a bunch of bare-metal server systems and would like to ensure all cabling is correct / as expected. Currently uyuni does not show any information about which network interface is connected to which switch interface. Is there any option to get it into uyuni GUI? Or can someone recommend any salt code for querying it? BR Heiner

2 1

Uyuni 2022.05 is released!
by Julio Gonzalez 10 May '22

10 May '22

IMPORTANT NOTE: The release is done, but it seems OpenBuildService is a bit overloaded now, so we recommend waiting at least a few hours before applying the update, to give more time for the mirrors to sync We are happy to announce the immediate availability of Uyuni 2022.05 At https://www.uyuni-project.org/pages/stable-version.html you will find all the resources you need to start working with Uyuni 2022.05, including the release notes, documentation, requirements and setup instructions. VERY IMPORTANT: Always read the release notes! If you are updating from an Uyuni version older than 2021.06, a major upgrade procedure is required. This is the list of highlights for this release: * Reporting Database documentation * spacewalk-report now uses data from the reporting database * Adding systems with failed actions to System Set Manager * Technology Preview: JSON over HTTP API Remember that Uyuni will follow a rolling release planning, so the next version will contain bugfixes for this one and any new features. There will be no maintenance of 2022.05 As always, we hope you will enjoy Uyuni 2022.05 and we invite everyone of you to send us your feedback [1] and of course your patches, if you can contribute. Happy hacking! [1] https://www.uyuni-project.org/pages/contact.html -- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez(a)suse.com

1 0

Taskomatic errors since 2022.4
by Simon Avery 10 May '22

10 May '22

Hi I've been seeing email warnings since upgrading to Uyuni latest over the past couple of weeks. Taskomatic bunch update-payg-data-bunch was scheduled to run within the update-payg-default schedule. Subtask update-payg-hosts failed. For more information check null. And then ten minutes later, at the next run, a second email with Subtask update-payg-hosts finished successfully and is back to normal. These occur every day or two, always early in the morning (0130 or 0220), and there have been some other taskomatic emails referencing things other than payg-hosts. Prior to this version, I'd only ever see these emails for repo errors. rhn_taskomatic_daemon.log has a few entries like * 2022-04-03 16:20:00,562 [Thread-6531] ERROR com.redhat.rhn.taskomatic.task.payg.PaygUpdateHostsTask - p11-kit: couldn't create symlink: /var/lib/ca-certificates/openssl/dbc54cab.0: File exists * 2022-05-10 02:10:00,996 [DefaultQuartzScheduler_Worker-3] ERROR com.redhat.rhn.taskomatic.task.payg.PaygUpdateHostsTask - Message: Command '[/usr/share/rhn/certs/update-ca-cert-trust.sh]' exited with error code 1: p11-kit: couldn't complete writing of file: /var/lib/ca-certificates/ca-bundle.pem.tmp: File exists The first file exists when I check, the second does not. If I run /usr/share/rhn/certs/update-ca-cert-trust.sh manually, it completes without error. It's like the same task is being run twice concurrently but I don't know how to check; there's no duplicates in Uyuni -> Admin -> Task schedules. Obviously not a major issue as it's apparently self-healing, but I don't want to get into the habit of ignoring emails from Uyuni so would like to get to the bottom of it. Any ideas? Simon Avery Linux Systems Administrator: ATASS Sports Oxygen House | Grenadier Road, Exeter Business Park | EX1 3LH t: 01392 440 400 e: simon.avery(a)atass-sports.co.uk<mailto:simon.avery@atass-sports.co.uk> www.atass-sports.co.uk<https://gbr01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.atass-…> Follow us on Twitter: @atassSports<https://twitter.com/atassSports> NOTICE This email and any attachments confidential and intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient be advised that you have received this email in error and that any use, dissemination, forwarding, printing or copying of this email is strictly prohibited. Please notify the sender immediately. ATASS Ltd is incorporated in England and Wales with company number 04807405. See our website for further details and our privacy policy

3 3

Odd error
by McGranahan, Jamen (VU) 10 May '22

10 May '22

Good afternoon - On our Centos 7 servers, I am seeing the following errors when trying to update packages: saltutil_|-sync_states_|-sync_states_|-sync_states: name: sync_states changes: { } result: true comment: No updates to sync __sls__: util.syncstates __run_num__: 0.0 start_time: '14:49:31.179203' duration: 214.441 __id__: sync_states file_|-mgrchannels_susemanagerplugin_yum_|-/usr/share/yum-plugins/susemanagerplugin.py_|-managed: changes: { } comment: File /usr/share/yum-plugins/susemanagerplugin.py is in the correct state name: /usr/share/yum-plugins/susemanagerplugin.py result: true __sls__: channels __run_num__: 1.0 start_time: '14:49:31.405372' duration: 139.592 __id__: mgrchannels_susemanagerplugin_yum file_|-mgrchannels_susemanagerplugin_conf_yum_|-/etc/yum/pluginconf.d/susemanagerplugin.conf_|-managed: changes: { } comment: File /etc/yum/pluginconf.d/susemanagerplugin.conf is in the correct state name: /etc/yum/pluginconf.d/susemanagerplugin.conf result: true __sls__: channels __run_num__: 2.0 start_time: '14:49:31.545144' duration: 35.11 __id__: mgrchannels_susemanagerplugin_conf_yum file_|-mgrchannels_enable_yum_plugins_|-/etc/yum.conf_|-replace: result: true name: /etc/yum.conf changes: { } comment: onlyif condition is false skip_watch: true __sls__: channels __run_num__: 3.0 start_time: '14:49:31.580457' duration: 6319.884 __id__: mgrchannels_enable_yum_plugins file_|-mgrchannels_repo_|-/etc/yum.repos.d/susemanager:channels.repo_|-managed: changes: { } comment: File /etc/yum.repos.d/susemanager:channels.repo is in the correct state name: /etc/yum.repos.d/susemanager:channels.repo result: true __sls__: channels __run_num__: 4.0 start_time: '14:49:37.901468' duration: 72.448 __id__: mgrchannels_repo cmd_|-mgrchannels_yum_clean_all_|-/usr/bin/yum clean all_|-run: changes: { } result: true duration: 0.003 start_time: '14:49:37.974496' comment: State was not run because none of the onchanges reqs changed __state_ran__: false __run_num__: 5.0 __sls__: channels cmd_|-trust_res_gpg_key_|-rpm --import https://opensuse.library.vanderbilt.edu:443/pub/res-gpg-pubkey-0182b964.key…: result: true name: rpm --import https://opensuse.library.vanderbilt.edu:443/pub/res-gpg-pubkey-0182b964.key changes: { } comment: unless condition is true skip_watch: true __sls__: channels __run_num__: 6.0 start_time: '14:49:37.974555' duration: 464.903 __id__: trust_res_gpg_key ? cmd_|-trust_suse_manager_tools_rhel_gpg_key_|-rpm --import https://opensuse.library.vanderbilt.edu:443/pub/sle12-gpg-pubkey-39db7c82.k… : result: true name: rpm --import https://opensuse.library.vanderbilt.edu:443/pub/sle12-gpg-pubkey-39db7c82.k… changes: { } comment: unless condition is true skip_watch: true __sls__: channels __run_num__: 7.0 start_time: '14:49:38.439839' duration: 171.767 __id__: trust_suse_manager_tools_rhel_gpg_key pkg_|-pkg_installed_|-pkg_installed_|-installed: name: pkg_installed changes: venv-salt-minion: old: - version: '3002.2' release: 45.1.uyuni arch: x86_64 install_date_time_t: 1.650462456E9 epoch: null new: - version: '3002.2' release: 48.1.uyuni arch: x86_64 install_date_time_t: 1.651521007E9 epoch: null python2-rhnlib: old: - version: 4.3.3 release: 3.1.uyuni arch: noarch install_date_time_t: 1.650389632E9 epoch: null new: - version: 4.3.4 release: 2.1.uyuni arch: noarch install_date_time_t: 1.651521E9 epoch: null python2-uyuni-common-libs: old: - version: 4.3.3 release: 3.1.uyuni arch: x86_64 install_date_time_t: 1.650389632E9 epoch: null new: - version: 4.3.4 release: 2.1.uyuni arch: x86_64 install_date_time_t: 1.651521E9 epoch: null result: false comment: |- The following packages failed to install/update: grub2-common=1:2.02-0.87.el7.centos.7, grub2=1:2.02-0.87.el7.centos.7, grub2-pc-modules=1:2.02-0.87.el7.centos.7, grub2-tools-minimal=1:2.02-0.87.el7.centos.7, grub2-pc=1:2.02-0.87.el7.centos.7, grub2-tools=1:2.02-0.87.el7.centos.7, grub2-tools-extra=1:2.02-0.87.el7.centos.7 3 targeted packages were installed/updated. __sls__: packages.pkginstall __run_num__: 8.0 start_time: '14:49:38.612594' duration: 129411.979 __id__: pkg_installed Packages Scheduled: * venv-salt-minion-3002.2-48.1.uyuni.x86_64 * grub2-common-2.02-0.87.el7.centos.7:1.noarch * grub2-2.02-0.87.el7.centos.7:1.x86_64 * grub2-pc-modules-2.02-0.87.el7.centos.7:1.noarch * python2-rhnlib-4.3.4-2.1.uyuni.noarch * grub2-tools-minimal-2.02-0.87.el7.centos.7:1.x86_64 * grub2-pc-2.02-0.87.el7.centos.7:1.x86_64 * grub2-tools-2.02-0.87.el7.centos.7:1.x86_64 * python2-uyuni-common-libs-4.3.4-2.1.uyuni.x86_64 * grub2-tools-extra-2.02-0.87.el7.centos.7:1.x86_64 [Vanderbilt] Jamen McGranahan Associate Director of Library Technology & Digital Services, Vanderbilt Library Vanderbilt University 615.343.1614 | jamen.mcgranahan(a)vanderbilt.edu<mailto:jamen.mcgranahan@vanderbilt.edu> | https://www.library.vanderbilt.edu/ Central Library, 419 21st Avenue South Nashville, TN 37203 Pronouns: he/him/his [cid:image002.png@01D85EF2.E3A00000]

2 1

venv-salt-minion failing to install as part of bootstrap script
by Paul-Andre Panon 09 May '22

09 May '22

Hi, We're trying to bootstrap an ubuntu 20.04 server with the same bootstrap script that we've used on many other servers. However on this server the package install is failing in the post-install script. ... FINISHED --2022-05-06 19:08:52-- Total wall clock time: 0.007s Downloaded: 1 files, 1.1K in 0s (223 MB/s) Reading package lists... Done Building dependency tree Reading state information... Done gnupg is already the newest version (2.2.19-3ubuntu2.1). 0 upgraded, 0 newly installed, 0 to remove and 6 not upgraded. 1 not fully installed or removed. After this operation, 0 B of additional disk space will be used. Setting up venv-salt-minion (3002.2-47.3.uyuni) ... dpkg: error processing package venv-salt-minion (--configure): installed venv-salt-minion package post-installation script subprocess returned error exit status 1 Errors were encountered while processing: venv-salt-minion E: Sub-process /usr/bin/dpkg returned an error code (1) OK ... Looks like it's trying to do something with dpkg so perhaps there's a missing or conflicting dependency. With Uyuni's cross-platform build, I haven't been able to figure out what that post-install script is to figure out what it might be trying to do. Any suggestions? Thanks, Paul-Andre

2 6

Salt ID continues to return
by McGranahan, Jamen (VU) 06 May '22

06 May '22

I've got an oddity that I am having trouble figuring out. One of our servers is not listed on the Uyuni web admin site, but there's a Salt ID for it. I've deleted it multiple times, but it keeps reappearing, even after rejecting it and deleting it. What I am trying to do is to remove any instance of this server from Uyuni and then re-add it - hoping that a clean install will take care of this issue. Ideas? [cid:image001.png@01D8606A.22AD1D00] [Vanderbilt] Jamen McGranahan Associate Director of Library Technology & Digital Services, Vanderbilt Library Vanderbilt University 615.343.1614 | jamen.mcgranahan(a)vanderbilt.edu<mailto:jamen.mcgranahan@vanderbilt.edu> | https://www.library.vanderbilt.edu/ Central Library, 419 21st Avenue South Nashville, TN 37203 Pronouns: he/him/his [cid:image003.png@01D8606A.22AD1D00]

4 6

grub2
by McGranahan, Jamen (VU) 05 May '22

05 May '22

Most of our CentOS 7 servers are reporting that grub2 package needs to be upgraded, but they all fail to upgrade, giving this error message: comment: |- The following packages failed to install/update: grub2-common=1:2.02-0.87.el7.centos.7, grub2=1:2.02-0.87.el7.centos.7, grub2-pc-modules=1:2.02-0.87.el7.centos.7, grub2-tools-minimal=1:2.02-0.87.el7.centos.7, grub2-pc=1:2.02-0.87.el7.centos.7, grub2-tools=1:2.02-0.87.el7.centos.7, grub2-tools-extra=1:2.02-0.87.el7.centos.7 (code 2) When I manually run yum update on these servers, I get "No packages marked for update". So why is Uyuni reporting that grub2 needs to be updated? [Vanderbilt] Jamen McGranahan Associate Director of Library Technology & Digital Services, Vanderbilt Library Vanderbilt University 615.343.1614 | jamen.mcgranahan(a)vanderbilt.edu<mailto:jamen.mcgranahan@vanderbilt.edu> | https://www.library.vanderbilt.edu/ Central Library, 419 21st Avenue South Nashville, TN 37203 Pronouns: he/him/his [cid:image002.png@01D86073.1C59C3A0]

2 4

SLES15_SAP SP3: Missing GPG Key for PackageHub-15-SP3-Backports // how to install nmon RPM
by Heiner Wulfhorst 03 May '22

03 May '22

Hi List, we would like to install nmon on our SLES15 SP3 SAP Systems, it can be obtained from SUSE-PackageHub-15-SP3-Backports-Pool repository. Problem: Uyuni Bootstrapping fails if we include it into autoyast.xml ("key ID 65176565: NOKEY"), because zypper tries to install python3-pycares-3.1.1-bp153.1.17.x86_64.rpm as a recommended package for salt: Retrieving: python3-pycares-3.1.1-bp153.1.17.x86_64.rpm [done] python3-pycares-3.1.1-bp153.1.17.x86_64.rpm: Header V3 RSA/SHA256 Signature, key ID 9c214d4065176565: NOKEY V3 RSA/SHA256 Signature, key ID 9c214d4065176565: NOKEY warning: /var/tmp/AP_0xAKTyvC/getPackage/NULL/42ce2ba338b2c092f38882d20e7c38f316a90a89d76d6f74235eb8f039da609d/python3-pycares-3.1.1-bp153.1.17.x86_64.rpm: Header V3 RSA/SHA256 Signature, key ID 65176565: NOKEY Looking for gpg key ID 65176565 in cache /var/cache/zypp/pubkeys. Repository sles15sp3-sap-sandbox PackageHub-15-SP3-Backports-Pool does not define additional 'gpgkey=' URLs. python3-pycares-3.1.1-bp153.1.17.x86_64 (sles15sp3-sap-sandbox PackageHub-15-SP3-Backports-Pool): Signature verification failed [4-Signatures public key is not available] Abort, retry, ignore? [a/r/i] (a): a Problem occurred during or after installation or removal of packages: Installation has been aborted as directed. Please see the above error message for a hint. no package provides salt ERROR: Failed to install all missing packages. Key Details: gpg-pubkey-65176565-5d94a381 gpg(openSUSE:Backports OBS Project <openSUSE:Backports@build.opensuse.org>): http://download.opensuse.org/distribution/leap/15.3/repo/oss/gpg-pubkey-651… - Why is that key missing? A Temporary bug? Or must i manually/explicitly add it in uyuni? - I do not like the idea of using backports within installation and keeping them enabled. Can someone recommend a better solution? How about autoyast w/o backport repos, adding them (disabled) using salt, then installing nmon using 'zypper --plus-content <reponame> install nmon'? Thanks, BR, Heiner

2 1

Uyuni 2022.04 is released!
by Julio Gonzalez 29 Apr '22

29 Apr '22

IMPORTANT NOTE: The release is done, but it seems OpenBuildService is a bit overloaded now, so we recommend waiting at least a few hours before applying the update, to give more time for the mirrors to sync We are happy to announce the immediate availability of Uyuni 2022.04 At https://www.uyuni-project.org/pages/stable-version.html you will find all the resources you need to start working with Uyuni 2022.04, including the release notes, documentation, requirements and setup instructions. VERY IMPORTANT: Always read the release notes! If you are updating from an Uyuni version older than 2021.06, a major upgrade procedure is required. This is the list of highlights for this release: * Salt SSH now uses the Salt Bundle * Technology Preview: Containerized Uyuni Proxy and Retail Branch Server * Reporting Database improvements * Improved image management * HSTS Enabled Remember that Uyuni will follow a rolling release planning, so the next version will contain bugfixes for this one and any new features. There will be no maintenance of 2022.04 As always, we hope you will enjoy Uyuni 2022.04 and we invite everyone of you to send us your feedback [1] and of course your patches, if you can contribute. Happy hacking! [1] https://www.uyuni-project.org/pages/contact.html -- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez(a)suse.com

1 0