SUSE Manager 4.0 Proxy

This chapter explains how to install and set up SUSE Manager 4.0 Proxy. It also provides notes about migrating a previous proxy to version 3.2.

Overview

SUSE Manager 4.0 Proxy is a SUSE Manager add-on that caches software packages on an internal, central server. The proxy caches patch updates from SUSE or custom RPMs generated by third-party organizations. A proxy allows you to use bandwidth more effectively because client systems connect to the proxy for updates, and the SUSE Manager server is no longer required to handle all client requests. A SUSE Manager Proxy can serve both Traditional and Salt clients. The proxy also supports transparent custom package deployment.

SUSE Manager Proxy is an open source (GPLv2) solution that provides the following features:

Cache software packages within a Squid proxy.
Client systems see the SUSE Manager Proxy as a SUSE Manager server instance.
The SUSE Manager Proxy is registered as a client system with the SUSE Manager server.

The primary goal of a SUSE Manager Proxy is to improve SUSE Manager performance by reducing bandwidth requirements and accelerating response time.

Proxy Installation and Connecting Clients

Requirements

The following section provides SUSE Manager Proxy requirements.

Supported Client Systems

For supported clients and their requirements, see xref:FILENAME.adoc#quickstart.sect.prereq.clientos[].

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.

Hardware	Required
CPU	Multi-core 64-bit CPU (x86_64).
RAM	Minimum 4 GB for a non-production server
	Minimum 16 GB for a production server
Free Disk Space	Minimum 100 GB for base installation and at least 50 GB for caching per SUSE product and +100 GB per Red Hat product; a resizeable partition strongly recommended.

Hardware

Required

CPU

Multi-core 64-bit CPU (x86_64).

RAM

Minimum 4 GB for a non-production server

Minimum 16 GB for a production server

Free Disk Space

Minimum 100 GB for base installation and at least 50 GB for caching per SUSE product and +100 GB per Red Hat product; a resizeable partition strongly recommended.

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 xref:FILENAME.adoc#quickstart.sect.prereq.network[].

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:

One or more subscriptions for SUSE Manager Proxy.
One or more subscriptions for SUSE Manager.
Subscriptions for the products on the client systems you want to register with SUSE Manager via SUSE Manager Proxy .
Subscriptions to client entitlements for the client system you want to register with SUSE Manager via SUSE Manager Proxy .

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):

At least 1 GB of RAM
Bridged network

Installation and Setup

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

SUSE Manager Proxy systems are registered as traditional clients or as Salt clients using a bootstrap script. Migrating a traditionally registered Proxy system to a Salt Proxy system is not possible. Re-install the Proxy if you want to switch to Salt.

Downloading Channels

Before you can select the correct child channels while creating the activation key, ensure you have completely downloaded the channels for SUSE Linux Enterprise 12 SP4.

Procedure: Registering the Proxy

Create an activation key based on the SUSE Linux Enterprise 12 SP4 base channel. For more information about activation keys, see xref:FILENAME.adoc#create.act.keys[].

Figure 1. Proxy Activation Key
From the Child Channels listing select the SUSE Manager 4.0 Proxy child channel with the matching update channel (SUSE Manager Proxy-3.2-Pool and SUSE-Manager-Proxy-3.2-Updates). These child channels are required for providing the proxy packages and updates. For normal SLES clients, SLES12-SP4-Updates plus SLE-Manager-Tools12-Pool and SLE-Manager-Tools12-Updates are mandatory.

Figure 2. Base and Child Proxy Channel
Modify a bootstrap script for the proxy if needed. If you want to run the proxy on a traditional client (system type Management) uncheck Bootstrap using Salt. Using Salt is supported since version 3.2. For more information about bootstrap scripts, see xref:FILENAME.adoc#modify.bootstrap.script[].

Figure 3. Modifying Bootstrap Script
Create the SUSE Manager Tools Repository for bootstrapping, see xref:FILENAME.adoc#create.tools.repository[].
Bootstrap the client with the bootstrap script. For more information, see xref:FILENAME.adoc#connect.first.client[].
In case of a Salt client, accept the key on the Main Menu Salt Keys page by clicking the check mark and it will appear in the Main Menu Systems Overview.
Check via System Details Software Software Channels that the two proxy channels SUSE Manager Proxy-3.2-Pool and SUSE-Manager-Proxy-3.2-Updates are selected.

