Distribution Upgrade and Server Migration
|
|
Uyuni server hosts that are hardened for security may restrict execution of files from the For example:
In Uyuni updates, tools will be changed to make this workaround unnecessary. |
SSL certificates are needed at a later stage. If not using the self-signed generated CA and certificates, ensure you have the following before starting:
-
A certificate authority (CA) SSL public certificate. If you are using a CA chain, all intermediate CAs must also be available.
-
An SSL database private key.
-
An SSL database certificate.
All files must be in PEM format.
The hostname of the SSL server certificate must match the fully qualified hostname of the machine you deploy them on.
You can set the hostnames in the X509v3 Subject Alternative Name section of the certificate.
You can also list multiple hostnames if your environment requires it.
Supported Key types are RSA and EC (Elliptic Curve).
|
Database SSL certificate requires |
During a migration the server SSL certificate and CA chain are copied from the source server, meaning that only the database certificates are required
|
Uyuni 5.0 peripheral servers are always using third-party SSL certificates. If the hub server has generated the certificates for the peripheral server, it needs to generate the certificate for the peripheral database too. On the hub server, run the following command for each of the peripheral server to migrate.
The files to use will be inside the server container and need to be copied to the new peripheral server host:
|
1. Client tools rebranding
Uyuni 2026.04 introduces a rebranded set of client tools for all supported operating systems. This transition is seamless, and users performing a new product synchronization should only notice the updated channel names.
Channels named SUSE Manager Client Tools for XYZ, used by clients previously registered with Uyuni 4.3 or 5.0, are no longer available in version 5.1 and will no longer receive updates in 5.1.
Although the legacy channels remain assigned to existing clients after migration, the corresponding repositories have been removed.
To ensure continued updates, users must:
-
Mirror the new
SUSE Multi-Linux Manager Client Tools for XYZchannels for the relevant products and assign them to the appropriate clients. -
Unassign the outdated
SUSE Manager Client Tools for XYZchannels.
This also means that any CLM projects based on the old client tools must be adjusted accordingly.
For example workflow, see Switch to new client tools channels.
2. SLE Micro 5.5 to SL Micro 6.1
This document provides the tested procedure to upgrade a SLE Micro 5.5 host deployed with Uyuni 5.0 Server to SL Micro 6.1 and migrate to Uyuni 2026.04.
2.1. Prerequisites
|
SL Micro 6.1 uses NetworkManager as the network managing service. If your server is using wicked as the network manager it must be migrated to NetworkManager before upgrading the Operating System. For more information on migrating to NetworkManager see: https://documentation.suse.com/sle-micro.
|
2.2. Distribution upgrade and server migration
Verify current product status.
SUSEConnect --status-textConfirm:
Base OS:
SUSE Linux Enterprise Micro 5.5Extension:
SUSE Manager Server 5.0 ExtensionEnsure the system is updated.
transactional-update patch
If patches were applied, stop the server and then reboot the system before proceeding to migration:
mgradm stop rebootIf no updates were found, you can proceed directly to the migration step.
Start the migration.
transactional-update migration --auto-agree-with-licenses --gpg-auto-import-keysFollow the prompts and select the available migration to SUSE Linux Micro 6.1 and Uyuni Server Extension 5.1.
Stop the server and then reboot to apply changes.
mgradm stop rebootPerform post-reboot checks.
Verify upgraded OS and Uyuni extension:
cat /etc/os-release SUSEConnect --status-textYou should see:
PRETTY_NAME="SUSE Linux Micro 6.1"
SUSE Multi-Linux Manager Server 5.1 ExtensionEnable root SSH access (if required).
SL Micro 6.1 disables root login via SSH by default.
Edit
/etc/ssh/sshd_config.d/sshd.conf:PermitRootLogin yesAnd restart the service:
systemctl restart sshdFor more information, see Remote root login on SL Micro.
Verify Uyuni tools
mgradm --versionExpected output:
Version
5.1.11or higherReferences
5.1.0or higherUpgrade server containers.
Risk of Automated Version Downgrade and PTF Loss
Running the
mgradm upgrade podmancommand 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 start mgradm upgrade podmanFollow the prompts to pull and configure the new 5.1.0 containers.
Check the running containers:
podman psYou should see:
server:5.1.0or higher
server-postgresql:5.1.0or higher
|
Errors for missing services like |
2.3. Migration complete
The system is now running Uyuni 5.1 on SL Micro 6.1. Validate your setup before resuming production operations. If you have a Uyuni 5.0 proxy connected to this server, proceed to the Proxy Migration from 5.0 to 5.1 guide to upgrade the proxy host.
2.4. 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.
3. SUSE Linux Enterprise Server 15 SP6 to 15 SP7
This document provides the tested procedure to upgrade a SUSE Linux Enterprise Server 15 SP6 host deployed with SUSE Multi-Linux Manager 5.0 Server to SUSE Linux Enterprise Server 15 SP7 with SUSE Multi-Linux Manager 5.1.
3.1. Prerequisites
-
SUSE Multi-Linux Manager 5.0 is installed and running on SUSE Linux Enterprise Server 15 SP6.
-
The system is registered and has valid subscriptions in SUSE Customer Center (SCC).
-
Ensure backups are created before proceeding.
3.2. Distribution upgrade and server migration
Verify current product status.
SUSEConnect --status-textConfirm:
Base OS:
SUSE Linux Enterprise Server 15 SP6Extension:
SUSE Manager Server 5.0 ExtensionApply all system patches.
zypper patchStop the server, and then reboot if the update stack was updated.
mgradm stop rebootLaunch the Zypper migration tool.
zypper migrationZypper will show the possible migration targets with detailed summaries.
Select the appropriate target, and follow the prompts to complete the migration.
After the migration completes, stop the server and then reboot the system.
mgradm stop rebootPerform post-reboot checks:
Verify upgraded OS and Uyuni extension.
cat /etc/os-release SUSEConnect --status-textYou should see:
VERSION="15-SP7"
SUSE Multi-Linux Manager Server 5.1 Extension for SLEVerify Uyuni tools version.
mgradm --versionExpected output:
Version
5.1.11or higherImage tag
5.1.0or higherUpgrade the server containers.
Risk of Automated Version Downgrade and PTF Loss
Running the
mgradm upgrade podmancommand 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 start mgradm upgrade podmanFollow prompts to pull the new container images and reconfigure the environment.
Check the running containers.
podman psExpected containers:
server:5.1.0or higher
server-postgresql:5.1.0or higher
3.3. Migration complete
The system is now running Uyuni 5.1 on SUSE Linux Enterprise Server 15 SP7. Validate your setup before resuming production operations. If you have a Uyuni 5.0 proxy connected to this server, proceed with Proxy Migration from 5.0 to 5.1.
3.4. 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.