Red Hat NETWORK PROXY SERVER 3.6 -, Installation Manual

Page: 7 / 38

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 chan-
nels, 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 writ-
ten 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