An ideal Fedora repository computer should meet the requirements associated with a Red Hat Network Proxy Server, as described in Chapter 1. To review, while CPU speed is less important, you should have a computer with the following:

When you configure Fedora as a patch management computer, it is best to set up a dedicated partition for the purpose. In this way, other programs that you might install and other services with ever-growing log files won’t crowd out your repositories (or vise versa).

Normally, patches are downloaded to the /var directory. Red Hat, Fedora, Debian, and SUSE all follow this convention. Red Hat and Fedora patch RPMs are normally downloaded to /var/spool/up2date and then deleted after the RPMs are used to update your system. As you learned in Chapter 1, Fedora clients are configured through files such as /etc/yum.conf or in the /etc/yum.repos.d directory to pull updates from FTP or HTTP servers.

Therefore, most administrators create Fedora repositories on a local FTP or HTTP server. The default directories for associated files are /var/ftp/pub and /var/www/html. If you want to protect the space assigned to your repositories, you’ll want to dedicate a partition for this purpose.

Compared with the space available on the latest inexpensive hard drives, the space required for a Fedora repository is not terribly significant. All you need is room for the operating system and the repository. However, if you manage multiple repositories for multiple versions of Fedora on more than one architecture, you can still run out of room quickly. It’s best if you plan ahead. If you plan to reinstall Fedora on your computers every time a new version is released, the requirements are straightforward; one possible scenario with an installation and update repository for x86 systems is shown in Table 2-1. This is just a hypothetical breakdown; I’ve tried to be generous with space requirements.

That doesn’t seem so bad. With these requirements, it seems like you can install a Fedora repository on an older computer with a 10GB hard drive. As long as you make sure that your network can handle the load, this seems to be sufficient. But you need to consider additional factors:

Personally, I enjoy installing Linux on my computers. However, preserving the configuration and personal files associated with older versions can be a tedious process. After Linux is installed, you may not want to reinstall another version until there are significant changes, such as a major new kernel. It’s normally two or three years between major kernel releases (such as between versions 2.4 and 2.6). By then, you could be maintaining client computers with multiple architectures. It’s easy to see how a repository could grow to hundreds of gigabytes.

It’s easiest to configure partitions for Fedora Core during the installation process. The Disk Druid screen shown in Figure 2-1 allows you to dedicate partitions or logical volumes to the directory of your choice.

Figure 2-1. You can configure partitions with Fedora Disk Druid

In Disk Druid, just click Add, and then you can assign a directory such as /var/ftp to a partition such as /dev/hda5. Alternatively, if there’s room on a Logical Volume Management (LVM) physical volume (PV), you can assign space from that area for your repository.

You can still configure a dedicated partition for your repository after Linux is installed. All you need is sufficient free space on an available hard drive. For example, assume that you’ve added a second hard drive on your computer and want to dedicate that space to a repository. You could then use fdisk to create a new partition on that drive. Just take the following steps:

After you’ve created a new partition, the remaining steps are straightforward. All you need to do is format the partition, mount it on a temporary directory, copy existing data, and then bring the result into your partition table. The next time you boot Linux, it’ll boot the desired directory on your new partition automatically. For details, take the following steps:

If you haven’t already done so, you should run the Update Agent on this computer. Before you use it as a repository for other computers on your network, you should make sure this computer itself is up to date!

The steps are quite similar to those you’ve seen for RHEL in Chapter 1; one major difference is that you do not have to register your Fedora Linux computer on the Red Hat Network.

As described in Chapter 1, Fedora clients pull updates from FTP and HTTP (Web) servers. You learned how to point a Fedora client to a FTP or HTTP mirror. You’ll want to create your repository on an FTP, NFS, or HTTP server, which is what Fedora users are familiar with. While I personally prefer FTP because the protocol is inherently faster, some prefer the security associated with an HTTP (or even an HTTPS) server.

After you choose a service, you should set up a dedicated partition, as described earlier in this chapter. Then you can install and configure the service of your choice. We’ll show you how to configure a yum repository on a vsFTP server in Chapter 7.

Next, you’ll need to plan the directory structure. The simplest plan is to mirror an existing repository from a server connected to the Internet. But as many repositories are configured for multiple architectures, mirroring may download much more than what you need.

There is a substantial number of directories associated with Fedora Core repositories. If you don’t need development, testing, or source packages, you do not need all the standard repository directories on your system. In fact, you may want to discourage users from downloading and installing developmental packages, because they may have unpredictable effects on your system.

For the latest releases of Fedora Core, you may need to justify your use of different repository directories. Some of the options include

Unless you’re a Fedora developer, you don’t want or need most of these directory trees in your repository.

Now that you know what you want to download, you can proceed with the process. With the right command, such as rsync or wget, you can download the repository trees of your choice. We’ll describe this process in more detail in Chapter 7. There are a number of developers who have automated this process.

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 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.

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:

192.168.1.1     enterprise3d.example.com

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, 2^nd 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

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:

up2date -u

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.

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.

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.

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

Now you can provision your system as a 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.

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="[email protected]"

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.

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.

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:

wget http://enterprise3d.example.com/pub/RHN-ORG-TRUSTED-SSL-CERT

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

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

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: