Red Hat NETWORK 4.0 - User manual

Red Hat Network 4.0
Client Configuration Guide

Red Hat Network 4.0: Client Configuration Guide
Copyright © 2001 - 2005 Red Hat, Inc.
Red Hat, Inc.
1801 Varsity Drive
Raleigh NC 27606-2072 USA
Phone: [phone]
Phone: [phone]
Fax: [phone]
PO Box 13588
Research Triangle Park NC 27709 USA
RHNclient-config(EN)-4.0-RHI (2005-04-20T13:40)
Copyright © 2005 by Red Hat, Inc. This material may be distributed only subject to the terms and conditions set
forth in the Open Publication License, V1.0 or later (the latest version is presently available at
http://www.opencontent.org/openpub/).
Distribution of substantively modified versions of this document is prohibited without the explicit permission of
the copyright holder.
Distribution of the work or derivative of the work in any standard (paper) book form for commercial purposes is
prohibited unless prior permission is obtained from the copyright holder.
Red Hat and the Red Hat "Shadow Man" logo are registered trademarks of Red Hat, Inc. in the United States
and other countries.
All other trademarks referenced herein are the property of their respective owners.
The GPG fingerprint of the [email protected] key is:
CA 20 86 86 2B D6 9D FC 65 F6 EC C4 21 91 80 CD DB 42 A6 0E

Table of Contents
1. Introduction....................................................................................................................1
2. Client Applications.........................................................................................................3
2.1. Deploying the Latest Red Hat Network Client RPMs ......................................3
2.2. Configuring the Client Applications .................................................................4
2.2.1. Registering with Activation Keys ......................................................5
2.2.2. Using the --configure Option .......................................................5
2.2.3. Updating the Configuration Files Manually ......................................8
2.2.4. Implementing Server Failover............................................................9
2.3. Configuring the Red Hat Network Alert Notification Tool with Satellite...10
3. SSL Infrastructure .......................................................................................................13
3.1. A Brief Introduction To SSL...........................................................................13
3.2. The RHN SSL Maintenance Tool.................................................................14
3.2.1. SSL Generation Explained...............................................................15
3.2.2. RHN SSL Maintenance Tool Options ...........................................16
3.2.3. Generating the Certificate Authority SSL Key Pair .........................21
3.2.4. Generating Web Server SSL Key Sets .............................................22
3.3. Deploying the CA SSL Public Certificate to Clients ......................................23
3.4. Configuring Client Systems ............................................................................23
4. Importing Custom GPG Keys.....................................................................................25
5. Using RHN Bootstrap ..................................................................................................27
5.1. Preparation ......................................................................................................27
5.2. Generation .......................................................................................................28
5.3. Script Use........................................................................................................29
5.4. RHN Bootstrap Options ................................................................................30
6. Manually Scripting the Configuration .......................................................................33
7. Implementing Kickstart ..............................................................................................35
A. Sample Bootstrap Script.............................................................................................37
Index.................................................................................................................................. 43

Chapter 1.
Introduction
This best practices guide is intended to help customers of RHN Satellite Server and RHN
Proxy Server configure their client systems more easily.
By default, all Red Hat Network client applications are configured to communicate with
central Red Hat Network Servers. When connecting clients to RHN Satellite Server or
RHN Proxy Server instead, many of these settings must be altered. Altering client settings
for a system or two may be relatively simple. A large enterprise environment, containing
hundreds or thousands of systems, will likely benefit from the mass reconfiguration steps
described here.
Due to the complexity of this undertaking, customers may utilize a pre-populated script
that automates many of the tasks necessary to access their Satellite or Proxy server; refer
to Chapter 5 Using RHN Bootstrap for details. Red Hat believes that understanding the
implications fo these changes is helpful and therefore describes the manual steps for re-
configuration in the opening chapters. Use your best judgement in determining the ideal
solution for your organization.
Although many of the commands provided within this guide can be applied as they ap-
pear, it is impossible to predict all potential network configurations adopted by customers.
Therefore, Red Hat encourages you to use these commands as references that must take
into account your organization’s individual settings.
Note
Unix client configuration information may be found in the RHN 4.0 Reference Guide in the
Unix Support chapter.

2 Chapter 1. Introduction

Chapter 2.
Client Applications
In order to utilize most enterprise-class features of Red Hat Network, such as registering
with a RHN Satellite, configuration of the latest client applications is required. Obtaining
these applications before the client has registered with Red Hat Network can be difficult.
This paradox is especially problematic for customers migrating large numbers of older
systems to Red Hat Network. This chapter identifies techniques to resolve this dilemma.
Important
Red Hat strongly recommends that clients connected to a RHN Proxy Server or RHN
Satellite Server be running the latest update of Red Hat Enterprise Linux to ensure proper
connectivity.
2.1. Deploying the Latest Red Hat Network Client RPMs
Red Hat Update Agent (up2date) and Red Hat Network Registration Client
(rhn_register) are prerequisites for using much of Red Hat Network’s enterprise
functionality. It is crucial to install them on client systems before attempting to use RHN
Proxy Server or RHN Satellite Server in your environment.
There are several sensible approaches to accomplish this update of the RHN client soft-
ware. One of which involves storing the RPMs in a location that is accessible by all client
systems and deploying the packages with the simplest command possible. In nearly all
cases, a manual deployment of up2date and rhn_register (if RHEL 2.1) do not need
to be performed. Those client tools should have no issues connecting to your RHN Satellite
or Proxy environment. These discussion below assumes that the "out of box" up2date and
rhn_register are not the latest and do not work for your environment.
Remember, only systems running Red Hat Enterprise Linux 2.1 must use the Red Hat
Network Registration Client to register with RHN. Systems running Red Hat Enterprise
Linux 3 and later can use the registration functionality built into the Red Hat Update
Agent.
This document presumes that the customer has installed at least one RHN Satellite Server
and/or RHN Proxy Server on their network. The example below demonstrates a simple ap-
proach of deploying up2date and rhn_register for the first time by an administrator as-
suming the machines don’t already have a working RHN. The administrator has populated
the /var/www/html/pub/ directory with a copy of the up2date and rhn_register
(for RHEL 2.1 systems) RPMs that his client systems need, and then has simply deployed

4 Chapter 2. Client Applications
those RPMs onto his client systems with a simple rpm -Uvh command. Run from a client,
this command installs the RPMs to that client, assuming the domain name, paths, and RPM
versions are correct:
rpm -Uvh \
http://your_proxy_or_sat.your_domain.com/pub/rhn_register-2.9.12-1.2.1AS.i386.rpm \
http://your_proxy_or_sat.your_domain.com/pub/rhn_register-gnome-2.9.12-1.2.1AS.i386.rpm \
http://your_proxy_or_sat.your_domain.com/pub/up2date-2.9.14-1.2.1AS.i386.rpm \
http://your_proxy_or_sat.your_domain.com/pub/up2date-gnome-2.9.14-1.2.1AS.i386.rpm
Note the inclusion of the associated gnome RPMs. Keep in mind, the architecture (in this
case, i386) may need to be altered depending on the systems to be served.
2.2. Configuring the Client Applications
Not every customer must connect securely to a RHN Satellite Server or RHN Proxy Server
within their organization. Not every customer needs to build and deploy a GPG key for cus-
tom packages. (Both of these topics are explained in detail later.) Every customer who uses
RHN Satellite Server or RHN Proxy Server must reconfigure the Red Hat Update Agent
(up2date) and possibly the Red Hat Network Registration Client (rhn_register) to
redirect it from Red Hat Network to their RHN Satellite Server or RHN Proxy Server.
Important
Although this is not configurable, note that the port used by the Red Hat Update Agent
is 443 for SSL (HTTPS) and 80 for non-SSL (HTTP). By default, up2date uses SSL
only. For this reason, users should ensure that their firewalls allow connections over
port 443. To bypass SSL, change the protocol for serverURL from https to http in
/etc/sysconfig/rhn/up2date. Similarly, to use RHN’s Monitoring feature and probes
requiring the Red Hat Network Monitoring Daemon, note that client systems must allow
connections on port 4545 (or port 22, if using sshd instead).
By default, the Red Hat Network Registration Client and the Red Hat Update Agent
refer to the main Red Hat Network Servers. Users must reconfigure client systems to refer
to their RHN Satellite Server or RHN Proxy Server.
Note that the latest versions of the Red Hat Update Agent can be configured to accommo-
date several RHN Servers, thereby providing failover protection in case the primary server
is inaccessible. Refer to Section 2.2.4 Implementing Server Failover for instructions on en-
abling this feature.
The next sections describe three methods of configuring the client systems to access
your RHN Satellite Server or RHN Proxy Server: using an Activation Key, up2date

Chapter 2. Client Applications 5
--configure, and manually updating the configuration files.( To see how virtually all
reconfiguration can be scripted, see Chapter 6 Manually Scripting the Configuration.)
2.2.1. Registering with Activation Keys
Red Hat recommends using activation keys for registering and configuring client systems
that access RHN Proxy Server or RHN Satellite Server. Activation keys can be used to
register, entitle, and subscribe systems in a batch. Refer to the Activation Keys section of
the Red Hat Update Agent chapter within the RHN Management Reference Guide for
instructions on use.
Registering with an activation key has four basic steps:
1. Generate an Activation Key as described in the Activation Keys section of the Red
Hat Update Agent chapter within the RHN Management Reference Guide
2. Import custom GPG keys.
3. Download and install the SSL Certificate RPM from the /pub/ directory of the RHN
Proxy Server or RHN Satellite Server. The command for this step could look some-
thing like this:
rpm -Uvh\
http://your-satellite.com/pub/rhn-org-trusted-ssl-cert-1.0-1.noarch.rpm
4. Register the system with your RHN Proxy Server or RHN Satellite Server. The com-
mand for this step could look something like:
rhnreg_ks --activationkey mykey --serverUrl https://your-satellite.com/XMLRPC
Alternatively, most of the above steps can be combined in a shell script that includes the
following lines:
wget -0 - http://your-satellite-DQDN/pub/bootstrap.sh | bash \
&& rhnreg_ks --activation-key my_key --serverUrl \
https://your-satellite-FQDN/XMLRPC
The bootstrap script, generated at installation and available for both RHN Satellite Server
and RHN Proxy Server, is such a script. The script and the RHN Bootstrap that generates
it are discussed in detail in Chapter 5 Using RHN Bootstrap.
Warning
Systems running Red Hat Enterprise Linux 2.1 and versions of Red Hat Linux prior to 8.0
may experience problems using Activation Keys to migrate SSL certificate settings from
rhn_register to up2date. Therefore, the SSL certificate information on those systems
must be set manually. All other settings, such as the server URL, transfer properly.

6 Chapter 2. Client Applications
2.2.2. Using the --configure Option
Both the Red Hat Network Registration Client and the Red Hat Update Agent that ship
with Red Hat Enterprise Linux provide interfaces for configuring various settings. For full
listings of these settings, refer to the chapters dedicated to the applications in the RHN
Management Reference Guide.
Each application offers a graphical user interface (GUI) for configuration that enables you
to change the settings required by RHN Proxy Server or RHN Satellite Server. The GUI
requires that the client system run the X Window System. The command to launch the GUI
configuration interface will look like:
application_filename --configure
To reconfigure the Red Hat Update Agent, issue the following command as root:
up2date --configure
You are presented with a dialog box offering various settings that may be
reconfigured. In the General tab, under Select a Red Hat Network
Server to use replace the default value with the fully qualified domain
name (FQDN) of the RHN Satellite Server or RHN Proxy Server, such as
https://your_proxy_or_sat.your_domain.com/XMLRPC. Retain the
/XMLRPC at the end. When finished, click OK.

Chapter 2. Client Applications 7
Figure 2-1. Red Hat Update Agent GUI Configuration
Make sure you enter the domain name of your RHN Satellite Server or RHN
Proxy Server correctly. Entering an incorrect domain or leaving the field blank
may prevent up2date --configure from launching. This may be resolved,
however, by editing the value in the up2date configuration file. Refer to
Section 2.2.3 Updating the Configuration Files Manually for precise instructions.
Warning
Systems running Red Hat Enterprise Linux 3 or newer have registration functionality built
into the Red Hat Update Agent and therefore do not install the Red Hat Network Regis-
tration Client. Systems running Red Hat Enterprise Linux 2.1 (and versions of Red Hat
Linux prior to 8.0) must reconfigure and use the Red Hat Network Registration Client,
as well as the Red Hat Update Agent.
To reconfigure the Red Hat Network Registration Client, perform an almost identical set
of steps. As root, run the following command:

8 Chapter 2. Client Applications
/usr/bin/rhn_register --configure
You are presented with a dialog box offering basic settings that may be reconfigured.
Under Select a Red Hat Network server to use replace the default value with
the fully qualified domain name (FQDN) of the RHN Satellite Server or RHN Proxy
Server, such as https://your_proxy_or_sat.your_domain.com/XMLRPC.
Retain the /XMLRPC at the end. Click OK when finished.
Figure 2-2. Red Hat Network Registration Client GUI Configuration
If your version of rhn_register does not display the server field, and you cannot
upgrade to a later version, you may enter the domain name of your RHN Satellite Server
or RHN Proxy Server directly into the rhn_register configuration file. Refer to
Section 2.2.3 Updating the Configuration Files Manually for precise instructions.
2.2.3. Updating the Configuration Files Manually
As an alternative to the GUI interface described in the previous section, users may also
reconfigure the Red Hat Network Registration Client and the Red Hat Update Agent
by editing the applications’ configuration files.
To configure Red Hat Update Agent on the client systems connecting to the RHN Proxy
Server or RHN Satellite Server, edit the values of the serverURL and noSSLServerURL

Chapter 2. Client Applications 9
settings in the /etc/sysconfig/rhn/up2date configuration file (as root). Replace the
default Red Hat Network URL with the fully qualified domain name (FQDN) for the RHN
Proxy Server or RHN Satellite Server. For example:
serverURL[comment]=Remote server URL
serverURL=https://your_primary.your_domain.com/XMLRPC
noSSLServerURL[comment]=Remote server URL without SSL
noSSLServerhttp://your_primary.your_domain.com/XMLRPC
Warning
The httpProxy setting in /etc/sysconfig/rhn/up2date does not refer to the RHN
Proxy Server. It is used to configure an optional HTTP proxy for the client. With an RHN
Proxy Server in place, the httpProxy setting must be blank (not set to any value).
Skip this section if you are running Red Hat Enterprise Linux 3 or later on the client system.
Note
You must use version 2.7.11 or higher of rhn_register on client systems so they can
recognize new certificates. This RPM should be available in /var/spool/up2date on
your proxy system after running up2date for the Proxy.
To configure the Red Hat Network Registration Client on the client systems connecting
to the RHN Proxy Server or RHN Satellite Server, edit the values of the serverURL and
noSSLServerURL options in the /etc/sysconfig/rhn/rhn_register configuration
file (as root). Replace the default Red Hat Network URL with the fully qualified domain
name (FQDN) for the RHN Proxy Server or RHN Satellite Server. For example:
serverURL[comment]=Remote server URL
serverURL=https://your_proxy_or_sat.your_domain.com/XMLRPC
noSSLServerURL[comment]=Remote server URL without SSL
noSSLServerURL=http://your_proxy_or_sat.your_domain.com/XMLRPC

10 Chapter 2. Client Applications
2.2.4. Implementing Server Failover
Beginning with up2date-4.2.38, the Red Hat Update Agent can be configured to seek
updates from a series of RHN Servers. This can be especially helpful in sustaining constant
updates if your primary RHN Proxy Server or RHN Satellite Server may be taken offline.
To use this feature, first ensure that you are running the required version of up2date. Then
manually add the secondary servers to the serverURL and noSSLServerURL settings in
the /etc/sysconfig/rhn/up2date configuration file (as root). Add the fully qualified
domain names (FQDN) for the Proxy or Satellite immediately after the primary server,
separated by a semicolon (;). For example:
serverURL[comment]=Remote server URL
serverURL=https://your_primary.your_domain.com/XMLRPC; \
https://your_secondary.your_domain.com/XMLRPC;
noSSLServerURL[comment]=Remote server URL without SSL
noSSLServerhttp://your_primary.your_domain.com/XMLRPC; \
https://your_secondary.your_domain.com/XMLRPC;
Connection to the servers is attempted in the order provided here. You can include as many
servers as you wish. You may list the central RHN Servers, as well. This makes sense,
however, only if the client systems can reach the Internet.
2.3. Configuring the Red Hat Network Alert Notification
Tool with Satellite
The Red Hat Network Alert Notification Tool, the round icon in the panel of your Red
Hat desktop, can be configured on systems running Red Hat Enterprise Linux 3 or later
to recognize updates available from custom channels on your RHN Satellite Server. You
must ensure the RHN Satellite Server is configured to support this feature. (RHN Proxy
Server supports the applet without modification of client or server.) The steps to configure
the Red Hat Network Alert Notification Tool are as follows:
1. Ensure that your RHN Satellite Server is version 3.4 or later and that you have the
rhns-applet package installed on the Satellite. The package can be found in the
RHN Satellite software channel for versions 3.4 and newer.
2. Retrieve the rhn-applet-actions package with up2date or through the Red Hat
Network Tools software channel. Install the package on all Red Hat Enterprise Linux
3 and newer client systems to be notified of custom updates with the Red Hat Net-
work Alert Notification Tool. The client systems must be entitled to the Manage-
ment or Provisioning service levels.

Chapter 2. Client Applications 11
3. Within the Satellite’s version of the RHN website, go to the System Details page for
each system and click the link within the RHN Applet area to redirect the Red Hat
Network Alert Notification Tool to the Satellite.
The next time the applet is started, it will apply its new configuration and connect to the
RHN Satellite Server for updates.

12 Chapter 2. Client Applications

Chapter 3.
SSL Infrastructure
For Red Hat Network customers, security concerns are of the utmost importance. One of
the strengths of Red Hat Network is its ability to process every single request over Secure
Sockets Layer, or SSL. To maintain this level of security, customers installing Red Hat
Network within their infrastructures must generate custom SSL keys and certificates.
Manual creation and deployment of SSL keys and certificates can be quite involved. Both
the RHN Proxy Server and the RHN Satellite Server allow you to build your own SSL keys
and certificates based on your own private Certificate Authority (CA) during installation.
In addition, a separate command line utility, the RHN SSL Maintenance Tool, exists for
this purpose. Regardless, these keys and certificates must then be deployed to all systems
within your managed infrastructure. In many cases, deployment of these SSL keys and
certificates is automated for you. This chapter describes efficient methods for conducting
all of these tasks.
Please note that this chapter does not explain SSL in depth. The RHN SSL Maintenance
Tool was designed to hide much of the complexity involved in setting up and maintain-
ing this public-key infrastructure (PKI). For more information, please consult some of the
many good references available at your nearest bookstore.
3.1. A Brief Introduction To SSL
SSL, or Secure Sockets Layer, is a protocol that enables client-server applications to pass
information securely. SSL uses a system of public and private key pairs to encrypt com-
munication passed between clients and servers. Public certificates can be left accessible,
while private keys must be secured. It’s the mathematical relationship (a digital signature)
between a private key and its paired public certificate that makes this system work. Through
this relationship, a connection of trust is established.
Note
Throughout this document we discuss SSL private keys and public certificates. Techni-
cally both can be referred to as keys (public and private keys). But it is convention, when
discussing SSL, to refer to the public half of an SSL key pair (or key set) as the SSL public
certificate.
An organization’s SSL infrastructure is generally made up of these SSL keys and certifi-
cates:

14 Chapter 3. SSL Infrastructure
•Certificate Authority (CA) SSL private key and public certificate — only one set per
organization generally generated. The public certificate is digitally signed by its private
key. The public certificate is distributed to every system.
•Web server SSL private key and public certificate — one set per application server. The
public certificate is digitally signed by both its private key and the CA SSL private key.
We often refer to a Web server’s key set; this is because there is an intermediary SSL
certificate request that is generated. The details of what this is used for are not important
to this discussion. All three are deployed to an RHN Server.
Here’s a scenario: If you have one RHN Satellite Server and five RHN Proxy Servers, you
will generate one CA SSL key pair and six Web server SSL key sets. The CA SSL public
certificate is distributed to all systems and used by all clients to establish a connection to
their respective upstream servers. Each server has its own SSL key set that is specifically
tied to that server’s hostname and generated using its own SSL private key and the CA SSL
private key in combination. This establishes a digitally verifiable association between the
Web server’s SSL public certificate and the CA SSL key pair and server’s private key. The
Web server’s key set cannot be shared with other web servers.
Important
The most critical portion of this system is the CA SSL key pair. From that private key and
public certificate an administrator can regenerate any Web server’s SSL key set. This CA
SSL key pair must be secured. It is highly recommended that once the entire RHN infras-
tructure of servers is set up and running, you archive the SSL build directory generated
by this tool and/or the installers onto separate media, write down the CA password, and
secure the media and password in a safe place.
3.2. The RHN SSL Maintenance Tool
Red Hat Network provides a command line tool to ease management of your secure
infrastructure: the RHN SSL Maintenance Tool, commonly known by its command
rhn-ssl-tool. This tool is available as part of the rhns-certs-tools package.
This package can be found within the software channels for the the latest RHN Proxy
Server and RHN Satellite Server (as well as the RHN Satellite Server ISO). RHN SSL
Maintenance Tool enables you to generate your own Certificate Authority SSL key pair,
as well as Web server SSL key sets (sometimes called key pairs).
This tool is only a build tool. It generates all of the SSL keys and certificates that are
required. It also packages the files in RPM format for quick distribution and installation on
all client machines. It does not deploy them, however. That is left to the administrator, or
in many cases, automated by the RHN Satellite Server.

Chapter 3. SSL Infrastructure 15
Note
The rhns-certs-tools, which contains rhn-ssl-tool, can be installed and run on any
current Red Hat Enterprise Linux system with minimal requirements. This is offered as
a convenience for administrators who wish to manage their SSL infrastructure from their
workstation or another system other than their RHN Server(s).
Here are the cases in which the tool is required:
•When updating your CA public certificate - this is rare.
•When installing an RHN Proxy Server version 3.6 or later that connects to the central
RHN Servers as its top-level service - the hosted service, for security reasons, cannot be
a repository for your CA SSL key and certificate, which is private to your organization.
•When reconfiguring your RHN infrastructure to use SSL where it previously did not.
•When adding RHN Proxy Servers of versions prior to 3.6 into your RHN infrastructure.
•When adding multiple RHN Satellite Servers to your RHN infrastructure - consult with
a Red Hat representative for instructions regarding this.
Here are the cases in which the tool is not required:
•During installation of an RHN Satellite Server - all SSL settings are configured during
the installation process. The SSL keys and certificate are built and deployed automati-
cally.
•During installation of an RHN Proxy Server version 3.6 or later if connected to an RHN
Satellite Server version 3.6 or later as its top-level service - the RHN Satellite Server
contains all of the SSL information needed to configure, build and deploy the RHN
Proxy Server’s SSL keys and certificates.
The installation procedures of both the RHN Satellite Server and the RHN Proxy Server
ensure the CA SSL public certificate is deployed to the /pub directory of each server.
This public certificate is used by the client systems to connect to the RHN Server. Refer to
Section 3.3 Deploying the CA SSL Public Certificate to Clients for more information.
In short, if your organization’s RHN infrastructure deploys the latest version of RHN Satel-
lite Server as its top-level service, you will likely have little need to use the tool. Otherwise,
become familiar with its usage.
3.2.1. SSL Generation Explained
The primary benefits of using the RHN SSL Maintenance Tool are security, flexibility,
and portability. Security is achieved through the creation of distinct Web server SSL keys
and certificates for each RHN server, all signed by a single Certificate Authority SSL key
pair created by your organization. Flexibility is supplied by the tool’s ability to work on

16 Chapter 3. SSL Infrastructure
any machine that has the rhns-certs-tools package installed. Portability exists in a
build structure that can be stored anywhere for safe keeping and then installed wherever
the need arises.
Again, if your infrastructure’s top-level RHN Server is the most current RHN Satellite
Server, the most you may have to do is restore your ssl-build tree from an archive to
the /root directory and utilize the configuration tools provided within the RHN Satellite
Server’s website.
To make the best use of the RHN SSL Maintenance Tool, complete the following high-
level tasks in roughly this order. Refer to the remaining sections for the required details:
1. Install the rhns-certs-tools package on a system within your organization, per-
haps but not necessarily the RHN Satellite Server or RHN Proxy Server.
2. Create a single Certificate Authority SSL key pair for your organization and install
the resulting RPM or public certificate on all client systems.
3. Create a Web server SSL key set for each of the Proxies and Satellites to be deployed
and install the resulting RPMs on the RHN Servers, restarting the httpd service
afterwards:
/sbin/service httpd restart
4. Archive the SSL build tree - consisting of the primary build directory and all subdi-
rectories and files - to removable media, such as a floppy disk. (Disk space require-
ments are insignificant.)
5. Verify and then store that archive in a safe location, such as the one described for
backups in the Additional Requirements sections of either the Proxy or Satellite in-
stallation guide.
6. Record and secure the CA password for future use.
7. Delete the build tree from the build system for security purposes, but only once the
entire RHN infrastructure is in place and configured.
8. When additional Web server SSL key sets are needed, restore the build tree on a
system running the RHN SSL Maintenance Tool and repeat steps 3 through 7.
3.2.2. RHN SSL Maintenance Tool Options
The RHN SSL Maintenance Tool offers a plethora of command line options for
generating your Certificate Authority SSL key pair and managing your server SSL
certificates and keys. The tool offers essentially three command line option help listings:
rhn-ssl-tool --help (general), rhn-ssl-tool --gen-ca --help (Certificate
Authority), and rhn-ssl-tool --gen-server --help (Web server). The manual
page for rhn-ssl-tool is also quite detailed and available to assist: man rhn-ssl-tool.
The two tables below break down the options by their related task, either CA or Web server
SSL key set generation.