2.2. Configuring a Red Hat Network Proxy
When you're managing patches for a group of RHEL computers, you may not want all of them downloading hundreds of megabytes of patches through the Internet simultaneously. As discussed in Chapter 1, you can configure one or more Proxy or Satellite Servers for patch management.
In this section, you'll learn to configure a Red Hat Network Proxy Server and client. You can then attach other RHEL clients on your network, download the same updates more quickly, and keep the load on your Internet connection to a minimum.
If you're connecting a Red Hat Network Proxy Server to a local Red Hat Network Satellite Server, that Satellite serves as the Red Hat Network for the purpose of this chapter. Substitute accordingly. We have chosen not to cover the Red Hat Network Satellite Server, as that would bias this book too far toward Red Hat and related distributions.
2.2.1. Configuring the Proxy Server
The installation requirements for a Red Hat Network Proxy Server described in Chapter 1 mean that you'll need a dedicated computer. Red Hat suggests that you keep what you install on the Proxy Server computer to an absolute minimum.
In other words, don't install other services on a Red Hat Network Proxy Server computer. This includes a GUI. As a competent Linux administrator, you do not need a GUI to configure or update the Proxy Server.
In this section, you'll configure a Red Hat Network Proxy Server from the command line interface and your administrative account on the Red Hat Network. In the following sections, we'll describe specific installation requirements, and we will then outline everything that you need to do to configure your Proxy Server, which includes the following:
When this process is complete, you can configure the clients on your network to pull updates from this computer (and not directly from the Red Hat Network).
At any time during the Proxy Server configuration process, you may need to refresh your server and client configuration settings on the Red Hat Network. To do so, navigate to the target computer and run the rhn_check command.
Specialized Installation Requirements
Red Hat suggests that what you install on a Proxy Server computer should be kept to a minimum. For RHEL versions 3 and 4, this corresponds to the Base and Core package groups. This does include all packages required to network and configure this computer through the Update Agent. And the network connection allows you to configure this computer remotely through your Red Hat Network account.
Red Hat and related distributions document package groups in an XML file, comps.xml. It's available on the first installation CD, in the /RedHat/base/ subdirectory.
Red Hat also suggests that you should disable the iptables and ipchains firewall commands on a Proxy Server. While you can configure a Proxy Server between your RHEL clients and the Internet, you should not configure this computer as a firewall.
The Proxy Server packages that you'll install through the Red Hat Network will allow you to configure minimal Web, Proxy, and routing services on this computer. However, it's best if you don't also configure this computer with any other functionality. For example, standard Apache or Squid services could interfere with the Red Hat Network Proxy Server.
After you've configured a minimal installation of RHEL, you'll need to complete the configuration yourself.
This book uses Red Hat Network Proxy Server 3.6 on RHEL 3. You can also use Proxy Server 3.7 or 4.0. If you want to dedicate a RHEL 4 computer for this purpose, you can use Red Hat Network Proxy Server 3.7 or 4.0. In either case, a Proxy Server on a RHEL 3 or 4 server works equally well for both RHEL 3 and RHEL 4 clients.
A minimal installation doesn't load the Red Hat Setup Agent, also known as the First Boot service. Therefore, you may not have a regular user account. You aren't even connected (yet) to the Red Hat Network.
Before you can run this computer as a Red Hat Network Proxy Server, there are a few more things that you need to do. As you configure this RHEL computer, you'll be working from the command line interface. You do remember how to do this, don't you?
First, this computer needs to recognize its own Fully Qualified Domain Name (FQDN). While this can be accomplished through a DNS (Domain Name Service) server, you'll need to update your /etc/hosts file with your FQDN. For example, I've added the following line to my version of this file:
Please note that configuration details associated with the Red Hat Network have changed from time to time, so you may need to modify the steps listed in this section for your Red Hat Network account.
To keep your system secure, it's best to disable any services which you don't need. For example, while the CUPS (Common Unix Print System) is enabled by default even on a minimal installation of RHEL, you're probably not going to use this computer as a print server. You can therefore disable this software with the following command:
chkconfig cups off
It would be even better if you could uninstall all unneeded services, but that isn't always possible. In fact, with a RHEL minimal installation, most services that are installed are due to dependencies. Some of those services you might be tempted to uninstall are necessary for a Red Hat Network Proxy Server. While some of the installed services are not required, detailing those services is beyond the scope of this book.
Because Red Hat does not support the use of a firewall on a Red Hat Network Proxy Server, you should disable any firewall tools such as iptables or ipchains on that computer. The iptables service is installed by default on RHEL 3 and 4. You can disable this service with the following commands:
service iptables stop chkconfig iptables off
Because you won't have firewall tools on this computer, it will likely sit behind a firewall. It needs to communicate with the Red Hat Network. To do so, it requires open ports for outbound connections to regular and secure Web services, on TCP/IP ports 80 and 443. It's normal to have these connections open for most computers on an Internet connected network, so your system is probably already set. However, you may need to reconfigure your firewall to open these ports.
However, if your Proxy Server connects to a Red Hat Network Satellite Server on an external network, you'll also need to configure your firewall to allow inbound connections on TCP/IP port 5222. For details on firewalls and using the iptables command, see Real World Linux Security, 2nd Edition by Bob Toxen (Upper Saddle River, N.J.: Prentice Hall, 2003).
It's important to make sure the clocks on the computers on your network are relatively synchronized. The standard method is with the NTP daemon (ntpd), which relies on the Network Time Protocol (NTP).
To configure the NTP service, add at least three active time servers to the associated /etc/ntp.conf configuration file and make sure the NTP daemon runs when you start RHEL. A list of public NTP servers is available online from ntp.isc.org/bin/view/Servers/. Many networks depend on these servers. If overloaded, their responses may be delayed, and that's not good for a time server. As described on the noted Web site, the administrators of these servers may require you to notify them, and you often need to get authorization to link to their servers.
Some servers, especially those known as "Stratum 2" servers, are two levels away from official clocks and aren't as heavily loaded. While they are less accurate, the variance is some small fraction of a second, which causes no problems for most network applications, including the Red Hat Network Proxy Server. Stratum 2 servers generally do not get as much traffic. If so noted on the Public NTP server Web site, you may connect to them without notifying their administrator.
To make sure the NTP server is running (and runs the next time you boot RHEL), run the following commands:
service ntpd start chkconfig ntpd on
Configuring the Proxy as a Router
In many scenarios, you'll want to configure your Red Hat Network Proxy Server between your LAN and a gateway to the Internet. As the associated software includes the router associated with the jabberd project (jabberd.jabberstudio.org), the process is simpler than it would be for a regular router.
Routing on a RHEL computer allows network communication between networks over that computer. All you need to do is configure forwarding of IP packets. You can do so during the current RHEL session with the following command:
echo '1' > /proc/sys/net/ipv4/ip_forward
To make sure RHEL enables routing the next time you boot, you'll need to set the following line in your Linux kernel system control configuration file, /etc/sysctl.conf:
net.ipv4.ip_forward = 1
Before you can download the Red Hat Network Proxy Server software, you need to register that computer on the Red Hat Network. The most straightforward method is with one of the following commands:
rhn_register up2date --register
Alternatively, if you have not yet registered this computer, the first time you run the up2date command, the Update Agent runs the registration process automatically.
Even if you've installed RHEL in a minimal configuration, Red Hat supports a low-intensity blue graphical screen for the Update Agent, similar to what you see if you install RHEL in text mode. Before you register, you're taken through
This is an excellent time to make sure this RHEL computer is up to date with the latest packages. You've read about using the Update Agent on RHEL in Chapter 1. Just remember, you don't have the benefit (or curse, perhaps) of the GUI for this process. Now that you've registered this computer, you may be able to complete this process with a command that completely updates the system with all relevant packages:
When complete, you can download Red Hat Network Proxy Server software. We'll illustrate the process from a Red Hat Network administrative account in the following sections.
Getting to the Right Channel
Before you can administer the Red Hat Network Proxy Server software, you'll need to subscribe to the Red Hat Network Tools software channel. In the next subsection, I'll show how you can even "push" the installation of Proxy Server software. To subscribe to the right channel, you'll need to take the following steps:
To install the packages required for a Red Hat Network Proxy Server, continue to the next section. Do not log out of your Red Hat Network account.
Installing Proxy Packages
Now you'll install the packages required for a Red Hat Network Proxy Server. It's available from the Red Hat Network Tools channel that you just configured in the previous section. If you're not already there, log into your Red Hat Network account, and click Systems. Click the name of your Proxy Server computer.
Provisioning a Proxy Subscription
To provision your system as a Proxy Server, log into the Red Hat Network. Click Systems. Select the computer that you want to use. Click Details, and then click Proxy. If you have a valid and available Proxy subscription, you should see a screen similar to Figure 2-7.
Figure 2-7. Assigning a computer as a Proxy Server
To review your Red Hat Network entitlements, click Channels and then click Channel Entitlements. You'll see a list of software channels to which you can subscribe.
Now you can provision your system as a Proxy Server.
Configuring the Proxy Server
Now that you've installed the required software packages, you can start the Proxy Server configuration process through your administrative Red Hat Network account. Log into that account, navigate to the Proxy Server computer, click Details, and then click Proxy. Click the Activate Proxy button shown in Figure 2-7. This starts the Red Hat Network Proxy Installer. Follow these steps:
Your Red Hat Network Proxy Server system is now ready for clients. If you've configured a SSL Proxy Server, you'll need to create cert keys for the Proxy Server and Web clients.
Creating the Certificate Keys
To secure your Update Agent system, create certificates for your Proxy Server and associated clients. This requires you to return to the Proxy Server and use the rhn-ssl-tool command, with several different options. Don't run any of these commands until you understand the whole process as I describe in this section.
The rhn-ssl-tool command is part of the rhns-certs-tools package that you installed earlier in this process. There are two major command options. The first allows you to create a Certificate Authority (CA) for your network:
rhn-ssl-tool --gen-ca [followed by many options]
The second option creates Web server CA key sets, which is required for your Proxy Server:
rhn-ssl-tool --gen-server [followed by many options]
Let's examine these options one at a time. To generate a proper CA for your network, you need to specify appropriate directories for the certificates, using secure passwords with certificates that reflect basic parameters for your organization. You can review some of the switches (which come after --gen-ca) in Table 2-2. You don't need to use all the switches shown; however, the more you use, the more unique the CA you create.
For a complete list of switches associated with the --gen-ca option, run the rhn-ssl-tool --gen-ca --help command. I don't include switches such as --password=PASSWORD, because there is no reason to help a "shoulder surfer" by typing your CA password in clear text. The rhn-ssl-tool command prompts you for the password if you don't use the --password switch.
On my Proxy Server, I run the following command:
rhn-ssl-tool --gen-ca --dir=" /root/ssl-build" --set-state="Somewhere Else" --set-city="Nice One" --set-org="Mommabears" --set-org- unit="home office"
This command first prompts for a password. Remember this password. You'll have to use the same password shortly. It then generates a private and public CA key in the /root/ssl-build directory, with messages related to your location and organization. My use of this command leads to the following output:
Using distinguishing variables: --set-country = "US" --set-state = "Somewhere Else" --set-city = "Nice One" --set-org = "Mommabears" --set-org-unit = "home office" --set-common-name = "" --set-email = ""
This command adds several files to the specified /root/ssl-build directory, as noted in Table 2-3.
Now, you can configure the Web server keys. Remember, to have a proxy server, you also need a Web server. The packages that you installed through your Red Hat Network account earlier install a customized version of an Apache and Squid proxy server.
To generate proper Web server keys, specify appropriate directories for the certificates, using secure passwords, with certificates that reflect basic parameters for your organization. You can review some of the switches (which come after --gen-ca) in Table 2-4. You don't need to use all the switches shown; however, the more you use, the more unique the CA you create.
For a complete list of switches associated with the --gen-server option, run the rhn-ssl-tool --gen-server --help command. I don't include switches such as --password=PASSWORD, because there is no reason to help a "shoulder surfer" by typing your CA password in clear text.
On my Proxy Server, I run the following command:
rhn-ssl-tool --gen-server --dir="/root/ssl-build" --set- state="Somewhere Else" --set-city="Nice One" --set-org="Mommabears" --set-org-unit="home office" --set-email="firstname.lastname@example.org"
This rhn-ssl-tool command proceeds to generate SSL keys and certificate files for the Web server, as well as associated RPMs that you can use to build corresponding keys on client computers. The command adds several files to the hostname (enterprise3d) subdirectory of the /root/ssl-build directory, as noted in Table 2-5.
Now that you've generated SSL keys for the Proxy Server and Web host, you'll need to install the public CA certificate on each client and the Web service RPM on the Proxy Server.
If you haven't already done so, you can use the archive of the server keys, with the .tar extension, to configure SSL on your Red Hat Network Proxy Server. When available, upload the archive, as shown in Figure 2-9. Then you can return to the Red Hat Network Proxy Server Install Progress page shown in Figure 2-10.
While you're still on the Proxy Server, install the associated Web service RPM. For the commands shown, you can install the Web service SSL certificate RPM package with the following command:
cd /root/ssl-build/enterprise3d/ rpm -i rhn-org-httpd-ssl-key-pair-enterprise3d-1.0-1.noarch.rpm
Next, make the RHN-ORG-TRUSTED-SSL-CERT file that you created earlier available for clients. Because the software that you've installed has created a Web server on the Proxy Server computer, you can copy this file to the /var/www/html/pub directory. To make sure your Proxy Server computer's Web server sees this file, you'll need to restart the Web service with a command, such as
service httpd restart
One more command; to make the files in the /var/www/html/pub directory accessible to Web clients, you'll need to change ownership of these files to the apache user. It's easy to do with the following command:
chown apache.apache /var/www/html/pub/*
In the next section, we'll install this file on a client.
Alternatively, you can copy and then install the RPM that you created earlier with the rhn-ssl-tool --gen-ca <lots of stuff> command. In this case, it's the rhn-org-trusted-ssl-cert-1.0-1.noarch.rpm package; if you install this RPM on any client, it will automatically install RHN-ORG-TRUSTED-SSL-CERT in the correct directory.
2.2.2. Configuring the Proxy Client
Now you can set up RHEL 2.1, 3, and 4 clients for your Red Hat Network Proxy Server computer. The process is straightforward. You'll need to reconfigure the update agent to take updates from the Proxy Server (instead of the Red Hat Network). Then, you'll need the cert keys created during the Proxy Server installation process.
If you have a substantial number of RHEL clients, you can automate this process with scripts. Finally, you can make sure RHEL clients are updated on a regular basis, either through the Red Hat Network or with a regular cron job.
Copying the Certificate Key
Before you start configuring the Update Agent, you'll need to copy the right client cert key. It's embedded in the RHN-ORG-TRUSTED-SSL-CERT file described earlier.
If you've followed the instructions described earlier, this file is already available through the Web server on the Proxy Server computer. You need to download the RHN-ORG-TRUSTED-SSL-CERT file. You can do so with a graphical browser. Navigate to this computer with the name or even the IP address of that computer, and you'll see a simple home page, as shown in Figure 2-11.
Figure 2-11. The Red Hat Network Proxy Server local Web site
Now the process is easy. Click the [pub] link, and you're taken to a list of files on the Proxy Server's /var/www/html/pub directory. You can now download any files that you've loaded to that directory, including RHN-ORG-TRUSTED-SSL-CERT.
Alternatively, you can use the wget command to download this file from the command line interface:
After you download the RHN-ORG-TRUSTED-SSL-CERT file, copy it to the /usr/share/rhn directory. Alternatively, if you've loaded the RPM on the Web server, you could install it directly with the following command:
rpm -i http://enterprise3d.example.com/pub/rhn-org-trusted-ssl-cert- 1.0-1.noarch.rpm
The previous command may seem too long. In many Web browsers, you can right click a link, select Copy Link from the shortcut menu, and then paste it into the command line.
Reconfiguring the Update Agent
After all this talk about the Proxy Server, there's one possible surprise: it is not a proxy server for your clients. (For details, see the note at the beginning of this chapter.) You won't configure your clients' Update Agent for a proxy server (unless you've configured one on a different computer, between your client and your Red Hat Network Proxy Server).
You could partially reconfigure the Update Agent in the GUI with the up2date-config command. The GUI interface allows you to modify only some of the settings you need. Alternatively, you could reconfigure the Update Agent from the command line interface using the up2date-nox --configure command. But as you can see for yourself, the interface is rather inconvenient.
The best way to fully reconfigure the Update Agent is to open its configuration file, /etc/sysconfig/rhn/up2date. In that file, you'll want to change three settings. The defaults are as follows, which pull updates through the Internet from Red Hat's servers:
noSSLServerURL=http://xmlrpc.rhn.redhat.com/XMLRPC serverURL=https://xmlrpc.rhn.redhat.com/XMLRPC sslCACert=/usr/share/rhn/RHNS-CA-CERT
You'll want to change these parameters. For example, my proxy server has a FQDN of enterprise3d.example.com, so I've changed the following parameters in my version of /etc/sysconfig/rhn/up2date:
noSSLServerURL=http://enterprise3d.example.com/XMLRPC serverURL=https://enterprise3d.example.com/XMLRPC sslCACert=/usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT
Automating Updates (Local and Remote)
You can configure updates remotely through the Red Hat Network. Details are beyond the scope of this book. However, the general procedure is straightforward:
If there are problems after you've followed the instructions described in this chapter, there are a number of things that you can do.
While this is far from a comprehensive list, I've personally run into a few problems during this process: