- ARCHIVED: Uyuni Users

Uyuni 2022.10 is released!
by Julio Gonzalez 14 Oct '22

14 Oct '22

VERY IMPORTANT: 2022.10 requires special procedures for the upgrade from any previous version! Make sure you read the release notes for all the versions between the one you are using now, and 2022.10! We are happy to announce the availability of Uyuni 2022.10. Most openSUSE mirrors should already have 2022.10, but if you do not see it yet, wait a few hours until your local openSUSE mirror is synced. At https://www.uyuni-project.org/pages/stable-version.html you will find all the resources you need to start working with Uyuni 2022.10, including the release notes, documentation, requirements and setup instructions. This is the list of highlights for this release: - Special instructions for the update, make sure you read them! - RHEL/Oracle Linux/AlmaLinux/Rocky Linux 9 as clients - Monitoring for Ubuntu 22.04 - pip support for the Salt Bundle - Apache exporter updated to version 0.11.0 for SUSE Linux Enterprise and openSUSE - Cobbler updated to version 3.3.3 Remember that Uyuni follows 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.10 As always, we hope you will enjoy Uyuni 2022.10 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

CentOS 7 channel selection issue
by Paul-Andre Panon 12 Oct '22

12 Oct '22

Hi, I've been running into an issue with our CentOS 7 clients. We didn't have this problem before but seem to have it with recent client additions. When trying to change the base and child channels for a CentOS 7 system, the change fails and corrupts the client repo config file at /etc/yum.repos.d/susemanager:channels.repo. The gpgkey= lines somehow have the non-Uyuni repo signing keys still in there, with the Uyuni key on a separate line immediately after. For example [susemanager:centos7-x86_64] name=CentOS 7 (x86_64) enabled=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7 file:///etc/pki/rpm-gpg/mgr-gpg-pub.key baseurl=https://carmd-nv-uyuni1.sierrawireless.local:443/rhn/manager/download/centos7-x86_64 susemanager_token=eyJhbGciOiJIUzI1NiJ9.eyJleHAiOjE2OTUyNDgzNzEsImlhdCI6MTY2MzcxMjM3MSwibmJmIjoxNjYzNzEyMjUxLCJqdGkiOiI0UkhWYWUzU0VnTngwRk1yaXFsWG13Iiwib3JnIjoxLCJvbmx5Q2hhbm5lbHMiOlsiY2VudG9zNy14ODZfNjQiXX0.EoqL2bHAZ4li3FGsXuatKny5BU0qJ1aDbdJifTD_Gkw gpgcheck=1 repo_gpgcheck=1 type=rpm-md Instead that gpgkey line should just look like gpgkey=file:///etc/pki/rpm-gpg/mgr-gpg-pub.key It currently only seems to happen with the CentOS 7 clients. Is this a bug in a recent CentOS client update, or a database issue? Cheers, Paul-Andre Panon

2 3

SSO redirect not happening
by Georg Pfuetzenreuter 29 Sep '22

29 Sep '22

Hello, I read the document https://www.uyuni-project.org/uyuni-docs/en/uyuni/administration/auth-metho…, configured the following additional properties in /etc/rhn/rhn.conf and executed `spacewalk-service restart`: ``` ### custom java.sso = true java.sso.onelogin.saml2.sp.entityid = https://uyuni.example.com/rhn/manager/sso/metadata java.sso.onelogin.saml2.sp.assertion_consumer_service.url = https://uyuni.example.com/rhn/manager/sso/acs java.sso.onelogin.saml2.sp.single_logout_service.url = https://uyuni.example.com/rhn/manager/sso/sls java.sso.onelogin.saml2.idp.x509cert = -----BEGIN CERTIFICATE-----\n<redacted>\n-----END CERTIFICATE----- java.sso.onelogin.saml2.idp.single_sign_on_service.url = https://sso.example.com/realms/dev/protocol/saml java.sso.onelogin.saml2.idp.entityid = https://uyuni.example.com/rhn/manager/sso/metadata java.sso.onelogin.saml2.idp.single_logout_service.url = https://sso.example.com/realms/dev/protocol/saml ``` The linked documentation states "When you visit the Uyuni URL, you are redirected to the IdP for SSO where you are requested to authenticate.", but this does not seem to be the case on my end - opening web UI presents me with the regular/local login page - no redirect to my IDP is happening. The system journal does not seem to show anything "new" either. Any ideas on what I am missing? This is a fresh stable installation. Thanks for reading! Georg

2 2

Permissions for approving salt keys
by Paul-Andre Panon 13 Sep '22

13 Sep '22

Hi, Is it only possible to approve salt keys with Organization or Uyuni administrator privileges? Or is it possible to delegate those permissions somehow without implicitly giving activation key, configuration, Image, and channel permissions as well? It would be good if the administrators of default system groups for activation keys could somehow approve the salt keys for systems added with a bootstrap script using those keys. Salt key approval is most closely associated with the system group administration use cases. Cheers, Paul-Andre Panon

1 0

editing ansible playbooks and inventories
by 4thomasmueller＠gmail.com 12 Sep '22

12 Sep '22

Hi, it would be nice if the playbooks and hostlists can edited/written directly via uyuni GUI (like SALT states). Does anybody know if this is planned for future releases? Thanks, Thomas

2 1

"No job return event was received." (code -1)
by Martin 11 Sep '22

11 Sep '22

Hello list Since some days, all zypper jobs to my openSuSE Clients ends up with "No job return event was received." (code -1). The patches are installes successfully on the clients as shown in /var/log/zypp/history, but uyuni still shows the same number of avaliable patches. When I start a Package List Refresh - it ends up with the same error: Systemverlaufsereignisse Zusammenfassung: Package List Refresh geplant von admin Einzelheiten: Diese Aktion wird ausgeführt nach 08.09.22 12:06:45 MESZ Der Status dieser Aktion ist: Fehlgeschlagen. Der Client hat diese Aktion abgeschlossen am 09.09.22 00:00:51 MESZ Client-Ausführung meldet "No job return event was received." (code -1) Zeit: 08.09.22 12:06:45 MESZ Neu einplanen: Dieses Verlaufsereignis wurde durch eine fehlgeschlagene geplante Aktion verursacht. Falls Sie das Problem behoben haben, können Sie die Aktion unten erneut planen. I use Unyuni Release 2022.08 Best regards Martin

1 0

AW: AW: RE: Subtask mgr-update-reporting failed.
by Crefeld, Tobias LKV Bayern e.V. 08 Sep '22

08 Sep '22

