Red Hat Technical Series Deploying RHN Proxy Server in the Enterprise

Copyright 2001, 2002 by Red Hat, Inc.

Tammy Fox, Mihai Ibanescu, and Todd Warner

RHN Proxy Server is a service deployed at a customers site that caches packages for distribution across the local Intranet while maintaining a single, secure connection to Red Hat Network. Additionally, RHN Proxy Server enables a customer to develop custom channels containing locally built packages.

Table of Contents
1. Introduction..................................................................................................................................... 5 2. Hardware Requirements ................................................................................................................ 8 3. Additional Requirements ............................................................................................................... 8 4. Example Topologies ........................................................................................................................ 9 5. Conclusion ..................................................................................................................................... 11

1. Introduction
1.1. Red Hat Network
Red Hat Network (RHN) is the environment for system-level support and management of Red Hat Linux systems and networks of systems. Red Hat Network brings together the tools, services, and information administrators need to maximize the reliability, security, and performance of their systems. To use RHN, system administrators register the software and hardware proles, known as System Proles, of their client systems with Red Hat Network. When the client systems request package updates, only the applicable packages for the client are returned (based on the software prole stored on the RHN Servers). Advantages of using Red Hat Network include:

Scalability set up and manage a network of dozens of Red Hat Linux systems with equal ease. With Red Hat Network and Red Hat Linux, a single system administrator can set up and maintain hundreds or thousands of Red Hat Linux 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 les. Security all communication between registered systems and Red Hat Network are over secure Internet connections. View Errata Alerts easily view Errata Alerts for all your client systems through one Web interface. Scheduled Actions use the Web interface to schedule actions including Errata Updates, package installation, and software prole updates. Simplication maintaining Red Hat Linux systems becomes a simple automated process.

1.2. RHN Proxy Server

A 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 custom package deployment via customizable channels. 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 Servers 1 over the Internet. The clients System Proles and user information are stored on the secure RHN servers. Only the RPM les 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 ofcial Red Hat packages, the RHN Proxy Server can be congured to deliver an organizations 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 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.
Throughout this document, replace RHN Servers with RHN Satellite Server if the RHN Proxy Server con-

1.

nects to a RHN Satellite Server instead.

Red Hat Technical Series

Security an end-to-end secure connection is maintained: from the client systems, to the local RHN Proxy Server, to Red Hats server. Saves time packages are delivered signicantly faster over a local area network instead of over the Internet. Saves bandwidth packages are only downloaded from the RHN File Servers once (per local proxy servers 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 ofcial Red Hat packages as well as any custom software packages required for the client systems. Custom private RHN channels allow an organization to automate delivery of in-house packages. Customized conguration restrict or grant updates to specic architectures and OS versions. Only one Internet connection required the client systems connect through the HTTP Proxy server and do not need an Internet connection. Only the RHN Proxy Servers need 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 Red Hat Linux packages. There are two types of channels: base channels and child channels. A base channel consists of a list of packages based on a specic architecture and Red Hat Linux release. For example, all the packages in Red Hat Linux 7.2 for the x86 architecture compose a base channel. The list of packages in Red Hat Linux 7.2 for the Itanium architecture compose a different base channel. A child channel is a channel associated with a base channel but contains extra packages. For example, an organization can create a child channel that is associated with the Red Hat Linux 7.2 for the x86 architecture and that contains extra packages needed only for the organization, such as a custom engineering application. Organization Administrator Organization Administrator is a user role with the highest level of control over an organizations 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. 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 troubleshooting 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 Servers conguration le.

For more detailed explanations of these terms and others, refer to the Red Hat Network Enterprise User Reference Guide available at http://www.redhat.com/docs/.

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) connect to a RHN Proxy Server that connects to the Red Hat Network Servers. Thus, the client systems do not need direct access to the Internet. They only need access to the RHN Proxy Server.

