将 SUSE Multi-Linux Manager 服务器迁移到容器化环境

1. 要求和注意事项

1.1. 一般要求

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.
无论所选主机操作系统是 SL Micro 6.1 还是 SUSE Linux Enterprise Server 15 SP7，均不支持从 SUSE Multi-Linux Manager 4.3 就地迁移到 5.1。

在从 SUSE Multi-Linux Manager 4.3 迁移到 5.1 之前，必须将所有现有的传统客户端（包括传统代理）迁移到 Salt。有关将传统 SUSE Multi-Linux Manager 4.3 客户端迁移到 Salt 客户端的详细信息，请参见将传统客户端迁移到 Salt 客户端。

SUSE Multi-Linux Manager 5.0 及更高版本不再支持传统联系协议。

本指南仅涵盖从 SUSE Multi-Linux Manager 4.3 到 5.1 的迁移流程。

Migrating an existing SUSE Multi-Linux Manager 5.1 instance to the same version while switching the host operating system from SL Micro 6.1 to SUSE Linux Enterprise Server 15 SP7, or vice versa, is not handled by the mgradm migrate command.

1.2. 主机名

当前的迁移过程不包含重命名主机名的功能。因此，新服务器的完全限定域名 (FQDN) 将与旧服务器的一样。
IP 地址必须保持不变，以确保客户端可以连接到服务器。

迁移之后，需要手动更新 DHCP 和 DNS 记录以指向新的服务器。

1.3. GPG 密钥

自信任 GPG 密钥不会迁移。
GPG keys that are trusted in the RPM database only are not migrated. Thus, synchronizing channels with spacewalk-repo-sync can fail.
在完成服务器的实际迁移后，管理员必须手动将这些密钥从所安装的 4.3 系统迁移到容器主机。
过程：手动将 4.3 GPG 密钥迁移到新服务器
1. 将 4.3 服务器中的密钥复制到新服务器的容器主机。
2. Later, add each key to the migrated server with the command mgradm gpg add <PATH_TO_KEY_FILE>.

1.4. SSL 证书

迁移期间会从源服务器复制服务器 SSL 证书和 CA 链，这意味着您只需准备数据库证书即可。

Starting with SUSE Multi-Linux Manager 5.1, the PostgreSQL database runs in a separate container that requires its own SSL certificate during migration. This is why database certificates are needed even when the server certificate and CA chain are copied from the source.

Third-party certificates that are already in use on your SUSE Multi-Linux Manager 4.3 installation will be copied automatically during the migration. No additional configuration is required for most scenarios.

When migrating, SUSE Multi-Linux Manager uses self-signed certificates by default. To use certificates from an external PKI (certificate authority), you can provide all certificate files when running mgradm migrate using the --ssl* flags.

Table 1. Quick-reference: which flags are needed for your migration
Migration situation	Flags needed
Self-signed CA, everything unchanged	None
New server certificate (same CA)	`--ssl-server-cert`, `--ssl-server-key`
New database certificate (same CA)	`--ssl-db-cert`, `--ssl-db-key`
New server and database certificates (same CA)	`--ssl-server-cert`, `--ssl-server-key`, `--ssl-db-cert`, `--ssl-db-key`
New server certificate + new CA	`--ssl-server-cert`, `--ssl-server-key`, `--ssl-ca-root`, `--ssl-ca-intermediate`
New database certificate + new CA	`--ssl-db-cert`, `--ssl-db-key`, `--ssl-db-ca-root`, `--ssl-db-ca-intermediate`
Changing CA only (same cert files, different CA chain)	`--ssl-ca-root`, `--ssl-ca-intermediate`, `--ssl-db-ca-root`, `--ssl-db-ca-intermediate`
Full replacement — new certs and CA for both components	See "All certificates from an external PKI" below

Any --ssl* flag not specified uses the corresponding value from the source server. Only provide flags for the files that differ from your current setup.

1.4.1. Flag reference

The following --ssl* flags are supported by mgradm migrate:

Flag Description

Flag	Description
`--ssl-ca-root`	Path to the root CA certificate that signed the server certificate (defaults to source server CA)
`--ssl-ca-intermediate`	Path to an intermediate CA certificate in the chain (can be specified multiple times; defaults to source server)
`--ssl-server-cert`	Path to the server certificate (defaults to source server certificate)
`--ssl-server-key`	Path to the server private key (defaults to source server key)
`--ssl-db-ca-root`	Path to the root CA certificate that signed the database certificate
`--ssl-db-ca-intermediate`	Path to an intermediate CA certificate in the database certificate chain (can be specified multiple times)
`--ssl-db-cert`	Path to the database certificate
`--ssl-db-key`	Path to the database private key