Hi, meanwhile I updated Uyuni from 2022.06 to 2022.08 and since then patching of (salt) clients works again after some manual resynchronisations. Now most of the Taskomatic jobs get executed successfully again. The Taskomatic job mgr-update-reporting-bunch still fails with similar log messages as before. Another job “minion-action-executor-bunch” that failed can’t be found on the Task Schedules list. Systems with the Contact Method “Push via SSH” still cannot check in. Trying to remove a ssh-client was successful. Trying to re-register the client by the bootstrap dialogue fails with the message “Error: Unable to download https://lkv-srvapp39.lkvbay.net:443/pub/repositories/opensuse/15/1/bootstra… file!” Actually this file doesn’t exist but we never changed the respective repositories manually so we don’t know why the same task worked before. I found a job “ssh-push” with the status “SKIPPED”. The log message is “com.redhat.rhn.taskomatic.task.SSHPush - Maximum number of workers already put ... skipping.” BTW: Returning to latest Uyuni-version before the upgrade to 2022.06 wasn’t successful, too. Seems to be related to different salt versions. Regards, Tobias Crefeld. Von: David Mace [mailto:david@macemail.co.uk] Gesendet: Dienstag, 16. August 2022 11:42 "BTW: Meanwhile the number of Taskomatic jobs that fail is increasing and since 3 days Uyuni stopped to check patch and config status of its clients" Since the update taskomatic also just crashes every 10 seconds for me <https://github.com/uyuni-project/uyuni/issues/5556> https://github.com/uyuni-project/uyuni/issues/5556 -----Original Message----- From: "Crefeld, Tobias LKV Bayern e.V." < <mailto:%22Crefeld,%20Tobias%20LKV%20Bayern%20e.V.%22%20%3cTobias.Crefeld@lkv.bayern.de%3e> Tobias.Crefeld(a)lkv.bayern.de> Reply-To: General discussion related to the openSUSE Uyuni project < <mailto:General%20discussion%20related%20to%20the%20openSUSE%20Uyuni%20project%20%3cusers@lists.uyuni-project.org%3e> users(a)lists.uyuni-project.org> To: 'Paul-Andre Panon via Uyuni Users' < <mailto:'Paul-Andre%20Panon%20via%20Uyuni%20Users'%20%3cusers(a)lists.uyuni-project.org%3e> users(a)lists.uyuni-project.org> Subject: AW: RE: Subtask mgr-update-reporting failed. Date: Tue, 16 Aug 2022 09:11:27 +0000 Hi Robert, "ping lkv-srvapp39" and "host lkv-srvapp39" work as expected. A request with psql works fine, too: uyuni@lkv-srvapp39:~> psql -h lkv-srvapp39 Passwort für Benutzer uyuni: psql (14.3) SSL-Verbindung (Protokoll: TLSv1.3, Verschlüsselungsmethode: TLS_AES_256_GCM_SHA384, Bits: 256, Komprimierung: aus) Geben Sie »help« für Hilfe ein. uyuni=# How can I add the short name to the "TLS SAN"? Where can I configure the host name the application is using? I don't know if It is important, but according to the status of systemctl Uyuni's applications connect to the DB-server via 127.0.0.1 which resolves to localhost: lkv-srvapp39:/var/lib/pgsql/data # systemctl status postgresql ● postgresql.service - PostgreSQL database server Loaded: loaded (/usr/lib/systemd/system/postgresql.service; enabled; vendor preset: disabled) Active: active (running) since Tue 2022-08-02 10:41:35 CEST; 2 weeks 0 days ago Process: 2357 ExecStart=/usr/share/postgresql/postgresql-script start (code=exited, status=0/SUCCESS) Main PID: 2388 (postgres) Tasks: 43 (limit: 4915) CGroup: /system.slice/postgresql.service ├─ 828 "postgres: uyuni uyuni 127.0.0.1(49822) idle" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─ 829 "postgres: uyuni uyuni 127.0.0.1(49824) idle" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─ 830 "postgres: uyuni uyuni 127.0.0.1(49826) idle" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─ 2388 /usr/lib/postgresql14/bin/postgres -D /var/lib/pgsql/data ├─ 2430 "postgres: logger " "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ""> ├─ 2445 "postgres: checkpointer " "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─ 2446 "postgres: background writer " "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─ 2447 "postgres: walwriter " "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─ 2448 "postgres: autovacuum launcher " "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─ 2451 "postgres: archiver last was 00000001000000CD000000B0" "" "" "" "" "" ├─ 2452 "postgres: stats collector " "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─ 2453 "postgres: logical replication launcher " "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─ 2926 "postgres: uyuni uyuni ::1(39194) idle" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─ 4397 "postgres: uyuni uyuni 127.0.0.1(48680) idle in transaction" ├─ 4403 "postgres: uyuni uyuni 127.0.0.1(48688) idle in transaction" ├─ 4472 "postgres: uyuni uyuni 127.0.0.1(48692) idle" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─ 5145 "postgres: uyuni uyuni 127.0.0.1(48694) idle" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─ 5146 "postgres: uyuni uyuni 127.0.0.1(48696) idle" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─ 5147 "postgres: uyuni uyuni 127.0.0.1(48700) idle" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─ 5148 "postgres: uyuni uyuni 127.0.0.1(48702) idle" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─ 5149 "postgres: uyuni uyuni 127.0.0.1(48704) idle" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─ 5150 "postgres: uyuni uyuni 127.0.0.1(48706) idle" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─ 5151 "postgres: uyuni uyuni 127.0.0.1(48708) idle" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─ 5152 "postgres: uyuni uyuni 127.0.0.1(48710) idle" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─ 5153 "postgres: uyuni uyuni 127.0.0.1(48712) idle" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─ 5155 "postgres: uyuni uyuni 127.0.0.1(48714) idle" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─ 5156 "postgres: uyuni uyuni 127.0.0.1(48716) idle" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─ 5157 "postgres: uyuni uyuni 127.0.0.1(48718) idle" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─ 5159 "postgres: uyuni uyuni 127.0.0.1(48720) idle" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─ 5160 "postgres: uyuni uyuni 127.0.0.1(48722) idle" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─ 5161 "postgres: uyuni uyuni 127.0.0.1(48724) idle" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─ 5226 "postgres: uyuni uyuni 127.0.0.1(48740) idle" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─ 5227 "postgres: uyuni uyuni 127.0.0.1(48738) idle" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─ 5228 "postgres: uyuni uyuni 127.0.0.1(48736) idle" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─12183 "postgres: uyuni uyuni ::1(39198) idle in transaction" "" "" "" "" "" ├─17094 "postgres: uyuni uyuni 127.0.0.1(48018) idle in transaction" ├─18174 "postgres: uyuni uyuni 127.0.0.1(48204) idle" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─22694 "postgres: uyuni uyuni 127.0.0.1(50300) idle in transaction" ├─22915 "postgres: uyuni uyuni 127.0.0.1(48214) idle" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─25894 "postgres: uyuni uyuni 127.0.0.1(52958) idle" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─25895 "postgres: uyuni uyuni 127.0.0.1(52960) idle" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─26392 "postgres: uyuni uyuni 127.0.0.1(52962) idle" "" "" "" "" "" "" "" "" "" "" "" "" "" "" └─26670 "postgres: uyuni uyuni 127.0.0.1(48228) idle" "" "" "" "" "" "" "" "" "" "" "" "" "" "" Notice: journal has been rotated since unit was started, output may be incomplete. BTW: Meanwhile the number of Taskomatic jobs that fail is increasing and since 3 days Uyuni stopped to check patch and config status of its clients. Just as it happened to the ssh clients since the update of Uyuni. No configuration changes since last week. Maybe it's better to recover the system to a version before the update. Regards, Tobias. -----Ursprüngliche Nachricht----- Von: Robert Paschedag [mailto:robert.paschedag@web.de <mailto:robert.paschedag@web.de> ] org.postgresql.util.PSQLException: The hostname lkv-srvapp39 could not be verified by hostnameverifier PgjdbcHostnameVerifier. This sounds to me, that you configuration is using the "short" name to access PostgreSQL. Try from your server, if this is resolvable. Maybe you're missing a proper "search" DNS config option. If the internal connection to your PostgreSQL is TLS encrypted, then the short name also needs to be added to the TLS SAN (Subject Alternative Name) the PostgreSQL is running, of the default TLS verification options are used 1. As mentioned... Is a simple "ping lkv-srvapp39" resolvable from within your uyuni server? 2. Try to change the host setting that defines your PostgreSQL and change it to use the full FQDN. Robert

1 0

since update 2022.08 (probably earlier) error "The scheduling service appears down"
by Thomas Weis 08 Sep '22

08 Sep '22

