Release notes for Uyuni Server

With this release 2024.10 Uyuni Server is ONLY available as container images. The classic RPM version is not available any more.

These containers images are now built on top of openSUSE Leap 15.6, which means a version bump from 15.5.

In order to migrate a legacy Uyuni Server (RPM based) to an Uyuni Server based on containers, please check the documentation Migrating the Uyuni Server to a Containerized Environment

SUSE Linux Micro 6 is now supported in Uyuni.

For more information about the registration process, refer to the Registration section, and for more information about supported features, consult the Supported Features.

Uyuni 2024.10 now supports managing Ubuntu 24.04 (amd64) clients as both Salt and Salt SSH minions. All features previously available for managing older Ubuntu versions are also functional for Ubuntu 24.04.

For more details about the supported features, check the Client Configuration Guide.

Check the Client Configuration Guide for information about how to manage Ubuntu 24.04 clients with Uyuni 2024.10.

Note: SCAP profiles for Ubuntu 24.04 are not yet available in the scap-security-guide package. Users will need to source and provide the necessary SCAP content from an alternative location to use Uyuni SCAP auditing features for Ubuntu 24.04.

Base POS image templates were updated and POS images built from base templates are now compressed by default.

All API endpoints now return dates in the ISO-8601 format, simplifying the process of chaining API calls where the expected date format is ISO-8601. Please note that this change might require adjustments to your existing scripts to ensure compatibility with the updated date format.

With the 2024.08 release, we removed the restriction on flattening AppStream repositories. This improvement allows users to manage their clients both from Uyuni and directly on the client using DNF if needed.

We had also introduced a new Web UI page under System > Software > AppStreams, where users can enable or disable modules and their streams on the client.

This enhancement now extends to Activation Keys as well. You can configure an activation key with the desired AppStreams modules, and when a client will be onboarded using that Activation Key, the correct AppStream modules will be automatically enabled on that client.

Additionally, this update also introduces addAppStreams and removeAppStreams methods to the ActivationKey namespace, allowing users to configure activation keys and achieve the same through the API.

Uyuni comes with the migrate command to facilitate the upgrade from rpm-based version to containers. However, for large deployments with a substantial number of packages and a large database, the migration process can be complex and time-consuming.

To address this, we’ve added a --prepare option to the mgradm migrate command. This option uses rsync to pre-copy content, significantly reducing the time required for the actual migration. Additionally, the source server doesn’t need to be stopped during this pre-copy phase. Since it uses rsync, this command can be run multiple times without any issues.

During the final migration, services on the source server are stopped, and the migration command is executed to rsync everything once more and perform the necessary transformations.

Uyuni 2024.07 continues to use Salt 3006.0. It is considered by upstream to be a long-term support (LTS) version. Our plan is to upgrade to the next LTS version, which will be 3008.0 when available. Short-term support (STS) versions of Salt are not supported for use with Uyuni.

Throughout this process, all critical bug fixes, including CVEs, L3 fixes, and essential features needed for Uyuni, will be provided.