--ssl-ca-root

Path to the root CA certificate that signed the server certificate (defaults to source server CA)

--ssl-ca-intermediate

Path to an intermediate CA certificate in the chain (can be specified multiple times; defaults to source server)

--ssl-server-cert

Path to the server certificate (defaults to source server certificate)

--ssl-server-key

Path to the server private key (defaults to source server key)

--ssl-db-ca-root

Path to the root CA certificate that signed the database certificate

--ssl-db-ca-intermediate

Path to an intermediate CA certificate in the database certificate chain (can be specified multiple times)

--ssl-db-cert

Path to the database certificate

--ssl-db-key

Path to the database private key

The database certificate chain is completely separate from the server certificate chain. The --ssl-db-* flags must be provided even when using the same CA, as the database container requires its own certificates generated during migration.

1.4.2. Certificate requirements

The following requirements apply to all certificate files used with mgradm migrate:

All certificate files must be in PEM format. If your certificates are in DER format, convert them first.
The hostname in the X509v3 Subject Alternative Name section of the certificate must match the fully qualified hostname of the machine the certificates are deployed on.
Database certificates require reportdb and db as Subject Alternative Name (SAN).
Supported key types are RSA and EC (Elliptic Curve).

When a CA chain is used, concatenate the certificates with the server or database certificate first, followed by all intermediate CA certificates in order. The root CA certificate should be provided in its own file. To combine files, you can use the following command:

cat server.pem intermediate-ca1.pem intermediate-ca2.pem > combined-server.pem

For full details on certificate preparation, see Import SSL Certificates.

1.4.3. Scenario: All certificates from an external PKI

This scenario covers migrating a server where both the web and database components use certificates from a third-party CA. The organization must gather the following certificate files:

Root CA certificate for the web component
Intermediate CA certificate for the web component (if applicable)
Server certificate for the web component
Private key for the web component
Root CA certificate for the database component
Intermediate CA certificate for the database component (if applicable)
Server certificate for the database component (with reportdb and db as SAN)
Private key for the database component

In most deployments, a single CA serves both the server and database components. In that case, the same certificate files are used for both --ssl- and --ssl-db- flags. The example below uses separate file names for clarity.

Listing 1. Example migration command with all --ssl* flags

mgradm migrate podman <oldserver.fqdn> \
  --ssl-ca-root rootCAweb.pem \
  --ssl-ca-intermediate intermediateCAweb.pem \
  --ssl-server-cert webcert.pem \
  --ssl-server-key webkey.key \
  --ssl-db-ca-root rootCAdb.pem \
  --ssl-db-ca-intermediate intermediateCAdb.pem \
  --ssl-db-cert dbcert.pem \
  --ssl-db-key dbkey.key

Client deployment of external CA certificates

After a successful migration with external PKI certificates, deploy the CA certificate to all clients so they can verify the new server certificates:

mgrctl exec -- 'salt -b 50 * state.apply certs'

1.4.4. Scenario: Mixed external and self-signed certificates

When migrating with a mix of external and self-signed certificates, only replace the CA in a certificate chain when the server or database certificate and its private key are also being replaced in that same chain. For example, when replacing both the server certificate and key with external PKI versions, also provide the corresponding CA certificates. However, when only replacing database certificates, the self-signed CA password is still needed if the original CA is being reused.

For the complete procedure, see the SCC article: SUSE Multi-Linux Manager Server migration fails due to unknown (or lost) CA password.

2. 迁移

2.1. 准备 SUSE Multi-Linux Manager 5.1 服务器主机

请勿在已准备好的 SL Micro 6.1 或 SUSE Linux Enterprise Server 15 SP7 系统上预先安装 SUSE Multi-Linux Manager。

The migration process is designed to perform the server installation automatically. Running mgradm install and then mgradm migrate is not supported and will lead to an unsupported system state.

在以下步骤中，我们只会准备主机系统，而不实际安装 SUSE Multi-Linux Manager 5.1 服务器。

您可使用基于 SL Micro 6.1 的 VM 映像作为迁移目标。在此场景下，您可按照以下指南中的说明准备主机系统：

However, at the end the last step is executing the command mgradm migrate <FQDN> instead of mgradm install <FQDN>.