Hello, everyone recently we upgraded from 2022.06 to Uyuni 2022.08 without any problems. It was noticed that there has been a task in Schdule, Pending Actions since 08/27/2022, which is not being processed. The task should be aborted using chancel Actions, but this was not possible. After marking the task and executing chancel actions, the error message "Could not cancel action. Please make sure that the task scheduler is running" appeared. No tasks/schedules are listed under "Uyuni Schedules" either. systemctl status taskomatic.service indicates that Taskomatic is active. There are regular messages in /var/log/messages: " WARNING: sun.reflect.Reflection.getCallerClass is not supported. This will impact performance. taskomatic.service: Main process exited, code=exited, status=255/EXCEPTION taskomatic.service: Failed with result 'exit-code'. taskomatic.service: Scheduled restart job, restart counter is at 1 /var/log/rhn/rhn_taskomatic_daemon.log shows: "2022-09-05 09:34:47,805 [Thread-41] WARN org.hibernate.orm.deprecation - HHH90000014: Found use of deprecated [org.hibernate.id.SequenceHiLoGenerator] sequence-based id generator; use org.hibernate .id.enhanced.SequenceStyleGenerator instead.See Hibernate Domain Model Mapping Guide for details. 2022-09-05 09:34:47,807 [Thread-41] WARN org.hibernate.orm.deprecation - HHH90000014: Found use of deprecated [org.hibernate.id.SequenceGenerator] sequence-based id generator; use org.hibernate.id.enhanced.SequenceStyleGenerator instead. See Hibernate Domain Model Mapping Guide for details. 2022-09-05 09:34:47,807 [Thread-41] WARN org.hibernate.orm.deprecation - HHH90000014: Found use of deprecated [org.hibernate.id.SequenceGenerator] sequence-based id generator; use org.hibernate.id.enhanced.SequenceStyleGenerator instead. See Hibernate Domain Model Mapping Guide for details. 2022-09-05 09:34:47,807 [Thread-41] WARN org.hibernate.orm.deprecation - HHH90000014: Found use of deprecated [org.hibernate.id.SequenceGenerator] sequence-based id generator; use org.hibernate.id.enhanced.SequenceStyleGenerator instead. See Hibernate Domain Model Mapping Guide for details. 2022-09-05 09:34:47,807 [Thread-41] WARN org.hibernate.orm.deprecation - HHH90000014: Found use of deprecated [org.hibernate.id.SequenceGenerator] sequence-based id generator; use org.hibernate.id.enhanced.SequenceStyleGenerator instead. See Hibernate Domain Model Mapping Guide for details. 2022-09-05 09:34:47,808 [Thread-41] WARN org.hibernate.orm.deprecation - HHH90000014: Found use of deprecated [org.hibernate.id.SequenceGenerator] sequence-based id generator; use org.hibernate.id.enhanced.SequenceStyleGenerator instead. See Hibernate Domain Model Mapping Guide for details. 2022-09-05 09:34:54,777 [Thread-41] WARN org.hibernate.orm.deprecation - HHH90000017: Found use of deprecated entity-type selector syntax in HQL/JPQL query ['s.class']; use TYPE operator instead : type(s) 2022-09-05 09:34:55,003 [Thread-41] WARN org.hibernate.orm.deprecation - HHH90000017: Found use of deprecated entity-type selector syntax in HQL/JPQL query ['s.class']; use TYPE operator instead : type(s) 2022-09-05 09:34:55,214 [Thread-41] WARN org.hibernate.orm.deprecation - HHH90000017: Found use of deprecated entity-type selector syntax in HQL/JPQL query ['sa.server.class']; use TYPE operator instead : type(sa.server) 2022-09-05 09:34:55,249 [Thread-41] WARN org.hibernate.orm.deprecation - HHH90000017: Found use of deprecated entity-type selector syntax in HQL/JPQL query ['sa.server.class']; use TYPE operator instead : type(sa.server) 2022-09-05 09:34:55,263 [Thread-41] WARN org.hibernate.orm.deprecation - HHH90000017: Found use of deprecated entity-type selector syntax in HQL/JPQL query ['s.class']; use TYPE operator instead : type(s) 2022-09-05 09:34:56,378 [Thread-41] FATAL com.redhat.rhn.taskomatic.core.TaskomaticDaemon - Failure occurred during job recovery." Synchronize repositories does not work, pat ches and updates are not displayed / processed. Up until 08/26/2022 and Uyuni 2022.06 everything was fine and working correctly. Where can I start troubleshooting, does anyone have an idea? Thank you very much Best Regards Thomas mit freundlichen Gruessen Thomas Weis NTW Netzwerk • Telekommunikation • Datentechnik Burghaldenstrasse 24 D-71336 Waiblingen Fon: +49 7151 9440447 Fax: +49 7151 9440446 E-Mail: tweis(a)ntw-datentechnik.de Web: www.ntw-datentechnik.de Portal: https://support.ntw-datentechnik.de UST-ID: DE175034656 Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

2 3

"The salt master has cached the public key for this node" error.
by Allen Beddingfield 30 Aug '22

30 Aug '22

I have a salt minion that I deleted (by going to "salt keys" in the web ui), stopped the salt minion process on the server, changed the hostname, and re-ran the bootstrap script. It shows up in the lists of keys, and I have selected to approve it, but it never actually turns blue so that it can be selected. The minion on the server is giving this error: "The Salt Master has cached the public key for this node, this salt minion will wait for 10 seconds before attempting to re-authenticate". I've also tried deleting it with salt-key -d, with the same result. I have encountered this before on a SUSE Manger server, and the resolution was to remove the corresponding entry from /var/lib/salt/.ssh/known_hosts, which doesn't seem to exist on my Uyuni 2022.06 server. Any ideas on how to proceed? FYI, the minion is running CentOS 7.x. Thanks. Allen B. -- Allen Beddingfield Systems Engineer Office of Information Technology The University of Alabama Office 205-348-2251 allen(a)ua.edu

2 2

AW: Uyuni 2022.08 is released!
by Crefeld, Tobias LKV Bayern e.V. 29 Aug '22

29 Aug '22

