VERY IMPORTANT: 2023.01 will require a special procedure if you are not
upgrading from 2022.12 Make sure you read the release notes for all the
versions between the one you are using now, and 2023.01!
We are happy to announce the availability of Uyuni 2023.01. Most openSUSE
mirrors should already have 2023.01, 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 2023.01, including the
release notes, documentation, requirements and setup instructions.
This is the list of highlights for this release:
- Release notes cleanup
- SUSE Linux Enterprise Micro support as client
- Content Lifecycle Management: Disabling modularity for AppStream
repositories
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 2023.01.
As always, we hope you will enjoy this new Uyuni version 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
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
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!
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
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
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
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
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
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
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.htmlhttps://www.suse.com/security/cve/CVE-2022-43754.htmlhttps://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!