The database engine has been updated from PostgreSQL 14 to PostgreSQL 16 (actually , which brings a number of performance and reliability improvements. A detailed changelog is available upstream.

Please notice that this comment ONLY refers to the containerized version of Uyuni (and actually the change has been in place since version 2024.03). The legacy RPM-based version continues to use PostgreSQL 14.

Uyuni 2024.07 supports an even wider range of operating systems as clients. The following additional OS releases will be supported in Uyuni 2024.07.

For more information about the registration process, refer Registration section, and for more information about supported features, consult Supported Features.

Repositories are now kept strictly in sync with the upstream repository. For example, when a package is removed from the upstream repo, it is also removed from the channel directly connected to that repo. Cloned channels will remain unchanged unless the admin syncs them with the original parent channel.

Users can disable this behavior for custom channels; however, it cannot be changed for vendor channels.

In the last milestone, we introduced capabilities in Uyuni to support Confidential Computing Attestation via API components for attesting AMD SEV-SNP clients.

With the completion of this milestone, a user-friendly UI has been incorporated to simplify the utilization of this feature for users.

For more information, please refer to the Confidential Computing

Due to the changes introduced in this version, the Uyuni Documentation API has been upgraded from version 26 to 27.

For further details about the API, please refer to the Uyuni API Documentation.

In Uyuni 2024.05 we are continuing the process of cleaning our WebUI and CLI from unused or deprecated features. For more details, please refer to the next subsections.

The uyuni-tools utilities can be now localized. Further improvements are expected in the upcoming versions, but translations can already be provided in a standarized way, and we welcome contributions from the community.

If you want to contribute translating Uyuni in your language, feel free to refer also to our wiki page.

For translating Uyuni, we are using this Weblate instance https://l10n.opensuse.org/projects/uyuni/

Following the integration of modularity and modular repositories in Red Hat Enterprise Linux and its derivatives, Uyuni initially implemented modularity through Content Lifecycle Management (CLM) and the introduction of AppStream filters. These filters effectively removed the modularity features from a repository by flattening it, enabling consumption through the Uyuni UI. However, this approach introduced complexity and limited functionality, prompting the need for a more comprehensive solution.

In the 2024.05 release, we have eliminated the restriction on flattening the AppStream repositories. This enhancement allows users to manage their clients, both from Uyuni and directly from the client using DNF if necessary.

Additionally, a new UI page has been introduced under System > Software > AppStreams. This page enables users to select the modules and their respective streams they wish to enable/disable on the client.

Uyuni 2024.05 also introduces two new API namespaces: channel.appstreams and system.appstreams. These namespaces provide different endpoints that can be used to retrieve more information about available module streams and enable or disable them on a specific system using API.

For further details about these endpoints, please refer to the Uyuni API Documentation.

As of August 31, 2021, upstream Salt 3000 has reached its end of life. Consequently, Uyuni will cease support for Salt 3000. To continue receiving security updates and support, users must migrate their current Salt 3000 Minions to the Salt Bundle. To date, the migration process can be accomplished by utilizing the pre-existing util.mgr_switch_to_venv_minion state from the command-line interface (CLI).

Since Uyuni 2023.09, we have implemented enhancements to make the migration process even smoother for users. Now, the migration will be automatically performed during the first highstate applied, streamlining the overall experience.

Note: We have had this automatic migration feature in place since version 2023.09, but unfortunately, it wasn’t documented in the release notes.

In Uyuni 2024.05, we are introducing a new state to update Salt in recurring states. Additionally, we enhance the detection of needed reboots and the update-to-date state.

These improvements have led to the update of a common workflow for keeping the system up to date with Uyuni.

For more information, please refer to Clients Update Using Recurring Actions workflow in the official documentation.

Following the release of the Confidential Computing Attestation with Uyuni 2024.03, this release enhances the new feature with the inclusion of a new Secure Boot module.

Grafana has been updated from version 9.5.16 to 9.5.18, signifying a minor update that addresses several bugs.

This update also fixes the following security vulnerability:

For detailed information about the fixes and features, you can refer to the following links:

Confidential computing is becoming increasingly crucial in our industry. While there is significant ongoing work in the industry on this topic, Uyuni will play a role in aiding confidential computing attestation. We will adopt a phased approach, starting with a small-scale implementation and gradually expanding. Initially, our offering will be exclusively on AMD-based hardware, aligning with available tools.

Specifically, we’ve incorporated the API components for attesting AMD Secure Encrypted Virtualization - Secure Nested Paging (SEV-SNP). This functionality is compatible with hardware featuring either an AMD EPYC Milan CPU or an AMD EPYC Genoa CPU and it’s available only on x86_64 architecture.

Uyuni’s CVE audit feature scans systems and images for known security vulnerabilities (CVEs), providing administrators with visibility and enabling prioritization and mitigation based on severity. Previously, it relied on channel metadata to determine system vulnerability, leading to limitations in distinguishing between unaffected systems and those lacking needed patches.

To expand this, we are enhancing the approach by integrating OVAL data provided by the upstream. This helps us avoid false positives and allows for system scanning without the need to synchronize channels. Channel information will continue to be for patch application and remediation.

In Uyuni 2024.03, we’re upgrading to the next LTS version of Java, which is Java 17. This update brings several new features, security enhancements, including support for new TLS versions and improved certificate validation.

Please notice that this change only applies to the containerized version of Uyuni. The rpm-based version is still running Java 11.

For more information on this topic, see https://www.oracle.com/java/technologies/javase/17-relnote-issues.html

With Uyuni 2024.03, golang-github-prometheus-node_exporter has been updated from version 1.5.0 to 1.7.0

The update includes also several bugfixes and features but no breaking changes.

Please note that supervisord and ntp collectors have been deprecated in version 1.6.0 and they will be removed in future versions.

Check the upstream changelogs for more details:

This release of Uyuni fixes the following vulnerabilities for Ansible:

Please note that this update introduces the following breaking change: Assert - Nested templating may result in an inability for the conditional to be evaluated.

See the porting guide for more information.

Following CVEs have been fixed with this release:

For clients that were set up using a SSH key, their key is temporarily kept in the /srv/susemanager/salt/salt_ssh/ directory. In this directory, there is also some more sensitive information. As /srv/susemanager/salt/ is part of the Salt file system, there is a risk that any Minion could potentially access this sensitive data, which they should not be able to do. What we are doing with this release, is moving this sensitive information away from this directory so that no Minion can request this data. This provides the fix for CVE-2023-32189.

To eliminate the possibility of any Minion accessing an unintended key, we strongly advise users to rotate the keys and carry out the following steps.

While Uyuni facilitates most system operations, there are instances where users may need to execute arbitrary remote commands. Although executing remote commands from Uyuni is a powerful feature, it comes with inherent risks. If used without proper understanding, it can potentially lead to undwanted system states. Remember, with great power comes great responsibility.

In this Uyuni release, a new configuration, java.disable_remote_commands_from_ui=false, has been introduced. Users can modify it by adding this property to rhn.conf with the desired value. This empowers users to disable the feature for all users if deemed unnecessary or if it poses a risk. It’s important to note that this feature is enabled by default, emphasizing the need for users to consider its implications and adjust the settings accordingly.

With Uyuni 2023.10 we introduced the availability of the Uyuni Server as container image and Helm Chart.

Unfortunately, the aarch64 version was not available at that point of time, which has been fixed now with this new release.

For more information about the prerequisites, how to install and configure, please consult the dedicated initial documentation.

With Uyuni 2024.02, start, stop and restart commands were added to one the Uyuni tools used to handle the containers: mgradm.

Previously, when bootstrapping a SUSE Linux Enterprise Server Micro client, Uyuni would automatically schedule a reboot. We have now removed this feature. Moving forward, please manually reboot the SUSE Linux Enterprise Server Micro client after bootstrapping to complete the onboarding process.

Uyuni now extends its support to an even broader range of operating system releases. Starting with version 2024.01, openEuler 22.03 will be supported.

openEuler 22.03 is the first community LTS release of openEuler and it is now supported as a client.

The supported architectures are x86_64 and aarch64. The Uyuni Client Tools repositories to be used are the same as Enterprise Linux 8.

For general details on the registration process, please refer to the Registration section. To learn more about supported features, consult the Supported Features section in our documentation.

For specific details on the registration process, please consult the Registration section in our documentation.

In the upcoming 2024.01 release, we are happy to announce that Uyuni will accurately indicate the need for a reboot across all supported distributions. This enhancement ensures that if a restart is necessary, be it due to a kernel update or any other package modifications, Uyuni will clearly display this requirement in the user interface (UI). Users will receive clear and timely notifications about the need for a client restart, enhancing the overall system management experience.

Starting with Uyuni 2024.01, during the creation (or editing) of a recurring state, if multiple systems are part of the entity, a list that allows for selection of individual systems will be displayed.

While Uyuni facilitates most system operations, there are instances where users may need to execute arbitrary remote commands. Although executing remote commands from Uyuni is a powerful feature, it comes with inherent risks. If used without proper understanding, it can potentially lead to undwanted system states. Remember, with great power comes great responsibility.

In this Uyuni release, a new configuration, java.disable_remote_commands_from_ui=false, has been introduced. Users can modify it by adding this property to rhn.conf with the desired value. This empowers users to disable the feature for all users if deemed unnecessary or if it poses a risk. It’s important to note that this feature is enabled by default, emphasizing the need for users to consider its implications and adjust the settings accordingly.

As an improvement for the containerized Uyuni Server, the livenessProbe and the readinessProbe provide a more accurate status of the pod to Kubernetes.

The official security support for Debian 10 ended on September 10th, 2022.

After a grace period of more than a year, Uyuni 2024.01 is stopping support for this operating system.

While existing client tools repositories will not be removed, they will not get updates.

As for the code, it will not be broken on purpose, but it will not get tested for Debian 10 anymore, so even if Uyuni 2024.01 can still manage Debian 10, this can break at any further release.

All remaining users with Debian 10 systems are encouraged to migrate to Debian 11 or Debian 12 as soon as possible.

Uyuni now extends its support to an even broader range of operating system releases. Starting with version 2023.12, the following additional operating system releases will be supported:

For details on the registration process, please refer to the Registration section. To learn more about supported features, consult the Supported Features section in our documentation.

Starting with Uyuni 2023.12, we introduce a new filter in Content Lifecycle Management (CLM) that enables users to filter packages according to their build time. With this addition, users can conveniently filter packages based on the timing of their build, enhancing the efficiency and precision of package management within CLM.

CVE-2023-22644 has been addressed. The resolution for CVE-2023-22644 addresses three interconnected issues as follows:

This update fixes the following CVE for Salt:

With Uyuni 2023.10 we are delighted to announce the availability of the Uyuni Server as container image and Helm Chart.

This new way to run the Uyuni Server is the continuation of the work initially done for the Uyuni proxy and Retail Branch Server, made available with Uyuni 2022.04.

For more information about the prerequisites, how to install and configure, please consult the dedicated initial documentation.

With the release of the Uyuni Server as image, we are also providing the so called uyuni-tools, intended for helping users administer and manage the new Uyuni Servers.

Please note that the tools could be renamed in the future, even if the features available will be kept.

As per today, we provide:

For more information about the available features, please consult the README file.

The API response of errata.getDetails now returns two extra booleans.

reboot_suggested boolean flag signals whether a system reboot is advisable following the application of the errata. A typical example is upon kernel update.

In the same way, restart_suggested boolean flag signals whether reboot of the package manager is advisable following the application of the errata. This is commonly used to address update stack issues before proceeding with other updates.

The config file rhn_java.conf provides the option java.reboot_delay defining the number of minutes to wait before performing a system reboot. The used value should be >= 1 because a value of 0 would cause a direct shutdown which makes it impossible for Salt to return the result back, resulting in a failed action. Its default value is java.reboot_delay = 3

The action Create user uses a different logic than all the other events to send e-mails and it doesn’t respect users' e-mail preferences. This enahancement removes users that have e-mail notifications off from the recipient list when sending user creation e-mails.

Grafana has been updated from version 9.5.5 to 9.5.8, signifying a minor update that addresses several bugs.

For detailed information about the fixes and features, you can refer to the following links:

The saltkeys namespace now accepts GET requests instead of POST for the following endpoints:

WARNING: This release updates the base OS from openSUSE Leap 15.4 to openSUSE Leap 15.5 and there are special steps required. You need at least Uyuni 2023.04 already installed to perform the upgrade, and you need to follow the major upgrade procedure for the Server. More details are also available at the "Update from previous versions of Uyuni Server" section below.

WARNING: This release updates the Salt version for Master and Minions to a next major release. Make sure you update the Uyuni Server before updating the clients, as backward compatibility of Minions against an older Master is not guaranteed

The base operating system has been upgraded to openSUSE Leap 15.5.

Please notice that openSUSE Leap 15.5 and SUSE Linux Enterprise Server 15 SP5 have been previously enabled as beta, and now their stable version is supported.

Salt has been upgraded to upstream version 3006.0, plus a number of patches, backports and enhancements by SUSE, for the Uyuni Server, Proxy, and Client Tools.

Salt 3006.0 is the first LTS release of Salt based on the newly defined release strategy. The purpose of the LTS release is to provide users with a stable version of Salt for a longer period.

Following CVEs have been fixed for Salt with this Maintenance Update. - CVE-2023-20897 - bsc#1214796 bsc#1213441 - CVE-2023-20898 - bsc#1214797 bsc#1193948

For more details about this release, see the Salt 3006.0 upstream release notes.

WARNING: This release updates the Salt version for master and minions. Make sure you update the Uyuni Server before updating the clients, as stated here https://docs.saltproject.io/salt/install-guide/en/latest/topics/upgrade.html

Salt Bundle 3006.0 will be available for all supported clients.

The non-bundle version of Salt requires Python 3 installed by default, and it will not be available for:

When a highstate is performed, all the unsupported Salt 3000 clients will be automatically migrated to the Salt bundle in its latest release.

Salt version 3006.0 introduced a significant regression that led to communication issues between Salt Minions and the Salt Master. These communication problems manifest in two distinct ways:

Both Salt Minion (classic) and Salt Bundle are impacted by these issues.

This update provides the necessary fix to address the communication problems. However, there is a minor caveat to consider. Installing this update on Salt Minions carries a high probability of causing the previously mentioned job result loss. Consequently, the Uyuni action responsible for updating the Salt Minion may remain in a permanent "pending" state until manually canceled. To be clear, we expect this to be a one-time issue happening when this update is installed. Subsequent interactions with Salt Minions are expected to function without any problems.

IMPORTANT: We strongly advise upgrading the Salt Minion (classic or Salt bundle) on all Minions, ideally as a separate action. Please note that this action may remain in a pending state as expected. After some time has passed, you can execute a package refresh to verify the successful completion of the update and confirm that the Salt Minion package has been upgraded.

When deleting a Salt SSH managed system, the cleanup state tries to disable and stop the salt-minion process. This can result in a state.apply error which requires a force delete when neither salt-minion nor venv-salt-minion is installed. In case a customer uses salt-minion against an own salt-master, this would disable and remove a working minion.

Ubuntu 18.04 was End of Life on May 31st, 2023.

After a grace period of more than a quarter of a year, Uyuni 2023.09 is stopping support for this operating system.

While existing client tools repositories will not be removed, they will not get updates.

As for the code, it will not be broken on purpose, but it will not get tested for Ubuntu 18.04 anymore, so even if Uyuni 2023.09 can still manage Ubuntu 18.04, this can break at any further release.

All remaining users with Ubuntu 18.04 systems are encouraged to migrate to Ubuntu 20.04 or Ubuntu 22.04 as soon as possible.

In order to achieve optimal performance, we are updating the minimal memory requirement for the server from 8GB to 16GB. To ensure smooth operations, we suggest updating your system accordingly.

In the past, there was a requirement to manually import certificates and entitlement data into the Uyuni Server.

Now, we have streamlined this procedure by integrating the same mechanism employed for SUSE PAYG instances. The PAYG connection regularly communicates with the client to retrieve the most current authentication data. It’s crucial to ensure that the client remains operational and undergoes regular updates.

For more detailed information on this, please refer to the Red Hat Clients - RHUI section in the Uyuni 2023.09 documentation.

Please consult the Known issues section for some issues around this.

Given the widespread usage and advocacy of Ansible by various vendors and tools, it was a logical step to incorporate Ansible integration into Uyuni.

Initially introduced as a Technology Preview in Uyuni 2021.06, we are delighted to announce that starting with Uyuni 2023.09, Ansible integration will be officially supported.

You can now effortlessly utilize and execute your existing Ansible playbooks. This feature not only saves time and resources but also consolidates tools, preserving your prior automation investments. The integration eliminates the need to re-implement your Ansible automation solution, simplifying the migration process.

Furthermore, when combined with Uyuni’s powerful Salt capabilities, it enhances the configuration and automation functionalities of the platform. This comprehensive solution empowers you to efficiently orchestrate even the most complex environments, spanning across both cloud and on-premise infrastructure.

For more detailed information on this integration, please refer to the Ansible Integration section in the Uyuni documentation.

SUSE provides temporary fixes for all currently supported solutions delivered directly to its customers. These PTFs (Program Temporary Fixes) are now available as repositories, which can be synced in Uyuni. This enables users to conveniently install the PTFs on clients wherever necessary, directly from Uyuni.

For more information about this feature, see the dedicated section about Using PTFs in Uyuni.

Note: PTF packages are currently only supported for SUSE Linux Enterprise Server 12 and SUSE Linux Enterprise Server 15 based systems. Other versions or operating systems do not have this feature yet and the related pages are not visible for them.

Our recent focus has been on enhancing automation capabilities, particularly through the recurrent highstate feature. While that capability received positive feedback, it was deemed somewhat restricted. To address this, we have extended the initiative by enabling users to schedule custom states on a recurrent basis. With this new feature, users can now automate their workflows more effectively and efficiently. Users can schedule automated recurring actions for Salt clients both from the WebUI and the API. One can apply recurring action to individual clients, to all clients in a system group, or to an entire organization.

For more information about this feature, see the Recurring Actions section in the administration guide.

Note: We would like to inform our users that the recurringaction namespace in the API has been deprecated. In its place, we have introduced three new namespaces: recurring, recurring.custom, and recurring.highstate. These new namespaces are now available for use and we recommend updating your code to reflect these changes.

Note: As part of this feature, we have also exposed some internal states and a new state called uptodate that helps users to keep clients up to date. Users can combine all these states in any order, but states with a reboot should be scheduled last. Note that the execution order may differ from what it seems if a state includes any ordering or condition using order or requires.

To ensure a consistent view in SCC for clients registered through SUSEconnect, RMT, SMT, and SUSE Manager, a new taskomatic job called system-profile-refresh was introduced specifically for SUSE Manager. This job is necessary to send accurate subscription information to SCC, as up-to-date hardware data is required for that purpose. The task runs once every month on the 15th at 5:00 AM, which may impose some load on the systems. However, no significant performance issues are anticipated during that time.

Uyuni will check in the background for updates or critical security patches available from the official Uyuni channels on a daily basis (via the daily summary taskomatic job). Users are then notified in the UI with a reference to the latest release notes accordingly. The notification shown is currently rather generic and the patch relies on the repository names in order to work, in regards to this first implementation.

Until Uyuni 2023.03, localhost.log, manager.log, host-manager.log, localhost_access_log.txt and catalina.out were rotated with Valve.

Valve does not support archiving, so now the Tomcat logs are configured to rotate with logrotate and support archiving.

The configuration is the same as for the other tomcat logs: weekly rotation, one year of retention and compression enabled.

Together with the password, this Uyuni release also removes the arguments key and content from the API logging, because they could still include sensitive data and should not be exposed in the logs.

openSUSE Leap Micro is an ultra-reliable, lightweight operating system built for containerized and virtualized workloads.

Based on SUSE Linux Enterprise Micro, it leverages the enterprise hardened security and compliance components of SUSE Linux Enterprise. This merging of technologies provides for a modern, immutable and developer-friendly OS platform.

Check the Client Configuration Guide for information about the supported features.

Both products are still beta, and both products will work only using the Salt Bundle (default since Uyuni 2022.12) as otherwise they ship Salt 3005 which is incompatible with the salt master version being used on Uyuni server (the Salt master on Uyuni still uses Salt 3004 as provided by openSUSE Leap 15.4).

This update fixes several security vulnerabilities:

No other bugfixes, features or changelogs are part of this update.

Check the upstream changelog for all the details.

Until Uyuni 2023.01, syncing optional channels was only possible with the CLI tool mgr-sync, but not from the WebUI Setup Wizard.

Starting with Uyuni 2023.03, doing this from WebUI is now possible.

Each product at the Setup Wizard will now allow syncing optional channels, provided that the mandatory channels for the product are already synced.

To enable the optional channels:

This change is only relevant for users using SUSE subscriptions.

Previous versions of Uyuni created a notification each day when a SUSE Customer Center (SCC) subscription was about to expire, starting 90 days before the subscription expiration and 30 days after expiration.

With Uyuni 2023.03 we are addressing the feedback we got about the frequency, and we are changing it to happen weekly, on Mondays.

The warning box at the Dashboard (Home > Overview) will still show up any time there is a subscription expiring in the next 90 days, or expired in the last 30 days.

Upstream Salt 3000 went End of life on August 31, 2021. However, because it was part of the Advanced Systems Management Module of SUSE Linux Enterprise 12 and there was no bundle available for SUSE Manager 4.1, it was still supported.

Salt 3000 will no longer be supported in the context of Uyuni now that both SUSE Manager 4.1 and the Advanced Systems Management Module of SUSE Linux Enterprise 12 are End of Life.

Users are required to migrate existing Salt 3000 minions for SUSE Linux Enterprise Server 12, Red Hat Enterprise Linux 7, CentOS 7, Oracle Linux 7, and Amazon Linux 2 to the Salt Bundle before creating any bug reports.

For more information about performing Salt 3000 to Salt Bundle migrations, please consult the Salt Bundle section in the Client Configuration Guide.

Debian 9 LTS support ended in June 30th, 2022.

After a grace period of more than half a year, Uyuni 2023.03 is stopping support for this operating system.

While existing client tools repositories will not be removed, they will not get updates.

As for the code, it will not be broken on purpose, but it will not get tested for Debian 9 anymore, so even if Uyuni 2023.03 can still manage Debian 9, this can break at any further release.

All remaining users with Debian 9 systems are encouraged to migrate to Debian 10 or Debian 11 as soon as possible.

With Uyuni 2023.03, spacewalk-clone-by-date tool has been deprecated. With CLM (Content Lifecycle Management), we believe users have a better alternative to spacewalk-clone-by-date, which is much more flexible and powerful.

CLM provides a comprehensive API to cover all the important features that spacewalk-clone-by-date tool offers.

With Uyuni 2023.01, we are removing versions older than 2021.12 from the release notes, to make the document smaller and easier to review.

Release notes for older versions, up to 4.0.0 can still be found at the website.

SUSE Linux Enterprise Server Micro is an ultra-reliable, lightweight operating system purpose built for containerized and virtualized workloads. It leverages the enterprise hardened security and compliance components of SUSE Linux Enterprise and merges them with a modern, immutable, developer-friendly OS platform.

Support for SUSE Linux Enterprise Server Micro in Uyuni was added as a tech preview. In the meanwhile, we have made some significant improvements around it to make sure that users get the seamless usability experience in case of an immutable OS such as SUSE Linux Enterprise Server Micro.

Check the Client Configuration Guide for information about the supported features.

Please consult the Known issues section for an issue around SUSE Linux Enterprise Micro support.

Starting with Uyuni 2023.01, AppStream modularity can be disabled by removing the module metadata from the target repositories without having to enable any modules. This can be achieved by using the new none matcher with the AppStream filters.

This new feature is especially useful for AlmaLinux 9, Rocky Linux 9, Oracle Linux 9 or RHEL 9, as default versions of most applications are now served as regular packages.

Check the Administration Guide for more information.

Uyuni 2022.12 brings several improvements to the reboot of the Uyuni clients:

Uyuni shows notification messages on the WebUI, but they are not very useful for those users that do not login very often.

With Uyuni 2022.12, each user can enable such notifications to be delivered via e-mail using the user preferences (checkbox Receive email notifications).

This update fixes several security vulnerabilities:

No other bugfixes, features or changelogs are part of this update.

Check the upstream changelog for all the details-

Uyuni 2022.12 will show notifications at the Overview page now, when SUSE subscriptions are about to expire or have already expired.

This will not affect users not using SUSE subscriptions.

Until 2022.11, Uyuni added all the changelog entries for all packages to the generated metadata for each repository generated at the Uyuni Server. This caused the file others.xml.gz to be very big in some situations, and therefore increasing the time it takes to synchronize the metadata on the Uyuni clients.

Starting with Uyuni 2022.12, this is now limited to 20 entries for each package by default for new packages. Already synced packages will keep the whole changelog.

This change is only about the repository metadata and will not affect the packages themselves, which will keep the complete changelogs.

If you want to go back to keeping all the changelog entries, increase the number of entries, or apply the new default for all existing packages. For that check the Administration Guide.

In the past, using DISABLE_LOCAL_REPOS=0 with the bootstrap script allowed users to keep local repositories enabled after registration.

This feature can be accomplished with Salt, for any kind of onboarding (WebUI, API, Bootstrap script, etc.), as explained at the Client Configuration Guide.

The System list page has been refactored to be more optimized and can handle thousands of systems with a breeze.

For this we had to add a new database table to store the cached system data.

This table is updated every hour by the update-system-overview-default task and within a minute after data for any of the systems is changed.

As a side effect, the System list will be empty after the server upgrade until the refresh is triggered.

To force a refresh before the top of the hour, run the update-system-overview-default task manually in Admin > Task Schedules page. Keep in mind that processing this task can take some time depending on how many systems are present in the database.

We intend to automate the initial refresh during during the Uyuni Server update in a future release, for people that are still upgrading from versions older than 2022.11

The new page has also introduced a more advanced filtering of the data. Though quite powerful, the user interface for the value selection is still rough and requires knowing what to query. While this has been temporarily been worked around by keeping the old links in the Systems List menu, we expect improvements for the interface in a future release.

Since Uyuni 2022.10, the custom channels are now synced automatically.

By default, a synchronization will start automatically after adding a new repository to a custom channel. Moreover, they will all update daily as a part of the mgr-sync-refresh-default scheduled task.

To disable this new feature and revert back to the old behavior, you can set in /etc/rhn/rhn.conf:

Custom Channels section of the Administration guide for information about the custom channel synchronization.

Until now, the Uyuni Server only supported Wicked for network management, because of a problem at the uyuni-check-database service.

With Uyuni 2022.11, this problem is fixed and now any other tool such as NetworkManager can be used.

Uyuni 2022.03 updates Grafana from version 8.3.5 to 8.5.13.

This update fixes several security vulnerabilities:

Check the upstream changelog for all the details on what has changed.

There is one breaking change: - For a data source query made via /api/ds/query, if the DatasourceQueryMultiStatus feature is enabled and the data source response has an error set as part of the DataResponse, the resulting HTTP status code is now 207 Multi Status instead of 400 Bad gateway.

Updating Grafana is strongly recommended.

Uyuni 2022.10 and previous versions were using basic authentication for the Blackbox exporter scrapping, even though using TLS client certificates was enabled at the prometheus-formula

With Uyuni 2022.11, the Prometheus formula adds a section for the Blackbox exporter with TLS certificate and key for client certificate authentication.

Uyuni 2022.06 was the last version where traditional client tools were tested to work, and it was announced that with Uyuni 2022.08 the traditional client tools will be deprecated and removed at some point after the summer.

Uyuni 2022.11 is already removing code for the traditional clients, so this version will not support traditional clients in any way. New deployments will not work and existing deployments will not work either. If you still have traditional clients and they still work normally, you need to migrate them to Salt before updating to Uyuni 2022.11.

WARNING: This release requires vendor changes for some Uyuni dependencies at the server, so pay attention to the following instructions!

Because of bug at zypper, it could be that --allow-vendor-change is broken on your system. This can apply even if you are still on Uyuni 2022.05 or earlier (based on openSUSE Leap 15.3)

Make sure you manually update zypper first at the Uyuni Server with zypper ref && zypper in zypper, and then verify that the installed zypper version is 1.14.57 or newer (use zypper info zypper).

Then:

Uyuni is now able to manage RHEL/Oracle Linux/AlmaLinux/Rocky Linux 9 as Salt or Salt SSH minions. All other features that worked for previous versions of RHEL/Oracle Linux/AlmaLinux/Rocky will work now too, with the exception of the Prometheus Exporters.

The following architectures can be managed:

Check the Client Configuration Guide for information about how to configure the Uyuni Server to work with RHEL/Oracle Linux/AlmaLinux/Rocky Linux 8 clients.

The Client Tools for Ubuntu 22.04 now contain four exporters:

With these tools all of the features available for previous Ubuntu versions are available at 22.04

The Salt Bundle now includes support for pip, allowing users to extend the functionality of the bundled Salt Minion with extra Python packages.

Check the official SaltStack documentation on how to do it as a module and a state.

Keep in mind that not all of the functions are available with the state, but the missing functionality can still be accessed with module.run.

Uyuni 2022.10 updates the Prometheus exporter for Apache from version 0.7 to version 0.10.0 for SUSE Linux Enterprise and openSUSE, including the Uyuni Server, the Uyuni Proxy and the Uyuni Retail Branch Server.

Check the upstream release notes for more details, including new metrics.

Cobbler was updated from version 3.1.2 to version 3.3.3.

For the complete list of changes, see the upstream release notes:

A backup of old Cobbler settings file will be created at /etc/cobbler/settings.before-migration-backup and old collections backup under /var/lib/cobbler/.

Uyuni is now able to manage Ubuntu 22.04 clients as Salt or Salt SSH minions. All other features that worked for previous versions of Ubuntu will work now too, with the exception of the Prometheus Exporters and package vendor identification, which will be part of a future Uyuni release (for now, Prometheus Exporters are available in the Universe repositories).

The following architectures can be managed:

Check the Client Configuration Guide for information about how to configure Uyuni Server to work with Ubuntu 22.04 clients.

Uyuni is now taking care of trusting the required GPG keys on the clients, in order to install packages from assigned channels

The GPG key URL can be defined for Software Channels which will be used to find the key needed for that channel.

When the channel is assigned to the client the key will be trusted on repository refresh or when installing a package out of the channels.

For more information, check the documentation.

To prevent problems with local defined repositories providing wrong or unwanted packages, we disable now all these repositories as the first step in bootstraping.

Additionally we try to keep local repositories disabled and perform this in the channel state which is also used during highstate.

For more information, check the documentation.

Deploying Proxy and Retail Branch Servers as containers is now also possible using a Helm chart.

For more information check this README file. The information will be part of the Uyuni official documentation in a future release.

WARNING: The container images configuration has a new format and it is now packaged as tar.gz file. All previously deployed container Proxies and Retail Branch Servers will need to get their configuration regenerated and deployed again before pulling these images.

WARNING: This release updates the base OS from openSUSE Leap 15.3 to openSUSE Leap 15.4 and there are special steps required. You need at least Uyuni 2021.06 already installed to perform the upgrade, and you need to follow the major upgrade procedure for the Server. More details are also available at the "Update from previous versions of Uyuni Server" section below.

WARNING: This release updates the Salt version for Master and Minions to a next major release. Make sure you update the Uyuni Server before updating the clients, as backward compatiblity of minions agains an older master is not guaranteed

WARNING: With Uyuni 2021.12, we announced the future deprecation of the Traditional client tools. Uyuni 2022.06 is the last release that supports them. Starting with Uyuni 2022.08, the traditional client tools will be deprecated as we will start removing the code at some point after the summer. Do not use traditional for any new deployments of clients or proxies, and start migrating your traditional clients to Salt.

The base operating system has been upgraded to openSUSE Leap 15.4.

The database engine has been updated from PostgreSQL 13 to PostgreSQL 14, which brings a number of performance and reliability improvements. A detailed changelog is available upstream.

To prevent inconsistent configurations and data on upgrade or update, Uyuni 2022.06 refuse to start until the database migration from PostgreSQL 13 to PostgreSQL 14 has been completed successfully.

Salt has been upgraded to upstream version 3004, plus a number of patches, backports and enhancements by SUSE, for the Uyuni Manager Server, Proxy, and Client Tools.

We intend to regularly upgrade Salt to more recent versions.

For more details about changes in your manually-created Salt states, see the Salt 3004 upstream release notes.

Salt Bundle 3004 will be available for all supported clients.

The non-bundle version of Salt requires Python 3 installed by default, and it will not be available for:

The reporting database schema is now fully documented.

The documentation describes the schema in detail, showing all the tables and the views available and highlighting the relationships among them.

You can access it from the Uyuni Server WebUI, at Help > Report Database Schema, from the left navigation bar.

Starting with Uyuni 2022.05, spacewalk-report will use the data from the report database by default. This change affects both new and updated setups.

This means that the new generated reports will differ in the structure and the format of the data and might break existing integrations.

If this change causes trouble in your use case, the new option --legacy-report can be used to fallback to the old report engine.

For a comprehensive list of what is changed and what reports are affected, see the section "Generate Reports" at the Administration Guide.

It is now possible to select and add systems that failed or completed actions, with a new button Add Selected to SSM that shows for the actions at "Completed Systems" and "Failed Systems".

You can the find the actions at the Uyuni Server WebUI, at Schedule on the left navigation bar.

This can be useful to fix issues with systems that failed to complete actions, or to run more actions on those that completed them.

With Uyuni 2022.05, in addition to the current XML-RPC API, a new JSON over HTTPI API will also be provided to make Uyuni API even easier to consume.

Uyuni is seeing more and more use in automated scenarios, where it is a part of a bigger system and driven via its APIs.

The XML-RPC protocol has served users well so far and will continue to do so, but HTTP APIs are more in demand and have better tooling support.

The API documentation has been updated to reflect the changes to support the HTTP API, and is available at the Uyuni Server WebUI under About > API, and at the website

Usage examples can be found in the "Sample scripts" section of the documentation.

With the addition of the JSON over HTTP API documentation:

The Salt Bundle is now used to handle Salt SSH executions on the client side. The bootstrap of new Salt clients using WebUI or API is now also using the Salt Bundle.

To ensure bootstrap works in the proper way, the bootstrap repositories for the clients must be regenerated before bootstrapping new clients.

The bootstrap repository regeneration happens for any given product when a resync for the product repositories happens:

To manually trigger the regeneration, use the tool mgr-create-bootstrap-repo at the Uyuni Server.

Starting with Uyuni 2022.04, it will be possible to run the Uyuni proxy and Retail branch server also in containers. This could be very helpful in scenarios where adding new virtual machines is not feasible for some reason.

Additionally, the ability to run Uyuni Proxy and Retail branch servers in containers make it more flexible to run them anywhere without worrying about the underlying OS, while also making it possible to get the advantage of Kubernetes offerings like HA.

The following improvements have been made in the reporting database

Uyuni 2022.04 comes with a lot of improvements for image management.

HTTP Strict Transport Security (HSTS) is a policy mechanism that helps to protect websites against man-in-the-middle attacks such as protocol downgrade attacks and cookie hijacking.

Uyuni 2022.04 allows enabling HSTS. Which means each request will need to be HTTPS while plain HTTP requests will be rejected.

To enable it for the Uyuni Server:

To enable it for the Uyuni Proxy

IMPORTANT: If you enable HSTS while using the default SSL certificate generated by Uyuni, or a self-signed certificate, some browsers will refuse to connect using HTTPS unless the CA used to sign such certificates is trusted by the browser. If you are using the SSL certificate generated by Uyuni, you can trust it at the servers by using the file located at http://<UYUNI-SERVER-HOSTNAME>/pub/RHN-ORG-TRUSTED-SSL-CERT

Fixes for the following security issues have been released: CVE-2022-22934, CVE-2022-22935, CVE-2022-22936, CVE-2022-22941.

You should patch your Salt master at the Uyuni Server and minions as soon as possible. Please take the next section into account when upgrading the Salt.

To properly upgrade Salt with the fixes for the latest CVEs, and avoid breaking the communication between for Salt master and minion, you need to upgrade your "salt-master" first and then continue upgrading your Salt minions.

In case that a Salt minion is upgraded with the CVE fixes but your Salt master is not, then the communication between the master and this minion will be broken, and you would see errors like the following in your minion logs:

As soon as your Salt master is upgraded and restarted then the communication between master and minion will be restablished and the errors messages will not longer happen.

Uyuni 2022.03 updates the XML-RPC API version from 25 to 26, in preparation for SUSE Manager 4.3

There are no breaking changes to any methods.

If any of your scripts are checking for the version 25, you can change them to use version 26 without any further changes.

Starting with PostgreSQL 13, some defaults have changed.

To improve performance, smdba autotuning was adapted to use the new values.

Additionally an extra paramater --ssd was added to autotuning to tell smdba that the database is stored on ssd or fast network storage.

To change an existing configuration with the new defaults call

Remember you can also adjust some other parameters, in case you need them:

Uyuni 2022.03 updates Grafana from version 7.5.12 to 8.3.5.

This update fixes several security vulnerabilities:

Updating Grafana is strongly recommended.

Relevant changes are:

Check the upstream changelog for more details on what has changed.

There is one breaking change:

Uyuni does not use Grafana alerting, so if you do not need it, you can disable it at the Grafana WebUI.

If you use legacy Grafana alerting in your environment, consider migrating to new Grafana 8 alerting.

We highly encourage you to migrate your workload to a newer version of each distribution, or to an alternative distribution that is still supported, so you can continue managing your infrastructure with Uyuni.

Please note that we will not break things on purpose for these unsupported products, and there is a possibility that they could still continue to work. But if things break, there will not be any support provided, not even on a best-effort basis, unless someone from the community can step in.

PostgresSQL is changing its default password encryption mechanism from md5 to scram-sha-256.

With this update Uyuni will follow this change and will migrate the database user to this new encryption mechanism.

This should happen fully automated for the existing database user.

The following changes will happen:

In case additional users where created, the passwords must be reseted.

This can be done with the following command on the Uyuni Server executed as "root" user, and exchanging`<DBUSER>` with the right username and <DBPASSWD> with the new password:

The reporting database provides Uyuni data used for reports in a simplified schema, and is accessible by any reporting tool with support for SQL databases as content sources.

This new database is isolated from the one used for the Uyuni Server, and created automatically.

The tool uyuni-setup-reportdb-user can create new users which has read-only access to the data.

For more information on this topic, see Hub reporting.

Uyuni now comes with Ubuntu errata support. It does this by downloading errata information from https://usn.ubuntu.com/usn-db/database.json and matching it after the syncing of Ubuntu channels.

It also adds support for installing errata on Ubuntu systems by mapping them to package installs.

For users, it will be a seamless experience and they will get exactly the same UX as it was for errata management for other distros.

It is now possible to sync content from SUSE-operated Cloud RMT Server from Uyuni. This makes it a lot easier for users with SUSE Linux Enterprise Server PAYG instances because now they don’t need to go through a cumbersome process of getting zero-cost subscriptions.

It works in all three major public clouds AWS, GCP, and Azure.

For more information and instructions on this topic, see the Connect Pay-as-you-go instance.

Uyuni 2022.02 provides the openscap package binaries using the sources from Debian Sid. Debian11 itself does not provide openscap, as it was removed from Debian Testing during Debian 11 development.

This is a Tech Preview and therefore not supported, but we invite the community to provide feedback and will provide updates from the Debian upstream package if needed.

Uyuni is now able to manage Debian 11 clients as salt or salt-ssh minions, as well as all other features that work for previous versions of Debian, with the exception of openscap as it is not available on Debian 11

The following architectures can be managed:

Check the Client Configuration Guide for information about how to configure Uyuni Server to work with Debian 11 clients.

The patch details page now contains a new section Vendor Advisory, which links to the original advisory provided by the vendor of the patch.

This information is auto-generated from data already existing in the database thus, when possible, it will be available for both new and existing patches.

With Uyuni 2022.01, the following providers are supported:

Starting with Uyuni 2022.01, using TCP port 22 for SSH minions is not required anymore, and any TCP port can be used.

It is now possible to change the proxy used by an Uyuni client using the WebUI.

This can be done from the Connection tab at the Details tab for any Salt client, using the new link Change to change the connection type.

Using System Set Manager is supported as well, and can be done from the Misc tab, and then Proxy tab.

NOTE: Changing the connection for a Proxy to move it, is not supported at this moment. The Connectiontab will not show the Change link for proxies.

Salt Bundle is a single package called venv-salt-minion containing the Salt Minion, Python and all Python modules. It is exactly the same version and codebase for the current salt-minion RPM package.

The Salt Bundle can be used on systems that already run another Salt Minion, that do not meet Salt’s requirements or already provide a newer salt version that is used instead of the version provided by Uyuni.

Starting with Uyuni 2021.12, Uyuni is able to bootstrap systems with Salt Bundle for all the supported operating systems.

On bootstrapping new clients the Salt Bundle package will be used instead of salt-minion, if the package venv-salt-minion is present in the bootstrap repo.

Clients already registered will not be changed, but can be switched to Salt Bundle with applying the state util.mgr_switch_to_venv_minion to them. For more information see the Client Configuration Guide.

Uyuni 2021.12 adds support for the aarch64 (ARM64) architecture for the following operating systems:

It is now possible to re-activate a system using the UI/XMLRPC-API of Uyuni which was only possible using bootstrap script before. The bootstrapping page UI has been extended and the user can now enter the reactivation key of the system and the UI/XMLRPC-API of Uyuni will take care of the rest.

The same could be achieved from the XMLRPC API.

With Uyuni 2021.12, on the login page, a banner will be shown when available disk space on the server will be running low. This will help users avoid situations like the automatic shutdown of Uyuni when disk space is critically low, without even noticing it.

Package locks are used to prevent unauthorized installation or upgrades of software packages. In the past the package lock feature was only available for traditional clients. Now it is also available for Salt clients (SUSE, RHEL and clones, and Debian/Ubuntu).

Check the Package Locking documentation for information about how to use this feature.

From the Content Lifecycle Management project view, the new column Last build has been added. This information is useful when you need a general overview of all latest build times rather than retrieving the information project by project.

Following new XMLRPC methods have been added in SaltKey namespace.

These methods could further help in improving the automation workflows.

A security fix for CVE-2021-40348 is included as apart of Uyuni 2021.08, to fix a potential injection arbitrary code to a root-owned file that eventually will be executed by the system.

The fix for this problem was previously released on October 29th as a patch on top of Uyuni 2021.09, but if you did not apply such patch yet, we recommend appling the update to Uyuni 2021.12 as soon as possible.

CentOS 8 will be End of Life on December 31st, 2021. Uyuni support for this product will end as well.

Please refer to support section for more information.

With Uyuni 2021.12, we announced the future deprecation of the Traditional client tools.

Uyuni 2022.06 is the last release that supports them.

Starting with Uyuni 2022.08, the traditional client tools will be deprecated as we will start removing the code at some point after the summer.

Do not use traditional for any new deployments of clients or proxies, and start migrating your traditional clients to Salt.