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 /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 업데이트에서는 이 해결 방법이 불필요하도록 도구가 변경될 예정입니다.

Before upgrading, verify that every root and intermediate CA certificate used by SUSE Multi-Linux Manager marks X509v3 Basic Constraints as critical and includes CA:TRUE. Strict certificate validators, including Python 3.13 and later, reject CA certificates that miss the critical flag.

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 reportdb and db as Subject Alternative Name. This is no longer needed, and only the Server FQDN (used to access the report database) is mandatory as Subject Alternative Name.

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. 배포판 업그레이드 및 서버 마이그레이션

Procedure: Migration from SUSE Multi-Linux Manager 5.1 to SUSE Multi-Linux Manager 5.2

  1. 현재 제품 상태를 확인합니다.

    SUSEConnect --status-text

    확인:

    • Base OS: SL Micro 6.1

    • Extension: SUSE Multi-Linux Manager Server 5.1 Extension

  2. 시스템이 업데이트되었는지 확인합니다.

    transactional-update patch

    • 패치가 적용된 경우 마이그레이션을 진행하기 전에 서버를 중지한 다음 시스템을 재부팅합니다.

      mgradm stop
reboot

    • 업데이트가 없는 경우, 마이그레이션 단계로 바로 진행할 수 있습니다.

  3. 마이그레이션을 시작합니다.

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

    Follow the prompts and select the available migration to SUSE Linux Micro 6.2 and SUSE Multi-Linux Manager Server Extension 5.2.

  4. 사용하지 않는 컨테이너 이미지를 정리하여 디스크 공간을 확보합니다.

    podman image prune -a

    In some upgrades, multiple *.rpmnew and *.rpmsave files 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.

  5. 서버를 중지한 다음 재부팅하여 변경 사항을 적용합니다.

    mgradm stop
reboot

  6. 재부팅 후 점검을 수행합니다.

    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 Extension

    • Version: mgradm version 5.2.0 or higher

  7. Upgrade server containers.

    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

    Follow the prompts to pull and configure the new 5.2.x containers.

  8. Verify PostgreSQL database version.

    podman ps

    예상 출력:

    • server:5.2.0 or higher

    • server-postgresql:5.2.0 or higher

  9. 사용하지 않는 컨테이너 이미지를 정리하여 디스크 공간을 확보합니다.

    podman image prune -a

    In some upgrades, multiple *.rpmnew and *.rpmsave files 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.

  10. Verify running containers:

    podman ps

    You 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

Procedure: Update SUSE Multi-Linux Manager components on SUSE Linux Enterprise Server 15 SP7

  1. 현재 제품 상태를 확인합니다.

    SUSEConnect --status-text

    확인:

    • Base OS: SUSE Linux Enterprise Server 15 SP7

    • Extension: SUSE Multi-Linux Manager Server 5.1 Extension

  2. 시스템이 업데이트되었는지 확인합니다.

    zypper patch

    If patches were applied, stop the server and then reboot before proceeding:

    mgradm stop
reboot

  3. Perform the migration to SUSE Multi-Linux Manager 5.2.

    zypper migration

    Select to migrate to:

    • SUSE Multi-Linux Manager Server Extension 5.2

  4. Stop the server and reboot.

    mgradm stop
reboot

  5. 재부팅 후 점검을 수행합니다.

    Verify SUSE Multi-Linux Manager extension:

    SUSEConnect --status-text

    예상 출력:

    • Extension: SUSE Multi-Linux Manager Server 5.2 Extension

  6. Verify SUSE Multi-Linux Manager version.

    mgradm --version

    예상 출력:

    • Version: mgradm version 5.2.0 or higher

  7. Upgrade server containers.

    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

    Follow the prompts to pull and configure the new 5.2.x containers.

  8. Verify containers:

    podman ps

    예상 출력:

    • server:5.2.0 or higher

    • server-postgresql:5.2.0 or 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.