Hi, is this true for packages like "Uyuni Server", too? After upgrading from 2022.06 to 2022.08 "zypper up" shows: Loading repository data... Reading installed packages... The following 4 package updates will NOT be installed: Uyuni-Server-release cobbler netty supportutils-plugin-salt The following product update will NOT be installed: "Uyuni Server" Nothing to do. zypper lr says: Repository priorities are without effect. All enabled repositories share the same priority. # | Alias | Name | Enabled | GPG Check | Refresh --+-----------------------------+------------------------------------------- --------------------------------------------------+---------+-----------+--- ----- 1 | repo-backports-debug-update | Update repository with updates for openSUSE Leap debuginfo packages from openSUSE Backports | No | ---- | ---- 2 | repo-backports-update | Update repository of openSUSE Backports | Yes | (r ) Yes | No 3 | repo-non-oss | Non-OSS Repository | Yes | (r ) Yes | No 4 | repo-oss | Main Repository | Yes | (r ) Yes | No 5 | repo-sle-debug-update | Update repository with debuginfo for updates from SUSE Linux Enterprise 15 | No | ---- | ---- 6 | repo-sle-update | Update repository wiht updates from SUSE Linux Enterprise | Yes | (r ) Yes | No 7 | repo-update | Main Update Repository | Yes | (r ) Yes | No 8 | repo-update-non-oss | Update Repository (Non-Oss) | Yes | (r ) Yes | No 9 | uyuni-server-stable | Uyuni Server Stable | Yes | (r ) Yes | No Thanks & regards, Tobias Crefeld. -----Ursprüngliche Nachricht----- Von: Simon Avery [mailto:Simon.Avery@atass-sports.co.uk] Gesendet: Dienstag, 16. August 2022 11:05 An: Julio Gonzalez <jgonzalez(a)suse.com>; General discussion related to the openSUSE Uyuni project <users(a)lists.uyuni-project.org> Cc: Paul-Andre Panon <ppanon(a)sierrawireless.com> Betreff: RE: Uyuni 2022.08 is released! Thanks for the prompt clarification, Julio. Leaving them be. -----Original Message----- From: Julio Gonzalez <jgonzalez(a)suse.com> Sent: 16 August 2022 09:41 To: General discussion related to the openSUSE Uyuni project <users(a)lists.uyuni-project.org>; Simon Avery <Simon.Avery(a)atass-sports.co.uk> Cc: Paul-Andre Panon <ppanon(a)sierrawireless.com> Subject: [EXTERNAL EMAIL] Re: Uyuni 2022.08 is released! Hi all, Never change the vendor for packages, unless we ask for it at the release notes. Doing it can render Uyuni unusable. There are some packages we require strictly from our repositories. Best regards. El martes, 16 de agosto de 2022 10:32:15 (CEST) Simon Avery escribió: > Just chipping in. > > I don't have the original mgr-create-bootstrap-repo error, but during > the upgrade from 2022.06 to 08, I also have some files that weren't upgraded. > > === > The following 3 package updates will NOT be installed: > cobbler netty supportutils-plugin-salt Nothing to do. > === > > Attempting to update them manually gives me options, but I'm unsure > what to do. Uyuni itself seems to be operating normally since the upgrade. > > === > ata-oxy-uyuni01:/home/simon # zypper install cobbler netty > supportutils-plugin-salt Loading repository data... > Reading installed packages... > 'netty' is already installed. > There is an update candidate for 'netty' from vendor 'SUSE LLC > <https://www.suse.com/>', while the current vendor is > 'obs://build.opensuse.org/systemsmanagement:Uyuni'. Use 'zypper > install netty-4.1.75-150200.4.9.1.x86_64' to install this candidate. > 'cobbler' is already installed. > There is an update candidate for 'cobbler' from vendor 'openSUSE', > while the current vendor is > 'obs://build.opensuse.org/systemsmanagement:Uyuni'. Use 'zypper > install cobbler-3.3.1.0+git.f5b0599a-bp154.1.26.noarch' to install this candidate. 'supportutils-plugin-salt' is already installed. > There is an update candidate for 'supportutils-plugin-salt' from > vendor 'obs://build.opensuse.org/systemsmanagement:Uyuni', while the > current vendor is 'SUSE LLC <https://www.suse.com/>'. Use 'zypper > install supportutils-plugin-salt-1.2.1-1.4.uyuni2.noarch' to install > this candidate. Resolving package dependencies... > Nothing to do. > === > > -----Original Message----- > From: Paul-Andre Panon via Uyuni Users <users(a)lists.uyuni-project.org> > Sent: 12 August 2022 17:58 > To: Julio Gonzalez <jgonzalez(a)suse.com>; General discussion related to > the openSUSE Uyuni project <users(a)lists.uyuni-project.org> Cc: > Paul-Andre Panon <ppanon(a)sierrawireless.com> > Subject: [EXTERNAL EMAIL] RE: Uyuni 2022.08 is released! > > Well, two packages aren't updated because there appears to be > duplicate packages from different repos for netty and cobbler. > > # zypper update > Loading repository data... > Reading installed packages... > > The following 2 package updates will NOT be installed: > cobbler netty > Nothing to do. > > # zypper install cobbler netty > Loading repository data... > Reading installed packages... > 'netty' is already installed. > There is an update candidate for 'netty' from vendor 'SUSE LLC > <https://www.suse.com/>', while the current vendor is > 'obs://build.opensuse.org/systemsmanagement:Uyuni'. Use 'zypper > install netty-4.1.75-150200.4.9.1.x86_64' to install this candidate. > 'cobbler' is already installed. > There is an update candidate for 'cobbler' from vendor 'openSUSE', > while the current vendor is > 'obs://build.opensuse.org/systemsmanagement:Uyuni'. Use 'zypper > install cobbler-3.3.1.0+git.f5b0599a-bp154.1.26.noarch' to install this candidate. Resolving package dependencies... > Nothing to do. > > I've been assuming that Uyuni vendor packages are the correct ones. If > I try use the zipper install command above then it indicates a whole > bunch of Uyuni package dependencies would get removed, so I'm fairly > sure the one currently installed is the right one. > > # zypper install netty-4.1.75-150200.4.9.1.x86_64 Loading repository data... > Reading installed packages... > Resolving package dependencies... > > Problem: the installed spacewalk-java-4.3.35-1.12.uyuni2.noarch > requires 'netty < 4.1.45', but this requirement cannot be provided Solution 1: > Following actions will be done: deinstallation of > spacewalk-java-4.3.35-1.12.uyuni2.noarch > deinstallation of spacewalk-common-4.3.5-1.12.uyuni2.noarch > deinstallation of spacewalk-postgresql-4.3.5-1.12.uyuni2.noarch > deinstallation of susemanager-tools-4.3.18-1.11.uyuni2.x86_64 > deinstallation of patterns-uyuni_server-2022.08-2.2.uyuni2.x86_64 > deinstallation of susemanager-4.3.18-1.11.uyuni2.x86_64 > deinstallation of spacewalk-backend-tools-4.3.15-1.10.uyuni2.noarch > deinstallation of > supportutils-plugin-susemanager-4.3.4-1.24.uyuni2.noarch > deinstallation of spacewalk-setup-4.3.10-1.2.uyuni2.noarch > deinstallation of spacewalk-utils-4.3.13-1.6.uyuni2.noarch > Solution 2: do not install netty-4.1.75-150200.4.9.1.x86_64 Solution 3: > break spacewalk-java-4.3.35-1.12.uyuni2.noarch by ignoring some of its > dependencies > > Choose from above solutions by number or cancel [1/2/3/c/d/?] (c): c > > Otherwise, the server appears up-to-date, has been rebooted, and we > get the error. That said the reprepro does seem different than the > version you indicated. > > # rpm -q -i reprepro > Name : reprepro > Version : 5.3.0 > Release : 2.33.uyuni2 > Architecture: x86_64 > Install Date: Tue Jun 28 15:25:55 2022 > Group : System/Packages > Size : 1179511 > License : GPL-2.0 > Signature : RSA/SHA256, Wed Jun 22 09:25:40 2022, Key ID 972e5d6c0d20833e > Source RPM : reprepro-5.3.0-2.33.uyuni2.src.rpm > Build Date : Wed Jun 22 09:25:33 2022 Build Host : lamb02 > Relocations : (not relocatable) > Packager : https://www.suse.com/ > Vendor : obs://build.opensuse.org/systemsmanagement:Uyuni > URL : https://salsa.debian.org/brlink/reprepro > Summary : Handle local repositories of debian packages > Description : > This project is a lightweight feature complete manager of a debian > package (i.e. binary .deb and source .dsc+.tar.gz+.diff.gz) > repository. Emphasis is put on having all packages in the > pool/-directory, maximal checking of all sources, generation of signed Release file, Contents, ... Distribution: > systemsmanagement:Uyuni:Master / openSUSE_Leap_15.4 > > -----Original Message----- > From: Julio Gonzalez <jgonzalez(a)suse.com> > Sent: Thursday, August 11, 2022 2:35 AM > To: General discussion related to the openSUSE Uyuni project > <users(a)lists.uyuni-project.org> Cc: Paul-Andre Panon > <ppanon(a)sierrawireless.com>; Paul-Andre Panon via Uyuni Users > <users(a)lists.uyuni-project.org> Subject: Re: Uyuni 2022.08 is released! > > Did you fully upgrade the server? > > What's the changelog of the reprepro package? > > IIRC we had to fix this package so it could handle the new zstd > compresed control file, and the fix is part of 2022.08: > > https://download.opensuse.org/repositories/systemsmanagement:/Uyuni:/S > table/ > images/repo/Uyuni-Server-POOL-x86_64-Media1/x86_64/reprepro-5.3.0-2.8. > uyuni2 > .x86_64.rpm > > $ rpm -q --changelog reprepro-5.3.0-2.8.uyuni2.x86_64.rpm|more > * mié jun 29 2022 Julio González Gil <jgonzalez(a)suse.com> > - Bump up the maxsize on a fixed-size C buffer to avoid breaking on some > autogenerated rust packages > * 0001-Bump-up-the-maxsize-on-a-fixed-size-C-buffer-to-avoi.patch > - Flush stdout and stderr before execv of an end hook > * 0002-Flush-stdout-stderr-before-calling-endhook.patch > - Add support for Zstd compressed debs > * 0003-Add-Zstd-support.patch > > If you don't have this changelog entry, and if you already updated > your server, maybe be the mirror you used still didn't have the > reprepro version? > El jueves, 11 de agosto de 2022 11:28:54 (CEST) Paul-Andre Panon via > Uyuni Users escribió: > > That's excellent! I was worried we might have to wait longer for > > Ubuntu > > 22.04 support after the lack of a 2022.07 release. Thank you. > > > > That said, when I tried to create an Ubuntu 22.04 bootstrap repo, I > > got the following error message: > > > > # mgr-create-bootstrap-repo --create ubuntu-22.04-amd64-uyuni > > > > Creating bootstrap repo for ubuntu-22.04-amd64-uyuni copy > > 'venv-salt-minion-3004-4.6.uyuni.amd64-deb' > > Could not find a suitable control.tar file within > > '/srv/www/htdocs/pub/repositories/ubuntu/22/4/bootstrap.tmp/debs/ven > > v- > > salt- minion-3004-4.6.uyuni.amd64-deb.deb'! There have been errors! > > Error creating bootstrap repo. > > > > Could it be that that function isn't benefiting from the updates to > > support the new compression algorithm used for Ubuntu 22.04 packages? > > > > Cheers, > > > > Paul-Andre > > > > -----Original Message----- > > From: Julio Gonzalez via Uyuni Users <users(a)lists.uyuni-project.org> > > Sent: Wednesday, August 10, 2022 4:07 AM > > To: announce(a)lists.uyuni-project.org; devel(a)lists.uyuni-project.org; > > users(a)lists.uyuni-project.org Cc: Julio Gonzalez > > <jgonzalez(a)suse.com> > > Subject: Uyuni 2022.08 is released! > > > > VERY IMPORTANT: 2022.08 requires special procedures if you are not > > already using Uyuni 2022.06! The configuration files for the proxy > > on containers also needs to be updated. Make sure you read the > > release notes before updating! > > > > We are happy to announce the availability of Uyuni 2022.08. Most > > openSUSE mirrors should already have 2022.08, but if you do not see > > it yet, wait a few hours until your local openSUSE mirror is synced. > > > > At https://www.uyuni-project.org/pages/stable-version.html you will > > find all the resources you need to start working with Uyuni 2022.08, > > including the release notes, documentation, requirements and setup > > instructions. > > > > This is the list of highlights for this release: > > > > - Ubuntu 22.04 as client > > - GPG key handling in Uyuni > > - Disabling locally defined repositories > > - Technology Preview: Helm chart to deploy containerized Uyuni Proxy > > > > and Retail Branch Server > > > > 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.08 > > > > As always, we hope you will enjoy Uyuni 2022.08 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 > > -- > Julio González Gil > Release Engineer, SUSE Manager and Uyuni jgonzalez(a)suse.com -- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez(a)suse.com

