ディストリビューションのアップグレードとサーバ移行

  • SUSE Multi-Linux Manager 5.0は、アップグレード前に停止する必要があります。

  • SUSE Multi-Linux Manager 5.0は、ホストOSとしてSL Micro 6.1およびSUSE Linux Enterprise Server 15 SP7上ではサポートされていません。

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の更新では、この回避策が不要になるようにツールが変更されます。

1. 要件と考慮事項

1.1. SSL証明書

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.

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 upgrade 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.1.1. Flag reference

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

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

During a migration the server SSL certificate and CA chain are copied from the source server.

2. クライアントツールのブランド変更

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を参照してください。

3. SLE Micro 5.5からSL Micro 6.1

このドキュメントでは、SUSE Multi-Linux Manager 5.0 Serverが配備されたSLE Micro 5.5ホストをSL Micro 6.1にアップグレードし、SUSE Multi-Linux Manager 5.1に移行するためのテスト済みプロシージャについて説明します。

3.1. 前提条件

  • SUSE Multi-Linux Manager 5.0がSLE Micro 5.5にインストールされ、実行されている。

  • システムは登録済みであり、SCCにアクティブなサブスクリプションがある。

3.2. ディストリビューションのアップグレードとサーバ移行

プロシージャ: SUSE Multi-Linux Manager 5.0からSUSE Multi-Linux Manager 5.1への移行

  1. 現在の製品ステータスを確認します。

    SUSEConnect --status-text

    確認:

    • ベースOS: SUSE Linux Enterprise Micro 5.5

    • 拡張機能: SUSE Manager Server 5.0拡張機能

  2. システムが更新されていることを確認します。

    transactional-update patch

    • パッチが適用された場合、移行を続行する前に、サーバを停止し、システムを再起動してください。

      mgradm stop
reboot

    • 更新が見つからなかった場合、移行ステップに直接進むことができます。

  3. 移行を開始します。

    transactional-update migration --auto-agree-with-licenses --gpg-auto-import-keys

    プロンプトに従って、SUSE Linux Micro 6.1およびSUSE Multi-Linux Manager Server Extension 5.1への利用可能な移行を選択します。

  4. サーバを停止し、再起動して変更を適用します。

    mgradm stop
reboot

  5. 再起動後のチェックを実行します。

    アップグレードされたOSとSUSE Multi-Linux Manager拡張機能を確認します。

    cat /etc/os-release
SUSEConnect --status-text

    以下が表示されるはずです。

    • PRETTY_NAME="SUSE Linux Micro 6.1"

    • SUSE Multi-Linux Manager Server 5.1 Extension

  6. Enable root SSH access (if required).

    SL Micro 6.1 disables root login via SSH by default.

    Edit /etc/ssh/sshd_config.d/sshd.conf:

    PermitRootLogin yes

    サービスを再起動します。

    systemctl restart sshd

    詳細については、SL Microへのリモートルートログインを参照してください。

  7. SUSE Multi-Linux Managerツールを確認します。

    mgradm --version

    予想される出力:

    • Version 5.1.11 or higher

    • References 5.1.0 or higher

  8. サーバコンテナをアップグレードします。

    Risk of Automated Version Downgrade and PTF Loss

    Running the mgradm upgrade podman command when no newer upgrade is available will cause the system to automatically revert to the base version. This process removes all currently applied Program Temporary Fixes (PTFs) without a confirmation prompt.

    To avoid unintended data or fix loss, verify upgrade availability before execution. Future releases will include a confirmation prompt to prevent this behavior.

    		 
    mgradm start
mgradm upgrade podman

    プロンプトに従い、新しい5.1.0コンテナをプルして設定します。

  9. 実行中のコンテナを確認します。

    podman ps

    以下が表示されるはずです。

    • server:5.1.0 or higher

    • server-postgresql:5.1.0 or higher

Errors for missing services like uyuni-db or saline during upgrade can be ignored if not installed previously.

3.3. 移行の完了

システムは現在、SL Micro 6.1上でSUSE Multi-Linux Manager 5.1を実行しています。 本番運用を再開する前に設定を検証してください。 このサーバにSUSE Multi-Linux Manager 5.0プロキシが接続されている場合は、5.0から5.1へのプロキシの移行ガイドに進み、プロキシホストをアップグレードしてください。

