Proxy Migration

In SUSE Manager 4.3, the proxy can be deployed using three different methods: RPM based, containerized running on podman or k3s.

In SUSE Manager 5.0, management of the containerized proxy running with podman was re-designed and made simpler with the mgrpxy tool. At the same time, RPM based support was removed, and only the containerized version running with podman or k3s is supported.

This section describes migrating from Proxy 4.3 using the mgrpxy tool.

An in-place migration from SUSE Manager 4.3 to 5.0 is unsupported. The host operating system has changed from SUSE Linux Enterprise Server 15 SP4 to SLE Micro 5.5 or SUSE Linux Enterprise Server 15 SP6.

The traditional contact protocol is no longer supported in SUSE Manager 5.0 and later. Before migrating from SUSE Manager 4.3 to 5.0, any existing traditional clients including the traditional proxies must be migrated to Salt.

For more information about migrating to Salt clients, see https://documentation.suse.com/suma/4.3/en/suse-manager/client-configuration/contact-methods-migrate-traditional.html

1. Deploy a New SUSE Manager Proxy

Because in-place migration is not supported, the users must deploy a new SUSE Manager proxy with a new FQDN.

For more information about installing SUSE Manager Proxy, see Install SUSE Manager Proxy.

2. Migrate Clients to the New Proxy

Before migrating the clients, ensure that the new proxy is already deployed and fully functional.
Procedure: Migrating Client Between Proxies

  1. Log in to the SUSE Manager Server Web UI.

  2. From the left navigation, select Systems  Systems List.

  3. Navigate to the old 4.3 proxy page, and click the Proxy tab.

  4. Select all systems to "SSM".

  5. From the left navigation, select Systems  System Set Manager.

  6. Select the sub-menu Misc  Proxy.

  7. From the drop-down select the new proxy to migrate to.

  8. Click Change Proxy.

All selected clients will now be migrated to the new proxy. You can check the schedule progress to verify if all clients were successfully migrated.

After a few minutes, the clients will start to show up the new connection path. When all clients have the connection path under the new proxy, the old 4.3 proxy system is not needed anymore and can be removed.

3. TFTP files synchronization

Containerized proxies do not use tftpsync mechanism to transfer tftproot files. Instead these files are transparently downloaded and cached on demand.

To prevent false positive errors during cobbler sync run, migrated 4.3 proxies need to be removed from tftpsync mechanism.

If you previously configured a 4.3 proxy to receive TFTP files, one of the following configuration option is required:

  • In the server container, run configure-tftpsync.sh with the list of remaining 4.3 proxies as arguments. If no 4.3 proxies remain, run configure-tftpsync.sh with no arguments.

  • In the server container, manually remove the relevant proxy from the proxies setting in the /etc/cobbler/settings.yaml file. If there are no 4.3 proxies remaining, then manually remove the proxies list completely.