1 0

Error "installation medium unavailable" when using autoinstall distro based on tftpboot-installation (SLE-15-SP4-x86_64)
by Heiner W. 25 Aug '22

25 Aug '22

Hi List, for autoinstalling SLES15-SP4 i tried to use the Data from tftpboot-installation package as stated in Uyuni Client Config Documentation "Distribution Based on a RPM Package." (https://www.uyuni-project.org/uyuni-docs/en/uyuni/client-configuration/auto…) i queried RPM "tftpboot-installation-SLE-15-SP4-x86_64-16.57.20-150400.1.18.noarch.rpm" on my uyuni Server and found out it installs into "/usr/share/tftpboot-installation" My autoinstall distro files are stored in "/var/autoinstall" where i have plenty of space, so i symlinked: ln -s /var/autoinstall/tftpboot-installation /usr/share/tftpboot-installation After "zypper install"ing said RPM i found this content in "/var/autoinstall/tftpboot-installation/SLE-15-SP4-x86_64/": EFI README boot net In uyuni gui i created my autoinstall distro using tree path "/var/autoinstall/tftpboot-installation/SLE-15-SP4-x86_64" and created matching profile and activation key. I found no special instructions in documentation when using tftpboot-installation instead of full ISO, so i sticked to the defaults. Cobbler shows my new autoinstall distro/profile. When trying to install a System it is able to load linuxrc but says "installation medium unavailable". Uyuni Tomcat logs this: 2022-08-24 15:39:44,266 [ajp-nio-0:0:0:0:0:0:0:1-8009-exec-1] ERROR com.redhat.rhn.frontend.action.common.DownloadFile - //var/autoinstall/tftpboot-installation/SLE-15-SP4-x86_64/content Not Found .. 404! 2022-08-24 15:39:44,272 [ajp-nio-0:0:0:0:0:0:0:1-8009-exec-8] ERROR com.redhat.rhn.frontend.action.common.DownloadFile - //var/autoinstall/tftpboot-installation/SLE-15-SP4-x86_64/repodata/repomd.xml Not Found .. 404! 2022-08-24 15:39:44,278 [ajp-nio-0:0:0:0:0:0:0:1-8009-exec-3] ERROR com.redhat.rhn.frontend.action.common.DownloadFile - //var/autoinstall/tftpboot-installation/SLE-15-SP4-x86_64/media.1/products Not Found .. 404! It seems like i must set a special path to further Data (media/repos) that isn't included in tftpboot-installation but i don't know what to configure where. For older SLES SPs i downloaded the full 12GB install iso (like "SLE-15-SP3-Full-x86_64-GM-Media1"), unpacked it and put all files into uyuni "tree path" directory of its autoinstall distro. It would be great if i wouldn't need that extra space for SP4 as all RPMs are already stored within my synced Upstream/Product and CLM Repos. Any hint is much appreciated! Thanks, Heiner

1 1

Uyuni 2022.08 is released!
by Julio Gonzalez 24 Aug '22

24 Aug '22

VERY IMPORTANT: 2022.08 requires special procedures if you are not already using Uyuni 2022.06! The configuration files for the proxy on containers also needs to be updated. Make sure you read the release notes before updating! We are happy to announce the availability of Uyuni 2022.08. Most openSUSE mirrors should already have 2022.08, but if you do not see it yet, wait a few hours until your local openSUSE mirror is synced. At https://www.uyuni-project.org/pages/stable-version.html you will find all the resources you need to start working with Uyuni 2022.08, including the release notes, documentation, requirements and setup instructions. This is the list of highlights for this release: - Ubuntu 22.04 as client - GPG key handling in Uyuni - Disabling locally defined repositories - Technology Preview: Helm chart to deploy containerized Uyuni Proxy and Retail Branch Server 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.08 As always, we hope you will enjoy Uyuni 2022.08 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

6 18

[uyuni-users] Fresh Install uyuni 2020.05 Error generating bootstrap repo
by Thomas Weis 24 Aug '22

24 Aug '22

Hello everyone we are configuring a fresh installation of Uyuni 2020.05 After a successful reposync of SUSE Linux Enterprise Server 15 SP1 x86_64 we get an error message: Type: Creating Bootstrap Repository failed Summary: Error generating bootstrap repo for: SLE-15-SP1-x86_64 show details said: ERROR: package 'hwdata' not found ERROR: package 'python3-hwdata' not found ERROR: package 'python3-rhnlib' not found ERROR: package 'spacewalk-check' not found ERROR: package 'spacewalk-client-setup' not found ERROR: package 'spacewalk-client-tools' not found ERROR: package 'python3-spacewalk-check' not found ERROR: package 'python3-spacewalk-client-setup' not found ERROR: package 'python3-spacewalk-client-tools' not found ERROR: package 'python3-uyuni-common-libs' not found ERROR: none of 'mgr-daemon', 'spacewalksd' found ERROR: package 'suseRegisterInfo' not found ERROR: package 'python3-suseRegisterInfo' not found ERROR: package 'zypp-plugin-spacewalk' not found ERROR: package 'python3-zypp-plugin-spacewalk' not found The installation was error-free, we proceeded exactly according to the documentation. What is our mistake? thanks for suggestions Regards Thomas-- To unsubscribe, e-mail: uyuni-users+unsubscribe(a)opensuse.org To contact the owner, e-mail: uyuni-users+owner(a)opensuse.org

3 2

IMPORTANT: Problems creating the bootstrap repository for Ubuntu 22.04
by Julio Gonzalez 17 Aug '22

17 Aug '22

Hello, There's a bug affecting Uyuni 2022.08 and the bootstrap repository creating for Ubuntu 22.04. Please check https://github.com/uyuni-project/uyuni/issues/5764#issuecomment-1217969673 for all the information about the problem, and how apply the fix Uyuni for 2022.08. The fix will be part of Uyuni 2022.09. Thanks to kyle-aas, Lukas Magauer (lumarel) and Chri (chr78) for the bug report and all the help provided for debugging the issue. -- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez(a)suse.com

1 0

AW: RE: Subtask mgr-update-reporting failed.
by Crefeld, Tobias LKV Bayern e.V. 16 Aug '22

16 Aug '22

Hi Robert, "ping lkv-srvapp39" and "host lkv-srvapp39" work as expected. A request with psql works fine, too: uyuni@lkv-srvapp39:~> psql -h lkv-srvapp39 Passwort für Benutzer uyuni: psql (14.3) SSL-Verbindung (Protokoll: TLSv1.3, Verschlüsselungsmethode: TLS_AES_256_GCM_SHA384, Bits: 256, Komprimierung: aus) Geben Sie »help« für Hilfe ein. uyuni=# How can I add the short name to the "TLS SAN"? Where can I configure the host name the application is using? I don't know if It is important, but according to the status of systemctl Uyuni's applications connect to the DB-server via 127.0.0.1 which resolves to localhost: lkv-srvapp39:/var/lib/pgsql/data # systemctl status postgresql ● postgresql.service - PostgreSQL database server Loaded: loaded (/usr/lib/systemd/system/postgresql.service; enabled; vendor preset: disabled) Active: active (running) since Tue 2022-08-02 10:41:35 CEST; 2 weeks 0 days ago Process: 2357 ExecStart=/usr/share/postgresql/postgresql-script start (code=exited, status=0/SUCCESS) Main PID: 2388 (postgres) Tasks: 43 (limit: 4915) CGroup: /system.slice/postgresql.service ├─ 828 "postgres: uyuni uyuni 127.0.0.1(49822) idle" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─ 829 "postgres: uyuni uyuni 127.0.0.1(49824) idle" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─ 830 "postgres: uyuni uyuni 127.0.0.1(49826) idle" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─ 2388 /usr/lib/postgresql14/bin/postgres -D /var/lib/pgsql/data ├─ 2430 "postgres: logger " "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ""> ├─ 2445 "postgres: checkpointer " "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─ 2446 "postgres: background writer " "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─ 2447 "postgres: walwriter " "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─ 2448 "postgres: autovacuum launcher " "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─ 2451 "postgres: archiver last was 00000001000000CD000000B0" "" "" "" "" "" ├─ 2452 "postgres: stats collector " "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─ 2453 "postgres: logical replication launcher " "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─ 2926 "postgres: uyuni uyuni ::1(39194) idle" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─ 4397 "postgres: uyuni uyuni 127.0.0.1(48680) idle in transaction" ├─ 4403 "postgres: uyuni uyuni 127.0.0.1(48688) idle in transaction" ├─ 4472 "postgres: uyuni uyuni 127.0.0.1(48692) idle" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─ 5145 "postgres: uyuni uyuni 127.0.0.1(48694) idle" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─ 5146 "postgres: uyuni uyuni 127.0.0.1(48696) idle" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─ 5147 "postgres: uyuni uyuni 127.0.0.1(48700) idle" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─ 5148 "postgres: uyuni uyuni 127.0.0.1(48702) idle" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─ 5149 "postgres: uyuni uyuni 127.0.0.1(48704) idle" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─ 5150 "postgres: uyuni uyuni 127.0.0.1(48706) idle" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─ 5151 "postgres: uyuni uyuni 127.0.0.1(48708) idle" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─ 5152 "postgres: uyuni uyuni 127.0.0.1(48710) idle" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─ 5153 "postgres: uyuni uyuni 127.0.0.1(48712) idle" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─ 5155 "postgres: uyuni uyuni 127.0.0.1(48714) idle" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─ 5156 "postgres: uyuni uyuni 127.0.0.1(48716) idle" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─ 5157 "postgres: uyuni uyuni 127.0.0.1(48718) idle" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─ 5159 "postgres: uyuni uyuni 127.0.0.1(48720) idle" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─ 5160 "postgres: uyuni uyuni 127.0.0.1(48722) idle" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─ 5161 "postgres: uyuni uyuni 127.0.0.1(48724) idle" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─ 5226 "postgres: uyuni uyuni 127.0.0.1(48740) idle" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─ 5227 "postgres: uyuni uyuni 127.0.0.1(48738) idle" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─ 5228 "postgres: uyuni uyuni 127.0.0.1(48736) idle" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─12183 "postgres: uyuni uyuni ::1(39198) idle in transaction" "" "" "" "" "" ├─17094 "postgres: uyuni uyuni 127.0.0.1(48018) idle in transaction" ├─18174 "postgres: uyuni uyuni 127.0.0.1(48204) idle" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─22694 "postgres: uyuni uyuni 127.0.0.1(50300) idle in transaction" ├─22915 "postgres: uyuni uyuni 127.0.0.1(48214) idle" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─25894 "postgres: uyuni uyuni 127.0.0.1(52958) idle" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─25895 "postgres: uyuni uyuni 127.0.0.1(52960) idle" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ├─26392 "postgres: uyuni uyuni 127.0.0.1(52962) idle" "" "" "" "" "" "" "" "" "" "" "" "" "" "" └─26670 "postgres: uyuni uyuni 127.0.0.1(48228) idle" "" "" "" "" "" "" "" "" "" "" "" "" "" "" Notice: journal has been rotated since unit was started, output may be incomplete. BTW: Meanwhile the number of Taskomatic jobs that fail is increasing and since 3 days Uyuni stopped to check patch and config status of its clients. Just as it happened to the ssh clients since the update of Uyuni. No configuration changes since last week. Maybe it's better to recover the system to a version before the update. Regards, Tobias. -----Ursprüngliche Nachricht----- Von: Robert Paschedag [mailto:robert.paschedag@web.de] org.postgresql.util.PSQLException: The hostname lkv-srvapp39 could not be verified by hostnameverifier PgjdbcHostnameVerifier. This sounds to me, that you configuration is using the "short" name to access PostgreSQL. Try from your server, if this is resolvable. Maybe you're missing a proper "search" DNS config option. If the internal connection to your PostgreSQL is TLS encrypted, then the short name also needs to be added to the TLS SAN (Subject Alternative Name) the PostgreSQL is running, of the default TLS verification options are used 1. As mentioned... Is a simple "ping lkv-srvapp39" resolvable from within your uyuni server? 2. Try to change the host setting that defines your PostgreSQL and change it to use the full FQDN. Robert

2 1

Promoting new Version in CLM Project Environment: How long should it normally take? ("Waiting for repositories data to be generated")
by Heiner W. 08 Aug '22

08 Aug '22

Hi List, we wanted to apply latest available SP2 updates and patches before migrating to SP3. 3.5 hours ago i triggered a final "promote" for the current SLES15 SP2 CLM Project Environment/stage (containing base, packagehub, Server-Applications, Public-Cloud15 and a few small custom repos). Now we are waiting impatiently (WebGUI still says "Waiting for repositories data to be generated") and affected systems aren't aware of new package Versions when calling zypper ref && zypper up. What are your experiences how long repo data regeneration "normally" takes? How can it be tuned? - Which config parameters should we change? - should we increase CPU or Memory? Uyuni VM currently runs on 4x2.2GHz and 32GB Memory We have 65 managed Systems running sles15 sp2 or sp3 in 3 CLM Projects we are running on default values: # java.taskomatic_channel_repodata_workers=2 # taskomatic.java.maxmemory=4096 # taskomatic.java.initmemory=256 # ps -efa|grep tasko root 14974 1 0 Jul28 ? 00:00:00 /bin/sh /usr/sbin/taskomatic root 14989 14974 1 Jul28 ? 04:38:51 /usr/bin/java -Djava.library.path=/usr/lib:/usr/lib64 -classpath /usr/share/rhn/classes:/usr/share/rhn/lib/spacewalk-asm.jar:/usr/share/rhn/lib/rhn.jar:/usr/share/rhn/lib/java-branding.jar:/usr/share/spacewalk/taskomatic/* -Dibm.dst.compatibility=true -Dfile.encoding=UTF-8 -Xms256m -Xmx4096m --add-modules java.annotation,com.sun.xml.bind --add-exports java.annotation/javax.annotation.security=ALL-UNNAMED --add-opens java.annotation/javax.annotation.security=ALL-UNNAMED com.redhat.rhn.taskomatic.core.TaskomaticDaemon Current Load: top - 12:37:44 up 25 days, 58 min, 2 users, load average: 0.00, 0.18, 0.46 Tasks: 369 total, 1 running, 368 sleeping, 0 stopped, 0 zombie %Cpu(s): 23.1 us, 1.5 sy, 0.0 ni, 75.4 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st MiB Mem : 32107.11+total, 1894.559 free, 9224.531 used, 20988.02+buff/cache MiB Swap: 0.000 total, 0.000 free, 0.000 used. 18222.20+avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 24611 postgres 20 0 4175884 156508 146952 S 53.33 0.476 0:36.23 postgres 13345 tomcat 20 0 5006136 1.317g 23912 S 40.00 4.202 60:20.16 java 14979 root 20 0 4267224 288120 20300 S 6.667 0.876 27:11.55 java Thanks, Heiner

1 0

AW: Subtask mgr-update-reporting failed.
by Crefeld, Tobias LKV Bayern e.V. 08 Aug '22

08 Aug '22

Hi Simon, thanks for your hints! I followed them and received a lot of messages but actually I'm no java developer. I tried to reduce the log output by leaving out the "at"-lines but it is still large. Hope that no one gets annoyed too much: 2022-08-02 09:56:00,022 [DefaultQuartzScheduler_Worker-18] WARN org.hibernate.orm.deprecation - HHH90000022: Hibernate's legacy org.hibernate.Criteria API is deprecated; use the JPA javax.persistence.criteria.CriteriaQuery instead 2022-08-02 09:56:02,718 [DefaultQuartzScheduler_Worker-1] WARN org.hibernate.orm.deprecation - HHH020100: The Ehcache second-level cache provider for Hibernate is deprecated. See https://hibernate.atlassian.net/browse/HHH-12441 for details. 2022-08-02 09:56:33,348 [C3P0PooledConnectionPoolManager[identityToken->z8kfluaqp0t6ro20pjuq|3ff5aba ]-HelperThread-#0] WARN com.mchange.v2.resourcepool.BasicResourcePool - com.mchange.v2.resourcepool.BasicResourcePool$ScatteredAcquireTask@1c8f4b1f -- Acquisition Attempt Failed!!! Clearing pending acquires. While trying to acquire a needed new resource, we failed to succeed more than the maximum number of allowed acquisition attempts (30). Last acquisition attempt exception: org.postgresql.util.PSQLException: The hostname lkv-srvapp39 could not be verified by hostnameverifier PgjdbcHostnameVerifier. 2022-08-02 09:56:33,348 [C3P0PooledConnectionPoolManager[identityToken->z8kfluaqp0t6ro20pjuq|3ff5aba ]-HelperThread-#0] WARN com.mchange.v2.resourcepool.BasicResourcePool - Having failed to acquire a resource, com.mchange.v2.resourcepool.BasicResourcePool@411ce9ec is interrupting all Threads waiting on a resource to check out. Will try again in response to new client requests. 2022-08-02 09:56:33,348 [DefaultQuartzScheduler_Worker-1] WARN org.hibernate.engine.jdbc.env.internal.JdbcEnvironmentInitiator - HHH000342: Could not obtain connection to query metadata : Connections could not be acquired from the underlying database! 2022-08-02 09:56:33,354 [C3P0PooledConnectionPoolManager[identityToken->z8kfluaqp0t6ro20pjuq|3ff5aba ]-HelperThread-#1] WARN com.mchange.v2.resourcepool.BasicResourcePool - com.mchange.v2.resourcepool.BasicResourcePool$ScatteredAcquireTask@5ab931dd -- Acquisition Attempt Failed!!! Clearing pending acquires. While trying to acquire a needed new resource, we failed to succeed more than the maximum number of allowed acquisition attempts (30). Last acquisition attempt exception: org.postgresql.util.PSQLException: The hostname lkv-srvapp39 could not be verified by hostnameverifier PgjdbcHostnameVerifier. 2022-08-02 09:56:33,354 [C3P0PooledConnectionPoolManager[identityToken->z8kfluaqp0t6ro20pjuq|3ff5aba ]-HelperThread-#1] WARN com.mchange.v2.resourcepool.BasicResourcePool - Having failed to acquire a resource, com.mchange.v2.resourcepool.BasicResourcePool@411ce9ec is interrupting all Threads waiting on a resource to check out. Will try again in response to new client requests. 2022-08-02 09:56:33,360 [DefaultQuartzScheduler_Worker-1] WARN net.sf.ehcache.DiskStorePathManager - diskStorePath '/tmp' is already used by an existing CacheManager either in the same VM or in a different process. The diskStore path for this CacheManager will be set to /tmp/ehcache_auto_created2394383558487899130diskstore. To avoid this warning consider using the CacheManager factory methods to create a singleton CacheManager or specifying a separate ehcache configuration (ehcache.xml) for each CacheManager instance. 2022-08-02 09:56:33,361 [C3P0PooledConnectionPoolManager[identityToken->z8kfluaqp0t6ro20pjuq|3ff5aba ]-HelperThread-#2] WARN com.mchange.v2.resourcepool.BasicResourcePool - com.mchange.v2.resourcepool.BasicResourcePool$ScatteredAcquireTask@68e07fff -- Acquisition Attempt Failed!!! Clearing pending acquires. While trying to acquire a needed new resource, we failed to succeed more than the maximum number of allowed acquisition attempts (30). Last acquisition attempt exception: org.postgresql.util.PSQLException: The hostname lkv-srvapp39 could not be verified by hostnameverifier PgjdbcHostnameVerifier. 2022-08-02 09:56:33,362 [C3P0PooledConnectionPoolManager[identityToken->z8kfluaqp0t6ro20pjuq|3ff5aba ]-HelperThread-#2] WARN com.mchange.v2.resourcepool.BasicResourcePool - Having failed to acquire a resource, com.mchange.v2.resourcepool.BasicResourcePool@411ce9ec is interrupting all Threads waiting on a resource to check out. Will try again in response to new client requests. 2022-08-02 09:56:33,374 [C3P0PooledConnectionPoolManager[identityToken->z8kfluaqp0t6ro20pjuq|3ff5aba ]-HelperThread-#1] WARN com.mchange.v2.resourcepool.BasicResourcePool - com.mchange.v2.resourcepool.BasicResourcePool$ScatteredAcquireTask@3b518b25 -- Acquisition Attempt Failed!!! Clearing pending acquires. While trying to acquire a needed new resource, we failed to succeed more than the maximum number of allowed acquisition attempts (30). Last acquisition attempt exception: org.postgresql.util.PSQLException: The hostname lkv-srvapp39 could not be verified by hostnameverifier PgjdbcHostnameVerifier. 2022-08-02 09:56:33,374 [C3P0PooledConnectionPoolManager[identityToken->z8kfluaqp0t6ro20pjuq|3ff5aba ]-HelperThread-#0] WARN com.mchange.v2.resourcepool.BasicResourcePool - com.mchange.v2.resourcepool.BasicResourcePool$ScatteredAcquireTask@5599538e -- Acquisition Attempt Failed!!! Clearing pending acquires. While trying to acquire a needed new resource, we failed to succeed more than the maximum number of allowed acquisition attempts (30). Last acquisition attempt exception: org.postgresql.util.PSQLException: The hostname lkv-srvapp39 could not be verified by hostnameverifier PgjdbcHostnameVerifier. 2022-08-02 09:56:33,374 [C3P0PooledConnectionPoolManager[identityToken->z8kfluaqp0t6ro20pjuq|3ff5aba ]-HelperThread-#1] WARN com.mchange.v2.resourcepool.BasicResourcePool - Having failed to acquire a resource, com.mchange.v2.resourcepool.BasicResourcePool@411ce9ec is interrupting all Threads waiting on a resource to check out. Will try again in response to new client requests. 2022-08-02 09:56:33,375 [DefaultQuartzScheduler_Worker-1] WARN org.hibernate.engine.jdbc.spi.SqlExceptionHelper - SQL Error: 0, SQLState: null 2022-08-02 09:56:33,375 [DefaultQuartzScheduler_Worker-1] ERROR org.hibernate.engine.jdbc.spi.SqlExceptionHelper - Connections could not be acquired from the underlying database! 2022-08-02 09:56:33,375 [C3P0PooledConnectionPoolManager[identityToken->z8kfluaqp0t6ro20pjuq|3ff5aba ]-HelperThread-#0] WARN com.mchange.v2.resourcepool.BasicResourcePool - Having failed to acquire a resource, com.mchange.v2.resourcepool.BasicResourcePool@411ce9ec is interrupting all Threads waiting on a resource to check out. Will try again in response to new client requests. 2022-08-02 09:56:33,384 [DefaultQuartzScheduler_Worker-1] ERROR com.redhat.rhn.taskomatic.task.ReportDbUpdateTask - Executing a task threw an exception: org.quartz.JobExecutionException 2022-08-02 09:56:33,385 [DefaultQuartzScheduler_Worker-1] ERROR com.redhat.rhn.taskomatic.task.ReportDbUpdateTask - Message: Unable to update reporting db 2022-08-02 09:56:33,385 [DefaultQuartzScheduler_Worker-1] ERROR com.redhat.rhn.taskomatic.task.ReportDbUpdateTask - Cause: {} org.hibernate.exception.GenericJDBCException: Unable to acquire JDBC Connection Caused by: java.sql.SQLException: Connections could not be acquired from the underlying database! Caused by: com.mchange.v2.resourcepool.CannotAcquireResourceException: A ResourcePool could not acquire a resource from its primary factory or source. Caused by: org.postgresql.util.PSQLException: The hostname lkv-srvapp39 could not be verified by hostnameverifier PgjdbcHostnameVerifier. 2022-08-02 09:56:33,387 [DefaultQuartzScheduler_Worker-1] ERROR com.redhat.rhn.taskomatic.task.ReportDbUpdateTask - Stack trace:org.quartz.JobExecutionException: Unable to update reporting db [See nested exception: org.hibernate.exception.GenericJDBCException: Unable to acquire JDBC Connection] Caused by: org.hibernate.exception.GenericJDBCException: Unable to acquire JDBC Connection Caused by: java.sql.SQLException: Connections could not be acquired from the underlying database! Caused by: com.mchange.v2.resourcepool.CannotAcquireResourceException: A ResourcePool could not acquire a resource from its primary factory or source. Caused by: org.postgresql.util.PSQLException: The hostname lkv-srvapp39 could not be verified by hostnameverifier PgjdbcHostnameVerifier. 2022-08-02 09:57:00,022 [DefaultQuartzScheduler_Worker-2] WARN org.hibernate.orm.deprecation - HHH90000022: Hibernate's legacy org.hibernate.Criteria API is deprecated; use the JPA javax.persistence.criteria.CriteriaQuery instead Maybe someone has a better understanding of this stuff and can explain what's going wrong? BTW: The messages with "QuartzScheduler" are repeated every minute, independent of the status of "mgr-update-reporting-bunch". TIA! Regards. Tobias Crefeld.

4 3

Adding Oracle Linux
by Crefeld, Tobias LKV Bayern e.V. 01 Aug '22

01 Aug '22

Hi, I'd like to add Repositories for Oracle Linux 8 to the Uyuni-Server. Therefore I'm following the advice at https://www.uyuni-project.org/uyuni-docs/en/uyuni/client-configuration/clien ts-oracle.html#_add_software_channels and enter spacewalk-common-channels oraclelinux8 Afterwards system requests SUSE-Manager's credentials. There I enter the credentials that I use to logon to the Web-UI which can be found at the Web-UI under Users / User List / Active with the roles "SUSE Manager Administrator" and "Organization Administrator". Afterwards it reports Traceback (most recent call last): File "/usr/bin/spacewalk-common-channels", line 269, in <module> client, key = connect(options.user, options.password, options.server) File "/usr/bin/spacewalk-common-channels", line 119, in connect key = xmlrpc_login(client, options.user, password) File "/usr/lib/python3.6/site-packages/uyuni/common/cli.py", line 74, in xmlrpc_login sessionkey = client.auth.login(username, password) File "/usr/lib64/python3.6/xmlrpc/client.py", line 1112, in __call__ return self.__send(self.__name, args) File "/usr/lib64/python3.6/xmlrpc/client.py", line 1452, in __request verbose=self.__verbose File "/usr/lib64/python3.6/xmlrpc/client.py", line 1154, in request return self.single_request(host, handler, request_body, verbose) File "/usr/lib64/python3.6/xmlrpc/client.py", line 1187, in single_request dict(resp.getheaders()) xmlrpc.client.ProtocolError: <ProtocolError for localhost/rpc/api: 400 Bad Request> If I'm using tools like spacewalk-remove-channel, the same credentials work fine. Any idea? Regards, Tobias Crefeld.

1 0

Subtask mgr-update-reporting failed.
by Crefeld, Tobias LKV Bayern e.V. 28 Jul '22

28 Jul '22

Hi, recently I upgraded the Uyuni system from 2021.07 to 2022.06. Several tests were successful so I'm not sure if the current problems come from the update. There are two issues: 1. Since Uyuni's update several clients don't check in any more. All of them are using "Push via SSH tunnel" or "Push via SSH" as contact method. Salt clients with contact method "Default" (SLES15-SP3) run fine. Client OS is "openSUSE Leap 15.1 x86_64" or "SUSE Linux Enterprise Server 12 SP5 x86_64". There is no "configuration" or scripting - the only target is to monitor the patch level and provide repositories. 2. After a reboot of the Uyuni host I was sent an email with this content: "Taskomatic bunch mgr-update-reporting-bunch was scheduled to run within the update-reporting-default schedule. Subtask mgr-update-reporting failed. For more information check null." (Checking "null" wasn't successful) Any hints are welcome! Regards, Tobias Crefeld.

