Version Revision History

  • 2019/08/02: 4.0.2 release

  • 2018/12/19: 4.0.1 release

  • 2018/10/26: 4.0.0 release

Stay informed

You can stay up-to-date regarding information about Uyuni:

Check the home site https://www.uyuni-project.org

Support

Uyuni is a community support project. The ways or contacting the community are available at the home site.

Release model

Uyuni uses a rolling release model (meaning there will be no bugfixing for given Uyuni version, but new frequent versions that will include bugfixes and features)

Check the home site get in contact with the community.

Major changes since Uyuni Server 4.0.0

Features and changes

Version 4.0.2

Migrating the Server from 4.0.1 to 4.0.2
If you are using DHCP addresses and you do not use DHCP reservations, migrating from openSUSE Leap 42.3 to Leap 15.0 can change the IP address of your NICs. If using DHCP, make sure your instances have reserved IP addresses.
Before starting, make sure you have a backup of your server, as it will be hard to recover from failures during the migration.

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:

zypper ref
zypper in susemanager

And finally run the script:

/usr/lib/susemanager/bin/server-migrator.sh

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 2019.2.0

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.

Base system upgrade

The base system was upgraded to openSUSE 15.1.

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

Prometheus Monitoring

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

Exporters

Exporters convert existing metrics into the format Prometheus requires. We are now providing the following Prometheus Exporters as packages, for SLE12 and SLE15 as well as openSUSE Leap 15.1:

In addition we provide JMX exporter on Uyuni Server.

Monitoring is not yet available for other operating system platforms like Red Hat Enterprise Linux or Ubuntu.

Self-monitoring features in Uyuni

Uyuni provides metrics about its health to Prometheus. Both Server and Proxy can expose metrics. Self-monitoring can be enabled via the Web UI. For that purpose, some Prometheus exporters are pre-installed on Uyuni Server and Proxy.

A new formula is also included, to install and manage Node and PostgreSQL exporters on clients managed by Salt. This formula can be configured in the Uyuni Web UI.

Content lifecycle management

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.

Virtualization management for Salt minions

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:

  • Deleting virtual machines.

  • Editing virtual machines to add or remove network interfaces or disk, change CPU and memory allocation or the display type.

  • Quick update of the list and state of virtual machines.

  • Displaying virtual machines graphical display in a new tab.

Updated Documentation Structure

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.

Old Naming Format

  • Getting Started

  • Best Practices

  • Reference

  • Advanced Topics

New Naming Format

  • Installation Guide (Requirements, supported platforms, installation methods, etc)

  • Client Configuration Guide (Configuring and connecting clients to Uyuni)

  • Upgrade Guide (Migrate and update clients and Uyuni)

  • Reference Guide (Comprehensive guide to the Web UI)

  • Administration Guide (Maintenance and administration tasks in Uyuni)

  • Salt Guide (A comprehensive guide to Salt for system administrators)

  • Retail Guide (A guide to using Uyuni for Retail)

Improved logging for Salt Remote Command Page

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.

Support for more Distributions as Clients

openSUSE Leap 15.1 and SLE15 SP1 can now be managed.

EoL for openSUSE Leap 42.3 clients

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.

Salt Rate Limiting (Batching)

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).

Product Information Loaded from SCC

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:

curl -O https://scc.suse.com/suma/product_tree.json
Image build host with SLES 12 SP4

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.

Updated backend for communicating with SCC

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:

$> spacewalk-service stop
$> zypper patch
$> spacewalk-schema-upgrade
$> spacewalk-service start
$> mgr-sync refresh

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.

XMLRPC API changes

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

Deprecated calls:

synchronizeChannels()
synchronizeProductChannels()

New call:

synchronizeRepositories()

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

synchronizeChannelFamilies
synchronizeProducts
synchronizeRepositories
synchronizeSubscriptions
Support for Ubuntu Clients

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:

  • Bootstrapping and performing initial state runs such as setting repositories and performing profile updates

  • Assigning .deb channels to minions

  • Information displayed in System details pages

  • Package install, update, and remove

  • Package install using Package States

  • Configuration and state channels

  • Support Ubuntu products and Debian architectures in mgr-sync

  • Support creating bootstrap repositories for Ubuntu 18.04 and 16.04

  • Add support for Ubuntu in the bootstrap script

  • Generate InRelease file for Debian/Ubuntu repos when metadata signing is enabled

  • Trust SUSE GPG key for client tools channels on Ubuntu systems

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.

Change behavior on token refresh

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

token_refresh_auto_deploy = false

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.

New option to force regeneration of channel metadata

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

New products supported

  • openSUSE Leap 15.1

  • SLES11 SP4 LTSS

  • SLES12 SP3 LTSS

  • SLES 15 SP1 product family

  • SUSE Manager Tools for Ubuntu

  • SUSE Manager Tools for Red Hat

  • CaaSP 4 Toolchain

Package download endpoint override

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.

Technical preview: Single Sign-On (SSO)

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

Version 4.0.1

Support for PostgreSQL 10

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.

Migrating from PostgreSQL 9.6 to PostgreSQL 10

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

Existing installations of Uyuni Server will need to run

/usr/lib/susemanager/bin/pg-migrate-96-to-10.sh

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

