Legacy SUSE Multi-Linux Manager Server Migration to Container

To migrate a legacy SUSE Multi-Linux Manager Server to a container, a new machine is required.

In the context of this migration, the legacy SUSE Multi-Linux Manager Server (RPM installation) is sometimes also called old server.

1. 要件と考慮事項

1.2. ホスト名

The migration procedure currently does not include any hostname renaming functionality. The fully qualified domain name (FQDN) on the new server will remain identical to that on the legacy server.

移行後、新しいサーバを指すようにDHCPおよびDNSレコードを手動で更新する必要があります。

2. GPGキー

自己信頼GPGキーは移行されません。
RPMデータベースで信頼されているGPGキーのみが移行されます。したがって、spacewalk-repo-syncでチャンネルを同期すると失敗する可能性があります。
The administrator must migrate these keys manually from the legacy SUSE Multi-Linux Manager installation to the container host after the actual server migration.
Procedure: Manual Migration of the GPG Keys to New Server
1. Copy the keys from the legacy Uyuni server to the container host of the new server.
2. その後、コマンドmgradm gpg add <PATH_TO_KEY_FILE>を使用して、移行したサーバに各キーを追加します。

2.1. Initial Preparation on the Legacy Server

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 legacy server can stay up and running.

Only during the final migration the processes on the legacy server need to be stopped.

For all non-final replications add the parameter --prepare to prevent the automatic stopping the services on the legacy server. For example:

mgradm migrate podman <oldserver.fqdn> --prepare

Procedure: Initial Preparation on the Legacy Server

SUSE Multi-Linux Managerサービスを停止します。
```
spacewalk-service stop
```
PostgreSQLサービスを停止します。
```
systemctl stop postgresql
```

2.2. SSH接続の準備

プロシージャ: SSH接続を準備する

Ensure that for root an SSH key exists on the new 5.1 server. If a key does not exist, create it with the command:
```
ssh-keygen -t rsa
```

The SSH configuration and agent should be ready on the new server host for a connection to the legacy server that does not prompt for a password.

eval $(ssh-agent); ssh-add

To establish a connection without prompting 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.

Copy the public SSH key to the legacy SUSE Multi-Linux Manager Server (<oldserver.fqdn>) with ssh-copy-id. Replace <oldserver.fqdn> with the FQDN of the legacy server:
```
ssh-copy-id <oldserver.fqdn>
```
The SSH key will be copied into the legacy server’s ~/.ssh/authorized_keys file. For more information, see the ssh-copy-id manpage.
Establish an SSH connection from the new server to the legacy SUSE Multi-Linux 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. 移行の実行

When planning your migration from a legacy SUSE Multi-Linux Manager to a containerized SUSE Multi-Linux Manager, ensure that your target instance meets or exceeds the specifications of the legacy setup. This includes, but is not limited to, memory (RAM), CPU Cores, Storage, and Network Bandwidth.

プロシージャ: 移行を実行する

このステップはオプションです。ご使用のインフラストラクチャにカスタム永続ストレージが必要な場合は、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を参照してください。
Execute the following command to install a new SUSE Multi-Linux Manager server. Replace <oldserver.fqdn> with the FQDN of the legacy server:
```
mgradm migrate podman <oldserver.fqdn>
```
信頼されているSSL CA証明書を移行します。

2.3.1. 証明書の移行

Trusted SSL CA certificates that were installed as part of an RPM and stored on a legacy SUSE Multi-Linux Manager 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 legacy installation after migration:

プロシージャ: 証明書の移行

Copy the file from the legacy server to the new server. たとえば、/local/ca.fileです。

Copy the file into the container with the command:

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

After successfully running the mgradm migrate command, the Salt setup on all clients will still point to the legacy server.

To redirect them to the new 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 legacy server.

3. Kubernetes Preparations

Before executing the migration with mgradm migrate command, it is essential to predefine Persistent Volumes, especially considering that the migration job initiates the container from scratch.

For more information, see the installation section on preparing these volumes in Persistent Container Volumes.

4. 移行

Execute the following command to install a new SUSE Multi-Linux Manager server, replacing <oldserver.fqdn> with the appropriate FQDN of the legacy server:

mgradm migrate podman <oldserver.fqdn>

または

mgradm migrate kubernetes <oldserver.fqdn>

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