2.1.1. 准备 SL Micro 6.1 主机

2.1.1.1. 下载安装媒体

过程：下载安装媒体

访问 https://www.suse.com/download/sle-micro/，找到 SL Micro 6.1 的安装媒体，并下载相应媒体文件。

Prepare a DVD or USB flash drive with the downloaded .iso image for installation.

2.1.1.2. 安装 SL Micro 6.1

过程：安装 SL Micro 6.1

插入包含 SLE Micro 6.1 安装映像的 DVD 或 USB 闪存盘（USB 磁盘或密钥）。

引导或重引导您的系统。

Use the arrow keys to select Installation.

调整键盘和语言。

Click the checkbox to accept the license agreement.

Click Next to continue.

选择注册方法。在本示例中，我们将在 SUSE Customer Center 中注册服务器。

SUSE Multi-Linux Manager 5.1 容器会安装为扩展。根据以下列出的所需特定扩展，您还需要有各个扩展的 SUSE Customer Center 注册代码。

SUSE Multi-Linux Manager 5.1 服务器

SUSE Multi-Linux Manager 5.1 代理

SUSE Multi-Linux Manager 5.1 零售分支服务器

SL Micro 6.1 权利包含在 SUSE Multi-Linux Manager 权利中，因此不需要单独的注册代码。

输入您的 SUSE Customer Center 电子邮件地址。

输入您的 SL Micro 6.1 注册代码。

Click Next to continue.

To install a proxy, select the SUSE Multi-Linux Manager 5.1 Proxy extension; to install a server, select the SUSE Multi-Linux Manager 5.1 Server extension Checkbox.

Click Next to continue.

输入您的 SUSE Multi-Linux Manager 5.1 扩展注册代码。

单击 下一步 继续。

On the NTP Configuration page click Next.

On the Authentication for the System page enter a password for the root user. Click Next.

On the Installation Settings page click Install.

至此，SL Micro 6.1 及 SUSE Multi-Linux Manager 5.1 扩展的安装已完成。有关虚拟机或物理机准备工作的详细信息，请参见 SL Micro 部署指南。

2.1.1.3. 从命令行注册（可选）

如果您在安装 SL Micro 6.1 期间已将 SUSE Multi-Linux Manager 5.1 添加为扩展，则可以跳过此过程。不过，您也可以选择在安装 SL Micro 6.1 期间单击 跳过注册 按钮来跳过注册。本节提供了在安装 SL Micro 6.1 后注册产品的步骤。

以下步骤将注册 x86-64 体系结构的 SUSE Multi-Linux Manager 5.1 扩展，因此需要提供适用于 x86-64 体系结构的注册代码。要注册 ARM 或 s390x 体系结构，请使用正确的注册代码。

过程：从命令行注册

运行以下命令列出可用扩展：
transactional-update --quiet register --list-extensions
从可用扩展列表中选择一个要安装的扩展：
如果要安装服务器，请使用您的 SUSE Multi-Linux Manager Server Extension 5.1 x86_64 注册代码运行以下命令：
transactional-update register -p Multi-Linux-Manager-Server/5.1/x86_64 -r <reg_code>
如果要安装代理，请使用您的 SUSE Multi-Linux Manager Proxy Extension 5.1 x86_64 注册代码运行以下命令：
transactional-update register -p Multi-Linux-Manager-Proxy/5.1/x86_64 -r <reg_code>
重引导。

2.1.1.4. 更新系统

过程：更新系统

以 root 身份登录。
运行 transactional-update：
transactional-update
重引导。

SL Micro 设计为默认自动更新，并会在应用更新后重引导。但是，这种行为对于 SUSE Multi-Linux Manager 环境而言是不利的。为了防止服务器自动更新，SUSE Multi-Linux Manager 会在引导过程中禁用 transactional-update 计时器。

如果您希望保留 SL Micro 的默认行为，请运行以下命令来启用计时器：

systemctl enable --now transactional-update.timer

2.1.2. 准备 SUSE Linux Enterprise Server 15 SP7 主机

或者，您也可以在 SUSE Linux Enterprise Server 15 SP7 上部署 SUSE Multi-Linux Manager。

下面的过程介绍安装流程的主要步骤。

2.1.2.1. 在 SUSE Linux Enterprise Server 上安装 SUSE Multi-Linux Manager 扩展

过程：在 SUSE Linux Enterprise Server 上安装 SUSE Multi-Linux Manager 扩展