Figure 4. Proxy Channels

A few more steps are still needed:

Install the patterns-suma_proxy pattern (see xref:FILENAME.adoc#at.manager.proxy.run.pattern[])
Copy the SSL certificate and key from the server (see xref:FILENAME.adoc#at.manager.proxy.run.copycert[])
Run configure-proxy.sh (see pass:c[xref:FILENAME.adoc#at.manager.proxy.run.confproxy)

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 xref:FILENAME.adoc#at.manager.proxy.register.saltclients[].

Install the `suma_proxy` pattern

On the server select the pattern_suma_proxy package for installation, or make sure the suma_proxy pattern is installed using the following command on the proxy as 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.

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.

Copy Server Certificate and Key

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 PARENT:

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

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.

Running `configure-proxy.sh`

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:

SUSE Manager Parent

A SUSE Manager parent can be either another proxy server or a SUSE Manager server.

HTTP Proxy

A HTTP proxy enables your SUSE Manager proxy to access the Web. This is needed if direct access to the Web is prohibited by a firewall.

Proxy Version to Activate

Normally, the correct value (3.0, 3.1, or 3.2) should be offered as a default.

Traceback Email

An email address where to report problems.

Use SSL

For safety reasons, press Y.

Do You Want to Import Existing Certificates?

Answer N. This ensures using the new certificates that were copied previously from the SUSE Manager server.

Organization

The next questions are about the characteristics to use for the SSL certificate of the proxy. The organization might be the same organization that was used on the server, unless of course your proxy is not in the same organization as your main server.

Organization Unit

The default value here is the proxy’s hostname.

City

Further information attached to the proxy’s certificate. Beware the country code must be made of two upper case letters. For further information on country codes, refer to the online list of alpha-2 codes.

Country Code

As the country code enter the country code set during the SUSE Manager installation. For example, if your proxy is in US and your SUSE Manager in DE, you must enter DE for the proxy.

Cname Aliases (Separated by Space)

Use this if your proxy server can be accessed through various DNS CNAME aliases. Otherwise it can be left empty.

CA Password

Enter the password that was used for the certificate of your SUSE Manager server.

Do You Want to Use an Existing SSH Key for Proxying SSH-Push Salt Minions?

Use this option if you want to reuse a SSH key that was used for SSH-Push Salt minions on the server.

Create and Populate Configuration Channel rhn_proxy_config_1000010001?

Accept default Y.

SUSE Manager Username

Use same user name and password as on the SUSE Manager server.

Activate advertising proxy via SLP?

SLP stands for Service Location Protocol.

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 (Main Menu Systems Proxy, then the system name). Connection and Proxy subtabs display the respective status information.

Registering Salt Clients via SUSE Manager Proxy

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 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 the Main Menu Systems Bootstrapping page.

Figure 5. Bootstrapping a Salt Client With a Proxy

Procedure: Register a Salt client through a proxy from command line

Instead of the Web UI, you may use the command line to register a minion through a proxy. To do so, add the proxy FQDN as the master in the minions configuration file located at:
```
/etc/salt/minion
```
or alternatively:
```
/etc/salt/minion.d/NAME.conf
```
Add the FQDN to the minion file:
```
master: proxy123.example.com
```
Save and restart the salt-minion service with:
```
systemctl restart salt-minion
```
On the Server, accept the new minion key with:
```
salt-key -a 'minion'
```
The minion will now connect to the proxy exclusively for Salt operations and normal HTTP package downloads.

Registering Clients via SUSE Manager Proxy with a Script

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.

Create a client activation key on the SUSE Manager server using the Web UI. See xref:FILENAME.adoc#create.act.keys[].
On the proxy, execute the mgr-bootstrap command-line tool as root. If needed, use the additional command-line switches to tune your bootstrap script. An important option is --traditional that enables to opt for a traditional client instead of a salt minion.

To view available options type mgr-bootstrap --help from the command line:
```
# mgr-bootstrap --activation-keys=key-string
```
Optionally edit the resulting bootstrap script. Execute the bootstrap script on the clients as described in xref:FILENAME.adoc#connect.first.client[].

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

Additional Information about Client Registration on Proxies

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 menu:Details[Proxy.

A list of chained proxies for a minion can be located under Systems ] <minion name menu:Details[Connection

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

Enabling PXE Boot via SUSE Manager Proxy

Synchronizing Profiles and System Information

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.

On the SUSE Manager server install susemanager-tftpsync :
```
zypper in susemanager-tftpsync
```
On the SUSE Manager Proxy server install susemanager-tftpsync-recv :
```
zypper in susemanager-tftpsync-recv
```
Run the configure-tftpsync.sh setup script and enter the requested information:
```
configure-tftpsync.sh
```
It asks for hostname and IP address of the SUSE Manager server and of the proxy itself. Additionally, it asks for the tftpboot directory on the proxy.
On the SUSE Manager server, run configure-tftpsync.sh to configure the upload to the SUSE Manager Proxy server:
```
configure-tftpsync.sh FQDN_of_Proxy_Server
```
To initiate an initial synchronization on the SUSE Manager Server run:
```
cobbler sync
```
Also can also be done after each a change within Cobbler that needs to be synchronized immediately. Otherwise Cobbler synchronization will also run automatically when needed. For more information about Cobbler, see xref:FILENAME.adoc#advanced.topics.cobbler[].

Configuring DHCP for PXE via SUSE Manager Proxy

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"

Migrating SUSE Manager 3.1 Proxy to Version 4.0 [Management]

The recommended order for migrations is to first migrate the server and then the proxies.

For the migration of traditionally managed proxies there are two possible approaches:

Existing SUSE Manager proxies may be upgraded to version 3.2 with YaST or zypper migration.
Alternatively, the proxies may be replaced by new ones.

This section documents both approaches.

Migrating SUSE Manager 3 Proxy and Earlier

For migrating SUSE Manager 3 Proxy and earlier, see https://www.suse.com/documentation/suse-manager-3/book_suma_advanced_topics_31/data/sect1_chapter_book_suma_advanced_topics_31.html, Chapter "SUSE Manager 3.1 Proxy".

Replacing a SUSE Manager Proxy

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.

Procedure: Replacing a SUSE Manager Proxy and Keeping the Clients Registered

Before starting the actual migration procedure, save the data from the old proxy, if needed. Consider copying important data to a central place that can also be accessed by the new server:
- Copy the scripts that are still needed.
- Copy the activation keys from the previous server. Of course, it is always better to re-create the keys.
Shutdown the server.
Install a new SUSE Manager 4.0 Proxy, see xref:FILENAME.adoc#at.manager.proxy.inst-and-clients[].
In the SUSE Manager Web UI select the newly installed SUSE Manager Proxy and delete it from the systems list.
In the Web UI, create a reactivation key for the old proxy system: On the System Details tab of the old proxy click Reactivation. Then click Generate New Key, and remember it (write it on a piece of paper or copy it to the clipboard). For more information about reactivation keys, see xref:FILENAME.adoc#s5-sm-system-details-react[].
After the installation of the new proxy, perform the following actions (if needed):
- Copy the centrally saved data to the new proxy system.
- Install any other needed software.
- If the proxy is also used for autoinstallation, do not forget to setup TFTP synchronization.

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.

Upgrading a SUSE Manager Proxy from 3.1 to 4.0

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.

Synchronizing Target Channels

Before successfully initializing the product migration, you first must make sure that the migration target channels are completely mirrored. To upgrade to SUSE Manager 3.2 Proxy, you will require at least the SUSE Linux Enterprise Server 12 SP4 base channel with the SUSE Manager Proxy 3.2 child channel for your architecture.

Procedure: Migrating Proxy to 4.0

Direct your browser to the SUSE Manager Web UI where your proxy is registered, and login.
On the Main Menu Systems Systems Proxy page select your proxy server from the table.
On the system’s detail page select the Software SP Migration tab.
From this page you will see installed products listed on your proxy client, and the available target products. Select the required Target Products. In this case, you will require SUSE Linux Enterprise Server 12 SP4 with SUSE Manager Proxy 3.2.
Then confirm with Select Channels.
From the Schedule Migration menu, select the time and click Confirm.

Check the System Status on the System Details Overview when the migration is done.

Finally consider scheduling a reboot.