2 SUSE Manager 3.2 Proxy

The following section provides SUSE Manager Proxy requirements.

Supported Client Systems. For supported clients and their requirements, see Section 1.7, “Supported Client Systems”.

Hardware Requirements. Hardware requirements highly depend on your usage scenario. When planning proxy environments, consider the amount of data you want to cache on your proxy. If your proxy should be a 1:1 mirror of your SUSE Manager , the same amount of disk space is required. For specific hardware requirements, see the following table.

Tip: Storage for Proxy Data

SUSE recommends storing the squid proxy caching data on a separate disk formatted with the XFS file system.

SSL Certificate Password. For installing the proxy, you need the SSL certificate password entered during the initial installation of SUSE Manager .

Network Requirements. For additional network requirements, see Section 1.8, “Network Requirements”.

SUSE Customer Center. For using SUSE Manager Proxy , you need an account at SUSE Customer Center (SCC) where your purchased products and product subscriptions are registered. Make sure you have the following subscriptions:

Network Time Protocol (NTP). The connection to the Web server via Secure Sockets Layer (SSL) requires correct time settings on the server, proxy and clients. For this reason, all systems must use NTP. For more information, see https://www.suse.com/documentation/sles-12/book_sle_admin/data/cha_netz_xntp.html.

Virtual Environments. The following virtual environments are supported:

For running SUSE Manager Proxy in virtual environments, use the following settings for the virtual machine (VM):

The following section will guide you through the installation and setup procedure.

Important: Registering Proxies

SUSE Manager Proxy systems are registered as traditional clients using a bootstrap script. Currently there is no method to register proxy systems using Salt. A SUSE Manager Proxy can serve both Traditional and Salt clients.

Important: Procedure: Registering the Proxy

First completly download the channels (SUSE Linux Enterprise  12 SP3) and then create the activation key. Only then you can select the correct child channels.

+

A few more steps are still needed:

You will then be able to register your clients against the proxy using the Web UI or a bootstrap script as if it were a SUSE Manager server. For more information, see Section 2.2.6, “Registering Salt Clients via SUSE Manager Proxy”.

Make sure the suma_proxy pattern version 2.5.1.3 or later is installed using the following command on the proxy:

{prompt.root}zypper in -t pattern suma_proxy

The new salt-broker service will be automatically started at the end of the package installation. This service forwards the Salt interactions to the SUSE Manager server.

Note: Proxy Chains

It is possible to arrange Salt proxies in a chain. In such a case, the upstream proxy is named “parent” .

Make sure the proxie’s TCP ports 4505 and 4506 are open and that the proxy can reach the SUSE Manager server (or another upstream proxy) on these ports.

The proxy will share some SSL information with the SUSE Manager server, so the next step is to copy the certificate and its key from the SUSE Manager server or the upstream proxy.

As root , enter the following commands on the proxy using your SUSE Manager server or chained proxy named as PARENT:

{prompt.root}cd /root/ssl-build{prompt.root}scp root@`PARENT`:/root/ssl-build/RHN-ORG-PRIVATE-SSL-KEY .{prompt.root}scp root@`PARENT`:/root/ssl-build/RHN-ORG-TRUSTED-SSL-CERT .{prompt.root}scp root@`PARENT`:/root/ssl-build/rhn-ca-openssl.cnf .

Note: Known Limitation

The SUSE Manager Proxy functionality is only supported if the SSL certificate was signed by the same CA as the SUSE Manager Server certificate. Using certificates signed by different CAs for Proxies and Server is not supported.

The configure-proxy.sh script will finalize the setup of your SUSE Manager Proxy .

Now execute the interactive configure-proxy.sh script. Pressing Enter without further input will make the script use the default values provided between brackets []. Here is some information about the requested settings:

If parts are missing, such as CA key and public certificate, the script prints commands that you must execute to integrate the needed files. When the mandatory files are copied, re-run configure-proxy.sh. Also restart the script if a HTTP error was met during script execution.