Locate and download SUSE Linux Enterprise Server 15 SP7 .iso at https://www.suse.com/download/sles/.

确保您拥有主机操作系统 (SUSE Linux Enterprise Server 15 SP7) 和扩展的注册代码

启动 SUSE Linux Enterprise Server 15 SP7 的安装流程。

On the Language, keyboard and product selection select the product to install.

On the License agreement read the agreement and check I Agree to the License Terms.

选择注册方法。在本示例中，我们将在 SUSE Customer Center 中注册服务器。

输入您的 SUSE Customer Center 电子邮件地址。

输入 SUSE Linux Enterprise Server 15 SP7 的注册代码。

Click Next to continue.

请注意，对于 SUSE Linux Enterprise Server 15 SP7，您需要拥有有效的 SUSE Linux Enterprise Server 订阅及相应的注册代码，并在此界面提供。您还需要在下方输入 SUSE Multi-Linux Manager 扩展的注册代码。

In the screen Extensions and Modules Selection check the following:

选择 SUSE Multi-Linux Manager 服务器扩展以安装服务器，或选择 SUSE Multi-Linux Manager 代理扩展以安装代理。

Basesystem 模块

Containers 模块

Click Next to continue.

输入您的 SUSE Multi-Linux Manager 5.1 扩展注册代码。

单击 下一步 继续。

完成安装。

安装完成后，以 root 身份登录新安装的服务器。
更新系统（可选，如果在安装期间未将系统设置为自动下载更新）：
zypper up
重引导。

2.1.2.2. 从命令行注册（可选）

如果您在安装 SUSE Linux Enterprise Server 期间已将 SUSE Multi-Linux Manager 5.1 添加为扩展，则可以跳过此过程。

不过，您也可以选择在安装 SUSE Linux Enterprise Server 期间单击 跳过注册 按钮来跳过注册。本节提供了在安装 SUSE Linux Enterprise Server 后注册产品的步骤。

以下步骤将注册 x86-64 体系结构的 SUSE Multi-Linux Manager 5.1 扩展，因此需要提供适用于 x86-64 体系结构的注册代码。

要注册 ARM 或 s390x 体系结构，请使用正确的注册代码。

过程：从命令行注册

运行以下命令列出可用扩展：
SUSEConnect --list-extensions
从可用扩展列表中选择一个要安装的扩展：
If installing the Server, use your SUSE Multi-Linux Manager Server Extension 5.1 x86_64 registration code.

For example for SUSE Linux Enterprise 15 SP7, use the following commands:
SUSEConnect -r <regcode>
SUSEConnect -p sle-module-containers/15.7/x86_64
SUSEConnect -p Multi-Linux-Manager-Server-SLE/5.1/x86_64 -r <regcode>
如果要安装代理，请运行以下命令，并提供您的 SUSE Multi-Linux Manager Proxy Extension 5.1 x86_64 注册代码：
SUSEConnect -p Multi-Linux-Manager-Proxy-SLE/5.1/x86_64 -r <regcode>

2.1.2.3. Install and enable `podman`

Procedure: Installing podman

以 root 身份登录并安装产品软件包。
在服务器上：
zypper in podman
zypper in -t product Multi-Linux-Manager-Server-SLE
在代理上：
zypper in podman
zypper in -t product Multi-Linux-Manager-Proxy-SLE
Make sure that package podman is installed. Additionally, on the server mgradm and mgradm-bash-completion or on the proxies, mgrpxy and mgrpxy-bash-completion also need to be installed.
重引导系统或运行以下命令，以启动 Podman 服务：
systemctl enable --now podman.service

2.2. SSH 连接准备

此步骤可确保新的 SUSE Multi-Linux Manager 5.1 服务器无需口令便可通过 SSH 连接至现有 4.3 服务器。操作包括生成和配置 SSH 密钥、设置 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:
ssh-keygen -t rsa
新服务器上的 SSH 配置和代理应准备就绪，这样在连接 4.3 服务器时就不会提示输入口令。
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.
Copy the public SSH key to the SUSE Multi-Linux Manager 4.3 Server (<oldserver.fqdn>) with ssh-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 the ssh-copy-id manpage.
Establish an SSH connection from the new server to the old 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. 执行迁移

在规划从 SUSE Manager 4.3 到 SUSE Multi-Linux Manager 5.1 的迁移时，请确保您的目标实例达到或超出旧设置的规格。

