Migrating the Uyuni Server to a Containerized Environment
To migrate a Uyuni 4.3 Server to a container, a new machine is required.
|
An in-place migration from Uyuni 4.3 to 5.0 will remain unsupported because of the change of the underlying operating system from SUSE Linux Enterprise Server 15 SP4 to SLE Micro 5.5. The traditional contact protocol is no longer supported in Uyuni 5.0 and later. Before migrating from Uyuni 4.3 to 2024.08, any existing traditional clients including the traditional proxies must be migrated to Salt. For more information about migrating traditional Uyuni 4.3 clients to Salt clients, see https://documentation.suse.com/suma/4.3/en/suse-manager/client-configuration/contact-methods-migrate-traditional.html. |
|
Self trusted GPG keys are not migrated.
GPG keys that are trusted in the RPM database only are not migrated.
Thus synchronizing channels with The administrator must migrate these keys manually from the 4.3 installation to the container host after the actual server migration.
|
The current migration procedure does not include functionality for renaming hostnames. As a result, the fully qualified domain name (FQDN) of the new server will remain the same as that of the old server. Additionally, the IP address must remain unchanged to ensure that the clients can contact the server. After the migration, it will be necessary to manually update the DHCP and DNS records to point to the new server.
1. Initial Preparation on the Old 4.3 Server
-
Stop the Uyuni services:
spacewalk-service stop
-
Stop the PostgreSQL service:
systemctl stop postgresql
2. Prepare the SSH Connection
-
Ensure that for
rootan SSH key exists on the new 2024.08 server. If a key does not exist, create it with:ssh-keygen -t rsa
-
The SSH configuration and agent should be ready on the new server for a passwordless connection to the 4.3 server.
To establish a passwordless connection, the migration script relies on an SSH agent running on the new server. If the agent is not active yet, initiate it by running
eval $(ssh-agent). Then add the SSH key to the running agent withssh-addfollowed by the path to the private key. You will be prompted to enter the password for the private key during this process. -
Copy the public SSH key to the Uyuni 4.3 Server (
<oldserver.fqdn>) withssh-copy-id. Replace<oldserver.fqdn>with the FQDN of the 4.3 server:ssh-copy-id <old server.fqdn>
The SSH key will be copied into the old server's [path]``~/.ssh/authorized_keys`` file. For more information, see the [literal]``ssh-copy-id`` manpage.
-
Establish an SSH connection from the new server to the old Uyuni Server to check that no password is needed. Also there must not by any problem with the host fingerprint. In case of trouble, remove old fingerprints from the
~/.ssh/known_hostsfile. Then try again. The fingerprint will be stored in the local~/.ssh/known_hostsfile.
3. Perform the Migration
|
When planning your migration from Uyuni 4.3 to Uyuni 5.0, ensure that your target instance meets or exceeds the specifications of the old setup.
This includes, but is not limited to, |
-
This step is optional. If custom persistent storage is required for your infrastructure, use the
mgr-storage-servertool.-
For more information, see
mgr-storage-server --help. This tool simplifies creating the container storage and database volumes. -
Use the command in the following manner:
mgr-storage-server <storage-disk-device> [<database-disk-device>]
For example:
mgr-storage-server /dev/nvme1n1 /dev/nvme2n1
This command will create the persistent storage volumes at
/var/lib/containers/storage/volumes.For more information, see List of persistent storage volumes.
-
-
Execute the following command to install a new Uyuni server. Replace
<oldserver.fqdn>with the FQDN of the 4.3 server:mgradm migrate podman <oldserver.fqdn>
-
Migrate trusted SSL CA certificates.
|
Trusted SSL CA certificates that were installed as part of an RPM and stored on Uyuni 4.3 in the
|
|
After successfully running the To redirect them to the 2024.08 server, it is required to rename the new server at the infrastructure level (DHCP and DNS) to use the same Fully Qualified Domain Name and IP address as 4.3 server. |