- ARCHIVED: Uyuni Users

Uyuni salt master lost communications to most minions
by Paul-Andre Panon 19 Jan '23

19 Jan '23

Hi, We've got a weird behaviour that happened in the last day or so. The Uyuni salt master stopped being able to communicate with nearly all minions except one. salt -vvv ServerX test.ping Executing job with jid 20230118190311229937 ------------------------------------------- ServerX: Minion did not return. [Not connected] ERROR: Minions returned with non-zero exit code The venv-salt-minion service seems to be working on the minion. The service has the error salt-minion[952]: [ERROR] File /etc/venv-salt-minion/minion.d/_mgractionchains.conf not found, but that appears to be cosmetic based on the outstanding issue, and the working minion has the same error. However, I restarted one of the salt-minions and the salt master appears to be able to connect afterwards. And yet the minion system was rebooted the previous day and hasn't been patched in the interim so there should have been no version change. Is there possibly a bug in the latest salt minion version? The Ubuntu 22.04 minion version is venv-salt-minion 3004-11.3.uyuni amd64 The venvjailed client component for Salt although we're also getting this across the board on CentOS 7, openSUSE, and multiple versions of Ubuntu. Could the salt master have issued something that put all the salt minions in a wedged state due to some bug? Is there anything we can gather, information wise before restarting those venv-salt-minion services across the board? Cheers, Paul-Andre

1 1

Uyuni 2022.12 is released!
by Julio Gonzalez 17 Jan '23

17 Jan '23

VERY IMPORTANT: 2022.12 will require a special procedure if you are not upgrading from 2022.11 Make sure you read the release notes for all the versions between the one you are using now, and 2022.12! We are happy to announce the availability of Uyuni 2022.12. Most openSUSE mirrors should already have 2022.12, 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.12, including the release notes, documentation, requirements and setup instructions. This is the list of highlights for this release: - Indications for systems requiring reboot or with a scheduled reboot - Notification messages via email - Monitoring: Grafana update to 8.5.15 - Subscription warning notifications - Limit changelogs at repositories metadata to the last 20 entries - Drop legacy way to prevent disabling local repositories at bootstrap scripts 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.12. As always, we hope you will enjoy Uyuni 2022.12 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

5 5

Canceled: Uyuni Community Hours
by Julio Gonzalez 16 Dec '22

16 Dec '22

Dear Community: The December session of the Community hours will be skipped, as a lot of people is away because of the winter holidays. See you again in January, or at Gitter/Mailing lists. Happy hacking!

1 0

IMPORTANT: Security Patch for Uyuni Server 2022.11
by Julio Gonzalez 13 Dec '22

13 Dec '22

Hello! The SUSE security team detected a security problem that caused the proxy password to be present at the browser log, when using the Uyuni Server via WebUI. A patch for Uyuni 2022.11 is now available, and we recommend you apply it as soon as possible, without waiting for the next release (that obviously will include it as well. You can apply the patch at the Uyuni Server by following the instructions at: https://www.uyuni-project.org/pages/patches.html If you are still on 2022.10 or earlier, update first to 2022.11 normally (make sure you read the release notes, as special steps required if you are not on 2022.10 already), and then apply the patch as explained above. Happy hacking! -- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez(a)suse.com

1 0

OES 2023 repos
by Nick Fletcher 10 Dec '22

10 Dec '22

Hi, I'm fairly new to Uyuni and I am evaluating it as a better solution than Micro Focus SMT. I've entered my Micro Focus credentials and I can see all the OES 2018 products but not OES 2023, which I can see on my Micro Focus SMT server. Will OES 2023 appear eventually or do I need to do anything in particular to add these products? I couldn't see anything about this in the documentation. Thanks, Nick

4 10

IMPORTANT: Patch for Uyuni Server 2022.11 and Amazon Linux repository syncing
by Julio Gonzalez 02 Dec '22

02 Dec '22

Hello! A user has reported that after the update to Uyuni 2022.11, running spacewalk- repo-sync would fail with a permissions error, when trying to sync certain amazonlinux core channels. If you are affected, repository syncing will fail, and you will see errors similar to those reported at: https://github.com/uyuni-project/uyuni/issues/6244 This was due to a change in a script used by repo-sync, which checked if pages claiming to be mirrorlists were of the right media type. The check was overzealous and excluded some valid types of pages. A patch for Uyuni 2022.11 is now available, in case you are affected, so you do not need to wait for the next Uyuni release. You can apply the patch at the Uyuni Server by following the instructions at: https://www.uyuni-project.org/pages/patches.html If you are still on 2022.10 or earlier, update first to 2022.11 normally (make sure you read the release notes, as special steps required if you are not on 2022.10 already), and then apply the patch as explained above. Thanks to eins for the report and the help debugging the issue. Happy hacking! -- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez(a)suse.com

1 0

AW: Prob with spacewalk-common-channels
by Crefeld, Tobias LKV Bayern e.V. 01 Dec '22

01 Dec '22

Hi Julio, this vhost configuration didn't belong to Uyuni. Starting to evaluate Uyuni, we had the idea to add Netbox on the same system to provide data like ip-adresses, etc. for automated installations. It didn't work and afterwards we forgot this software installation. It was based on a tar file so there is no rpm entry for this application but after removing the respective configuration file from /etc/apache2/vhosts.s/ (+ 2 services + directory in /opt) it shouldn't disturb any more. Regards, Tobias Crefeld. -----Ursprüngliche Nachricht----- Von: Julio Gonzalez via Uyuni Users [mailto:users@lists.uyuni-project.org] Gesendet: Mittwoch, 30. November 2022 17:54 Glad to see things are working again :-) Was that a vhost configuration generated by you? I'd assume yes, as nobody else reported similar issues But if you can't recall, or if you are sure that's not yours, then if you still have the filename, please run rpm -qf <full_path> To see if it's owned by any package we provide (<full_path> being the path where file was) Thanks!

1 0

AW: AW: Prob with spacewalk-common-channels
by Crefeld, Tobias LKV Bayern e.V. 30 Nov '22

30 Nov '22

Hi Julio, the hint with the apache was helpful! It turned out that there was an old vhost configuration. No idea why it didn't cause troubles in the past and why there is a problem now but after removing the respective vhost config spacewalk-common-channels works as expected now. Afterwards spacewalk-repo-sync populated the channel and mgr-create-bootstrap-repo terminated without missing packages. -----Ursprüngliche Nachricht----- Von: Julio Gonzalez via Uyuni Users [mailto:users@lists.uyuni-project.org] Gesendet: Dienstag, 29. November 2022 17:31 I'd expect the HTTP 400 from the Uyuni API, and some logs at /var/log/hrn, but maybe somehow the problem is at Apache. Try to check `/var/log/apache2/` or even the output of `journalctl` (as root).

2 1

AW: Prob with spacewalk-common-channels
by Crefeld, Tobias LKV Bayern e.V. 29 Nov '22

29 Nov '22

Hi Julio, Thanks for you advise! I tested with different credentials including wrong ones - same return code. And yes, this is the user I defined during initial setup of Uyuni 2 years ago. There is no change of the log files in /var/log/rhn/ when I start the command including rhn_web_api.log that usually shows activity whenever I work with the repository management. Other commands like spacewalk-repo-sync or spacewalk-remove-channel work fine. If we talk about http return codes my understanding is, that code 400 is indicating malformed client requests. I will run the update to 2022.11 within the next few days hoping that this will fix the DB-warnings at least. But actually I fear that this won't fix the issue with spacewalk-common-channels Regards, Tobias Crefeld. -----Ursprüngliche Nachricht----- Von: Julio Gonzalez via Uyuni Users [mailto:users@lists.uyuni-project.org] Gesendet: Montag, 28. November 2022 16:05 An: 'users(a)lists.uyuni-project.org' <users(a)lists.uyuni-project.org> Cc: Crefeld, Tobias LKV Bayern e.V. <Tobias.Crefeld(a)lkv.bayern.de>; Julio Gonzalez <jgonzalez(a)suse.com> Betreff: Re: Prob with spacewalk-common-channels Since you are on 2022.08, I'd recommend updating to 2022.11 already (be ware of the manual steps required, carefully read the release notes) For the PostgreSQL log, I seem to remember it was something not harmful, but that was fixed on 2022.10. For the spacewalk-common-channels, I am not sure, but it could be there were some fixes at the API. In any case, since you see an error HTTP 400 Bad Request, you should also be able to see something at /var/log/rhn/ that explains why the request was incorrect. Does this problem happen if you use the first user created when you installed Uyuni?

3 2

Prob with spacewalk-common-channels
by Crefeld, Tobias LKV Bayern e.V. 28 Nov '22

28 Nov '22

Hi, the command spacewalk-common-channels -n sles15-sp3-uyuni-client returns SUSE Manager username: lkvadmin SUSE Manager password: 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> lkvbayern is SUSE Manager Administrator and Organization Administrator, being created during initial system setup. I tried another user-ID with the same credentials - same result. There is another fault. Don't know if it is related to the problem with spacewalk-common-channels described above: journalctl -f -u uyuni-check-database.service Nov 28 14:28:01 lkv-srvapp39 spacewalk-startup-helper[8717]: at /usr/lib/perl5/vendor_perl/5.26.1/Spacewalk/Setup.pm line 29. Nov 28 14:28:01 lkv-srvapp39 spacewalk-startup-helper[8700]: Your database schema already matches the schema package version [uyuni-reportdb-schema-4.3.5-1.21.uyuni2]. Nov 28 14:28:01 lkv-srvapp39 spacewalk-startup-helper[8700]: Schema upgrade: [uyuni-reportdb-schema-4.3.5-1.21.uyuni2] -> [uyuni-reportdb-schema-4.3.5-1.21.uyuni2] Nov 28 14:28:01 lkv-srvapp39 spacewalk-startup-helper[8726]: Prototype mismatch: sub Spacewalk::Setup::idn_to_ascii: none vs ($;$$) at /usr/lib/perl5/5.26.1/Exporter.pm line 66. Nov 28 14:28:01 lkv-srvapp39 spacewalk-startup-helper[8726]: at /usr/lib/perl5/vendor_perl/5.26.1/Spacewalk/Setup.pm line 29. Nov 28 14:28:01 lkv-srvapp39 spacewalk-startup-helper[8738]: Prototype mismatch: sub Spacewalk::Setup::idn_to_ascii: none vs ($;$$) at /usr/lib/perl5/5.26.1/Exporter.pm li System is running Uyuni 2022.08 on opensuse-15.4. Any idea how to get spacewalk-common-channels running? A result of the fault is that "mgr-create-bootstrap-repo" and therefore "Bootstrapping" isn't successful any more. Regards, Tobias Crefeld.

2 1

IMPORTANT: Patch for Uyuni Server 2022.11
by Julio Gonzalez 25 Nov '22

25 Nov '22

Hello! Several users at Gitter and GitHub have reported that after the update to Uyuni 2022.11, they see a notification whith an error message after a reposync for any channel is complete. The error will contain a python stacktrace as described at https://github.com/uyuni-project/uyuni/issues/6193 Uyuni 2022.11, includes a refactor for the System list page to use a dedicated cache table to improve performance. Because of this refactor, each time a repository is synchronized, we need to refresh the information for the minions using such repository. The query that processes such refresh had a bug, and was referring a non- existing reference. A patch for Uyuni 2022.11 is now available, in case you are affected, so you do not need to wait for the next Uyuni release. You can apply the patch at the Uyuni Server by following the instructions at: https://www.uyuni-project.org/pages/patches.html If you are still on 2022.10 or earlier, update first to 2022.11 normally (make sure you read the release notes, as special steps required if you are not on 2022.10 already), and then apply the patch as explained above. Thanks to all users that reported the issues, and helped with the debugging. Happy hacking! -- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez(a)suse.com

1 0

spacewalk-repo-sync failed after update 2022.10 to 2022.11
by Thomas Weis 24 Nov '22

24 Nov '22

hello everyone After updating from 2022.10 to 2022.11, after running spacewalk-repo-sync -p opensuse_leap15_4-x86_64, the process aborted with an error. The following error message was generated: 12:26:52 Repo URL: http://download.opensuse.org/distribution/leap/15.4/repo/oss/ 12:26:52 Packages in repo: 96026 12:34:39 No new packages to sync. 12:34:40 12:34:40 Patches in repo: 0. 12:34:45 12:34:45 Importing media products file products. 12:34:45 *** NOTE: Importing mediaproducts file for the channel 'opensuse_leap15_4-x86_64'. Previous media products will be discarded. 12:42:56 Updating overview of 1 systems Traceback (most recent call last): File "/usr/lib/python3.6/site-packages/spacewalk/server/rhnSQL/driver_postgresql.py", line 299, in _execute_wrapper retval = function(*p, **kw) File "/usr/lib/python3.6/site-packages/spacewalk/server/rhnSQL/sql_base.py", line 182, in _execute return self._execute_(args, kwargs) File "/usr/lib/python3.6/site-packages/spacewalk/server/rhnSQL/driver_postgresql.py", line 322, in _execute_ self._real_cursor.execute(self.sql, params) psycopg2.errors.UndefinedTable: missing FROM-clause entry for table "c" LINE 4: coalesce(c.org_id, 1), ^ During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/usr/bin/spacewalk-repo-sync", line 286, in <module> sys.exit(abs(main() or 0)) File "/usr/bin/spacewalk-repo-sync", line 269, in main elapsed_time, channel_ret_code = sync.sync() File "/usr/lib/python3.6/site-packages/spacewalk/satellite_tools/reposync.py", line 705, in sync self.update_servers() File "/usr/lib/python3.6/site-packages/spacewalk/satellite_tools/reposync.py", line 739, in update_servers taskomatic.add_to_system_overview_update_queue(row["id"]) File "/usr/lib/python3.6/site-packages/spacewalk/server/taskomatic.py", line 103, in add_to_system_overview_update_queue h.execute(sid=sid) File "/usr/lib/python3.6/site-packages/spacewalk/server/rhnSQL/sql_base.py", line 150, in execute return self._execute_wrapper(self._execute, *p, **kw) File "/usr/lib/python3.6/site-packages/spacewalk/server/rhnSQL/driver_postgresql.py", line 309, in _execute_wrapper raise sql_base.SQLStatementPrepareError(str(self.dbh), e.pgerror, self.sql) spacewalk.server.rhnSQL.sql_base.SQLStatementPrepareError: ('ERROR: missing FROM-clause entry for table "c"\nLINE 4: coalesce(c.org_id, 1),\n ^\n', "<connection object at 0x7f1c42cd6a08 ; dsn: 'user=uyunidbuser password=xxx dbname=uyuni', closed: 0>", "\n INSERT INTO rhnTaskQueue (org_id, task_name, task_data, priority, earliest)\n VALUES (\n coalesce(c.org_id, 1),\n 'update_system_overview',\n %(sid)s,\n 0,\n current_timestamp\n )\n ") After that it was completely canceled. The update from 2022.10 to 2022.11 ran without errors, the webgui is accessible. what can be done Restore from snapshot? Thanks for support! Regards Thomas

3 3

file.directory and user.present: how to configure dependencies
by Heiner Wulfhorst 24 Nov '22

24 Nov '22

Hi List, I am having trouble configuring dependencies between the existence of a user and his homedir ( a mounted lv ). If I put the user as a requirement for the chown (file.directory) I get a python error: "RecursionError: maximum recursion depth exceeded while calling a Python object". How should I do it? Here's my current code: sapinst: group.present: - gid: 200 sapsys: group.present: - gid: 201 daaadm: user.present: - require: - group: sapsys - group: sapinst - mount: /usr/sap/DAA - uid: 1112 - gid: 201 - home: /usr/sap/DAA - groups: - sapinst chown_/usr/sap/DAA_to_daaadm: file.directory: - name: /usr/sap/DAA - user: daaadm - group: sapsys - require: - user: daaadm Thanks a lot, Heiner

1 0

Uyuni 2022.11 is released!
by Julio Gonzalez 23 Nov '22

23 Nov '22

VERY IMPORTANT: 2022.11 will require a special procedure if you are not upgrading from 2022.10 Make sure you read the release notes for all the versions between the one you are using now, and 2022.11! We are happy to announce the availability of Uyuni 2022.11. Most openSUSE mirrors should already have 2022.11, 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.11, including the release notes, documentation, requirements and setup instructions. This is the list of highlights for this release: - Instructions to disable custom channel automatic synchronization - Allow more tools for network management for the Uyuni Server - Monitoring: Grafana update to 8.5.13 - Monitoring: Fix TLS configuration and enable client certificate authentication for Blackbox exporter - Traditional stack being removed 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.11 As always, we hope you will enjoy Uyuni 2022.11 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

3 5

IMPORTANT: Refresh of the Uyuni 2022.11 release notes
by Julio Gonzalez 23 Nov '22

23 Nov '22

Hello! Some users reported two issues: # System list showing empty after the update See: https://www.uyuni-project.org/doc/2022.11/release-notes-uyuni-server.html#_… # Rocky Linux 9 onboarding fails to complete See: https://www.uyuni-project.org/doc/2022.11/release-notes-uyuni-server.html#_… As you can see, we refreshed the release notes at the website. If you want to have them refreshed at your Uyuni Server, we also released the refreshed release notes as a Patch, but keep in mind this is not strictly needed. You can apply the patch at the Uyuni Server by following the instructions at: https://www.uyuni-project.org/pages/patches.html Thanks to all users that reported the issues, and helped with the debugging. Happy hacking! -- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez(a)suse.com

1 0

IMPORTANT: Patch for Uyuni Server 2022.10
by Julio Gonzalez 14 Nov '22

14 Nov '22

Hello! ################################################# WARNING: Instead of running `zypper up` as provided by the instructions at the website, we strongly recommend using `zypper up|tee /tmp/update.log` or similar, so you can find errors during the migration in the unlikely event they happen ################################################# Several users at Gitter and GitHub have reported that after the update to Uyuni 2022.10, and after applying the patch from last week, Cobbler had problems to start because templates files were not found, so some features were broken, such as: - Onboarding new clients - Removing existing clients - Autoinstallation In such cases you can see errors in Cobbler like: cobbler.cexceptions.CX: 'serializer: error loading collection profile: Invalid automatic installation template file location /var/lib/cobbler/templates/ xxxxxxxxxxxx.cfg, file not found This problem was caused because the "autoinstall" attribute for the Cobbler collections was wrongly migrated at the time of running the migration from the old Cobbler collections from version 2 to version 3, making Cobbler not able to find the "templates" files for the profiles anymore. Any subdirectory was removed from the "autoinstall" attribute. For "Autoinstallation" profiles generated using Uyuni, the "autoinstall" files are generated and placed by Uyuni at "upload/" and "wizard/" subdirectories of `/var/lib/cobbler/templates/`. These Cobbler collections and templates files (for Uyuni created profiles) are recreated by Uyuni in case they are missing, on every spacewalk-services restart. With this new upgrade, we have fixed the migration of the "autoinstall" attribute from Cobbler collections, and make the migration to run again in order to fix any possible inconsistency created by the execution of the wrong migration from the previous patch, so Cobbler will be now able to find the "autoinstall" templates and finish the startup. The migration will run automatically during the upgrade, if there is any unexpected issue during the migration you should see some errors when zypper is updating "cobbler" or "spacewalk-setup" packages. In the unlikely event there are still some conflicts for the `.cfg` files, you will get instructions provided by the upgrade, to fix the issue. A patch for Uyuni 2022.10 is now available, in case you are affected, so you do not need to wait for Uyuni 2022.11 (this version will also include this fix). You can apply the patch at the Uyuni Server by following the instructions at: https://www.uyuni-project.org/pages/patches.html (please be aware of the WARNING at the beginning of this email!) Thanks to all users that reported the issues, and helped with the debugging. Happy hacking! -- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez(a)suse.com

1 0

IMPORTANT: Security patches and feature patches for Uyuni Server 2022.10
by Julio Gonzalez 04 Nov '22

04 Nov '22

Hello! ### Cobbler migration Some users have reported that after the Update to Uyuni 2022.10, there are still some problems related to Cobbler, where collections are not migrated, so the cobbler service fails to start at the Uyuni Server. In such situations some features can be broken, such as: - Onboarding new clients - Removing existing clients - XML-RPC via HTTP - spacecmd - spacewalk-common-channels This is not happening for most users, but we are now releasing a patch to address it, and migrate any collections provided by any past cobbler version. ### File descriptors leakage Some users reported that, after updating to Uyuni 2022.10, and after some days, the Server stopped working, and they saw a steady increase of "open files" or "allocated file descriptors". This was caused after the migration to log4j2. Every time a taskomatic job object gets created, it initializes its own logger programmatically to write its logs into a file. The lifecycle of a job object is relatively short, but the log4j2 runtime doesn't know it. When it gets permissions to write into a file, there's nothing to release it after the job is over. Moreover the log4j2 keeps track of loggers based on the class names. It effectively means we mutate the same logger object in memory over and over again with every new taskomatic job. The fix adds functionality to re-initialize the logger when a new job comes around, dropping any file handler it has. ### Security fixes During a SUSE Manager and Uyuni security audit, the SUSE security team reported three vulnerabilities at the spacewalk-java source package (which provides spacewalk-java-* or spacewalk-taskomatic packages): * CVE-2022-31255: Fix directory path traversal vulnerability * CVE-2022-43754: Fix reflected cross site scripting vulnerability * CVE-2022-43753: Fix arbitrary file disclosure vulnerability You can find more details at: https://www.suse.com/security/cve/CVE-2022-31255.html https://www.suse.com/security/cve/CVE-2022-43754.html https://www.suse.com/security/cve/CVE-2022-43753.html A patch for Uyuni 2022.10 to fix all the issues was just published, and because of the security issues, it is strongly recommended you update your server, even if you are not affected by the cobbler migration issues or the file descriptors leakage. You can apply the patch at the Uyuni Server by following the instructions at: https://www.uyuni-project.org/pages/patches.html Thanks to all users that reported the issues, and helped with the debugging. Happy hacking!

1 0

Query about config management best practice.
by Simon Avery 04 Nov '22

04 Nov '22

Hello, I've got a query about best practice for config management. We have several Configuration Channels, each with a bunch of files in. Machines are subscribed to appropriate channels based on role and distro. We want to push those files out daily to subscribed machines, replacing any that have been edited on-server. We currently achieve this with a bash script on the Uyuni vm, called by crontab overnight, using "spacecmd -y -- configchannel_forcedeploy channelname" This works fine, but I'm wondering if that's the best way, as it's configured and monitored only outside of the webui? Forcing a regular high state appears to push those files, plus updates the .repo files and generally getting things as Uyuni thinks they should be. The recurring schedule seems to be designed to do this. But I can't see a way to automatically set a recurring schedule? Whilst I can set one for existing machines using SSM, I can't see a way to add one via Activation Key nor automatically enroll all machines into setting a highstate once a day or so. How do others approach this? Is there a gui way, or should I stick with the spacecmd route? S

1 0

Uyuni webui stops responding.
by Simon Avery 27 Oct '22

27 Oct '22

Hi Has anyone encountered an issue with Uyuni where the web interface becomes unresponsive? I've never had this happen before in at least a couple of years usage, but over the past couple of weeks we've had it happen several times to different users and when it happens, it affects all users. The user's web browsers report that no data is sent on page link or reload. Manually running "spacewalk-service restart" brings it back into life within a couple of minutes. This isn't related to the 2022.10 update, since I've held back applying that so far and we're still on 2022.08. The only thing that's changed is a couple of new users, and perhaps something is taking exception to them. (But we're all on similar chrome + windows clients) I've not yet done any serious debugging (each time the priority has been to get it back up), but would appreciate any tips from anyone that's encountered this. (I'll try and remember to run "spacewalk-service status" next time to at least identify which service is faulting) Thanks Simon

3 4

clients can't connect to uyuni server, JWT token
by Haupt, Torsten 25 Oct '22

25 Oct '22

Hi, since some time my clients can't contact the uyuni server. A "zypper ref" shows for example: zypper ref Permission to access 'https://xxxuyuni.xxx.de:443/rhn/manager/download/sle12_5-utilities-x86_64/r…' denied. Abort, retry, ignore? [a/r/i/...? shows all options] (a): i Last contact time in uyuni is also a long time ago. If I copy the url above in a browser, it get: Token is not valid to access repomd.xml in sle12_5-utilities-x86_64: JWT (claims->{"exp":1652861921,"iat":1621325921,"nbf":1621325801,"jti":"kufB_AaMdzSgIr92uq9cfA","org":1,"onlyChannels":["sle12_5-utilities-x86_64"]}) rejected due to invalid claims. Additional details: [The JWT is no longer valid - the evaluation time NumericDate{1666073380 -> 18.10.2022, 08:09:40 MESZ} is on or after the Expiration Time (exp=NumericDate{1652861921 -> 18.05.2022, 10:18:41 MESZ}) claim value.] It seems a token is to old; but how to renew it? Greets Torsten

4 5

Canceled: Uyuni Community Hours
by Julio Gonzalez 24 Oct '22

24 Oct '22

Dear Community: This Friday most of the SUSE Manager team will not be available, including the moderators, so we need to cancel this session. We'll see you in the November session, and meanwhile remember the Community is available at the mailing lists, Gitter and GitHub. Sorry about the inconvenience!

1 0

IMPORTANT: Patch for Uyuni Server 2022.10
by Julio Gonzalez 24 Oct '22

24 Oct '22

Hello! Several users at Gitter have reported that after the Update to Uyuni 2022.10, and after applying the patch from last week, that the cobbler package fails to update, or that the cobbler service is not starting at the Uyuni Server. In such situations some features can be broken, such as: - Onboarding new clients - Removing existing clients - XML-RPC via HTTP - spacecmd - spacewalk-common-channels The problem was causes because of bugs at migration scripts for cobbler itself. Such bugs are only happening for long time Uyuni users where the cobbler configuration is old enough, so most users should not notice this problem. If you are affected, you will see the following error while installing the cobbler package: > schema.SchemaError: Key 'proxy_url_ext' error: > None should be instance of 'str' Or the following error at the logs, when starting cobbler: > cobblerd[32057]: schema.SchemaError: Key 'allow_duplicate_hostnames' error: > cobblerd[32057]: 0 should be instance of 'bool' The fix is at the SR: https://build.opensuse.org/package/rdiff/systemsmanagement:Uyuni:Master/cob… (an OBS account is required to see the diff) A patch for Uyuni 2022.10 to fix both problems was just published, in case you are affected, and so you do not need to wait for Uyuni 2022.11 (this version will also include this fix) You can apply the patch at the Uyuni Server by following the instructions at: https://www.uyuni-project.org/pages/patches.html Thank to all users that reported the issue, and helped with the debugging Happy hacking! -- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez(a)suse.com

1 0

Disconnected Setup with SMT results in "java.io.FileNotFoundException: /path/to/product_tree.json"
by Srinidhi B 20 Oct '22

20 Oct '22

Hello List, I'm trying to use the contents of my existing SMT12 setup in Uyuni and I've followed the steps documented at: https://www.uyuni-project.org/uyuni-docs/en/uyuni/administration/disconnect… But I'm getting the following error when I run "mgr-sync refresh": uyuni:~ # mgr-sync refresh Refreshing Channel families Please enter the credentials of SUSE Manager Administrator. Login: admin Password: [DONE] Refreshing SUSE products [FAIL] Error: <Fault -1: 'redstone.xmlrpc.XmlRpcFault: unhandled internal exception: com.suse.scc.client.SCCClientException: java.io.FileNotFoundException: /media/SMT/repo/disconnected-setup/product_tree.json (No such file or directory)'> Detailed steps: =============== We use a NFS mount for our SMT servers. On the same NFS mount, I created a new sub-directory called "disconnected-setup" and ran the following two commands: # smt-sync --createdbreplacementfile /tmp/dbrepl.xml # smt-mirror --dbreplfile /tmp/dbrepl.xml --directory /srv/www/htdocs/repo/disconnected-setup/ --fromlocalsmt -L /var/log/smt/smt-mirror-export.log # ls -l /srv/www/htdocs/repo/disconnected-setup/ total 11848 -rw-r--r-- 1 smt www 2 Oct 3 00:07 organizations_orders.json -rw-r--r-- 1 smt www 10006809 Oct 3 00:07 organizations_products_unscoped.json -rw-r--r-- 1 smt www 1744853 Oct 3 00:07 organizations_repositories.json -rw-r--r-- 1 smt www 341708 Oct 3 00:07 organizations_subscriptions.json drwxr-xr-x 4 smt www 4096 Oct 3 04:28 repo lrwxrwxrwx 1 smt www 9 Oct 3 04:28 SUSE -> repo/SUSE Back on the Uyuni server, I ran: # mount -t nfs storage:/srv/ftp/SMT /media/SMT # echo 'server.susemanager.fromdir = /media/SMT/repo/disconnected-setup/' >> /etc/rhn/rhn.conf # systemctl restart tomcat Could someone please tell me what am I missing? How do I get the "product_tree.json" file generated from the SMT server? Regards, Srinidhi.

2 2

IMPORTANT: Patch for Uyuni Server 2022.10
by Julio Gonzalez 20 Oct '22

20 Oct '22

Hello! Several users at GitHub, mailing lists and Gitter have reported that after the Update to Uyuni 2022.10, cobbler is not starting at the Uyuni Server, therefore affecting some features, such as: - Onboarding new clients - Removing existing clients - XML-RPC via HTTP - spacecmd - spacewalk-common-channels The following bug reports are related to this problem: - https://github.com/uyuni-project/uyuni/issues/6037 - https://github.com/uyuni-project/uyuni/issues/6041 - https://github.com/uyuni-project/uyuni/issues/6045 The problem was caused for a bug at the script for the migration of the settings and collections to Cobbler 3.3.3 The fix is at the PR https://github.com/uyuni-project/uyuni/pull/6050 A patch for Uyuni 2022.10 to fix both problems was just published, in case you are affected, and so you do not need to wait for Uyuni 2022.11 (this version will also include this fix) You can apply the patch at the Uyuni Server by following the instructions at: https://www.uyuni-project.org/pages/patches.html Thank to all users that reported the issue, and helped with the debugging Happy hacking! -- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez(a)suse.com

1 0

no more OES2018 repos in Uyuni after new key for SLES subscriptions
by Thomas Weis 15 Oct '22

15 Oct '22

Hello everyone we synchronize the current OES2018-SP3 repositories via Uyuni. After a maintenance renewal, we received a new key for the SLES subscription because our current subscription could no longer be activated with the existing key. With the new key we can now synchronize all SLES repos within the scope of the subscription again, but obviously all OES2018 repos are missing. I am sure that with the old key all OES2018 repos were listed and could be selected. Are we doing something wrong or does something have to be activated in addition to the new subscription key? Thanks for the support! Thomas Mit freundlichen Grüßen / Kind regards Thomas Weis NTW Netzwerk • Telekommunikation • Datentechnik Burghaldenstrasse 24 D-71336 Waiblingen

2 3