configure-proxy.sh activates services required by SUSE Manager Proxy, such as squid , apache2 , salt-broker , and jabberd .

To check the status of the proxy system and its clients, click the proxy system’s details page on the Web UI (Systems › Proxy , then the system name). Connection and Proxy subtabs display the respective status information.

Proxy servers may now act as a broker and package cache for Salt minions. These minions can be registered with a bootstrap script like the traditional clients, or directly from the Web UI or the command line.

Registering Salt clients via SUSE Manager Proxy from the Web UI is done almost the same way as registering clients directly with the SUSE Manager server. The difference is that you specify the name of the proxy in the Proxy drop-box on Salt › Bootstrapping page.

Figure 2.3: Bootstrapping a Salt Client With a Proxy #

Registering clients (either traditional or Salt) via SUSE Manager Proxy with a script is done almost the same way as registering clients directly with the SUSE Manager server. The difference is that you create the bootstrap script on the SUSE Manager Proxy with a command-line tool. The bootstrap script then deploys all necessary information to the clients. The bootstrap script refers some parameters (such as activation keys or GPG keys) that depend on your specific setup.

The clients are registered with the SUSE Manager Proxy specified in the bootstrap script.

Within the Web UI , standard proxy pages will show information about client, no matter whether minions or traditional clients.

A list of clients connected to a proxy can be located under Systems <proxy name> DetailsProxy .

A list of chained proxies for a minion can be located under Systems <minion name> DetailsConnection

If you decide to move any of your clients between proxies or the server you will need to repeat the registration process from scratch.

To enable PXE boot via a proxy server, additional software must be installed and configured on both the SUSE Manager server and the SUSE Manager Proxy server.

SUSE Manager is using Cobbler to provide provisioning. PXE (tftp) is installed and activated by default. To enable systems to find the PXE boot on the SUSE Manager Proxy server add the following to the DHCP configuration for the zone containing the systems to be provisioned:

next-server:`IP_Address_of_SUSE_Manager_Proxy_Server`filename: "pxelinux.0"

A SUSE Manager Proxy is dumb in the sense that it does not contain any information about the clients which are connected to it. A SUSE Manager Proxy can therefore be replaced by a new one. Naturally, the replacement proxy must have the same name and IP address as its predecessor.

In order to replace a SUSE Manager Proxy and keeping the clients registered to the proxy leave the old proxy in SUSE Manager . Create a reactivation key for this system and then register the new proxy using the reactivation key. If you do not use the reactivation key, you will need to re-registered all the clients against the new proxy.

Important: Proxy Installation and Client Connections

During the installation of the proxy, clients will not be able to reach the SUSE Manager server. After a SUSE Manager Proxy system has been deleted from the systems list, all clients connected to this proxy will be (incorrectly) listed as directly connected to the SUSE Manager server. After the first successful operation on a client such as execution of a remote command or installation of a package or patch this information will automatically be corrected. This may take a few hours.

In most situations upgrading the proxy will be your preferred solution as this retains all cached packages. Selecting this route saves time especially regarding proxies connected to SUSE Manager server via low-bandwith links. This upgrade is similar to a standard client migration.

Warning: Synchronizing Target Channels

Before successfully initializing the product migration, you first must make sure that the migration target channels are completely mirrored. For the upgrade to SUSE Manager  3.1 Proxy, at least the SUSE Linux Enterprise Server 12 SP3 base channel with the SUSE Manager Proxy 3.1 child channel for your architecture is required.

Check the System Status on the system’s details when the migration is done.

Note: Checking refresh_pattern in /etc/squid/squid.conf

If you migrate from an early SUSE Manager Proxy  3.0 add the following refresh_pattern to /etc/squid/squid.conf :

# salt minions get the repodata via a different URL
refresh_pattern /rhn/manager/download/.*/repodata/.*$ 0 1% 1440 ignore-no-cache reload-into-ims refresh-ims