2 1

A question about venv-salt-minion and systemd
by Simon Avery 22 Jul '22

22 Jul '22

Hi A little flummoxed about this. I've switched to using venv-salt-minion on clients, and it installs okay. However, we require /tmp to have the noexec flag. Salt doesn't like this very much. Our previous workaround was to create a file in /etc/systemd/system/salt-minion.service.d containing [Service] Environment="TMPDIR=/usr/tmp" This told salt-minion to use a different tmpdir that did have the exec flag and it was happy again. However, venv-salt-minion doesn't read that file, because it's a different service. I assumed I could just create /etc/systemd/system/venv-salt-minion.service.d instead, but the process is not reading this. If I edit the system file directly and add that file it works, but I would prefer to use a drop-in file for this. I'm not overly familiar with venv programs, and less so when combined with systemd. Can anyone please point me the right way to do this? Thanks S

2 3

A fix for using HTTP proxies for repository synced is now released
by Julio Gonzalez 21 Jul '22

21 Jul '22

The fix requires two things: - Uyuni 2022.06 - The latest python3-urlgrabber from openSUSE Leap 15.4 The issue is being tracked at https://github.com/uyuni-project/uyuni/issues/4850 Special thanks to Dan Holstad, hbrown-uiowa, phibid and SpeedBlack for the report, and to Dominik Wombacher and Pablo Suárez for the fix. Happy hacking! -- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez(a)suse.com

