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:
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.
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.
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.
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 Network Server). If the RHN Package Manager is used, the client systems must be subscribed to the private RHN channel.