Red Hat RHN PROXY SERVER 3.6 Installation Manual
RHN Proxy Server 3.6
Installation Guide
RHN Proxy Server 3.6: Installation Guide
Copyright © 2001 - 2004 by Red Hat, Inc.
RHNproxy(EN)-3.6-RHI (2004-12-07T20:09)
Copyright © 2001 - 2004 by Red Hat, Inc.
Red Hat, Red Hat Network, the Red Hat "Shadow Man" logo, RPM, Maximum RPM, the RPM logo, Linux Library,
PowerTools, Linux Undercover, RHmember, RHmember More, Rough Cuts, Rawhide and all Red Hat-based trademarks and
logos are trademarks or registered trademarks of Red Hat, Inc. in the United States and other countries.
Linux is a registered trademark of Linus Torvalds.
All other trademarks and copyrights referred to are the property of their respectiveowners.
Table of Contents
1. Introduction..................................................................................................................................... 1
1.1. Red Hat Network ............................................................................................................... 1
1.2. RHN Proxy Server ............................................................................................................. 1
1.3. Terms to Understand .......................................................................................................... 2
1.4. How it Works ..................................................................................................................... 2
2. Requirements................................................................................................................................... 5
2.1. Software Requirements...................................................................................................... 5
2.2. Hardware Requirements..................................................................................................... 5
2.3. Disk Space Requirements .................................................................................................. 6
2.4. Additional Requirements ................................................................................................... 6
3. Example Topologies ........................................................................................................................ 9
3.1. Single Proxy Topology ...................................................................................................... 9
3.2. Multiple Proxy Horizontally Tiered Topology .................................................................. 9
3.3. Multiple Proxy Vertically Tiered Topology .....................................................................10
3.4. Proxies with RHN Satellite Server ..................................................................................11
4. Installation.....................................................................................................................................13
4.1. Base Install....................................................................................................................... 13
4.2. RHN Proxy Server Installation Process ........................................................................... 13
5. RHN Package Manager................................................................................................................21
5.1. Creating a Private Channel .............................................................................................. 21
5.2. Uploading Packages......................................................................................................... 21
5.3. Command Line Options................................................................................................... 22
6. Troubleshooting.............................................................................................................................25
6.1. Managing the Proxy Service ............................................................................................ 25
6.2. Log Files ..........................................................................................................................25
6.3. Questions and Answers.................................................................................................... 25
6.4. General Problems.............................................................................................................26
6.5. Host Not Found/Could Not Determine FQDN ................................................................ 26
6.6. Connection Errors ............................................................................................................ 27
6.7. Caching Issues .................................................................................................................27
6.8. Proxy Debugging by Red Hat ..........................................................................................28
A. Sample RHN Proxy Server Configuration File .........................................................................31
Index................................................................................................................................................... 33
Chapter 1.
Introduction
1.1. Red Hat Network
Red Hat Network (RHN) is the environment for system-level support and management of Red Hat
systems and networks of systems. Red Hat Network brings together the tools, services, and information repositories needed to maximize the reliability, security, and performance of their systems. To use
RHN, system administrators register the software and hardware profiles, known as System Profiles,
of their client systems with Red Hat Network. When a client system requests package updates, only
the applicable packages for the client are returned (based upon the software profile stored on the RHN
Servers).
Advantages of using Red Hat Network include:
• Scalability — with Red Hat Network, a single system administrator can set up and maintain hun-
dreds or thousands of Red Hat systems more easily, accurately, and quickly than that same administrator could maintain a single system without Red Hat Network.
• Standard Protocols — standard protocols are used to maintain security and increase capability. For
example, XML-RPC gives Red Hat Network the ability to do much more than merely download
files.
• Security — all communication between registered systems and Red Hat Network takes place over
secure Internet connections.
• View Errata Alerts — easily view Errata Alerts for all your client systems through one website.
• Scheduled Actions — use the website to schedule actions, including Errata Updates, package in-
stalls, and software profile updates.
• Simplification — maintaining Red Hat systems becomes a simple, automated process.
1.2. RHN Proxy Server
An RHN Proxy Server is a service deployed within a corporate network with advanced Red Hat
Network functionality, such as a package-caching mechanism for reduced bandwidth usage and customizable channels enabling custom package deployment.
This service allows a business or corporation to cache RPM Updates on an internal, centrally located
RHN Proxy Server and have the client systems download the updates from that server instead of
from one of the RHN Servers1over the Internet. The clients’ System Profiles and user information
are stored on the secure, central RHN Servers, which also serve the RHN website (rhn.redhat.com).
The Proxy does not serve the website itself; It acts as a go-between for client systems and Red Hat
Network. Only the RPM files are stored on the RHN Proxy Server. Every transaction is authenticated,
and the Red Hat Update Agent checks the GPG signature of each package retrieved from the local
RHN Proxy Server.
In addition to storing official Red Hat packages, the RHN Proxy Server can be configured to deliver
an organization’s own custom RPM packages from private RHN channels, using the RHN Package
Manager. For instance, an organization could develop its own software, package it in an RPM, sign it
1. Throughout this document, replace RHN Server with RHN Satellite Server if the RHN Proxy Server connects
to a RHN Satellite Server instead.
2 Chapter 1. Introduction
with its own GPG signature, and have the local RHN Proxy Server update all the individual systems
in the network with the latest versions of the custom software.
Advantages of using RHN Proxy Server include:
• Scalability — there can be multiple local RHN Proxy Servers within one organization.
• Security — an end-to-end secure connection is maintained: from the client systems, to the local
RHN Proxy Server, to the Red Hat Network Servers.
• Saves time — packages are delivered significantly faster over a local area network than the Internet.
• Saves bandwidth — packages are downloaded from the RHN File Servers only once (per local
Proxy Server’s caching mechanism) instead of downloading each package to each client system.
• Saves disk space on individual systems — one large disk array is required instead of extra disk
space on all the client systems.
• Customized updates — create a truly automated package delivery system for custom software pack-
ages, as well as official Red Hat packages required for the client systems. Custom private RHN
channels allow an organization to automate delivery of in-house packages.
• Customized configuration — restrict or grant updates to specific architectures and OS versions.
• Only one Internet connection required — the client systems connect through the HTTP-enabled
Proxy Server and do not need an Internet connection. Only the RHN Proxy Server needs an Internet
connection to contact the RHN Servers.
1.3. Terms to Understand
Before understanding RHN Proxy Server, it is important to become familiar with the following Red
Hat Network terms:
• Channel — A channel is a list of software packages. There are two types of channels: base channels
and child channels. A base channel consists of a list of packages based on a specific architecture
and Red Hat release. A child channel is a channel associated with a base channel but contains extra
packages.
• Organization Administrator — Organization Administrator is a user role with the highest level
of control over an organization’s Red Hat Network account. Members of this role can add other
users, systems, and system groups to the organization as well as remove them. A Red Hat Network
organization must have at least one Organization Administrator.
• Channel Administrator — A Channel Administrator is a user role with full access to channel man-
agement capabilities. Users with this role are capable of creating channels and assigning packages
to channels. This role can be assigned by an Organization Administrator through the Users tab of
the RHN website.
• Red Hat Update Agent — The Red Hat Update Agent is the Red Hat Network client application
(up2date) that allows users to retrieve and install new or updated packages for the client system
on which the application is run.
• Traceback — A traceback is a detailed description of "what went wrong" that is useful for trou-
bleshooting the RHN Proxy Server. Tracebacks are automatically generated when a critical error
occurs and are mailed to the individual(s) designated in the RHN Proxy Server’s configuration file.
For more detailed explanations of these terms and others, refer to the Red Hat Network Reference
Guide available at http://www.redhat.com/docs/.
Chapter 1. Introduction 3
1.4. How it Works
The Red Hat Update Agent on the client systems does not directly contact a Red Hat Network Server.
Instead, the client (or clients) connects to an RHN Proxy Server that connects to the Red Hat Network
Servers. Thus, the client systems do not need direct access to the Internet. They need access only to
the RHN Proxy Server.
Important
Red Hat strongly recommends that clients connected to RHN Proxy Server be running the latest
update of Red Hat Enterprise Linux to ensure proper connectivity.
By default, a client is authenticated directly by Red Hat Network Servers. Using an RHN Proxy Server,
authentication works similarly except that the RHN Proxy Server provides route information as well.
After a successful authentication, the Red Hat Network Server informs the RHN Proxy Server that it
is permitted to execute a specific action for the client. The RHN Proxy Server downloads all of the
updated packages (if they are not already present in its cache) and delivers them to the client system.
Requests from the Red Hat Update Agent on the client systems are still authenticated on the server
side, but package delivery is significantly faster since the packages are cached in the HTTP proxy
caching server or the RHN Proxy Server (for local packages); the RHN Proxy Server and client system
are connected via the LAN and are limited only by the speed of the local network.
Authentication is done in the following order:
1. The client performs a login action at the beginning of a client session. This login is passed
through one or more RHN Proxy Servers until it reaches a Red Hat Network Server.
2. The Red Hat Network Server attempts to authenticate the client. If authentication is successful,
the server then passes back a session token via the chain of RHN Proxy Servers. This token,
which has a signature and expiration, contains user information, including subscribe-to channels, username, etc.
3. Each RHN Proxy Server caches this token on its local file system in /var/cache/rhn/.
Caching reduces some of the overhead of authenticating with Red Hat Network Servers and
greatly improves the performance of Red Hat Network.
4. This session token is passed back to the client machine and is used in subsequent actions on Red
Hat Network.
From the client’s point of view, there is no difference between an RHN Proxy Server and a Red Hat
Network Server. From the Red Hat Network Server’s point of view, an RHN Proxy Server is a special
kind of client. Thus, clients are not affected by the route a request takes to reach a Red Hat Network
Server. All the logic is implemented in the RHN Proxy Servers and Red Hat Network Servers.
Optionally the RHN Package Manager can be installed and configured to serve custom packages written specifically for the organization. These are not official Red Hat packages. After creating a private
RHN channel, the custom RPM packages are associated with the private channel by uploading the
package headers to the RHN Servers. Only the headers are uploaded, not the actual package files. The
headers are required because they contain crucial RPM information, such as software dependencies,
that allows RHN to automate package installation. The actual custom RPM packages are stored on the
RHN Proxy Server and sent to the client systems from inside the organization’s private area network.
Configuring a computer network to use RHN Proxy Servers is straightforward. The Red Hat Network
applications on the client systems must be configured to connect to the RHN Proxy Server instead
of the Red Hat Network Servers. Refer to the RHN Client Configuration Guide for details. On the
proxy side, one has to specify the next proxy in the chain (which will eventually end with a Red Hat
4 Chapter 1. Introduction
Network Server). If the RHN Package Manager is used, the client systems must be subscribed to the
private RHN channel.
Chapter 2.
Requirements
These requirements must be met before installation. To install RHN Proxy Server version 3.6 or later
from RHN Satellite Server, the Satellite itself must be version 3.6 or later.
2.1. Software Requirements
To perform an installation, the following software components must be available:
• Base operating system — RHN Proxy Server is supported with Red Hat Enterprise Linux AS 2.1
Update 5 or later and Red Hat Enterprise Linux AS 3 Update 3 or later only. The operating system
can be installed from disc, local ISO image, kickstart, or any of the methods supported by Red Hat.
Important
If you plan to obtain Monitoring-level service, you must install your RHN Proxy Server on Red Hat
Enterprise Linux AS 3 Update 3. This is the only supported base operating system for Proxies
serving Monitoring-entitled systems.
Each version of Red Hat Enterprise Linux AS requires a certain package set to support RHN Proxy
Server. Anything more can cause errors during installation. Therefore, Red Hat recommends obtaining the desired package set in the following ways:
For kickstarting either Red Hat Enterprise Linux AS 3 Update 3 or Red Hat Enterprise Linux AS
2.1 Update 5, specify the following package group: @ Base
For installing Red Hat Enterprise Linux AS 3 Update 3 via CD or ISO image, select the following
package group: Minimal
For installing Red Hat Enterprise Linux AS 2.1 Update 5 via CD or ISO image, select the following
package group: Advanced Server
• An available RHN Proxy Server entitlement within your Red Hat Network account.
• An available Provisioning entitlement within your Red Hat Network account (which should come
packaged with your RHN Proxy Server entitlement).
• Access to the Red Hat Network Tools channel for the installed version of Red Hat Enterprise Linux
AS.
• All rhncfg* packages installed on the Proxy (from the RHN Tools channel).
• Either the rhns-certs-tools package installed on the Proxy (from the RHN Tools channel) or
the secure sockets layer (SSL) CA certificate password used to generate the parent server certificate
(such as on an RHN Satellite Server).
• Configuration of the system to accept remote commands and configuration management through
Red Hat Network. Refer to Section 4.2 RHN Proxy Server Installation Process for instructions.
2.2. Hardware Requirements
The following hardware configuration is required for the RHN Proxy Server:
• Dell PowerEdge 1750 or equivalent
6 Chapter 2. Requirements
• Two processors
• 512 MB of memory
• 3 GB storage for base install of Red Hat Enterprise Linux AS
• 1.5 GB storage for source packages and updates
Keep in mind, the frequency in which client systems connect to the Proxy is directly related to load
on the Apache HTTP Server. If you do reduce the default interval of four hours (or 240 minutes), as
set in the /etc/sysconfig/rhn/rhnsd configuration file of the client systems, you will increase
the load on this component significantly.
2.3. Disk Space Requirements
The caching mechanism used by RHN Proxy Server is the Squid HTTP proxy, which saves significant
bandwidth for the clients. It should have a reasonable amount of space available. The cached packages
are stored in /var/spool/squid. The required free space allotment is 1.5 GB (including updates
and source packages).
If the RHN Proxy Server is configured to distribute custom, or local packages, make sure that the
/var mount point on the system storing local packages has sufficient disk space to hold all of the
custom packages, which are stored in /var/spool/rhn-proxy. The required disk space for local
packages depends on the number of custom packages deployed.
2.4. Additional Requirements
The following additional requirements must be met before the RHN Proxy Server installation can be
considered complete:
• Full Access
Client systems need full network access to the RHN Proxy Server solution’s services and ports.
• Firewall Rules
The RHN Proxy Server solution can be firewalled from the Internet, but it must be able to issue
outbound connections to the Internet on ports 80 and 443. In addition, if the Proxy will be connected
to an RHN Satellite Server that will be configured to push actions to client systems and the Proxy,
you must allow inbound connections on port 5222.
• Synchronized System Times
There is great time sensitivity when connecting to a Web server running SSL (Secure Sockets
Layer); it is imperative the time settings on the clients and server are reasonably close together so
the SSL certificate does not expire before or during use. It is recommended Network Time Protocol
(NTP) be used to synchronize the clocks.
• Fully Qualified Domain Name (FQDN)
The system upon which the RHN Proxy Server will be installed must resolve its own FQDN properly. If this is not the case, cookies will not work properly on the website.
• A Red Hat Network Account
Customers who will be connecting to the central Red Hat Network Servers to receive incremental
updates will need an account with Red Hat Network. This account should be set up at the time of
purchase with the sales representative.
• Backups of Login Information
Chapter 2. Requirements 7
It is imperative customers keep track of all primary login information. For RHN Proxy Server, this
includes usernames and passwords for the Organization Administrator account and SSL certificate
generation. Red Hat strongly recommends this information be copied onto two separate floppy
disks, printed out on paper, and stored in a fireproof safe.
• Distribution Locations
Since the Proxy forwards virtually all HTTP requests to the central RHN Servers, you must take
care to put files destined for distribution (such as in a kickstart installation tree) in one of two nonforwarding locations on the Proxy: /var/www/html/pub/ and /var/www/html/_rhn_proxy/.
Files placed in these directories can be downloaded directly from the Proxy. This can be especially
useful for distributing GPG keys or establishing installation trees for kickstarts.
In addition, Red Hat recommends the system running the code not be publicly available. No users but
the system administrators should have shell access to these machines. All unnecessary services should
be disabled. You can use ntsysv or chkconfig to disable services.
Finally, you should have the following technical documents in hand for use in roughly this order:
1. The RHN Proxy Server Installation Guide — This guide, which you are now reading, provides
the essential steps necessary to get an RHN Proxy Server up and running.
2. The RHN Client Configuration Guide — This guide explains how to configure the systems to
be served by an RHN Proxy Server or RHN Satellite Server. (This will also likely require referencing The RHN Reference Guide, which contains steps for registering and updating systems.)
3. The RHN Channel Management Guide — This guide identifies in great detail the recommended
methods for building custom packages, creating custom channels, and managing private Errata.
4. The RHN Reference Guide — This guide describes how to create RHN accounts, register and
update systems, and use the RHN website to its utmost potential. This guide will probably come
in handy throughout the installation and configuration process.
8 Chapter 2. Requirements
Loading...