这包括但不限于内存 (RAM)、CPU 核心、存储和网络带宽。

SUSE Multi-Linux Manager server hosts that are hardened for security may restrict execution of files from the /tmp folder. In such cases, as a workaround, export the TMPDIR environment variable to another existing path before running mgradm.

例如：

export TMPDIR=/path/to/other/tmp

在 SUSE Multi-Linux Manager 的后续更新中，相关工具将进行优化，届时无需再使用此临时解决方案。

When migrating from SUSE Manager 4.3, you will be prompted for the Password for the CA key to generate. It is essential to enter the same CA password that was used in your SUSE Manager 4.3 installation.

输入错误口令会导致数据库证书生成失败，进而使迁移中止并显示以下错误：

错误：无法配置数据库容器：无法生成数据库证书：CA 验证失败！

请在启动迁移流程前，确认已准备好正确的 CA 口令。

过程：执行迁移

This step is optional. If custom persistent storage is required for your infrastructure, use the mgr-storage-server tool. For more information about mgr-storage-server, see installation-and-upgrade:hardware-requirements.adoc#install-hardware-requirements-storage.
Execute the following command to migrate and set up a new SUSE Multi-Linux Manager 5.1 server. Replace <oldserver.fqdn> with the FQDN of the 4.3 server:

请务必在开始迁移前升级 4.3 服务器并应用所有可用更新。此外，还需去除所有不必要的通道，以便缩短总迁移时间。

迁移可能需要很长时间，具体取决于需要复制的数据量。为了减少停机时间，可以在初始复制、重新复制或最终复制和切换过程中多次运行迁移，同时旧 4.3 服务器上的所有服务都可以保持正常运行。

只有在最终迁移期间才需要停止旧 4.3 服务器上的进程。

For all non-final replications add the parameter --prepare to prevent the automatic stopping of services on the old 4.3 server.

Re-running a failed migration creates multiple large backup directories, which accumulate and consume significant space, since each unsuccessful migration creates a new backup directory inside /var/lib/containers/storage/volumes.

这些备份不会被迁移工具自动去除。如果迁移失败，您必须手动检查并清理旧的备份目录，以确保有足够空间用于下次尝试。

若未妥善管理此空间，可能导致下次迁移尝试失败。

After the migration and validation of everything, var-pgsql-backup volume can be removed.

The --prepare step can be run multiple times only as long as a final migration has not been started.

Once the final migration is initiated and reaches the database upgrade stage, you must not run the --prepare command again, as it can lead to data corruption.
mgradm migrate podman <oldserver.fqdn> --prepare

过程：最终迁移

停止 4.3 服务器上的 SUSE Manager 服务：
spacewalk-service stop
停止 4.3 服务器上的 PostgreSQL 服务：
systemctl stop postgresql
在 SUSE Multi-Linux Manager 5.1 服务器上执行迁移
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 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 SUSE Manager 4.3 server after the migration.

过程：迁移证书

将 SUSE Manager 4.3 服务器中的该文件复制到新 SUSE Multi-Linux Manager 5.1 服务器。 For example, as /local/ca.file.
使用以下命令将文件复制到容器中：
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 old 4.3 server.

要将其重定向到 5.1 服务器，需要在基础架构级别（DHCP 和 DNS）重命名新服务器，以使用与 4.3 服务器相同的 FQDN 和 IP 地址。

如果客户端上安装了最新版本的受控端，则无需调整 IP 地址，因为较新版本仅通过 FQDN 就能自动重新连接服务器。

3. 客户端工具品牌更新

SUSE Multi-Linux Manager 5.1 为所有受支持的操作系统推出了一套重新命名的客户端工具。此过渡过程无缝衔接，执行新产品同步的用户仅会注意到通道名称已更新。

Channels named SUSE Manager Client Tools for XYZ, used by clients previously registered with SUSE Multi-Linux Manager 4.3 or 5.0, are no longer available in version 5.1 and will no longer receive updates in 5.1.

尽管迁移后旧版通道仍会分配给现有客户端，但对应的储存库已被去除。

为确保客户端能持续接收更新，用户必须执行以下操作：

Mirror the new SUSE Multi-Linux Manager Client Tools for XYZ channels for the relevant products and assign them to the appropriate clients.
Unassign the outdated SUSE Manager Client Tools for XYZ channels.

这也意味着，任何基于旧客户端工具的 CLM 项目都必须相应调整。

示例工作流程请参见 Switch to new client tools channels。