コンテナ化された環境への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)は古いサーバの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

--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. インストールメディアのダウンロード
プロシージャ: インストールメディアのダウンロード

  1. https://www.suse.com/download/sle-micro/でSL Micro 6.1のインストールメディアを見つけて、適切なメディアファイルをダウンロードします。

  2. 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のインストール

  1. SLE Micro 6.1のインストールイメージを含むDVDまたはUSBフラッシュドライブ(USBディスクまたはキー)を挿入します。

  2. システムをブートまたは再起動します。

  3. Use the arrow keys to select Installation.

  4. キーボードと言語を調整します。

  5. Click the checkbox to accept the license agreement.

  6. Click Next to continue.

  7. 登録方法を選択します。この例では、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 Retail Branch Server

    SL Micro 6.1エンタイトルメントは、SUSE Multi-Linux Managerエンタイトルメント内に含まれているため、別途登録コードは必要ありません。

  8. SUSE Customer Centerの電子メールアドレスを入力します。

  9. SL Micro 6.1の登録コードを入力します。

  10. Click Next to continue.

  11. 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.

  12. Click Next to continue.

  13. SUSE Multi-Linux Manager 5.1拡張機能の登録コードを入力します。

  14. 次へをクリックして続行します。

  15. On the NTP Configuration page click Next.

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

  17. 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のインストール後に製品を登録するステップについて説明します。

次のステップでは、SUSE Multi-Linux Manager 5.1拡張機能をx86-64アーキテクチャに登録します。そのため、x86-64アーキテクチャの登録コードが必要になります。ARMまたはs390xアーキテクチャを登録する場合は、正しい登録コードを使用してください。
プロシージャ: コマンドラインからの登録

  1. 次のコマンドで利用可能な拡張機能を一覧表示します。

    transactional-update --quiet register --list-extensions

  2. 利用可能な拡張機能のリストから、インストールしたい拡張機能を選択します。

    1. サーバをインストールする場合は、次のコマンドで 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>

    2. プロキシをインストールする場合は、次のコマンドで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>

  3. 再起動します。

2.1.1.4. システムの更新
プロシージャ: システムの更新

  1. rootとしてログインします。

  2. transactional-updateを実行します。

    transactional-update

  3. 再起動します。

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拡張機能をインストールする

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

  2. ホストオペレーティングシステム(SUSE Linux Enterprise Server 15 SP7)と拡張機能の両方の登録コードがあることを確認します。

  3. SUSE Linux Enterprise Server 15 SP7のインストールを開始します。

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

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

  4. 登録方法を選択します。この例では、SUSEカスタマーセンターにサーバを登録します。

  5. SUSE Customer Centerの電子メールアドレスを入力します。

  6. SUSE Linux Enterprise Server 15 SP7の登録コードを入力します。

  7. Click Next to continue.

    SUSE Linux Enterprise Server 15 SP7には、有効なSUSE Linux Enterprise Serverサブスクリプションと対応する登録コードが必要であり、この画面で入力する必要があることに注意してください。以下でSUSE Multi-Linux Manager拡張機能の登録コードを入力する必要があります。

  8. In the screen Extensions and Modules Selection check the following:

    • サーバをインストールするにはSUSE Multi-Linux Managerサーバ拡張機能を選択し、プロキシをインストールするにはSUSE Multi-Linux Managerプロキシ拡張機能を選択します。

    • ベースシステムモジュール

    • Containersモジュール

  9. Click Next to continue.

  10. SUSE Multi-Linux Manager 5.1拡張機能の登録コードを入力します。

  11. 次へをクリックして続行します。

  12. インストールを完了します。

  13. インストールが完了したら、rootとして新しくインストールしたサーバにログインします。

  14. システムを更新します(オプション。インストール時にシステムが更新をダウンロードするように設定されていない場合)。

    zypper up

  15. 再起動します。

2.1.2.2. オプション: コマンドラインからの登録

SUSE Linux Enterprise Serverインストール時にSUSE Multi-Linux Manager 5.1を拡張機能として追加した場合、このプロシージャはスキップできます。

ただし、オプションで、登録を行なわずに次へ進むボタンを選択することにより、SUSE Linux Enterprise Serverのインストール中に登録をスキップできます。このセクションでは、SUSE Linux Enterprise Serverのインストール後に製品を登録するステップについて説明します。

次のステップでは、SUSE Multi-Linux Manager 5.1拡張機能をx86-64アーキテクチャに登録します。そのため、x86-64アーキテクチャの登録コードが必要になります。

ARMまたはs390xアーキテクチャを登録する場合は、正しい登録コードを使用してください。
プロシージャ: コマンドラインからの登録

  1. 次のコマンドで利用可能な拡張機能を一覧表示します。

    SUSEConnect --list-extensions

  2. 利用可能な拡張機能のリストから、インストールしたい拡張機能を選択します。

    • 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

  1. 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.

  2. システムを再起動するか、次のコマンドを実行してPodmanサービスを起動します。

    systemctl enable --now podman.service

2.2. SSH接続の準備

このステップを使用すると、新しいSUSE Multi-Linux Manager 5.1サーバが既存の4.3サーバにパスワードを必要とせずにSSH経由で接続できるようになります。このステップには、SSHキーの生成と設定、SSHエージェントのセットアップ、および公開鍵の古いサーバへのコピーが含まれます。このセットアップは、手動による介入なしに移行プロセスを実行するために必要です。

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

  1. 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

  2. パスワードを要求しない4.3サーバへの接続のために、新しいサーバ上でSSH設定とエージェントを準備する必要があります。

    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. 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.

  4. 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.

間違ったパスワードを入力すると、データベース証明書の生成に失敗して、移行が中止され、次のエラーが表示されます。

Error: cannot configure db container: Cannot generate database certificate: CA validation failed!

移行プロセスを開始する前に、正しいCAパスワードが使用可能であることを確認します。
プロシージャ: 移行を実行する

  1. 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.

  2. 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
プロシージャ: 最終移行

  1. 4.3サーバ上のSUSE Managerサービスを停止します。

    spacewalk-service stop

  2. 4.3サーバ上のPostgreSQLサービスを停止します。

    systemctl stop postgresql

  3. SUSE Multi-Linux Manager 5.1サーバで最終移行を実行します。

    mgradm migrate podman <oldserver.fqdn>

  4. 信頼されている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.

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

  1. SUSE Manager 4.3サーバから新しいSUSE Multi-Linux Manager 5.1サーバにファイルをコピーします。 For example, as /local/ca.file.

  2. 次のコマンドを使用してファイルをコンテナにコピーします。

    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アドレスを使用する必要があります。

クライアントにminionの最新バージョンがインストールされている場合、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を参照してください。