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
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
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
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
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]
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]
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
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
Alright, I am closer to getting Uyuni set up the way we want it. Now, how can we get our servers that are registered to update through Uyuni? I was only given a option to schedule the update, so I picked as soon as possible, but they are all waiting and I do not know why:
[cid:image001.png@01D85422.7C84AA40]
Jamen McGranahan
Associate Director of Library Technology & Digital Services
Jean and Alexander Heard Libraries, Vanderbilt University
615-343-1614 | jamen.mcgranahan(a)vanderbilt.edu<mailto:jamen.mcgranahan@vanderbilt.edu>
he/his/him
[cid:image002.png@01D85422.7C84AA40]