Uyuni Server Upgrade

Before running the upgrade command, it is required to update the host operating system. Updating the host operating system will also result in the update of the Uyuni tooling such as the mgradm tool.

Before upgrading, verify that every root and intermediate CA certificate used by Uyuni marks X509v3 Basic Constraints as critical and includes CA:TRUE. Strict certificate validators, including Python 3.13 and later, reject CA certificates that miss the critical flag.

If your installation uses an older self-signed CA generated by Uyuni, you might need to create a new CA and new server certificates, then deploy the new root CA to all clients. For the verification command, certificate replacement, and client root-CA deployment procedure, see administration:ssl-certs-imported.adoc#ssl-certs-verify-ca-basic-constraints, administration:ssl-certs-selfsigned.adoc#ssl-certs-selfsigned-create-replace, and administration:ssl-certs-imported.adoc#ssl-certs-import-deploy-root-ca.
Procedure: Upgrading Server

  1. Refresh software repositories with zypper:

    zypper ref

  2. Apply available updates with transactional-update:

    transactional-update

  3. If updates were applied, reboot.

  4. The Uyuni Server container can be updated using the following command:

    Risk of Automated Version Downgrade and PTF Loss

    Running the mgradm upgrade podman command when no newer upgrade is available will cause the system to automatically revert to the base version. This process removes all currently applied Program Temporary Fixes (PTFs) without a confirmation prompt.

    To avoid unintended data or fix loss, verify upgrade availability before execution. Future releases will include a confirmation prompt to prevent this behavior.

    		 
    mgradm upgrade podman

    This command will bring the status of the container up-to-date and restart the server.

  5. Clean up the unused container images to free disk space:

    podman image prune -a

    In some upgrades, multiple *.rpmnew and *.rpmsave files may be generated. The presence or number of these files does not indicate that manual action is required. In SUSE Multi-Linux Manager container environments, required configuration changes are applied automatically during the upgrade process. These files are created as a result of differences between packaged defaults and existing configuration files, and may also include internal or informational changes that are not intended to be merged. If manual action is required for a configuration change, it will be explicitly documented in the release notes or upgrade documentation.

    Do not treat these files as a post-upgrade checklist or merge them in bulk. Only review a file if you are actively troubleshooting a specific issue and understand the impact of the configuration it contains. If a change is required, it should be applied intentionally based on a known requirement, not by copying differences from these files. If you are unsure, leave the file unchanged.
Upgrading with third-party SSL certificate

In previous versions, the database container needed to have an SSL certificate with the following Subject Alternate Names (SANs):

  • db

  • reportdb

This is no longer required. The database container needs only the externally facing fully qualified domain name. The old certificates with db and reportdb SANs can be still used.

The same certificate can be used for both the main container and the database one.

In order to pass the new certificates to the upgrade command, use the --ssl-db-ca-root, --ssl-db-cert and --ssl-db-key parameters.
Upgrading to specific version

If you do not specify the tag parameter, it will default to upgrading to the most recent version. To upgrade to a specific version, provide the tag parameter with the desired image tag.

For more information on the upgrade command and its parameters, use the following command:

Risk of Automated Version Downgrade and PTF Loss

Running the mgradm upgrade podman command when no newer upgrade is available will cause the system to automatically revert to the base version. This process removes all currently applied Program Temporary Fixes (PTFs) without a confirmation prompt.

To avoid unintended data or fix loss, verify upgrade availability before execution. Future releases will include a confirmation prompt to prevent this behavior.

 
mgradm upgrade podman -h

For air-gapped installations, first upgrade the container RPM packages, then run the mgradm command.

1. Database Backup Volume

Server migration or upgrade with mgradm migration or mgradm upgrade can create a volume with the database backup.

When the PostgreSQL database version is increased, the old database must be stored in a separate location before running the upgrade. For this purpose mgradm dynamically creates the volume var-pgsql-backup. When the migration or upgrade is done and the user has validated that the new system is working as expected, this volume can be removed safely.