September 2022 - ARCHIVED: Uyuni Users

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