Red Hat Technical Series

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 specic action for the client. The RHN Proxy Server downloads all 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 authenticated on the server side, but delivering packages is much faster since the packages are cached in the HTTP proxy caching server or the RHN Proxy Server (for local packages); and the RHN Proxy Server and client system are connected via the LAN with 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, then it passes back, via the chain of RHN Proxy Servers, a session token. This token, which has a signature and expiration, contains user information, includes subscribe-to channels, username, etc. 3. Each RHN Proxy Server caches this token on its local le system. 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 clients point of view, there is no difference between an RHN Proxy Server and a Red Hat Network server. From the servers 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. The entire RHN Proxy Server solution actually consists of a several components (refer to Section 4 for details):

The RHN Proxy Broker Server The core component that performs the RHN logic for the Red Hat Network Proxy solution. The RHN Proxy SSL Redirect Server The RHN Proxy Servers requests are sent through the RHN Proxy SSL Redirect Server on their way to the Red Hat Network servers, allowing an SSL connection between the RHN Proxy Server and the Red Hat Network servers. This is necessary due to the requirement of the non-SSL caching services. The RHN Proxy SSL Redirect Server sends any request to the Red Hat Network servers as an SSL request. This server can reside on the same machine as the RHN Proxy Server or on a separate machine. If you have multiple RHN Proxy Servers, it is recommend that all requests be sent through one RHN Proxy SSL Redirect Server. The RHN Authentication Daemon A small server daemon that acts as a caching and token verication mechanism. Like the RHN Proxy SSL Redirect Server, it can reside on the same physical server as the RHN Proxy Server. Again, if you have more than one RHN Proxy Server, it is recommended that a single RHN Authentication Daemon serve all RHN Proxy Servers.

Optionally the RHN Package Manager can be installed and congured to serve custom packages specically written for the organization. These packages are not ofcial Red Hat Linux 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 RPM package les. The headers are required because they contain crucial RPM information, including software dependencies, that allows RHN to automate package installation. The actual custom RPM packages are stored on the RHN Proxy Server server and sent to the client systems from inside the organizations private area network.

Red Hat Technical Series

In summary, a clients Red Hat Update Agent connects to the RHN Proxy Broker Server which connects to the RHN Proxy SSL Redirect Server which connects to Red Hat Network. Between the RHN Proxy Broker Server and the RHN Proxy SSL Redirect Server is a Squid HTTP proxy caching server and RHN Authentication Daemon. Between the RHN Proxy SSL Redirect Server and Red Hat Network, a corporate HTTP proxy caching server gateway may exist. Finally, a custom channel can be maintained with two tools: the RHN Web interface and the RHN Package Manager.

2. Hardware Requirements
To use the RHN Proxy Server, the following hardware is required:

The RHN Proxy Server and its components are only supported on the x86 architecture with a minimum requirement of a Pentium processors -- the faster, the better. For a single RHN Proxy Server, the minimum requirement is one server that acts as the RHN Proxy Broker Server, RHN Authentication Daemon, and RHN Proxy SSL Redirect Server. Alternately, the RHN Authentication Daemon and RHN Proxy SSL Redirect Server may reside on separate machines. The amount of memory is very dependent on other services that run on the same machine. 64MB of RAM memory should sufce.

2.1. Disk space Requirements

The HTTP proxy caching server used to save bandwidth for the clients should have a fairly reasonable amount of space available. If you are using Squid as the HTTP proxy caching server, the cached packages are stored in /var/cache/squid. The recommended free space allotment should be approximately 120% of the total space taken by the RPMs for all distributions intended to be served. You can compute the space requirements depending on how many different distributions the proxy will have to serve. Congure approximately 1.3G of space per distribution (including updates and source packages) as a maximum; the actual amount can be much lower if you only download package updates. If the RHN Proxy Server is congured to distribute local packages, make sure that the /var mount point on the system storing local packages has sufcient disk space to hold all of the custom packages, which are stored in /var/up2date/packages. The required disk space for local packages depend on the number of custom packages deployed. The RHN Authentication Daemon requires approximately 5 KB of disk space for each client server the RHN Proxy Server will service. The RHN Proxy SSL Redirect Server requires approximately 130 KB for the server itself plus disk space for Apache and Python, which approximately require 2 MB combined. For the RHN Proxy Broker Server (two scenarios): 1. If you are not planning to provide local channels (for example, have your own distribution stored locally on the proxy), the space requirements for the proxy itself are minimal: approximately 2M. 2. Running local channels will add some disk space requirements for the packages you will have: whatever is needed for the packages you plan to serve, plus the space required for step 1.

