Release notes for Uyuni Server

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 behaviour, 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.

Additionlly 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 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 Python3 installed by default, so 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 the Uyuni. This makes it a lot easier for users with SLES 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 supportes 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 content lifecycle project page in the WebUI has been further improved. This page now provides AppStreams with a default filter template. This template creates a module filter for each module in the repository, and specifies the default stream for each module.

Uyuni 2021.09 fixes a number of inconsistencies in date time handling related to time zones by always using the IANA standard format.

A few pages at the Admin menu still show the old format, and will be adapted with the next Uyuni versions.

Uyuni 2021.09 now supports the new advisory status pending as used by the EPEL7 and 8 repositories.

Virtualization in Uyuni has received some enhancements:

Added new commands to "spacecmd" to allow massive archive and delete actions:

This allows bypassing the Web User Interface display limit.

In addition to fixing Fixed Remote Code Execution in the XMLRPC API which additionally allowed arbitrary file read and write as root, this release includes the fixes for CVE-2021-40323, CVE-2021-40324, CVE-2021-40325.

Uyuni is now able to manage Rocky Linux 8 clients as salt or salt-ssh minions, as well as all other features that work for CentOS 8 or AlmaLinux 8.

Rocky Linux OS intends to fill the gap that will exist after CentOS 8 Stable is End of Life by the end of 2021. According to the Rocky Enterprise Software Foundation "Rocky Linux is a community enterprise operating system designed to be 100% bug-for-bug compatible with America’s top enterprise Linux distribution now that its downstream partner has shifted direction."

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

For now the following architectures are supported: x86_64

Support for Rocky Linux 8 will continue to improve, including support for other architectures.

Ansible Playbooks can now run in test mode.

Known issue: When running a playbook in test mode using an Ansible control node that is registered as SSH minion in Uyuni, then the action is always reported as failed, even if it succeeds.

It is now possible to pass custom kiwi parameters in an OS Image profile.

This can be particularly helpful for selecting a specific profile when passing the option (--profile <profilename>) to Kiwi files containing multiple profiles.

Uyuni 2021.08 now collects more information about CPU for AArch64 systems. That, together with some more fixes, make virtualization features usable on AArch64 systems.

Virtual machines can now be created with UEFI support from the web interface.

Starting with Uyuni 2021.08, creating a virtual machine on a Pacemaker cluster node defines the resource on the cluster. The cluster-managed virtual machines can also be live migrated using the Uyuni web interface.

Content Lifecycle Management got a new filter template to setup Live Patching based on an existing system.

The OpenSCAP XCCDF scan UI supports now more options and additional OVAL files can be defined. Supported options are:

You can provide additional OVAL files paths to prevent using --fetch-remote-resource when the file is locally available.

Starting with Uyuni 2021.08, all Salt SSH clients will have a log at /var/log/salt-ssh.log, as well as log rotation configured for it.

Uyuni 2021.08, includes Inter-Server Synchronization version 2. This new version allows exporting software channels between servers without the previous notions of master and slave. Unlike the previous Inter-Server Synchronization, no mandatory direct connection between servers is needed since data are exported and imported in a disconnected mode.

