SUSE Manager/Migration of SUSE Manager Proxies from 2.1 to 3
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. 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 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.
There are 2 options:
- in-place upgrade from the existing SUSE Manager Proxy. Be aware that this is not supported on VMWare guests.
- create a new VMWare guest with SLES12 SP2 and install the SUSE Manager Proxy software on this system.
Create activation keys
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 SLES12-SP2-Updates SUSE-Manager-Proxy-3.0-Pool SP2 SUSE-Manager-Proxy-3.0-Updates SP2
This upgrade can be automated by using the YaST autoinstallation feature:
First you need to create an autoinstallable distribution based on SLES 12 SP2 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-sp2-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-sp2/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-sp2/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-sp2/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-sp2/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.
In "Kernel Options" enter the following value:
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:
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:
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.
Install new server
This is the recommended method.
First install a new SLES12 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, don't forget to setup the tftp synchronization.
Re-register the new SUSE Manager Proxy Server
As already mentioned earlier, deleting the previous SUSE Manager Proxy Server 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 Server 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 Server can access SUSE Manager Server again.