Finally consider to schedule a reboot.

A SUSE Manager Proxy is dumb in the sense that it does not contain any information about the clients which are connected to it. A SUSE Manager Proxy can therefore be replaced by a new one. The replacement proxy must have the same name and IP address as its predecessor.

In order to replace a SUSE Manager Proxy and keeping the clients registered to the proxy leave the old proxy in SUSE Manager . Create a reactivation key for this system and then register the new proxy using the reactivation key. If you do not use the reactivation key, you will need to re-registered all the clients against the new proxy.

In other situations upgrading the proxy will be the preferred solution as it retains all cached packages. This route saves time especially regarding proxies connected to a SUSE Manager server via low-bandwith links. This upgrade can be automated by using the YaST auto-installation feature.

In the following example you will see an auto-install profile. The label Proxy31 is used both for the auto-installable distribution as well as for the auto-install profile. Use the following auto-installation as template and create the auto-installation 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-sp3-updates-x86_64/Proxy31</media_url>
        <name>SLES12 SP3 Updates</name>
        <product>SLES12-SP3</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-sp3/Proxy31</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-sp3/Proxy31</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.1-pool-x86_64/Proxy31</media_url>
        <name>SLE12 Proxy 3.1 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.1-updates-x86_64/Proxy31</media_url>
        <name>SLE12 Proxy 3.1 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>

        mount /dev/sda1 /mnt
        rm -f /mnt/initrd_koan
        umount /mnt

        </source>
      </script>
    </pre-scripts>
    <chroot-scripts config:type="list">
      <script>
        <filename>migration_fix_script.sh</filename>
        <chrooted config:type="boolean">true</chrooted>
        <source><![CDATA[ ln -sf /usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT /etc/pki/trust/anchors/
/usr/sbin/update-ca-certificates ]]>
</source>
      </script>
    </chroot-scripts>
    <init-scripts config:type="list">
      <script>
        <filename>sles_register.sh</filename>
        <source>

         $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>

Ensure all channels referenced in this file are available and fully synced. Replace the label Proxy31 with the correct reference chosen for your auto-installation profile. It is recommended to create a new activation key, for example: 1-sles12sp3 which has the relevant channels assigned; later this key will be used to subscribe the upgraded proxy with the correct channels. The following base channel should be assigned:

SLES12-SP3-Pool

Also include the following child channels:

SLE-Manager-Tools12-Pool
SLE-Manager-Tools12-Updates
SLES12-SP3-Updates
SUSE-Manager-Proxy-3.1-Pool
SUSE-Manager-Proxy-3.1-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 is vital! Do not remove it.

Save your changes then click on "Variables" and enter the following value:

registration_key=1-sles12sp3

Specify the name of the key which has all respective channels assigned to it. The auto-install file contains a script named remove_initrd_koan.sh. In this script you should specify the device name of your /boot partition.

Note: remove_initrd_koan.sh

The purpose of this script is to act as a workaround for the following problem: During installation the initrd of the installation media (SLES12SP3) is in use. This initrd is rather large (around 50 MB), so there is not enough space left when the new kernel is being installed. Therefore this script deletes the initial ramdisk file once it has been booted. The partition of your boot partition might differ, so it should be explicitly specified in the autoinstall file.

During auto-installation this script attempts to delete the initial ramdisk file once it has booted. Your boot partition may differ, so ensure it is explicitly specified within the auto-install file.

If this step is bypassed or mixed up (for example: specifying a wrong value) it’s fine. During installation of the new kernel, YaST will detect that there is not enough space available and will stop. You may switch to another console (there is a shell running on virtual console 2) and reclaim some disk space by issuing the command:

rm /mnt/boot/initrd_koan

When you have completed this step, switch back to the console where YaST is running (console 7) and click Retry . Installation of the kernel will continue and succeed. The system will reboot, a few automated init scripts will run and the proxy will be upgraded to the SUSE Manager  3.1 based on SLES12SP3 and will be fully functional.