Red Hat Technical Series

3. Additional Requirements
In addition to the hardware and disk space requirements, the RHN Proxy Server must have the following conguration:

Internal computers need full network access to the RHN Proxy Server Solutions services and ports. The RHN Proxy Server Solution connects to itself for some services. Thus, localhost connections must always be allowed between the RHN Proxy Server components. The RHN Proxy Server Solution can be rewalled from the Internet, but it must be able to issue outbound connections to the Internet on ports 80 and 443.

The following are recommended requirements:

The system running the code should not be publicly available. No user 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. The HTTP proxy caching server should be secured.

4. Example Topologies
The RHN Proxy Server can be congured in multiple ways. Select one method depending on the following factors: 1. The number of available physical servers for the RHN Proxy Broker Server, RHN Authentication Daemon, and RHN Proxy SSL Redirect Server. 2. The number of RHN Proxy Servers being used. 3. The maximum number of clients expected to connect concurrently to the RHN Proxy Server. Most organizations can deploy multiple RHN Proxy Broker Servers and have them connect to the same RHN Authentication Daemon. The number of RHN Proxy SSL Redirect Servers servicing the RHN Proxy Broker Servers is dependent upon the SSL connection requirements of the organization since the connection between the RHN Proxy Broker Server and the RHN Proxy SSL Redirect Server is a non-SSL connection. In the simplest case, the RHN Proxy SSL Redirect Server should reside on the same physical server. With multiple RHN Proxy Broker Servers, the recommended conguration is to use one physical server for the RHN Proxy SSL Redirect Server and the RHN Authentication Daemon, funneling requests via SSL through the HTTP Proxy and rewall (or any server(s) that the organization uses between the client systems and the Internet).

Note The RHN Proxy SSL Redirect Server is completely optional, but if you intend to have a secure connection between the RHN Proxy Server (specically the RHN Proxy Broker Server) and Red Hat Network, it must be installed.

4.1. Simple Topology Example

The simplest conguration is to have the RHN Proxy Broker Server, RHN Authentication Daemon, and RHN Proxy SSL Redirect Server on the same server as shown in Figure 1. This conguration is

10

Red Hat Technical Series

adequate to service a small group of clients and a network that would benet from caching Red Hat RPM packages and storing custom RPM packages on a local server. The disadvantage of using one physical server for the RHN Proxy Broker Server and the RHN Proxy SSL Redirect Server is that performance will be slightly compromised because the server receives two simultaneous HTTP requests for each client request.

Figure 1. Simple Topology

4.2. Two Server Topology Example

An alternative method is to use two servers. Use one server as the RHN Proxy Broker Server and RHN Authentication Daemon, and use the other server as the RHN Proxy SSL Redirect Server as shown in Figure 2. Because the RHN Authentication Daemon and the RHN Proxy SSL Redirect Server are on different servers, the network load of HTTP requests are better balanced. This conguration also allows for easier future expansion. The biggest disadvantage is the cost of an additional machine and its maintenance. However, this should not be considered a major disadvantage because the hardware requirements for the server are nominal.

Red Hat Technical Series

11

Figure 2. Two Server Topology Example

4.3. Multiple Server Topology Example

A different method is to have multiple RHN Proxy Broker Servers and an additional server for the RHN Authentication Daemon and RHN Proxy SSL Redirect Server as shown in Figure 3.

Figure 3. Multiple Server Topology Example

5. Conclusion
RHN Proxy Server is a exible solution for an organization that requires RPM software updates but also requires network security. Clients are not required to have access to the Internet to safely

12

Red Hat Technical Series

maintain their software, including custom software only available to the organization. Clients only need a connection to the organizations local area network.