Advanced Topics
- About This Guide
- 1 SUSE Manager on IBM z Systems
- 2 Uyuni 3.2 Proxy
- 3 Security
- 4 Uyuni in the Public Cloud: Uyuni Server and Uyuni Proxy in the Public Cloud
- 5 Optimization and Scalability
- 6 Salt SSH Integration
- 7 Monitoring with Icinga
- 8 Image Building and Management
- 9 Kubernetes Integration Guide
- 10 Cobbler
- 11 Virtualization
- 12 Inventorying vCenter/vSphere ESXi Hosts with Uyuni
- 13 SUSE Manager Command Line Tools
- 14 spacecmd Reference
- A Ports
- B Minimalist AutoYaST Profile for Automated Installations and Useful Enhancements
- C GNU Licenses
- 15 GNU Free Documentation License
2 Uyuni 3.2 Proxy
- 2.1 Overview
- 2.2 Proxy Installation and Connecting Clients
- 2.2.1 Requirements
- 2.2.2 Installation and Setup
- 2.2.3 Install the
suma_proxypattern - 2.2.4 Copy Server Certificate and Key
- 2.2.5 Running
configure-proxy.sh - 2.2.6 Registering Salt Clients via SUSE Manager Proxy
- 2.2.7 Registering Clients via SUSE Manager Proxy with a Script
- 2.2.8 Additional Information about Client Registration on Proxies
- 2.3 Enabling PXE Boot via SUSE Manager Proxy
- 2.4 Migrating Uyuni 3.1 Proxy to Version 3.2 [Management]
This chapter explains how to install and set up Uyuni 3.2 Proxy. It also provides notes about migrating a previous proxy to version 3.2.
2.1 Overview #
Uyuni 3.2 Proxy is a Uyuni 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 Uyuni server is no longer required to handle all client requests. The proxy also supports transparent custom package deployment.
Uyuni 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 Uyuni server instance.
The SUSE Manager Proxy is registered as a client system with the Uyuni server.
The primary goal of a SUSE Manager Proxy is to improve Uyuni performance by reducing bandwidth requirements and accelerating response time.
2.2 Proxy Installation and Connecting Clients #
2.2.1 Requirements #
The following section provides SUSE Manager Proxy requirements.
Supported Client Systems. For supported clients and their requirements, see 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 Uyuni, 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. |
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 Uyuni.
Network Requirements. For additional network requirements, see Additional 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:
One or more subscriptions for SUSE Manager Proxy .
One or more subscriptions for Uyuni .
Subscriptions for the products on the client systems you want to register with Uyuni via SUSE Manager Proxy .
Subscriptions to client entitlements for the client system you want to register with Uyuni 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
2.2.2 Installation and Setup #
The following section will guide you through the installation and setup procedure.
Important: Registering Proxies
Uyuni Proxy systems are registered as traditional clients or as Salt clients using a bootstrap script. A SUSE Manager Proxy can serve both Traditional and Salt clients.
Important: Procedure: Registering the Proxy
First completely download the channels (SUSE Linux Enterprise 12 SP3) and then create the activation key. Only then you can select the correct child channels.
+
Create an activation key based on the SUSE Linux Enterprise 12 SP3 base channel. For more information about activation keys, see Section 5.2, “Creating Activation Keys”.
Figure 2.1: Proxy Activation Key #
From the
Child Channelslisting select the Uyuni 3.2 Proxy child channel with the matching update channel (SUSE Manager Proxy-3.2-PoolandSUSE-Manager-Proxy-3.2-Updates). These child channels are required for providing the proxy packages and updates. As for normal SLES clients,SLES12-SP3-UpdatesplusSLE-Manager-Tools12-PoolandSLE-Manager-Tools12-Updatesare required.
Figure 2.2: Base and Child Proxy Channel #
Modify a bootstrap script for the proxy. Ensure unchecking , because in this case the proxy must be bootstrapped as a so-called traditional client. For more information about bootstrap scripts, see Section 5.4.2, “Editing the Bootstrap Script”.
Bootstrap the client with the bootstrap script.
You will see a list of channels to which your client is already subscribed to. Select the two unchecked proxy channels which include the
SUSE Manager Proxy-3.2-PoolandSUSE-Manager-Proxy-3.2-Updates, then select to continue. This will provide the required repositories for the proxy packages from the Uyuni server to the client.
A few more steps are still needed:
install the
suma_proxypattern (see Section 2.2.3, “Install thesuma_proxypattern”);copy the SSL certificate and key from the server (see Section 2.2.4, “Copy Server Certificate and Key”);
run
configure-proxy.sh(see Section 2.2.5, “Runningconfigure-proxy.sh”);
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 Uyuni server. For more information, see Section 2.2.6, “Registering Salt Clients via SUSE Manager Proxy”.
2.2.3 Install the suma_proxy pattern #
Make sure the suma_proxy pattern version 2.5.1.3 or later 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 Uyuni 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 Uyuni server (or another upstream proxy) on these ports.
2.2.4 Copy Server Certificate and Key #
The proxy will share some SSL information with the Uyuni server, so the next step is to copy the certificate and its key from the Uyuni server or the upstream proxy.
As root, enter the following commands on the proxy using your Uyuni server or chained proxy named as PARENT:
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 .
Note: Known Limitation
The SUSE Manager Proxy functionality is only supported if the SSL certificate was signed by the same CA as the Uyuni Server certificate. Using certificates signed by different CAs for Proxies and Server is not supported.
2.2.5 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:
- Uyuni Parent
A Uyuni parent can be either another proxy server or a Uyuni server.
- HTTP Proxy
A HTTP proxy enables your Uyuni proxy to access the Web. This is needed if where 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 Uyuni 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.
Tip: 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 Uyuni in DE, you must enter
DEfor 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 Uyuni 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 Uyuni 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 Uyuni 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 ( › , then the system name). › subtabs display the respective status information.
2.2.6 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 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 Uyuni server. The difference is that you specify the name of the proxy in the › page.
Figure 2.3: 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 proxy, 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.
2.2.7 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 Uyuni 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 Uyuni server using the Web UI. See Section 5.2, “Creating Activation Keys”.
On the proxy, execute the
mgr-bootstrapcommand-line tool as root. If needed, use the additional command-line switches to tune your bootstrap script. An important option is--traditionalthat enables to opt for a traditional client instead of a salt minion.To view available options type
mgr-bootstrap --helpfrom 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 Section 5.4.3, “Connecting Clients”.
The clients are registered with the SUSE Manager Proxy specified in the bootstrap script.
2.2.8 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 › › .
A list of chained proxies for a minion can be located under › ›
If you decide to move any of your clients between proxies or the server you will need to repeat the registration process from scratch.
2.3 Enabling PXE Boot via SUSE Manager Proxy #
2.3.1 Synchronizing Profiles and System Information #
To enable PXE boot via a proxy server, additional software must be installed and configured on both the Uyuni server and the SUSE Manager Proxy server.
On the Uyuni 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.shsetup script and enter the requested information:configure-tftpsync.sh
It asks for hostname and IP address of the Uyuni server and of the proxy itself. Additionally, it asks for the tftpboot directory on the proxy.
On the Uyuni server, run
configure-tftpsync.shto 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 Chapter 10, Cobbler.
2.3.2 Configuring DHCP for PXE via SUSE Manager Proxy #
Uyuni 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"
2.4 Migrating Uyuni 3.1 Proxy to Version 3.2 [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 Uyuni proxies may be upgraded to version 3.2 with YaST or
zyppermigration.Alternatively, the proxies may be replaced by new ones.
This section documents both approaches.
Note: Migrating Uyuni 3 Proxy and Earlier
For migrating Uyuni 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".
2.4.1 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 Uyuni. 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 Proxyand Keeping the ClientsRegistered #
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 Uyuni 3.2 Proxy, see Section 2.2, “Proxy Installation and Connecting Clients”.
In the Uyuni 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 clickGenerate 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 Section 7.3.1.4, “ › › [Management]”.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.
Important: Proxy Installation and Client Connections
During the installation of the proxy, clients will not be able to reach the Uyuni 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 Uyuni 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.
2.4.2 Upgrading a SUSE Manager Proxy from 3.1 to 3.2 #
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 Uyuni 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 Uyuni 3.2 Proxy, at least the SUSE Linux Enterprise Server 12 SP3 base channel with the SUSE Manager Proxy 3.2 child channel for your architecture is required.
Procedure: Migrating Proxy to 3.2 #
Direct your browser to the Uyuni Web UI where your proxy is registered, and login.
On the › › › page select your proxy server from the table.
On the system’s detail page select the › tab.
From this page you will see installed products listed on your proxy client, and the available target products. Select the wanted
Target Products, in this caseSUSE Linux Enterprise Server 12 SP3withSUSE Manager Proxy 3.2.Then confirm with .
From the
Schedule Migrationmenu, select the time and click .
Check the System Status on the › when the migration is done.
Finally consider scheduling a reboot.