Migrating the SUSE Manager Server to a Containerized Environment

To migrate a SUSE Manager 5.0 Server to a container, a new machine is required.

An in-place migration from SUSE Manager 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 SUSE Manager 5.0 and later. 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.

The original server is referred to as the source server, while the newly set-up machine is designated as the destination server.

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:

  1. Copy the keys from the source server to the container host of the destination server.

  2. Add the keys to the container with mgradm gpg add …​.

Trusted SSL CA certificates that were installed as part of an RPM and store 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:

  1. Copy the file from the source server to the destination server. For example, as /local/ca.file.

  2. Copy the file into the container with:

    mgradm cp /local/ca.file server:/etc/pki/trust/anchors/

The migration procedure currently does not include any hostname renaming functionality. The fully qualified domain name (FQDN) of the destination server will remain identical to the one of the source server. Therefore, after the migration, it will be necessary to manually adjust the DNS records to point to the new server.

1. Initial Preparation on the Source Server

Procedure: Initial preparation on the source server

  1. Stop the SUSE Manager services:

    spacewalk-service stop

  2. Stop the PostgreSQL service:

    systemctl stop postgresql

2. Prepare the SSH Connection

Procedure: Preparing the SSH connection

  1. The SSH configuration and agent should be ready on the destination server for a passwordless connection to the source server.

    To establish a passwordless connection, the migration script relies on an SSH agent running on the destination server. If the agent is not active yet, initiate it by running eval $(ssh-agent). Then, add the SSH key to the running agent with ssh-add /path/to/the/private/key. You will be prompted to enter the password for the private key during this process.

  2. The migration script only uses the source server’s FQDN in the SSH command.

  3. This means that every other configuration required to connect, needs to be defined in the ~/.ssh/config file.

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 your current setup. This includes, but is not limited to, Memory (RAM), CPU Cores, Storage, Network Bandwidth etc.
Procedure: Performing the Migration

  1. Execute the following command to install a new SUSE Manager server, replacing <source.fqdn> with the appropriate FQDN of the source server:

    mgradm migrate podman <source.fqdn>

After successfully running the mgradm migrate command, the Salt setup on all clients will still point to the old server (source server). To redirect them to the new server (destination 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 old server (source server).