SUSE Manager Server Migration to a Containerized Environment
1. Requirements and Considerations
1.1. General
-
To migrate a SUSE Manager 4.3 Server to a container, you require a new machine with SLE Micro 5.5 and
mgradm
installed. -
An in-place migration from SUSE Manager 4.3 to 5.0 is unsupported because of the change of the underlying operating system from SUSE Linux Enterprise Server 15 SP4 to SLE Micro 5.5.
-
Before migrating from SUSE Manager 4.3 to 5.0, any existing traditional clients including the traditional proxies must be migrated to Salt.
-
For more information about migrating traditional SUSE Manager 4.3 clients to Salt clients, see https://documentation.suse.com/suma/4.3/en/suse-manager/client-configuration/contact-methods-migrate-traditional.html.
-
-
Traditional contact protocol is no longer supported in SUSE Manager 5.0 and later.
1.2. Hostnames
-
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.
-
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.3. GPG Keys
-
Self trusted GPG keys are not migrated.
-
GPG keys that are trusted in the RPM database only are not migrated. Thus synchronizing channels with
spacewalk-repo-sync
can fail. -
The administrator must migrate these keys manually from the 4.3 installation to the container host after the actual server migration.
Procedure: Manual Migration of the 4.3 GPG Keys to New Server-
Copy the keys from the 4.3 server to the container host of the new server.
-
Later, add each key to the migrated server with the command
mgradm gpg add <PATH_TO_KEY_FILE>
.
-
2. Migration
The migration can take a very long time depending on the amount of data that needs to be replicated. To reduce downtime it is possible to run the migration multiple times in a process of initial replication, re-replication, or final replication and switch over while all the services on the old server can stay up and running. Only during the final migration the processes on the old server need to be stopped. For all non-final replications add the parameter mgradm migrate podman <oldserver.fqdn> --prepare |
2.1. Initial Preparation on the Old 4.3 Server
-
Stop the SUSE Manager services:
spacewalk-service stop
-
Stop the PostgreSQL service:
systemctl stop postgresql
2.2. SSH Connection Preparation
Pre-installing SUSE Manager on the prepared SLE Micro 5.5 with mgradm
is not necessary.
The migration process will take care of the server installation.
-
Ensure that for
root
an SSH key exists on the new 5.0 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 connection to the 4.3 server that does not prompt for a password.
eval $(ssh-agent); ssh-add
To establish a connection that does not prompt for a password, 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-add
followed 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 SUSE Manager 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
~/.ssh/authorized_keys
file. For more information, see thessh-copy-id
manpage. -
Establish an SSH connection from the new server to the old SUSE Manager 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_hosts
file. Then try again. The fingerprint will be stored in the local~/.ssh/known_hosts
file.
2.3. Perform the Migration
When planning your migration from SUSE Manager 4.3 to SUSE Manager 5.0, ensure that your target instance meets or exceeds the specifications of the old setup.
This includes, but is not limited to, memory (RAM), CPU Cores, Storage, and Network Bandwidth.
-
This step is optional. If custom persistent storage is required for your infrastructure, use the
mgr-storage-server
tool.-
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 SUSE Manager server. Replace
<oldserver.fqdn>
with the FQDN of the 4.3 server:mgradm migrate podman <oldserver.fqdn>
-
Migrate trusted SSL CA certificates.
2.3.1. Migration of the Certificates
Trusted SSL CA certificates that were installed as part of an RPM and stored on SUSE Manager 4.3 in the /usr/share/pki/trust/anchors/
directory will not be migrated.
Because SUSE does not install RPM packages in the container, the administrator must migrate these certificate files manually from the 4.3 installation after the migration.
-
Copy the file from the 4.3 server to the new server. For example, as
/local/ca.file
. -
Copy the file into the container with:
mgrctl cp /local/ca.file server:/etc/pki/trust/anchors/
After successfully running the To redirect them to the 5.0 server, it is required to rename the new server at the infrastructure level (DHCP and DNS) to use the same FQDN and IP address as 4.3 server. |