Check the (new Inter-Server Syncronization 2 documentation for more information.

WARNING: This release updates the base OS from openSUSE Leap 15.2 to openSUSE Leap 15.3 and there are special steps required. You need at least Uyuni 2020.07 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.

Salt has been upgraded to upstream version 3002, plus a number of patches, backports and enhancements by SUSE, for the Uyuni Server, Proxy and Client Tools (where the client operating system supports Python 3.5+; otherwise Salt 3000 or 2016.11 are used).

Salt 3002 only works with Python 3.5+, therefore:

We intend to regularly upgrade Salt to more recent versions.

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

The base system was upgraded to openSUSE Leap 15.3.

The Uyuni Proxy and Retail Branch Server can now be installed on top of openSUSE Leap 15.3 JeOS edition.

The database engine has been updated from PostgreSQL 12 to PostgreSQL 13, 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  2021.06 will refuse to start until the database migration from PostgreSQL 12 to PostgreSQL 13 has completed successfully.

Please note the database migration from PostgreSQL 12 will rebuild the database indices. This may take several hours if you have thousands of software channels.

After openSUSE Leap 15.3 GA, two new repositories we added as part of Maintenance Updates, and are now part of spacewalk-common-channels as two new channels:

Both channels are available for x86_64 and aarch64 architectures.

You can add them to your Uyuni Server with spacewalk-common-channels, and then sync them.

After the sync is complete, consider adding them to all your openSUSE Leap 15.3 clients.

Configuration and automation platforms have become increasingly important to control an organization’s ever-growing IT landscape. There are a variety of popular tools in the market and companies may have already made investments in a particular tool, one of them being Ansible.

Adopting Uyuni, or migrating to it, does not mean that you should necessarily renounce your previous configuration management systems investment. Uyuni 2021.06 provides support for Ansible packages on SLE and connects to the Ansible control nodes on any supported client operating system to gather inventory, playbooks and manage clients with Uyuni.

Uyuni 2021.06 allows you to simply re-use and run your Ansible playbooks, saving time and resources by consolidating tools while keeping existing automation investments. This means you do not have to re-implement your Ansible automation solution, making migration to the SUSE and openSUSE landscape easier.

Combined with its strong Salt capabilities, it enhances Uyuni’s configuration and automation capabilities helping you to orchestrate even the largest environments – across cloud and on-premise.

Uyuni 2021.05 provides limited support for SLE Micro 5.0 and openSUSE MicroOS clients. The following features work:

Known issues:

SLE Micro and openSUSE MicroOS are only supported as a Salt minion. The traditional stack will not be supported.

The missing features will be added in upcoming releases of Uyuni.

RHEL 6 (and clones: CentOS 6, Oracle Linux 6, SLES ES 6) ended upstream general support on November 30th, 2020. After a grace period of 7 months, we are now ending fixes for these operating systems.

Ubuntu 16.04 LTS ended upstream general support on April 30th, 2021. After a grace period of 3 months, we are now ending fixes for these operating systems.

Please note "ending fixes" means their client tools remain available and can still be added, mirrored and used. But in case they stop working at some point in time, fixes will only be provided as on a best-effort basis (which in general means if the issue can be reproduced with a supported operating system, it will be fixed; but if the issue is specific to the unsupported operating system, a fix should not be expected).

Prometheus and the Prometheus formulas now support TLS and basic authentication for HTTP endpoints. This provides a way to securely transfer metrics data.

Prometheus has been updated from version 2.21.1 to version 2.26.0, which brings a number of bugfixes and improvements (such as securing connections using TLS).

For details on what changed in each version between 2.21.1 and 2.26.0, see:

The "Service Pack Migration" feature has been renamed "Product Migration".

In Uyuni 2021.05, the Product Migration feature allows two different use cases:

Migration between different SUSE Linux Enterprise codestreams (e. g. SLE 12 to SLE 15) is not possible using the Product Migration feature. Use autoinstallation profiles for that.

Migration between non-SUSE products (e. g. from CentOS to AlmaLinux) is not available at the moment.

We have simplified the screens where system groups and configuration channels were assigned by removing the tabs and subtabs. All the information and actions are now in the same screen.

The Content Lifecycle Management filter list screen how allows filter selection, deletion and sorting and search by project.

While the recommended way to manage clients is to install, remove, patch, etc from Uyuni, which triggers the correct actions, sometimes users run the package managers directly. When doing this on Debian and Ubuntu clients, the WebUI showed an outdated package list for some time.

Uyuni now hooks directly into the package manager database on the client to identify local package management and trigger a package refresh from the Server to make sure the list of packages is always up to date.

It is now possible possible to set/get the primary FQDN of a given system.

Virtualization in Uyuni has received a number of enhancements:

Traditional stack clients could receive some custom information via macros but this feature was missing on Salt clients.

In Uyuni 2021.05, we have implemented passing any custom information to Salt clients (both salt-minion and salt-ssh) via pillars:

When an operating system vendor releases a new patch, it might happen that the patch has undesirable side effects (security, stability, boot no longer working, etc) on some scenario that was not identified by testing. When that happens (very rarely), vendors typically release a new patch, which may take from hours to days, depending on the internal processes in place by that vendor.

SUSE has introduced a new mechanism called "retracted patches" to take back such patches in minutes by simply removing the bad patch from the repository metadata and resorting to the previously working patch. These patches receive the advisory status "retracted" (instead of the usual "final" or "stable").

Uyuni now supports retracted paches across all the lifecycle:

Following the behavior defined in zypper:

To protect our users, the behaviour when cloning retracted patches is slightly different than usual:

This feature is only available when you enter your SCC mirroring credentials in Uyuni Server.

Until Uyuni 2021.05, the managed clients were not listed at SCC even if a SCC account was present at the Uyuni Server. This surprised users, who did not understand why clients connected via SUSEconnect, RMT or SMT would show in SCC, but clients connected with Uyuni would not.

Responding to this often-asked question and feature request for both Uyuni and SUSE Manager, we have now implemented client list forwarding to SCC in Uyuni 2021.05.

If you have a SCC account added at your Uyuni Servers, then the clients (even non-SUSE operating systems) managed by Uyuni Server (connected directly or via Proxy or Retail Branch Server) will be listed in SCC.

When a client is removed from Uyuni, it will also be removed from SCC.

The information transferred is limited to that which is already collected and transferred by SUSEconnect, RMT and SMT:

This information is used for statistical and product research purposes only.

In case you want to add your SCC account to Uyuni but completely disable client list submission to SCC, set this parameter in /etc/rhn/rhn.conf and restart Uyuni (spacewalk-service restart):

Display of the client operating system name and version in SCC is pending an upcoming update in SCC.

In Uyuni, configuration may come from many different places: Uyuni itself, configuration channels assigned to your organization, configuration channels assigned to the system groups your clients belong to, configuration channels assigned directly to a client system or formulas with forms.

When managing a large number of clients distributed across several organizations, with multiple system groups, channels, etc, knowing what is exactly the configuration that will be applied may become a daunting task.

In Uyuni 2021.05, we have added the configuration state summary to the Highstate page of the client. With this, you can see exactly where state is coming from.

SUSE Linux Enterprise Live Patching helps customers to bring down reboot cycles to once a year which saves companies a time, resources and availability compared to not using live patching at all.

Setting up Live Patching requires installing specific kernel versions which are enabled for live patches, and installing the specific live patches.

Uyuni 2021.05 implements filter templates, which are a set of pre-defined filters for a specific use case. The first filter template we are including in Uyuni 2021.05 makes it easy to configure live patching for a specific SUSE product (e. g. SLE 15 SP2). New filter templates and additional information about the lifecycle of the live kernel will be added in upcoming versions of Uyuni.

The API documentation is now available in HTML format, in addition to the existing PDF document.

The new HTML API documentation includes a search engine too:
https://www.uyuni-project.org/uyuni-docs-api/uyuni/index.html

New API calls have been added:

The spacecmd commandset has been modified to match the current features of the product:

Activation keys can be used when registering new clients, or re-registering existing clients, to make sure the correct software entitlements, software channels, system groups, etc are applied when they come under Uyuni management.

After a client is registered to Uyuni, activation keys serve no purpose. Software channels, groups, etc can be changed independently from the activation key.

The fact the activation key remained in the System Details led users to think editing the activation key (e. g. changing the software channels assigned to that activation key) would change what was assigned to that client system. This is not true. To avoid that confusion, the Activation Key field has been removed from the System Details of registered clients.

Activation keys can still be used during client registration.

The Software Crashes feature, based on the ABRT library, has been dropped in Uyuni 2021.05. This was a very old feature which only worked on a limited set of clients and required careful configuration to actually submit crash reports to the Uyuni Server instead of upstream projects.

Uyuni 2021.05 introduces some new changes related with the ongoing implementation of Ansible control node management:

We continue to increase the number of Java depencies we use directly from openSUSE.

Before starting the services, make sure you run this command to change the vendor of the xstream package:

zypper install --allow-downgrade --allow-vendor-change -f xstream-1.4.15-lp152.2.3.1

This will also install the packages xpp3 and xpp3-minimal

Uyuni 2021.04 fixes a potential security issue that could allow remote code execution via Java RMI.

This issue only existed on the Uyuni Server if the self-monitoring was enabled.

The access to Java RMI is now limited to localhost.

Uyuni is now able to manage Amazon Linux 2 and Alibaba Linux 2 clients as salt or salt-ssh minions, as well as all other features that work for CentOS 7.

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

For now the following architectures are supported: x86_64

Support for Amazon Linux2 and Alibaba Linux 2 will continue to improve, including support for aarch64 clients.

Uyuni is now able to manage AlmaLinux 8 clients as salt or salt-ssh minions, as well as all other features that work for CentOS 8.

AlmaLinux OS intends to fill the gap that will exist after CentOS 8 Stable is End of Life by the end of 2021. According to the AlmaLinux OS Foundation "AlmaLinux OS is a 1:1 binary compatible fork of RHEL® 8"

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

For now the following architectures are supported: x86_64

Support for AlmaLinux 8 will continue to improve, including support for other architectures as they are added to AlmaLinux.

Scheduling Maintenance Windows is now easier:

The following XMLRPC API methods have been deprecated for a long time and are removed as part of Uyuni 2021.04:

Bootstrap scripts can include an activation key to directly assign software channels, configuration channels, entitlements, etc to a system while registering.

Reactivation keys can be used to re-register a previously registered client and regain all Uyuni settings. For example, to move clients registered to the Uyuni Server to being registered through an Uyuni Proxy (or Retail Branch Server), when reinstalling, and in some other cases.

Uyuni now supports the combination of reactivation keys and bootstrap scripts. Specify a reactivation key in the bootstrap script to re-register systems. For example, if your Uyuni Server has too many clients directly attached and you want to bulk move them to a Uyuni Proxy (or Retail Branch Server).

Subject Alternative Name (SAN) is an extension to X.509 that allows various values to be associated with a security certificate using a subjectAltName field. This is commonly used to generate SSL certificates that protect multiple domains with a single certificate.

These kinds of certificate are becoming popular amongst users with their own Certificate Authority, so we have implemented support.

The Universe Security, Multiverse, Restricted, and Backport channels for Ubuntu 16.04, 18.04 and 20.04 are now part of spacewalk-common-channels. They can now be added to Uyuni Server for synchronization, and can be added to Ubuntu clients.

The Oracle Unbreakable Enterprise Kernel channels are now available at spacewalk-common-channels for Oracle Linux 6, 7, and 8.

The add packages to channel feature has been optimized, resulting in a faster experience in the WebUI when adding packages from another channel.

A number of database queries and error conditions have been optimized, particularly in pages related to software installation and patching. This has resulted in a faster experience in the WebUI.

Redfish is a suite of specifications that deliver an industry standard protocol for the management of servers, storage, networking, and converged infrastructure.

Uyuni now supports power management using Redfish, in addition to the existing IPMI power management.

Mass-auditing Salt clients with OpenSCAP is now possible from the System Set Manager.

The virtual networks page allows creating libvirt virtual networks with most supported configuration values.

mgr-create-bootstrap-repo will now log under /var/log/rhn/mgr-create-bootstrap-repo and will rotate the log files daily, keeping an history of 30 days. Clean up any leftover log file in /var/log/rhn/mgr-create-bootstrap-repo.* by archiving or deleting them.

This release includes the fixes for CVE-2020-28243, CVE-2020-28972, CVE-2021-3148, CVE-2021-25281, CVE-2021-25282, CVE-2021-25283, CVE-2021-3144, CVE-2021-25284, CVE-2021-3197 and CVE-2020-35662

The fixes affect your Uyuni Server, Proxy, Retail Branch Server and Salt minions, so we recommend appling the fixes as soon as possible.

The formula for Prometheus exporter’s formula can now be used with Ubuntu clients.

Besides the regular update, you will need to execute the following command to change the vendor for some Java dependencies:

zypper install --allow-downgrade --allow-vendor-change -f apache-commons-cli-1.4-lp152.1.3.noarch apache-commons-jexl-2.1.1-lp152.1.1.noarch apache-commons-el-1.0-lp152.2.3.1.noarch

If you do not do this, the WebUI will not start and you will get an HTTP 404 error.

In some rare cases, Uyuni suggested that users upgrade Ubuntu packages with an older version than the one currently installed (for example, suggesting installation of libtre5-0.8.0-3+deb7u1ubuntu1 instead of libtre5-0.8.0-3ubuntu1).

Starting with Uyuni 2021.02, the algorithm used for comparing package versions has been separated for RPM and deb packages. Having two algorithms for comparing packages means that deb packages in Ubuntu are now correctly ordered, and work as successfully as the RPM package algorithm. This means that the rare case explained above no longer occurs, and any proposed update is correct and should be performed.

This update also fixes problems syncing Ubuntu and Debian channels and repositories.

IMPORTANT: You need to plan this update. The database changes require updating the EVR information (epoch, version, release) for all packages. Depending on the specifications of your Uyuni installation, the number of channels, and onboarded instances, the services will take between 30 minutes and several hours while the schema is migrated.

SUSE Linux Enterprise Server for SAP applications is the best operating system to run your SAP workloads.

Tthis release of Uyuni includes content which provides added value to SLES for SAP users:

The formulas and Salt state modules are included in the Uyuni Server channel. The Grafana dashboards are included in the Uyuni Client Tools for SLE 12 and SLE 15 channels.

Unsupported clients are now handled gracefully and mitigations have been added for the Xen hypervisor.

Vendor change (changing the repository where a package comes from) can now optionally be enabled during service pack migration.

This feature is useful where the client system is using unofficial packages and you want to move back to official packages, or to switch from an official package to a third-party version of a package. Instead of performing the SP migration within the same vendor and then manually installing the package from the new vendor, you can now do everything in a single action.

This feature is available for SUSE Linux Enterprise 12 or newer, and can also be used to migrate from openSUSE Leap 15 to SUSE Linux Enterprise 15.

Autoinstallation provisioning is now compatible with GRUB and ELILO in addition to GRUB2 only, which is useful when provisioning SLES 11 SP4 and RHEL 6 (and clones) systems.

Oracle Unbreakable Linux Network repositories are now supported in Software > Manage > Repositories. Oracle Linux users with a subscription from Oracle can use this to manually add the repositories for KSplice and others.

CentOS 6 reached end-of-life on November 30th, 2020, and the CentOS Project moved its repositories to the vault archive. URLs at spacewalk-common-channels for new Uyuni Servers. For existing Uyuni servers the database migration will take care of updating the URLs at the database.

Other operating systems in the same class also reached end-of-life but require no change, since they will continue to work as-is: Oracle Linux 6 (URLs not changed) and Red Hat Enterprise Linux 6 (URLs are provided by users).

The countries and timezones list have been refreshed, adapting to the latest timezone and geopolitical changes.

When upgrading a cluster, the upgrade plan is now shown in the WebUI. This makes it easier to verify that an upgrade will be conducted as expected.

The formulas that make autoinstallation of SLES and openSUSE systems simpler have been upgraded to the latest version provided by the Yomi project. The updated formulas are more intuitive, harder to misuse, and allow you to specify additional advanced options.

The WebUI and the CLI commands no longer provide an option to disable SSL. The option was in fact already obsolete and not working.

This release includes the fixes for CVE-2020-16846, CVE-2020-17490 and CVE-2020-25592 that we already released on November 16th for Uyuni 2020.09.

If you did not apply the patch already, update your Uyuni Server, Proxy, Retail Branch Server and Salt minions as soon as possible.

Uyuni can now manage CentOS7 and CentOS8 ppc64le clients. Supported features are the same available for x86_64 clients.

The reverse-proxy Exporter Exporter, which allows you to expose a single port no matter how many exporters are running on the client, is now available for CentOS, Oracle and RHEL 7 and 8 for both x86_64 and ppc64le.

The following operating systems will receive version 1.0.1:

All the changes can be found at the changelog for the package, or at https://github.com/prometheus/node_exporter/releases/tag/v1.0.0 and https://github.com/prometheus/node_exporter/releases/tag/v1.0.1

Keep in mind this new version includes some breaking changes:

Uyuni now supports themes. Users can select what theme they want to use in the User Preferences page in the Web UI. Initially, we are providing three themes:

Administrators can globally disable themes in /etc/rhn/rhn.conf by listing which themes they want to allow:

The reverse-proxy Exporter Exporter, which allows you to expose a single port no matter how many exporters are running on the client, is now available for Ubuntu 20.04 LTS.

New APIs have been added to do IPMI power management. Redfish power management will be included in a future maintenance update.

It is now possible to add third-party errata information to CentOS and Ubuntu 20.04 LTS channels without cloning them, as described at the CentOS Clients section of the Client Configuration Guide.

The known issue present in previous releases of Uyuni has been fixed.

In Uyuni 2020.03, we automated the generation of bootstrap repositories on channel sync. Bootstrap repositories were not only autogenerated but also autoflushed, which caused disappearing packages problems to some users (e. g., in the case of multi-architecture bootstrap repositories).

Starting with Uyuni 2020.11, bootstrap repositories are not flushed by default. If you want to save some disk space, you can manually flush them using mgr-create-bootstrap-repo --flush.

With the update of ISC bind to version 9.16.6 on openSUSE Leap 15.1 and openSUSE Leap 15.2, DNSSEC is now enabled by default, which may cause DNS resolution to fail unless there are fallback DNS servers.

The Retail Branch Server formula has been modified to disable DNSSEC, and will be updated to support DNSSEC in a future release of Uyuni. For existing Retail Branch Servers, you can disable DNSSEC to retain the same behaviour ISC bind showed until version 9.11.2. To do that, edit /etc/bind and set:

Creating a virtual machine using the Web UI and the Salt virt states can now use a defined Autoinstallation profile, any defined cobbler profile like the Yomi one. The virtual machine can also be created using PXE or by adding a CDROM device with an attached ISO image.

The Uyuni Web UI and command-line tools are now available in Japanese thanks to the upstream Uyuni Community.

Since this is a community translation, it is not enabled by default. In order to allow users to select Japanese in their User Preferences in the Web UI, add the following line to /etc/rhn/rhn.conf:

A restart of Tomcat is required.

Starting with Uyuni 2020.09, the Uyuni Hub XML-RPC API is no longer considered a tech preview, but a fully supported feature.

This means that multiple peripheral servers (other Uyuni Servers) can be managed from a single Hub node, as a supported feature.

This version of Uyuni includes formulas that can be installed on a Hub node to manage the following on peripheral servers:

To use the formula, run zypper in uyuni-config-formula on the Hub node, and then enable the formula for the peripheral servers, and use it to manage them.

This feature will be documented at the Large Deployments Guide in a future Uyuni release.

The new maintenance windows feature allows you to schedule sensitive actions (like package installation or upgrade) to occur during a scheduled one-time or recurrent maintenance window period on selected systems. These actions are forbidden to be executed outside of the specified period.

Maintenance windows are defined using iCalendar data, which can be exported from your favorite calendaring tool (Microsoft Outlook, KDE Organizer, Google Calendar…​).

For more information about Maintenance windows check the Administration Guide

Prometheus fetches metrics using a pull mechanism, so the server must be able to establish TCP connections to each exporter on the monitored clients.

The new monitoring reverse proxies feature allows you to simplify your firewall configuration. By installing the reverse proxy on the clients you can get all the metrics for all the exporters on a single TCP port.

Check the Monitoring section of the Administration Guide for information about how to set up.

Monitoring reverse proxies are only available for SLE12, SLE15, and openSUSE Leap 15 families of products, and not yet available for other operating system platforms, including Red Hat Enterprise Linux and Ubuntu. Support for other operating system platforms will come in future releases of Uyuni

In Uyuni 2020.09, we have added a new type of Virtual Host Manager in order to gather virtual machines from Nutanix AHV infrastructure.

Creating a VHM to gather virtual instances from the Nutanix AHV enables the subscription matcher to match 1-2 virtual machines subscriptions for those instances that are running on the same virtualization host.

For more information about how to setup this new type, see the Client Configuration Guide

Note that this feature requires the virtual-host-gatherer-Nutanix package.

Grafana has been updated from version 7.0.3 to 7.1.5 which brings a number of bugfixes and improvements.

Notable improvements:

A detailed changelog is available upstream.

WARNING: Check "Update from previous versions of Uyuni Server" section below for details, as this release updates the base OS from openSUSE Leap 15.1 to openSUSE Leap 15.2, and there are special steps required.

The migration will be performed allowing vendor changes, so this upgrade will fix the issues with python3-psycopg2 mentioned at Uyuni Server 2020.05 release notes. Therefore you will not need to perform the manual steps mentioned there.

Salt has been upgraded to upstream version 3000, plus a number of patches, backports and enhancements by SUSE, for the Uyuni Server, Proxy and Client Tools. In particular, CVE-2020-11651 and CVE-2020-11652 fixes are included in our release.

As part of this upgrade, cryptography is now managed by the Python-M2Crypto library (which is itself based on the well-known OpenSSL library).

We intend to regularly upgrade Salt to more recent versions.

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

Please note Salt 3000 is the last version of Salt which will support the old syntax of the module.run module.

WARNING - POSSIBLE ACTION REQUIRED: The syntax for Salt module.run state has changed starting in next Salt 3001 (Sodium) release. This means, any custom SLS file or "Configuration State Channel" that is using module.run state needs to be adapted to fit into the new syntax. This turns even more problematic when you have minions with different Salt versions, because some minions would accept the new syntax but others would fail with it, so the SLS files would require extra logic to handle the different Salt versions & configurations.

To make this process much easier, we have introduced this new mgrcompat.module_run compatibility state, which is essentially a wrapper of module.run which accept the deprecated syntax and takes care of tailoring the parameters for the actual module.run if necesasary according to the particular minion version and configuration. The only thing to do would be to change module.run to `mgrcompat.module_run in your SLS files and "Configuration State Channels".

As an example of this, a non-migrated state like this:

would be adapted to:

We really encourage users and customer to start migrating their Salt States to use mgrcompat.module_run now before Salt 3001 (Sodium) release. Once Salt 3001 comes, those states will simply fail.

The database engine has been updated from PostgreSQL 10 to PostgreSQL 12, 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 2020.06 will refuse to start until the database migration from PostgreSQL 10 to PostgreSQL 12 has completed successfully.

The base system was upgraded to openSUSE Leap 15.2.

Starting with Uyuni  2020.07, Ubuntu 2020.04 LTS is supported as a client.

package hwdata now comes from from openSUSE Leap 15.1 and not from the client tools.

In oder to get updated versions, the following command must be executed on the clients:

It is recommended to execute this as a remote command.

This change is mandatory if you intend to use the openSUSE Leap 15.1 as a KVM virtualization host.

This does not affect openSUSE Leap 15.2 as it will always have hwdata from the distribution.

Oracle Linux 6, 7 and 8 can now be managed with salt and it will support the same features CentOS 6, 7 and 8 support.

The channels can be managed using spacewalk-common-channels.

Enabling verification of non-SUSE product metadata used to require manual acceptance, and sometimes even manual installation, of the third-party keys for products available from the product tree. Alternatively, an option to not verify the GPG key signature was there.

Uyuni 2020.06 now includes the GPG keys used to sign packages and/or metadata by other the following vendors:

Manual acceptance of those keys is no longer required for GPG signature verification for those products to work.

Manual acceptance of GPG keys for any other product or repository is still required for security reasons.

As you modernize your IT landscape and make use of Software Defined Infrastructure stacks based on technologies like Kubernetes and Ceph, your focus of managing the IT infrastructure has to move from managing individual Linux servers and VMs to managing infrastructure clusters. Multiple cluster types will be supported in coming releases, with Uyuni 2020.06 initially providing support for SUSE CaaSP.

Computing is increasingly being a more complex architecure: redundant servers, scale out, high-availability, etc where you deploy different kinds of clusters, such as SUSE CaaS Platform, SUSE Enterprise Storage or SAP. Managing those as a whole piece of infrastructure instead of as discrete nodes puts you in charge.

Uyuni 2020.06 implements cluster management of SUSE CaaS Platform clusters. Uyuni works hand-in-hand with CaaS Platform to make sure that all cluster operations are issued properly.

The following actions are currently supported:

Deployment of CaaS Platform clusters from scratch will be supported in an upcoming version of Uyuni.

The Unpublished Patches feature has been dropped in Uyuni 2020.05.

This was a very old feature which originated more than 15 years ago when Spacewalk was used internally by vendors to manage patches before making them available to their customers. This functionality has been superseded a long (more than 10 years) time ago by other features in Uyuni for sysadmins, and by tools such as the Open Build Service for operating system vendors.

After a consultation period with users both in the upstream Uyuni community and the SUSE Manager community, we received no feedback against the removal and executed on it.

This will help us realize even further performance improvements in several areas, including the commonly-used Content Lifecycle Management build and promotion operations.

If you still have any unpublished patches, make sure you publish them with Uyuni 2020.05 before migrating to Uyuni 2020.06.

Repository synchronization has been optimized to perform faster than in previous versions. This applies to if the synchronization is triggered in the WebUI, or from the command prompt using the spacewalk-repo-sync command. It also applies whether the synchronization is invoked manually, or automatically as part of product or custom channel synchronizations. The performance improvement is up six times faster than previous versions, but the improvement depends mostly on your hardware setup, especially the number of CPUs, and how many packages are being synchronized.

IMPORTANT: This requires a vendor change for the package python3-psycopg2-2.8.4-2.1.uyuni.x86_64.

After running zypper update you will need force the vendor change with

Then update again again, so the spacewalk-backend subpackages are updated:

As soon as python3-psycopg2-2.8.4 is part of openSUSE Leap 15.1 we will provide instructions use the openSUSE version again.

Custom info key-value pairs defined in image profiles are now passed to the Docker build command as build arguments. They can be accessed in Dockerfiles using the ARG command.

After a Service Pack migration dry-run, if the result is a success you will get a "Run migration" button in the event history to retrieve the "dry-run" settings and confirm the migration with these settings.

Scheduling recurring actions allows you to manage schedules for automated recurring highstate execution on client, group, and organization level depending on the frequency you choose.

This is useful, for example, to apply highstates on a regular schedule and ensure configurations are enforced.

For more information, see the Administration Guide.

Before this release, only password authentication was available for bootstrapping Salt clients from the Server.

Now SSH private key authentication is available, including use of a passphrase on the private key. For Uyuni 2020.04 this is only available from the API. It will be made available from the WebUI in a future release.

For security reasons, the private key is stored at the Uyuni Server only for the bootstrap procedure, and removed after bootstrapping is complete. The private key must be provided for each bootstrap.

The new method bootstrapWithPrivateSshKey in the namespace system is documented in the API Documentation.

You can use this example by adjusting the client, keyfile, passphrase, MANAGER_URL, MANAGER_LOGIN and MANAGER_PASSWORD according to your environment:

The content lifecycle project page in the WebUI now has improved feedback messages about module filters, including missing or conflicting modules, and dependency resolution problems. The messages are in the form of errors that require the user to fix configurations, or warnings about potential problems.

Database schema upgrades are now applied automatically during services startup, so there is no need to call spacewalk-schema-upgrade manually. A security mechanism has been implemented that prevents Uyuni Services from starting if the schema upgrade has failed.

When this occurs:

Uyuni is designed by default to work on small and medium scale installations.

For installations with more than 1000 clients per Uyuni Server, adequate hardware sizing and parameter tuning must be performed, and the new guide provides information about how to do it.

Keep in mind there is no hard maximum number of supported systems. Many factors can affect how many clients can reliably be used in a particular installation. Factors can include which features are used, and how the hardware and systems are configured.

The Uyuni Hub announced for 2020.03 has now documentation available as part of the Large Deployments Guide (section Multiple Servers with Hub).

This is a draft release, so please provide feedback using the Resources menu in the online documentation

This new draft guide shows you the fastest way to get Uyuni up and running in a public cloud. It includes instructions for Amazon Web Services, Microsoft Azure, and Google Cloud Engine.

This is a draft release, so please provide feedback using the Resources menu in the online documentation

CaaSP specific Grafana dashboards have been integrated and can be deployed via the UI.

The new version of the Prometheus formula allows configuring federation and pulling relevant metrics from Prometheus instances to provide a global monitoring view.

Note that suitable recording rules have to be configured on the Prometheus instances (for example at CaaSP Prometheus instances).

For more information about Prometheus federation, check the official documentation.

A default set of alerting rules have been added to monitor the Prometheus instances themselves (meta-monitoring) and the availability of configured targets. The rules can be disabled in the WebUI.

We now provide these Prometheus exporters as packages for CentOS8 x86_64 (compatible also with similar systems such as RHEL8):

All the changes can be found at the changelog for the package, or at https://github.com/prometheus/node_exporter/releases/tag/v0.18.0 and https://github.com/prometheus/node_exporter/releases/tag/v0.18.1

Keep in mind this new version includes some breaking changes:

Until now users could list the storage pools, which is where the virtual machines disks are stored. Storage pools are where virtual machine disks are stored. In previous versions, you could only list the pools. With this update, you can create, edit, start, stop, refresh, and delete storage pools. This is available from the WebUI, or through Salt states.

We now offer Debian client tools that allow for easy onboarding of Debian as salt minions, as well as running spacecmd from them.

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

For now the following architectures are supported: x86_64, aarch64, armv7l, i586

We plan to continue improving Debian support in the future, including support for ppc64le and s390x Debian 10 clients.

Nodes in a SUSE Container as a Service Platforms should be patched, rebooted, etc following CaaSP recommendations to avoid breaking cluster availability and software compability.

In Uyuni 2020.03, we have introduced node locking and action filtering to prevent uninteded operations.

You can enable or disable the system lock using the System Lock formula. When the system lock is disabled, all operations are permitted.

In Uyuni 4.0.1, we introduced virtual host gatherers for Amazon Web Services, Microsoft Azure and Google Cloud Engine. With these gatherers, our subscription matcher gained the ability to also include virtual machines running on the cloud in its calculations.

We have now enhanced the subscription matcher to exclude pay-as-you-go (PAYG) instances. Those do not require a subscription, as the agreement between the Cloud Service Provider and the Customer covers them.

A bootstrap repository contains packages for installing Salt on clients, as well as the required packages for registering Salt or traditional clients during bootstrapping.

In Uyuni 2020.01 and earlier, bootstrap repository creation was a manual step, by using the mgr-create-bootstrap-repo tool.

In Uyuni 2020.03, bootstrap repositories are automatically created and regenerated on the Uyuni Server after a product is synchronized (i. e. all mandatory channels are fully mirrored).

More details, including how to revert to manual invokation, are available from the Client Configuration Guide.

Enable provisioning API with Salt and bootstrap entitled systems. Previously, this only worked for traditional clients.

You can schedule automated recurring highstate actions for Salt clients.

Recurring highstate actions apply the highstate to clients on a specified schedule. You can apply recurring action to individual clients, to all clients in a system group, or to an entire organization. The Recurring Actions section in the Administration Guide contains all the details for this feature.

More improvements in regards to automation will be coming in subsequent releases of Uyuni: maintenance windows and patch automation.

RHEL, SLES ES, CentOS and Oracle Linux 8 appstreams can now be mixed and converted to flat repositories using a new type of CLM filter.

Each Uyuni release and maintenance update brings better Ubuntu support. In Uyuni 2020.03, we have include two small but valuable improvements:

Yomi (yet one more installer) is a Salt-based installer for SUSE and openSUSE operating systems.

In Uyuni, Yomi can be used as part of provisioning new clients, as an alternative to AutoYaST. Yomi consists of two components:

Detailed information on how to use Yomi is available from the Salt Guide.

Yomi is work in progress and more operating systems and features will be added in coming releases.

The Uyuni Hub is a new multi-server architecture we are introducing as a technology preview in Uyuni 2020.03.

Multiple Uyuni Servers can be managed from a single Hub node. The Hub is a Salt master itself and the managed Uyuni Server servers are both a minion (to the hub) and a master (to their own minions).

The Hub covers a number of use cases, such as:

The Hub comprises a number of components that we will be releasing and enhancing in the future. The first component of the Hub we are now introducing as a Technology Preview is the Hub XML-RPC API, which provides an extended version of the Uyuni Server XML-RPC API, targeted for the multi-server case.

Installation and usage

Install Uyuni Server and then install the hub-xmlrpc-api package. That Uyuni Server is now the Hub Server.

Configuration of hub-xmlrpc-api is specified in a JSON file like the following:

Set the HUB_CONFIG_FILE environment variable to point to the configuration file. hub-xmlrpc-api is a daemon, currently to be launched from the command line.

Once running, you can connect to the hub-xmlrpc-api at port 8888 via any XMLRPC compliant client libraries (see examples below).

API endpoints, namespaces and examples

Details about usage with Python script examples are available at the Uyuni project site: https://github.com/uyuni-project/hub-xmlrpc-api

In Uyuni 2020.01 and earlier, the spacewalk-utils package contained a mix tested and untested tools.

In Uyuni 2020.03, we have split spacewalk-utils in two packages:

Tools in spacewalk-utils-extras are valuable but they are so specific, or require additional customization for each user, that it is not possible for us to test for every use case. If you were using these scripts in spacewalk-utils in Uyuni 2020.01 or earlier, you will need to install spacewalk-utils-extras in Uyuni 2020.03.

The dhcp formula, branch network formula and pxe formula have been updated to support booting EFI terminals (systems) via HTTP in addition to TFTP.

On public cloud providers, the subscription matcher will identify pay-as-you-go instances, whose subscription is provided by the Cloud Service Provider, and will not ask for additional subscriptions.

Also, stackable subscriptions with the same parameters will be aggregated.

Uyuni supports Single Sign-On authentication by implementing the Security Assertion Markup Language (SAML) 2 protocol. This feature, introduced in 4.0.2 as a Technology Preview, is now declared stable

Uyuni must be reconfigured to use the IdP as the source of authentication and post-login mapped users must be already created before enabling SSO.

For more on configuring SSO, see the Authentication Methods chapter in the Administration guide.

In an effort to provide our web UI users with a smoother navigation, we have implemented large parts of the user interface as a single page application.

This enhancement was started in Uyuni 2020.01 as an opt-in feature and now becomes the default in Uyuni 2020.03

It is no longer necessary to have Python 3 on RHEL8 systems for the onboarding to work. With this enhancement, even plain-text RHEL machines can be onboarded directly.

Uyuni is now changing from X.Y version format to YYYY.MM format, and the URLs for the repositories remove the X.Y part.

This will allow easier releases, no need to change URLs at all in the future, and less confussion regarding the relationship between Uyuni and SUSE Manager (Uyuni is always ahead).

Because of the version format change, you need to adapt your zypper repository at the server before updating.

If you followed the instructions for installation, this command will do it for you:

sed -i -e 's/Uyuni-Server-4.0-POOL-x86_64-Media1/Uyuni-Server-POOL-x86_64-Media1/' /etc/zypp/repos.d/uyuni-server-stable.repo

Otherwise, find the Uyuni Server Stable repository and replace:

baseurl=https://download.opensuse.org/repositories/systemsmanagement:/Uyuni:/Stable/images/repo/Uyuni-Server-4.0-POOL-x86_64-Media1/

with:

baseurl=https://download.opensuse.org/repositories/systemsmanagement:/Uyuni:/Stable/images/repo/Uyuni-Server-POOL-x86_64-Media1/

If you are currently syncing Uyuni Proxy 4.0 (usually because you have proxies), you need to:

Most users will not require this unless, but if you have the Uyuni Server 4.0 channel at your server:

CentOS 8, Red Hat Enterprise Linux 8 and SUSE Linux Enterprise Server Expanded Support 8 are now supported clients as Salt minions. The traditional stack will not be supported on these operating systems.

With the new application streams concept introduced in these operating systems, you will need to import both the BaseOS and the AppStream directories from the ISO image for the bootstrap repository to be created correctly. If the AppStream directory is not imported, you will receive an error about missing Python 3 packages.

AppStream awareness in the UI and Content Lifecycle Management will be available in an upcoming version of Uyuni.

This version of Uyuni includes formulas to install Prometheus and Grafana, and makes the Apache exporter available for Ubuntu 18.04, CentOS6, CentOS7 and Proxy.

Additionally, self-monitoring capabilities have been implemented in the Admin Monitoring UI.

SUSE Package Hub is now supported on the Server, since the problems with the search that were caused by PackageHub-provided packages have been solved.

If you were using Package Hub as a source of packages for you clients, it is recommended that you re-generate all package metadata. The reason for this is in the Package Hub repositories there may exist multiple packages with the same NEVRA but different checksums. This might result in checksum errors when repositories are used on the clients as Uyuni randomly selected any of those packages. After this update, Uyuni will generate the checksum into the package path to ensure the right package is used. If you use also Uyuni Proxy please update all of them before you re-generate the metadata.

The Formulas with Forms screen has an enhanced layout that folds vertically instead of nesting deep inside, making if cleaner. Besides this, validators are now possible in formulas using the JEXL expression language.

The cpu-mitigations-formula is now installed by default.

The Retail branch network formula now works all SUSE and openSUSE based distros, using SuSEfirewall or firewalld as appropriate.

In Uyuni 4.0.2 we introduced Content Lifecycle Management with a filter to exclude packages and patches based on their name. Feedback for this feature was very positive and many proposals for enhancement were received.

In this release, we are introducing a lot of new possibilities for Content Lifecycle Management:

We have documented two typical use cases: a monthly patch cycle and live patching.

More enhancements to Content Lifecycle Management will come in future releases of Uyuni.

With each release of Uyuni, we continue to enhance our Debian and Ubuntu support.

Uyuni 2020.01 greatly improves our compatibility thanks to:

A new set of client tool packages now includes Prometheus exporters for more clients: CentOS 6, CentOS 7, RHEL 6, RHEL 7, SLES ES 6, SLES ES 7 and Ubuntu 18.04. Both the Prometheus node exporter and the PostgreSQL exporter are provided for those operating systems. The prometheus-exporters-formula formula makes easy to deploy them.

We’ve added new types of Virtual Host Managers in order to gather virtual instances from Public Cloud providers. Azure, AWS and Google Cloud are now supported, in addition to the existing VMware and generic (file-based, manually-maintained, useful for any cloud provider) gatherer modules.

Creating VHM to gather virtual instances from the Public Cloud will enable the subscription matcher to match "1-2 virtual machines" subscriptions for those instances that are running on the same Public Cloud zone.

Please take into account the following considerations in this version. They will be addressed in upcoming versions of Uyuni:

Some users have hit in the past a database corruption problem when PostgreSQL ran out of space.

In order to prevent that from happening in the future, we have added a diskchecker to Uyuni Server. This feature will send a warning mail when the most common and important Uyuni directories are below 10% of free disk space, and will shut down the Uyuni Server when those directories are below 5% of free disk space.

This new feature is only enabled by defult in new installations. For existing installations, the administrator can enable the tool manually after updating to the latest maintenance update by running:

systemctl --quiet enable spacewalk-diskcheck.timer

systemctl start spacewalk-diskcheck.timer

Full details on the parameterization of this new feature are available in the Managing disk space documentation page.

In an effort to provide our web UI users with a smoother navigation, we have implemented large parts of the user interface as a single page application.

This feature is optional for this release and is disabled by default. To enable it, users can now add web.spa.enable = true to /etc/rhn/rhn.conf, and then restart Tomcat.

Grafana is a tool for data visualization, monitoring, and analysis. It is used to create dashboards with panels representing specific metrics over a set period of time. Grafana is commonly used together with Prometheus, but also supports other data sources such as ElasticSearch, MySQL, PostgreSQL, and Influx DB.

This version of Uyuni includes Grafana in the client tools repositories. An Uyuni Grafana dashboard is provided as an example.

Monitoring section of the Administration Guide contains full detail on how to configure Grafana together with Uyuni.

Prometheus is a monitoring tool used to record real-time metrics in a time-series database. Metrics are collected using HTTP pulls, allowing for higher performance and scalability.

We have updated the Prometheus package with a new version that include a built-in service discovery mechanism that will allow users to more easily configure monitoring on their Uyuni systems.

Previously, after configuring the exporters on managed clients, users had to manually configure their Prometheus servers to start scrapping metrics from those systems. With this update, it will be possible to use a "service discovery" mechanism that will automate this part of the configuration. The configuration options are simple: it is only required to provide a Uyuni Server URL and valid API credentials.

Under the hood, what this mechanism does is letting Prometheus poll the Uyuni API, asking for a list of systems that have monitoring enabled, and automatically configuring Prometheus to collect metrics from those systems.

In this version, the autodiscovery functionality is provided as a Technology Preview.

More information about configuring Prometheus can be found in the Monitoring section of the Administration Guide.

CPU mitigations have been introduced to improve security on CPUs affected by vulnerabilities such as Meltdown and Spectre. The mitigations are available in SUSE Linux Enterprise 12 SP3 and later in the cpu-mitigations-formula package, which is not installed by default.

The new CPU Mitigation formula allows you to control which mitigations are enabled.

The Uyuni documentation has received improvements in all of the books, with small clarifications and enhancements all around: content lifecycle management filters, public cloud, JeOS, formulas, etc

Of particular interest for users with large installations will be the new Large Scale Deployment and Salt Tuning sections in the Salt Guide. Given that modifying advanced parameters can cause catastrophic failure, we recommend making a backup and being conservative doing changes.

Additionally, the search functionality in the documentation now works offline.

The Multi-Arch and Pre-depends headers are now supported for .deb repositories, hence avoiding installation problems that could arise in some cases when deploying packages from the UI.

Also, Ubuntu and Debian channels now come preconfigured in spacewalk-common-channels. The Debian CDN is used to provide the best mirror at each moment. For Ubuntu, you may want to replace the default mirror with a closer geo-mirror.

Keep in mind SUSE does not provide support for the spacewalk-common-channels tool form the spacewalk-utils package.

The Virtual Host Manager functionality has been extended to support SUSE Container as a Service Platform v4.

You can register each CaaSP node to Uyuni using the same method as you would a Salt client. After doing this, you will be able to see the patch level status of each node, perform configuration management on the nodes and assign channels o clusters.

We strongly recommend to check the documentation on the scope and extent of the CaaSPv4 integration in Uyuni: https://www.uyuni-project.org/uyuni-docs/en/uyuni/client-configuration/vhm-caasp.html

Upcoming versions of Uyuni will enhance CaaSP integration.

4.0.2 is now based on openSUSE Leap 15.1, so a base OS system is required.

To help administrators with the migration, a new script is provided by the susemanager package at /usr/lib/susemanager/bin/server-migrator.sh

Then, update susemanager package only:

And finally run the script:

After the migration is complete, you will be requested to reboot your server

Uyuni Server 4.0.2 works with SUSE Uyuni Proxy 4.0.1.

When upgrading, upgrade the Server first, followed by the Proxies.

Salt has been upgraded to the 2019.2.0 release.

We intend to regularly upgrade Salt to more recent versions.

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

The base system was upgraded to openSUSE 15.1.

As a result, all code was ported to run with Python 3 and OpenJDK 11.

We now include packages for the latest version of Prometheus, as well as self-monitoring capabilities for Uyuni.

Prometheus is a monitoring tool that is used to record real-time metrics in a time-series database.

For more information about Prometheus, see the Administration Guide

The content lifecycle management feature allows you to clone software channels through a lifecycle of several environments. You are able to create content projects, select a custom set of software channels as sources, and promote software channels through a pre-defined lifecycle of environments.

You can define filters to exclude specific packages and patches. More filters will be added in a later release.

Once you have selected your sources you can build the selected set which will populate the first environment. After the first environment is built, you can promote it through the environment lifecycle to the next environment in the loop. You can see the status of the build at any time throughout the process.

The result of the build, and the content of every environment, is a channel tree made of cloned software channels of the selected sources, to which systems can be assigned.

The existing virtualization features have been enhanced for Salt-based systems. This is a technology preview and will require an additional Virtualization Management entitlement. Pricing will be announced soon.

Salt-based virtualization host systems can also create virtual machines using a pre-built disk image.

These features have been added:

In this release, we have reorganized our documentation and updated our tooling to make it clearer where information is, and make it easier for you to find the content you need, when you need it.

The Salt Remote Command Page log now every command executed in a separate logfile (/var/log/rhn/rhn_salt_remote_commands.log). In addition to this, an entry in the System History is generated for every minion where the command was executed.

openSUSE Leap 15.1 and SLE15 SP1 can now be managed.

openSUSE Leap 42.3 is now End of Life since July 1st, as announced at the openSUSE Mailing lists

While the repositories for Leap 42.3 are still available, no support is provided aymore.

Any action scheduled on multiple Salt minions has now an upper limit on the number of systems that will process it simultaneously. This is referred to as batch size in Salt jargon, and defaults to 100 minions.

Please check the documentation for performance considerations in large installations (more than 1000 minions).

In the past information about product channels were shipped via maintenance updates. Now these information will be downloaded from SUSE Customer Center (SCC) like the other product and repository information.

In case of using the fromdir configuration with SMT or RMT, please check if they support already downloading this file. You can get the file with the following command:

Using SLES 12 SP4 as the base OS for an image build host is now supported.

Also building SLES 12 SP4 OS Images is supported.

This update contains a new backend to communicate with the SUSE Customer Center (SCC). This requires to run a mgr-sync refresh at the end of the update procedure.

The whole update procedure:

In case of Inter Server Sync (ISS) the master needs to be updated first, then the slave.

This change show products like they are setup in the SUSE Customer Center. As a consequence of this some older products show no architecture anymore and mirror all available architectures when such a product is selected for mirroring.

With this change also some invalid product combinations were removed. Please check /var/log/rhn/rhn_web_ui.log for error messages. Invalid channels can be removed using spacewalk-remove-channel command.

Due to the changes in the backend for communicating with SCC corresponding XMLRPC API has changed:

Deprecated calls:

New call:

For a refresh the XMLRPC API should be called in the following order:

Management of Ubuntu clients is now supported. We provide a repository with salt packages that can easily be added with spacewalk-common-channels or manually.

The following new features were added:

However, the root user on Ubuntu is disabled by default, so in order to use bootstrapping, you will require an existing user with sudo privileges for Python.

Channel authentication tokens are valid by default for about 1 year. The renew of tokens happens automatically some time before they expire but they are not deployed automatically to the clients.

As the renew happens mostly without noticing by the administrator that behavior has changed to autodeploy renewed tokens to the clients automatically.

This old behavior can be preserved by setting

in /etc/rhn/rhn.conf and restarting the services.

In case of a token renew without autodeployment enabled a log message will inform the administrator about it.

A new option --force was added to spacecmd softwarechannel_regenerateyumcache to force a regeneration of the metadata files.

It is now possible to set a custom protocol, host and path for minions to download packages at installation time. This will override the default setting of the Uyuni Server or Uyuni Proxy used at registration time.

Uyuni supports Single Sign-On authentication by implementing the Security Assertion Markup Language (SAML) 2 protocol. Mandatory requirement: an already existing and configured SAML Identity Service Provider (IdP). Uyuni must be reconfigured to use the IdP as the source of authentication and post-login mapped users must be already created before enabling SSO.

For more on configuring SSO, see the Administration Guide

A new version of the PostgreSQL database is available in openSUSE Leap 42.3 and can be used for Uyuni Server.

New installations of Uyuni Server based on openSUSE Leap 42.3 will automatically pick up this version.

PostgreSQL 10 needs a new version of smdba to initiate backups. This version is part of Uyuni Server 4.0.1.

You should have an up-to-date database backup before attempting the migration.

Existing installations of Uyuni Server will need to run

to migrate from PostgreSQL 9.6 to PostgreSQL 10

Your Uyuni Server installation will not be accessible during the migration.

Note The migration will create a copy of the database under /var/lib/pgsql and thus needs sufficient disk space to hold two copies (9.6 and 10) of the database.

Since it does a full copy of the database, it also needs considerable time depending on the size of the database and the IO speed of the storage.

If your system is scarce on disk space you can do an fast, in-place migration by running

The fast migration usually only takes minutes and no additional disk space. However, in case of failure you need to restore the database from a backup.

This wiki page contains additional information about the database migration.

spacecmd, the command line access to the Uyuni API, has been adapted to support state channels (aka Salt Minion config channels) with the following changes:

Please use the help functionality of spacecmd for detailed option descriptions for each mentioned call.

Functions softwarechannel_mergepackages and softwarechannel_errata_merge to merge packages and errata through spacecmd were added.

Added:

Removed:

openSUSE Leap 15.0, openSUSE Leap 42.3, SLE12, SLE15, CentOS6 and CentOS7 are now verified to bootstrap as both salt minions and traditional clients.