SUSE Manager/Migration of SUSE Manager Proxies from 2.1 to 3

From MicroFocusInternationalWiki
Jump to: navigation, search

SUSE Manager Main Page

For the migration of SUSE Manager Proxies from 2.1 to 3 there are two possible approaches: Existing SUSE Manager Proxies can be auto-upgraded to version 3 in-place by means of a YaST autoinstallation, or Proxies can be replaced with new ones. Both approaches are documented here.

The recommended order for migrations is to first migrate the SUSE Manager server and then the proxies. Note: A SUSE Manager proxy 2.1 cooperates just fine with a new SUSE Manager 3.

General Introduction

A SUSE Manager Proxy is "dumb" in the sense that it has no information about the clients that are connected to it. This means that a SUSE Manager Proxy can be replaced by a new one. Of course, the replacement needs to have the same name and IP address as its predecessor.

In order to replace a SUSE Manager Proxy and keep the clients registered to the proxy leave the old proxy in SUSE Manager. You need to create a re-activation key for this system and register the new proxy using the re-activation key to keep the clients assigned to this proxy. When you remove the old proxy from SUSE Manager, all clients connecting to this proxy, need to be re-registered against the new proxy. This can be prevented and will be discussed in the installation steps.

Migrating a SUSE Manager Proxy from 2.1 to 3

In many cases upgrading the Proxy will be the preferred solution because this will retain all the cached packages. Retaining packages can save a lot of time especially in setups where the proxies are connected to the SUSE Manager server via low-bandwith links.

There are 2 options:

  • Upgrading an existing SUSE Manager Proxy in-place. Note: This is not supported on VMware guests.
  • Installing a new SLES 12 SP2 with the SUSE Manager Proxy add-on; if wanted as a VMware guest.

Create Activation Key

It is advisable to also create a new activation key (labeled "1-sles12sp2-proxy" in this example) that has all these channels assigned; this key will be used later on to subscribe the upgraded proxy to the correct channels. It should use the following base channel:


and the following child channels:

SLE-Manager-Tools12-Pool SP2
SLE-Manager-Tools12-Updates SP2
SUSE-Manager-Proxy-3.0-Pool SP2
SUSE-Manager-Proxy-3.0-Updates SP2

Upgrading SUSE Manager Proxy In-place

This upgrade can be automated by using the YaST autoinstallation feature (AutoYaST):

First you need to create an autoinstallable distribution based on SLES 12 SP2 because SUSE Manager Proxy 3 is based on this version. Refer to the SUSE Manager documentation on how to create an autoinstallable distribution.

In order to start the autoinstallation of a proxy, some additional packages need to be installed on the proxy that are only available in some SUSE Manager Tools channel. Those tools are not available for proxies since the system has been shipped as an appliance only in the past. So in order to be able to provide those packages to the proxies, the underlying SLES 11 SP3 channel (SLES11-SP3-SUSE-Manager-Tools) needs to get cloned and assigned to the affected proxies.

After that you need to create an autoinstallation profile. In this example the label "Proxy3" is being used both for the autoinstallable distribution as well as for the autoinstall profile. Use the following autoinstallation as template and create the autoinstallation profile by uploading the edited file:

<?xml version="1.0"?>
<!DOCTYPE profile>
<profile xmlns="" xmlns:config="">
      <confirm config:type="boolean">false</confirm>
    <add_on_products config:type="list">
        <ask_on_error config:type="boolean">true</ask_on_error>
        <name>SLES12 SP1 Updates</name>
        <ask_on_error config:type="boolean">true</ask_on_error>
        <name>SLE12 Manager Tools Pool</name>
        <ask_on_error config:type="boolean">true</ask_on_error>
        <name>SLE12 Manager Tools Updates</name>
        <ask_on_error config:type="boolean">true</ask_on_error>
        <name>SLE12 Proxy 3 Pool</name>
        <ask_on_error config:type="boolean">true</ask_on_error>
        <name>SLE12 Proxy 3 Update</name>
    <only_installed_packages config:type="boolean">false</only_installed_packages>
    <stop_on_solver_conflict config:type="boolean">true</stop_on_solver_conflict>
    <sysconfig config:type="boolean">true</sysconfig>
    <modified config:type="boolean">true</modified>
    <remove_old config:type="boolean">false</remove_old>
    <keep_install_network config:type="boolean">true</keep_install_network>
    <start_immediately config:type="boolean">true</start_immediately>
    <pre-scripts config:type="list">
        mount /dev/sda1 /mnt
        rm -f /mnt/initrd_koan
        umount /mnt
    <init-scripts config:type="list">
         chmod 640 /etc/sysconfig/rhn/systemid
         chown root:www /etc/sysconfig/rhn/systemid
         systemctl enable squid
         systemctl start squid

Make sure all the channels referenced in this file are available and fully synced. Replace the label "Proxy3" by the one you chose for your autoinstallation profile.

In "Kernel Options" enter the following value:

autoupgrade=1 Y2DEBUG=1

The debug setting is not required but can help investigating problems in case something goes wrong. The "autoupgrade" parameter however is vital!

After saving this data, click on "Variables" and enter the following value:


where you should specify the name of the key that has all the respective channels assigned.

The autoinstall file contains a script named "". In this script you should specify the device name of your /boot partition. The purpose of this script is to workaround the following problem: During installation the initrd of the installation media (SLES12SP2) is being used. This initrd is quite big (around 50 MB), so there is not enough space left when the new kernel is about to getting installed. Therefore, this special script tries to delete this initial ramdisk file after it has been booted from. The partition of your boot partition might differ, so it needs to get explicitly specified in the autoinstall file.

In case this step gets forgotten or messed up (for example, by specifying a wrong value) nothing is lost. During installation of the new kernel, YaST will notice that there is not enough space available and will stop. Now you have the chance to switch to another console (there is a shell running on virtual console 2) and reclaim some disk space by issuing this command:

rm /mnt/boot/initrd_koan

After that, switch back to the console where YaST is running (console 7) and click retry. This time the installation of the kernel will succeed and the rest of the installation should run fine.

The system will reboot, some automatic init scripts will run and after that the proxy will be upgraded to SLES12SP2 based SUSE Manager 3 and will be fully functional.

Replacing the Proxy with a New Server Installation

This is the recommended method.

First install a new SLES 12 SP2 system using your standard procedures. Only this system should be registered with the 1-sles12sp2-proxy (created above), or any other name you have giving. After the server is registered with this key, install SUSE Manager Proxy on this server as have been done for the previous SUSE Manager Proxy Server. The installation procedure has not been changed.

Before the server is installed, perform the following actions (if needed):

  • Copy some information to a central place that also can be accessed by the new server:
    • Copy scripts needed.
    • Copy the activation keys from the previous server. Of course it is always better to re-create the keys.
  • Shutdown the server

After installation, perform the following actions (if needed):

  • Copy the data from the previous SUSE Manager Proxy to the new server .
  • Install any other needed software.
  • If the proxy is also used for autoinstallation, do not forget to setup the TFTP synchronization.

Re-register the New SUSE Manager Proxy

As already mentioned earlier, deleting the previous SUSE Manager Proxy from SUSE Manager Server will break the connection between the clients and the proxy!!!! And all clients have to be re-registered. This can be prevented using the following procedure:

  • In the SUSE Manager Server GUI select the new SUSE Manager Proxy and delete this system.
  • In the SUSE Manager Server GUI select the previous SUSE Manager Proxy Server and select the tab "Reactivation".
  • Click on "Generate New Key" and write down (or copy in clipboard) the new key.
  • On the new SUSE Manager Proxy enter the following to re-register this system:
rhnreg_ks --activationkey=<re-activation key> --force

Now all clients behind the previous SUSE Manager Proxy can access the SUSE Manager Server again.