Difference between revisions of "SUSE Manager/Migration of SUSE Manager Proxies from 2.1 to 3"

From MicroFocusInternationalWiki
Jump to: navigation, search
(Upgrading a SUSE Manager Proxy from 2.1 to 3)
(Replacing a SUSE Manager Proxy)
Line 9: Line 9:
 
A SUSE Manager Proxy is "dumb" in the sense that it has no information whatsoever about the clients that are connected to it. This means that a SUSE Manager Proxy can simply be replaced by a new one. Of course the replacement needs to have the same name and IP address as its predecessor.
 
A SUSE Manager Proxy is "dumb" in the sense that it has no information whatsoever about the clients that are connected to it. This means that a SUSE Manager Proxy can simply 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, simply delete the system from the SUSE Manager system list. Then shut down the proxy and install the new version. After registering the new Proxy to the server using the appropriate channels and running the configuration script, all clients connected via the proxy will work just as before. Note that during the installation of the proxy, the clients will not be able to reach their SUSE Manager server.
+
In order to replace a SUSE Manager Proxy and keep the clients registered to the proxy leave the old proxy in SUSE Manager. '''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 prevented and will be discussed in the installation steps.
 
+
After a SUSE Manager Proxy system has been deleted from the system list, all clients connected to this proxy will be (wrongly) listed as "directly connected" to the SUSE Manager server. This is an transient issue; after the first successful operation of a client (such as executing a remote command or installation of a package or patch) the information will automatically be corrected. So there is no intervention necessary. Some hours after the replacement of the proxy all the information will be correct again automatically.
+
  
 
== Upgrading a SUSE Manager Proxy from 2.1 to 3 ==
 
== Upgrading a SUSE Manager Proxy from 2.1 to 3 ==

Revision as of 06:26, 11 May 2017

Migration of SUSE Manager Proxies from 2.1 to 3

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

For the migration of the proxies there are two possible approaches: Existing SUSE Manager proxies can be auto-upgraded to version 3 by means of a YaST autoinstallation. Or the proxies can just simply be replaced by new ones. Both approaches are documented here.

Replacing a SUSE Manager Proxy

A SUSE Manager Proxy is "dumb" in the sense that it has no information whatsoever about the clients that are connected to it. This means that a SUSE Manager Proxy can simply 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. 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 prevented and will be discussed in the installation steps.

Upgrading 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 which can save a lot of time especially in setups where the proxies are connected to the SUSE Manager server via low-bandwith links.

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

First you need to create an autoinstallable distribution based on SLES 12 SP1 since SUSE Manager Proxy 3 is based on this version. Please 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="http://www.suse.com/1.0/yast2ns" xmlns:config="http://www.suse.com/1.0/configns">
  <general>
  $SNIPPET('spacewalk/sles_no_signature_checks')
    <mode>
      <confirm config:type="boolean">false</confirm>
    </mode>
  </general>
  <add-on>
    <add_on_products config:type="list">
      <listentry>
        <ask_on_error config:type="boolean">true</ask_on_error>
        <media_url>http://$redhat_management_server/ks/dist/child/sles12-sp1-updates-x86_64/Proxy3</media_url>
        <name>SLES12 SP1 Updates</name>
        <product>SLES12-SP1</product>
        <product_dir>/</product_dir>
      </listentry>
      <listentry>
        <ask_on_error config:type="boolean">true</ask_on_error>
        <media_url>http://$redhat_management_server/ks/dist/child/sle-manager-tools12-pool-x86_64-sp1/Proxy3</media_url>
        <name>SLE12 Manager Tools Pool</name>
        <product>SLES12</product>
        <product_dir>/</product_dir>
      </listentry>
      <listentry>
        <ask_on_error config:type="boolean">true</ask_on_error>
        <media_url>http://$redhat_management_server/ks/dist/child/sle-manager-tools12-updates-x86_64-sp1/Proxy3</media_url>
        <name>SLE12 Manager Tools Updates</name>
        <product>SLES12</product>
        <product_dir>/</product_dir>
      </listentry>
      <listentry>
        <ask_on_error config:type="boolean">true</ask_on_error>
        <media_url>http://$redhat_management_server/ks/dist/child/suse-manager-proxy-3.0-pool-x86_64/Proxy3</media_url>
        <name>SLE12 Proxy 3 Pool</name>
        <product>SLES12</product>
        <product_dir>/</product_dir>
      </listentry>
      <listentry>
        <ask_on_error config:type="boolean">true</ask_on_error>
        <media_url>http://$redhat_management_server/ks/dist/child/suse-manager-proxy-3.0-updates-x86_64/Proxy3</media_url>
        <name>SLE12 Proxy 3 Update</name>
        <product>SLES12</product>
        <product_dir>/</product_dir>
      </listentry>
    </add_on_products>
  </add-on>
  <upgrade>
    <only_installed_packages config:type="boolean">false</only_installed_packages>
    <stop_on_solver_conflict config:type="boolean">true</stop_on_solver_conflict>
  </upgrade>
  <backup>
    <sysconfig config:type="boolean">true</sysconfig>
    <modified config:type="boolean">true</modified>
    <remove_old config:type="boolean">false</remove_old>
  </backup>
  <networking>
    <keep_install_network config:type="boolean">true</keep_install_network>
    <start_immediately config:type="boolean">true</start_immediately>
  </networking>
  <scripts>
    <pre-scripts config:type="list">
      <script>
        <filename>remove_initrd_koan.sh</filename>
        <source>
        <![CDATA[
        mount /dev/sda1 /mnt
        rm -f /mnt/initrd_koan
        umount /mnt
        ]]>
        </source>
      </script>
    </pre-scripts>
    <init-scripts config:type="list">
      <script>
        <filename>sles_register.sh</filename>
        <source>
        <![CDATA[
         $SNIPPET('spacewalk/sles_register')
         chmod 640 /etc/sysconfig/rhn/systemid
         chown root:www /etc/sysconfig/rhn/systemid
         systemctl enable squid
         systemctl start squid
         ]]>
        </source>
      </script>
    </init-scripts>
  </scripts>
</profile>

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. It is advisable to also create a new activation key (labeled "1-sles12sp1" 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:

SLES12-SP1-Pool

and the following child channels:

SLE-Manager-Tools12-Pool
SLE-Manager-Tools12-Updates
SLES12-SP1-Updates
SUSE-Manager-Proxy-3.0-Pool
SUSE-Manager-Proxy-3.0-Updates

In "Kernel Options" enter the following value:

autoupgrade=1 Y2DEBUG=1

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

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

registration_key=1-sles12sp1

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

The autoinstall file contains a script named "remove_initrd_koan.sh". 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 (SLES12SP1) 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 get 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 (eg. 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 SLES12SP1 based SUSE Manager 3 and will be fully functional.