/usr/lib/susemanager/bin/pg-migrate-96-to-10.sh fast

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: Support state channels

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:

  • system_scheduleapplyconfigchannels

    • new call to schedule application of the assigned config channels to the system (minion only)

  • configchannel_updateinitsls

    • new call to update the init.sls file

  • configchannel_create

    • adapted call, now has a -t option to specify the channel type (normal or state)

  • configchannel_import

    • adapted call, honors channel type

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

New API calls

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

spacewalk-common-channels: Support for Uyuni, Fedora 29 and cleanup

Added:

  • Uyuni Server, Uyuni Proxy, Uyuni Client Tools, both stable and development version.

  • Fedora 29

Removed:

  • Fedora 26

  • Spacewalk 2.6 Server and Client Tools

  • Spacewalk 2.7 Server and Client Tools

  • Spacewalk 2.8 Server

  • Spacewalk nightly

  • OpenSUSE 13.2 and openSUSE 13.2 Client Tools

Support for more Distributions as Clients

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.

New products added to SCC syncing

  • SUSE OpenStack Cloud 9

Client Tools Notes

All Client Tools are still considered "Beta" and there could still be dependencies problems, notably for SLE12 and CentOS6 and CentOS7.

URLs of the Client Tools are:

Supported clients

At the moment the status is the following:

Distribution

Salt bootstrap from server

Salt SSH bootstrap from server

Salt bootstrap from client

Traditional

openSUSE Leap 15

SLE12

SLE15

CentOS6

CentOS7

Ubuntu16.04

Ubuntu18.04

= Working, = Not working, = Untested

In all cases, all maintained SPs and subversions are supported.

Untested clients

Distribution

Salt bootstrap from server

Salt SSH bootstrap from server

Salt bootstrap from client

Traditional

RHEL6

RHEL7

Debian10

RHEL6 and RHEL7 are expected to work in the same way CentOS6 and CentOS7. Client Tools repositories for a CentOS version should work at the respective RHEL version.

Debian10 is not tested, but it has Salt 2018.3.4, and users can test it and provide feedback. There are no traditional client tools for this Operating System.

Known limitations

The GPG key for Uyuni Client Tools is not trusted by default by the respective package management tools for each OS.

The systems will bootstrap without the GPG key being trusted, but will not be able to install new client tool packages or updated them.

This can be fixed by adding the key uyuni-gpg-pubkey-0d20833e.key to all the bootscrap scripts at variable ORG_GPG_KEY=. If you already have other keys there, you can keep them.

For systems bootstrapped from WebUI, a salt state should be created to trust the key, then the state can be assigned to the organization, and finally it can be used using an Activation Key and the Configuration Channels to deploy the change to the clients.

Documentation

It is usable but you can still find some issues, such references to SUSE Manager that are scheduled to be fixed on subsequent versions.

Installation

Requirements

  • OS: openSUSE Leap 15.1 x86_64, fully updated

  • Main memory: Minimum 16 GB for base installation

  • Disk space: Minimum 100 GB for root partition, Minimum 50 GB for /var/lib/pgsql, Minimum 50 GB per SUSE product + 100 GB per RHEL product (/var/spacewalk)

See the Getting Started manual for more details on the system requirements.

Installing the Server

Add the Stable repository:

zypper ar https://download.opensuse.org/repositories/systemsmanagement:/Uyuni:/Stable/images/repo/Uyuni-Server-4.0-POOL-x86_64-Media1/ uyuni-server

Install the pattern:

zypper in patterns-uyuni_server

Run Yast2 and go to Network Services > Uyuni Setup

Follow the setup assistant.

Update from previous versions of Uyuni Server

You can update from previous Uyuni Server Stable versions.

See the best practices manual for detailed instructions on how to upgrade.

All connected clients will continue to run and are manageable unchanged.

Uyuni Proxy versions

Uyuni Proxy 4.0.1 can work with Uyuni Server 4.0.2

When upgrading, start with the server first and then continue with the proxies. See the advanced topics manual for detailed upgrade instructions.

Other information

Red Hat Channels

Managing RHEL clients requires availability of appropriate Red Hat packages.

SUSE Channels

Managing SUSE Linux clients requires availability of appropriate SUSE channels.

Your licensed SUSE products can be used with Uyuni by following the setup Wizard.

Check the manuals for more information.

Providing feedback

In case of encountering a bug please report it at https://github.com/uyuni-project/uyuni/issues

Legal Notices

Copyright © 2012 – 2019 SUSE LLC and contributors. All rights reserved.

This work is licensed under the Creative Commons Attribution-ShareAlike 3.0 License. To view a copy of this license, visit http://creativecommons.org/licenses/by-sa/3.0/es/ or send a letter to Creative Commons, PO Box 1866, Mountain View, CA 94042, USA.

For SUSE trademarks, see http://www.suse.com/company/legal/. All other third-party trademarks are the property of their respective owners. Trademark symbols (®, ™ etc.) denote trademarks of SUSE and its affiliates. Asterisks (*) denote third-party trademarks.

All information found in this document has been compiled with utmost attention to detail. However, this does not guarantee complete accuracy. Neither SUSE LLC, its affiliates, the authors nor the translators shall be held liable for possible errors or the consequences thereof.