Server Upgrade from 5.1 to 5.2
|
SUSE Multi-Linux Manager 5.1 must be stopped before the upgrade. |
|
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. For the verification command, certificate replacement, and client root-CA deployment procedure, see administration:ssl-certs-imported.adoc#ssl-certs-verify-ca-basic-constraints, administration:ssl-certs-selfsigned.adoc#ssl-certs-selfsigned-create-replace, and administration:ssl-certs-imported.adoc#ssl-certs-import-deploy-root-ca. |
后续流程需要 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, meaning that only the database certificates are required.
1. SL Micro 6.1 to SL Micro 6.2
This document provides the tested procedure to upgrade a SL Micro 6.1 host deployed with SUSE Multi-Linux Manager 5.1 Server to SL Micro 6.2 and migrate to SUSE Multi-Linux Manager 5.2.
1.1. 先决条件
-
SUSE Multi-Linux Manager 5.1 is installed and running on SL Micro 6.1.
-
系统已注册到 SCC 且拥有有效的订阅。
1.2. 发行套件升级和服务器迁移
校验当前产品状态。
SUSEConnect --status-text确认以下信息:
Base OS:
SL Micro 6.1Extension:
SUSE Multi-Linux Manager Server 5.1 Extension确保系统已更新。
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:
mgradm version 5.2.0or higherUpgrade server containers.
Risk of Automated Version Downgrade and PTF Loss
Running the
mgradm upgrade podmancommand 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 podmanFollow the prompts to pull and configure the new 5.2.x containers.
Verify PostgreSQL database version.
podman ps预期输出:
server:5.2.0or higher
server-postgresql:5.2.0or higher清理未使用的容器映像以释放磁盘空间:
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.
Verify running containers:
podman psYou should see all the expected server containers are up and running.
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.1 proxy connected to this server, proceed to the Proxy Migration 5.1 > 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 SP7
This document provides the procedure to upgrade a SUSE Linux Enterprise Server 15 SP7 host deployed with SUSE Multi-Linux Manager 5.1 Server to SUSE Multi-Linux Manager 5.2.
2.1. 先决条件
-
SUSE Multi-Linux Manager 5.1 is installed and running on SUSE Linux Enterprise Server 15 SP7.
-
系统已注册到 SCC 且拥有有效的订阅。
2.2. Server package update and migration
校验当前产品状态。
SUSEConnect --status-text确认以下信息:
Base OS:
SUSE Linux Enterprise Server 15 SP7Extension:
SUSE Multi-Linux Manager Server 5.1 Extension确保系统已更新。
zypper patchIf patches were applied, stop the server and then reboot before proceeding:
mgradm stop rebootPerform the migration to SUSE Multi-Linux Manager 5.2.
zypper migrationSelect to migrate to:
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:
mgradm version 5.2.0or higherUpgrade server containers.
Risk of Automated Version Downgrade and PTF Loss
Running the
mgradm upgrade podmancommand 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 podmanFollow 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.1 proxy connected to this server, proceed to the Proxy Migration 5.1 > 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.