3.4. データベースバックアップボリューム

Server migration or upgrade with mgradm migration or mgradm upgrade can create a volume with the database backup.

When the PostgreSQL database version is increased, the old database must be stored in a separate location before running the upgrade. For this purpose mgradm dynamically creates the volume var-pgsql-backup. When the migration or upgrade is done and the user has validated that the new system is working as expected, this volume can be removed safely.

4. SUSE Linux Enterprise Server 15 SP6から15 SP7

このドキュメントでは、SUSE Multi-Linux Manager 5.0 Serverが配備されたSUSE Linux Enterprise Server 15 SP6ホストをSUSE Multi-Linux Manager 5.1を備えたSUSE Linux Enterprise Server 15 SP7にアップグレードするためのテスト済みプロシージャについて説明します。

4.1. 前提条件

  • SUSE Multi-Linux Manager 5.0がSUSE Linux Enterprise Server 15 SP6 にインストールされ、実行されている。

  • システムはSUSEカスタマーセンター(SCC)に登録済みで、有効なサブスクリプションがある。

  • 続行する前にバックアップ作成されていることを確認する。

4.2. ディストリビューションのアップグレードとサーバ移行

プロシージャ: SUSE Multi-Linux Manager 5.0からSUSE Multi-Linux Manager 5.1への移行

  1. 現在の製品ステータスを確認します。

    SUSEConnect --status-text

    確認:

    • Base OS: SUSE Linux Enterprise Server 15 SP6

    • 拡張機能: SUSE Manager Server 5.0拡張機能

  2. すべてのシステムパッチを適用します。

    zypper patch

  3. サーバを停止し、更新スタックが更新された場合は再起動します。

    mgradm stop
reboot

  4. Zypperの移行ツールを起動します。

    zypper migration

    Zypperは、可能な移行ターゲットと詳細を表示します。

  5. 適切なターゲットを選択し、プロンプトに従って移行を実行します。

  6. 移行が完了したら、サーバを停止して、システムを再起動します。

    mgradm stop
reboot

  7. 再起動後のチェックを実行します。

    アップグレードされたOSとSUSE Multi-Linux Manager拡張機能を確認します。

    cat /etc/os-release
SUSEConnect --status-text

    以下が表示されるはずです。

    • VERSION="15-SP7"

    • SUSE Multi-Linux Manager Server 5.1 Extension for SLE

  8. SUSE Multi-Linux Managerツールのバージョンを確認します。

    mgradm --version

    予想される出力:

    • Version 5.1.11 or higher

    • Image tag 5.1.0 or higher

  9. サーバコンテナをアップグレードします。

    Risk of Automated Version Downgrade and PTF Loss

    Running the mgradm upgrade podman command when no newer upgrade is available will cause the system to automatically revert to the base version. This process removes all currently applied Program Temporary Fixes (PTFs) without a confirmation prompt.

    To avoid unintended data or fix loss, verify upgrade availability before execution. Future releases will include a confirmation prompt to prevent this behavior.

    		 
    mgradm start
mgradm upgrade podman

    プロンプトに従って新しいコンテナイメージを取得し、環境を再設定します。

  10. 実行中のコンテナを確認します。

    podman ps

    予想されるコンテナ:

    • server:5.1.0 or higher

    • server-postgresql:5.1.0 or higher

4.3. 移行の完了

システムは現在、SUSE Linux Enterprise Server 15 SP7上でSUSE Multi-Linux Manager 5.1を実行しています。 本番運用を再開する前に設定を検証してください。 このサーバにSUSE Multi-Linux Manager 5.0プロキシが接続されている場合は、5.0から5.1へのプロキシの移行に進んでください。

4.4. データベースバックアップボリューム

Server migration or upgrade with mgradm migration or mgradm upgrade can create a volume with the database backup.

When the PostgreSQL database version is increased, the old database must be stored in a separate location before running the upgrade. For this purpose mgradm dynamically creates the volume var-pgsql-backup. When the migration or upgrade is done and the user has validated that the new system is working as expected, this volume can be removed safely.