1 0

Error trying to bootstrap / register / onboard sles15sp3 salt client/minion
by Heiner Wulfhorst 15 Jul '22

15 Jul '22

Hi List, i am trying to register a system to uyuni ( release 2022.05 <https://dehwlluyunip01.claas.local/docs/en/release-notes/release-notes-serv…> ). Installation of salt agent seems to work (both venv and classic), i can also accept salt key in uyuni, but after accepting there seems to be a communication problem when uyuni tries to onboard the client (create client profile: Here's some log regarding the issue: 2022-07-13 15:06:53,396 [salt-event-thread-3] WARN com.suse.manager.webui.services.impl.SaltService - Got no result for grains.items on minion dehwllhdb21.claas.local (minion did not respond in time) 2022-07-13 15:06:54,971 [ajp-nio-0:0:0:0:0:0:0:1-8009-exec-26] WARN com.suse.manager.webui.services.impl.SaltService - Got no result for grains.item on minion dehwllhdb21.claas.local (minion did not respond in time) 2022-07-13 15:06:54,971 [ajp-nio-0:0:0:0:0:0:0:1-8009-exec-26] ERROR com.suse.manager.reactor.messaging.RegisterMinionEventMessageAction - Aborting: needed grains are not found for minion: dehwllhdb21.claas.local 2022-07-13 15:06:57,369 [salt-event-thread-3] ERROR com.suse.manager.reactor.messaging.RegisterMinionEventMessageAction - Unable to find the server architecture for osfamily: '' and osarch: '' 2022-07-13 15:06:57,369 [salt-event-thread-3] ERROR com.suse.manager.reactor.messaging.RegisterMinionEventMessageAction - Error registering minion id: dehwllhdb21.claas.local java.lang.IllegalArgumentException: Unable to get the server architecture uyuni can ssh to the client and vice versa. can someone help me troubleshoot this issue? I have no more idea where to look and what to check/try :'( BR Heiner

3 6

Where is mgr-bootstrap on a containerized proxy?
by Paul-Andre Panon 14 Jul '22

14 Jul '22

After some brow sweat figuring out that a firewalld IP range overlap between zone sources was breaking routing for a containerized proxy, I'm ready to try to follow up with setting up some bootstrap scripts on the proxy. However I can't seem to find mgr-bootstrap to do so because it doesn't appear to be in the container host path. How does one generate bootstrap scripts on a containerized proxy? Thanks Paul-Andre Panon

2 9

Spacewalk add channel has failed
by Martin Willisegger 12 Jul '22

12 Jul '22

Hello list Currently I cannot attach a specific channel for opensuse Leap 15.4 to Uyuni. I get the following error message: uyuni:~ # spacewalk-common-channels -a x86_64 opensuse_leap15_4-sle-updates SUSE Manager username: admin SUSE Manager password: Base channel 'openSUSE Leap 15.4 (x86_64)' - exists WARNING: opensuse_leap15_4-x86_64-sle-updates: redstone.xmlrpc.XmlRpcFault: The channel name 'Update repository with updates from SUSE Linux Enterprise 15 (x86_64)' is already in use, please enter a different name I think there is a conflict with the existing subchannel from Leap 15.3: opensuse_leap15_3-x86_64-sle-updates However, this repo is needed for 15.3 and 15.4. What possibility do i have to import and attach this channel for 15.4 anyway? Best regards Martin

1 0

Patch for Uyuni 2022.06
by Julio Gonzalez 06 Jul '22

06 Jul '22

Hello! Several users syncing openSUSE Leap 15.3/15.4 and/or the SUSE PackageHub reported that they are getting the following error running reposync from CLI, or at the WebUI notifications area: 2022/07/05 09:22:01 +02:00 Importing packages to DB: 2022/07/05 09:22:02 +02:00 'rpm.hdr' object has no attribute 'get' Please note that this bug does **not** prevent syncing other packages, it just means that the package `kicad-packages3D` version `5.1.8-bp154.1.18` failed to sync due to the bug. So it wont be available for Uyuniu clients, as it won't be synced at the server. Other than that the reposync will work just as usual. If automated syncing is for the affected channels is enabled, then you will also get notifications at the UI (the "bell" icon). A patch for Uyuni 2022.06 to fix both problems was just published, in case you do not want to wait for Uyuni 2022.07 (it will be part of that release as well). You can apply the patch by following the instructions at: https://www.uyuni-project.org/pages/patches.html If you are using Uyuni 2022.05 or older: make sure you update to 2022.06, and remember 2022.06 changes the base OS to openSUSE Leap 15.4, so you need to follow a special procedure (check the release notes). Thank to all users that reported the issue, and specially to Jonathan Müller (LordofAgents) for providing the information about the affected package. Happy hacking! -- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez(a)suse.com

1 0