SUSE Multi-Linux Manager Server Migration to a Containerized Environment

1. Requirements and Considerations

1.1. General

  • To migrate a SUSE Multi-Linux Manager 4.3 Server to a container, you require a new machine with SL Micro 6.1 or SUSE Linux Enterprise Server 15 SP7 and mgradm installed.

  • An in-place migration from SUSE Multi-Linux Manager 4.3 to 5.1 is unsupported. The underlying operating system has been changed from SUSE Linux Enterprise Server 15 SP4 to SL Micro or SUSE Linux Enterprise Server 15 SP7.

  • Before migrating from SUSE Multi-Linux Manager 4.3 to 5.1, any existing traditional clients including the traditional proxies must be migrated to Salt. For more information about migrating traditional SUSE Multi-Linux 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 Multi-Linux 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.

  • 관리자는 실제 서버 마이그레이션을 수행한 후 이러한 키를 4.3 설치에서 컨테이너 호스트로 수동으로 마이그레이션해야 합니다.

    Procedure: Manual Migration of the 4.3 GPG Keys to New Server

    1. 4.3 서버의 키를 새 서버의 컨테이너 호스트로 복사합니다.

    2. 그 후, mgradm gpg add <PATH_TO_KEY_FILE> 명령을 사용하여 마이그레이션된 서버에 각 키를 추가합니다.

2. 마이그레이션

2.1. 기존 4.3 서버에서 초기 준비

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 --prepare to prevent the automatic stopping the services on the old server. For example:

mgradm migrate podman <oldserver.fqdn> --prepare
Procedure: Initial Preparation on the 4.3 Server

  1. SUSE Multi-Linux Manager 서비스를 중지합니다.

    spacewalk-service stop

  2. PostgreSQL 서비스를 중지합니다.

    systemctl stop postgresql

2.2. SSH Connection Preparation

Pre-installing SUSE Multi-Linux Manager on the prepared SL Micro or SUSE Linux Enterprise Server with mgradm is not necessary. The migration process will take care of the server installation.

Procedure: Preparing the SSH Connection

  1. 새 5.1 서버에 root에 대한 SSH 키가 있는지 확인합니다. 키가 없는 경우 다음을 사용하여 키를 만듭니다.

    ssh-keygen -t rsa

  2. 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 with ssh-add followed by the path to the private key. You will be prompted to enter the password for the private key during this process.

  3. ssh-copy-id를 사용하여 SUSE Multi-Linux Manager 4.3 서버(<oldserver.fqdn>)에 공개 SSH 키를 복사합니다. <oldserver.fqdn>을 4.3 서버의 FQDN으로 바꿉니다.

    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 the ssh-copy-id manpage.

  4. 새 서버에서 기존 SUSE Multi-Linux Manager 서버로 SSH 연결을 설정하여 비밀번호가 필요하지 않은지 확인합니다. 호스트 지문에도 문제가 없어야 합니다. 문제가 있는 경우 ~/.ssh/known_hosts 파일에서 기존 지문을 제거합니다. 그런 다음 다시 시도합니다. 지문은 로컬 ~/.ssh/known_hosts 파일에 저장됩니다.

2.3. 마이그레이션 수행

When planning your migration from SUSE Multi-Linux Manager 4.3 to SUSE Multi-Linux Manager 5.1, 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.

절차: 마이그레이션 수행

  1. 이 단계는 선택적 단계입니다. 인프라에 사용자 지정 영구 스토리지가 필요한 경우 mgr-storage-server 도구를 사용하십시오.

    • 자세한 내용은 mgr-storage-server --help를 참조하십시오. 이 도구는 컨테이너 스토리지 및 데이터베이스 볼륨 생성을 간소화합니다.

    • 다음 방법으로 명령 사용:

      mgr-storage-server <storage-disk-device> [<database-disk-device>]

      예:

      mgr-storage-server /dev/nvme1n1 /dev/nvme2n1

      이 명령은 /var/lib/containers/storage/volumes에 영구 스토리지 볼륨을 생성합니다.

      자세한 내용은 Persistent Container Volumes에서 확인할 수 있습니다.

  2. 새 SUSE Multi-Linux Manager 서버를 설치하려면 다음 명령을 실행합니다. <oldserver.fqdn>은 4.3 서버의 FQDN으로 대체합니다.

    mgradm migrate podman <oldserver.fqdn>

  3. 신뢰할 수 있는 SSL CA 인증서를 마이그레이션합니다.

2.3.1. Migration of the Certificates

Trusted SSL CA certificates that were installed as part of an RPM and stored on SUSE Multi-Linux 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.

Procedure: Migrating the Certificates

  1. 4.3 서버에서 새 서버로 파일을 복사합니다. 예를 들어 /local/ca.file일 수 있습니다.

  2. 다음을 사용하여 파일을 컨테이너에 복사합니다.

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

mgradm migrate 명령을 성공적으로 실행한 후에도 모든 클라이언트의 Salt 설정은 계속해서 기존 4.3 서버를 가리킵니다.

To redirect them to the 5.1 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.