Server Upgrade from 5.0 to 5.2
|
SUSE Multi-Linux Manager 5.0は、アップグレード前に停止する必要があります。 |
|
SUSE Multi-Linux Manager server hosts that are hardened for security may restrict execution of files from the 例:
SUSE Multi-Linux Managerの更新では、この回避策が不要になるようにツールが変更されます。 |
|
Before upgrading, verify that every root and intermediate CA certificate used by SUSE Multi-Linux Manager marks If your installation uses an older self-signed CA generated by SUSE Multi-Linux Manager, you might need to create a new CA and new server certificates, then deploy the new root CA to all clients. You can rotate the CA certificate on a Podman installation using the new Note that the command can only be used after upgrading both While failing to rotate the CA certificate may not cause an immediate system failure, it is strongly discouraged. |
SSL証明書は後の段階で必要となります。 自己署名生成CAおよび証明書を使用しない場合は、開始する前に以下があることを確認します。
-
認証局(CA) SSLパブリック証明書。 CAチェーンを使用している場合は、すべての中間CAも利用できる必要があります。
-
SSLデータベース機密鍵。
-
SSLデータベース証明書。
すべてのファイルがPEM形式である必要があります。
The hostname of the SSL server certificate must match the fully qualified hostname of the machine you deploy them on. You can set the hostnames in the X509v3 Subject Alternative Name section of the certificate. You can also list multiple hostnames if your environment requires it. Supported Key types are RSA and EC (Elliptic Curve).
|
In the past, database SSL certificate required |
The database container needs only the externally facing fully qualified domain name. The old certificates with db and reportdb SANs can be still used.
The same certificate can be used for both the main container and the database one.
In order to pass the new certificates to the upgrade command, use the --ssl-db-ca-root, --ssl-db-cert and --ssl-db-key parameters.
In SUSE Multi-Linux Manager 5.2, internal communication between the uyuni-server and uyuni-db Podman containers has been optimized. Because this traffic is strictly local, TLS is now explicitly disabled in /etc/rhn/rhn.conf. Consequently, defining db and reportdb in the certificate’s Subject Alternative Names (SAN) is no longer required or used. However, perimeter security has become stricter, and remote connections to the PostgreSQL port (5432) are now explicitly enforced to be TLS-protected via /var/lib/pgsql/data/pg_hba.conf.
|
特定のバージョンへのアップグレード
タグパラメータを指定しない場合、デフォルトで最新バージョンにアップグレードされます。特定のバージョンにアップグレードするには、タグパラメータと目的のイメージタグを指定します。 |
During a migration the server SSL certificate and CA chain are copied from the source server.
1. SLE Micro 5.5 to SL Micro 6.2
This document provides the tested procedure to upgrade a SLE Micro 5.5 host deployed with SUSE Multi-Linux Manager 5.0 Server to SL Micro 6.2 and migrate to SUSE Multi-Linux Manager 5.2.
1.1. 前提条件
-
SUSE Multi-Linux Manager 5.0がSLE Micro 5.5にインストールされ、実行されている。
-
システムは登録済みであり、SCCにアクティブなサブスクリプションがある。
1.2. ディストリビューションのアップグレードとサーバ移行
現在の製品ステータスを確認します。
SUSEConnect --status-text確認:
ベースOS:
SUSE Linux Enterprise Micro 5.5拡張機能:
SUSE Manager Server 5.0拡張機能システムが更新されていることを確認します。
transactional-update patch
パッチが適用された場合、移行を続行する前に、サーバを停止し、システムを再起動してください。
mgradm stop reboot更新が見つからなかった場合、移行ステップに直接進むことができます。
移行を開始します。
transactional-update migration --auto-agree-with-licenses --gpg-auto-import-keysFollow the prompts and select the available migration to SUSE Linux Micro 6.2 and SUSE Multi-Linux Manager Server Extension 5.2.
未使用のコンテナイメージをクリーンアップし、ディスク容量を解放します。
podman image prune -a
In some upgrades, multiple
*.rpmnewand*.rpmsavefiles may be generated. The presence or number of these files does not indicate that manual action is required. In SUSE Multi-Linux Manager container environments, required configuration changes are applied automatically during the upgrade process. These files are created as a result of differences between packaged defaults and existing configuration files, and may also include internal or informational changes that are not intended to be merged. If manual action is required for a configuration change, it will be explicitly documented in the release notes or upgrade documentation.Do not treat these files as a post-upgrade checklist or merge them in bulk. Only review a file if you are actively troubleshooting a specific issue and understand the impact of the configuration it contains. If a change is required, it should be applied intentionally based on a known requirement, not by copying differences from these files. If you are unsure, leave the file unchanged.
サーバを停止し、再起動して変更を適用します。
mgradm stop reboot再起動後のチェックを実行します。
Verify SUSE Multi-Linux Manager extension and SUSE Multi-Linux Manager version:
SUSEConnect --status-text mgradm --version予想される出力:
Extension:
SUSE Multi-Linux Manager Server 5.2 ExtensionVersion: referencing
5.2.0or higherVerify PostgreSQL database version.
podman ps予想される出力:
server:5.2.0or higher
server-postgresql:5.2.0or higherサーバコンテナをアップグレードします。
Risk of Automated Version Downgrade and PTF Loss
Running the
mgradm upgradecommand 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.
Before running
mgradm upgrade, check whether/etc/systemd/system/uyuni-server.servicecontains explicit IPv6 port bindings in the form-p [::]:PORT:PORT. These bindings are incompatible with netavark on SL Micro 6.2 and cause malformed nftables rules that prevent the web UI from being reachable after the upgrade.If such lines are present, remove them before proceeding:
-p 80:80 \ - -p [::]:80:80 \ -p 443:443 \ - -p [::]:443:443 \Then reboot the host before continuing:
systemctl rebootmgradm start mgradm upgradeFollow the prompts to pull and configure the new 5.2.x containers.
Verify running containers:
podman psYou should see all the expected server containers are up and running.
未使用のコンテナイメージをクリーンアップし、ディスク容量を解放します。
podman image prune -a
In some upgrades, multiple
*.rpmnewand*.rpmsavefiles may be generated. The presence or number of these files does not indicate that manual action is required. In SUSE Multi-Linux Manager container environments, required configuration changes are applied automatically during the upgrade process. These files are created as a result of differences between packaged defaults and existing configuration files, and may also include internal or informational changes that are not intended to be merged. If manual action is required for a configuration change, it will be explicitly documented in the release notes or upgrade documentation.Do not treat these files as a post-upgrade checklist or merge them in bulk. Only review a file if you are actively troubleshooting a specific issue and understand the impact of the configuration it contains. If a change is required, it should be applied intentionally based on a known requirement, not by copying differences from these files. If you are unsure, leave the file unchanged.
1.3. 移行の完了
The server host system is now running SL Micro 6.2 with updated SUSE Multi-Linux Manager 5.2 Server packages.
If you have a SUSE Multi-Linux Manager 5.0 proxy connected to this server, proceed to the Proxy Migration 5.0 > 5.2 guide to upgrade the proxy host.
Validate your setup before resuming production operations.
1.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.
2. SUSE Linux Enterprise Server 15 SP6から15 SP7
This document provides the procedure to upgrade a SUSE Linux Enterprise Server 15 SP6 host deployed with SUSE Multi-Linux Manager 5.0 Server to SUSE Linux Enterprise Server 15 SP7 and migrate to SUSE Multi-Linux Manager 5.2.
2.1. 前提条件
-
SUSE Multi-Linux Manager 5.0 is installed and running on SUSE Linux Enterprise Server 15 SP6.
-
システムは登録済みであり、SCCにアクティブなサブスクリプションがある。
2.2. ディストリビューションのアップグレードとサーバ移行
現在の製品ステータスを確認します。
SUSEConnect --status-text確認:
Base OS:
SUSE Linux Enterprise Server 15 SP6拡張機能:
SUSE Manager Server 5.0拡張機能システムが更新されていることを確認します。
zypper patchIf patches were applied, stop the server and then reboot before proceeding:
mgradm stop rebootPerform the migration to SP7 and SUSE Multi-Linux Manager 5.2.
zypper migrationSelect to migrate to:
SUSE Linux Enterprise Server 15 SP7
SUSE Multi-Linux Manager Server Extension 5.2Stop the server and reboot.
mgradm stop reboot再起動後のチェックを実行します。
Verify SUSE Multi-Linux Manager extension:
SUSEConnect --status-text予想される出力:
Extension:
SUSE Multi-Linux Manager Server 5.2 ExtensionVerify SUSE Multi-Linux Manager version.
mgradm --version予想される出力:
Version: referencing
5.2.0or higherサーバコンテナをアップグレードします。
Risk of Automated Version Downgrade and PTF Loss
Running the
mgradm upgradecommand 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 upgradeFollow the prompts to pull and configure the new 5.2.x containers.
Verify containers:
podman ps予想される出力:
server:5.2.0or higher
server-postgresql:5.2.0or higher
2.3. 移行の完了
The server host system is now running SUSE Linux Enterprise Server 15 SP7 with updated SUSE Multi-Linux Manager 5.2 Server packages.
If you have a SUSE Multi-Linux Manager 5.0 proxy connected to this server, proceed to the Proxy Migration 5.0 > 5.2 guide to upgrade the proxy host.
Validate your setup before resuming production operations.
2.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.