ARCHIVED: Uyuni Users

Download

users@lists.uyuni-project.org

November 2022

8 participants
12 discussions

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