Section 1.4. Configuring Your Lan | Linux Patch Management: Keeping Linux Systems Up To Date

1.4. Configuring Your Lan

When you configure a LAN with Linux, you need to consider the demands of patch management along with any other requirements of your users. While you can certainly schedule patch management upgrades during off-hours, there are a number of other demands which are often scheduled for off-hours, including backups, CPU intensive database programs, and more. This includes scripts run in the middle of the night on Linux computers, such as those in the /etc/cron.daily directory.

As an example, there have been around 2GB in updates to Fedora Core 3 over a four-month period. Averaged over this period, that's approximately 20MB of downloads per day. That's a problem only if you connect to updates via telephone modem (nearly half of all Internet connections in the USA still use a telephone modem). Therefore, one practical requirement for Linux patch management is a high-speed connection.

An update of 20MB per day might not be a big problem if you have one or two Linux computers and a typical residential DSL (Digital Subscriber Line) or Cable Internet connection. However, if you're running a network of Linux computers, you need to think about your requirements. If you choose to consolidate patches on a local computer, you'll need a computer that can handle the patch management demands from possibly all the other computers on your network.

The hardware requirements increase depending on whether you need to download source packagesand whether you're planning Linux patch management for more than one architecture on your network.

1.4.1. Linux Patch Management in a Network

If you have a substantial number of Linux computers, it may be cost effective to buy, configure, and dedicate one or more computers to the patch management task. For example, assume that you have a network of 100 computers, and patch management requires that each of these computers downloads 20MB per day. Downloading an additional 2GB per day, every day, can be expensive on business-level Internet connections.

Some packages, such as those associated with the OpenOffice.org suite, require several hundred MB to update. If 100 computers on your network download these packages simultaneously, this can overload many business-level Internet connections. For example, it could take all night for 100 computers to download this amount of data over a "T3" connection. This type of connection can easily cost upwards of $10,000/month.

Note

Common higher-speed connections for business start with dedicated "T1" lines at 1.44 Mbps. T3 connections support 45Mbps. Multiple and fractional connections are available through 620Mbps and even higher speeds. While a certain quality of service is often guaranteed on these connections, prices often start in the hundreds of dollars (U.S.) per month.

If you can configure a proxy server, you could download Linux patch data once from the Internet, and then the 100 computers on your network could download the patches locally. You would then save the additional costs for your Internet connection.

Note

The costs associated with business-level connections to the Internet vary widely. If you're in a country that encourages the market to provide inexpensive high-speed connections, such as the Republic of Korea, you may be able to let your network grow larger before considering a proxy server. On the other hand, if you're in an area where Internet connections are more expensive or less reliable, you may want to consider patch management even if your network includes only two or three Linux computers.

Depending on the number of computers that require updates, you may want to configure more than one patch management proxy server for your network. While details are beyond the scope of this book, you should consider several factors before making this decision:

Marginal costs; what is the additional cost required if all your systems accessed a remote repository through the Internet?
Network capacity; for example, whether your network conforms to Ethernet or faster standards. The Red Hat hardware requirements for proxy servers specify computers with Gigabit Ethernet adapters.
Control; if you have subscriptions to a Linux support service, you may prefer to store those subscriptions on a local server. Some subscription services make this possible.
Frequency of updates; how often do you need to update or synchronize each of your proxy servers with each other and a central repository through the Internet.
You can examine some of these factors in the following sections.

1.4.2. Rigorous Hardware Requirements

Any computer that you configure as a local repository for Linux patch management meets the definitions of a proxy server. It caches content from the Internet for use by multiple computers on your network.

As suggested earlier in this chapter, Red Hat includes some fairly rigorous requirements for Red Hat Network Proxy Servers. It's unlikely that you'll be able to recycle an older workstation for this purpose.

Storage/CPU/Network Specifications

If you're configuring a new computer as a Linux patch management repository, you should first consider any recommendations from your distribution supplier. Among others, Red Hat and Novell/SUSE have experience with caching content from the Internet.

In general, CPU speed is less important on a proxy server. If you've dedicated a computer as a proxy server, you're not expecting it to run many independent programs. However, if your network includes a substantial number of computers which need access to your local repository, multiple CPUs can be useful. The important hardware requirements of a proxy server repository include the following:

Network connections. If you have a limited budget for network hardware, it's worth focusing the latest hardware on your repositories. In other words, make sure that computer has the fastest network cards, along with faster hubs, switches and routers nearby, when possible.
Hard drives. Naturally, Linux patch management repositories require larger hard drives for the many GB of data associated with each distribution. Access speed, controllers, and caching size are more important on a proxy server.

Hardware reliability may be less important on a Linux patch management repository. After all, this computer is essentially just a mirror of data that is already available. If that computer fails, you can reload the data through the Internet. However, if Linux patches are important and time-sensitive in your organization, your view of this may differ.

Amount of Data

Hard drives don't always have to be large. If you're only storing updates on a Linux patch management repository, all you need on a proxy server is room for the operating system and the package updates. With today's Linux distributions, that amounts to less than 10GB of data (even for SUSE Linux).

But this may grow quickly depending on your needs. As suggested earlier, if you have more than one type of system architecture, such as Intel 32-bit, 64-bit, PowerPC, and so on, data requirements can grow exponentially.

In addition, if you have more than one version of Linux that requires updates, you'll need to keep separate repositories for each. In other words, not only do you need separate repositories for any RHEL, SUSE, and Debian computers, you'll need separate repositories for RHEL 3, RHEL 4, SUSE 9.0, SUSE 9.1, SUSE 9.2, SUSE 9.3, SUSE 10.0, Fedora Core 1 through 5, and more.

1.4.3. Source Packages

The size of your repositories could easily double if your users need access to the source code.

Source code is readily available because of the requirements of the GPL. This allows any developer to take the source code and modify it for their own needs. Developers can modify and redistribute GPL source code, as long as it is still released under the GPL.

But unless you're administering a network with Linux developers, you might think that you don't have to worry about Linux source packages.

You don't have to be a developer to need Linux source code. Anyone who wants to customize the Linux kernel needs the source code. While some distributions make the source code available in a binary package, Red Hat releases its build of the kernel source code as a source RPM.

Linux drivers for many hardware components are still under development. Experimental drivers often work well. But to install many of these drivers, you need the kernel source code.

The need for source code is not limited to the kernel. Regular users can modify the source code of many GPL-licensed programs. All they need is the source code, and they can revise, compile, and rebuild the program of choice.

1.4.4. More Than One Repository

Even if all the Linux computers on your network run the same version of the same distribution using the same CPU, you may need more than one repository. As noted earlier, Fedora Core 4 includes configuration files for six different repositories. While most users don't need to access the Red Hat development, or repositories, you never know when one user might be so desperate for the latest features that he is willing to try a development version of his favorite program.

You might need separate repositories on a Linux patch management server for the following reasons:

Distribution brands; each distribution brand builds its packages differently and therefore maintains separate repositories.
Distribution versions; for example, if you have a reliable server on RHEL 2.1, you might not want to upgrade to RHEL 4, even though a subscription makes this possible. Red Hat has committed to support each of its enterprise distributions for at least five years, which means you might need to maintain local repositories for RHEL 2.1 through at least 2007.
Number of architectures; for each architecture where you have Linux installed on your network, you'll need a separate repository.
Source requirements; if some of your users are Linux developers, you might need to download source packages into a separate repository.
Development packages; if you're monitoring the progress of a program, you'll want access to the development packages so you can monitor improvements as they're made.
Testing packages; some groups make development packages available in a separate repository before declaring them stable and ready for a production environment.
Independent repositories; some developers keep independent repositories on their Web and FTP servers. Many are available for public use.

1.4.5. Keeping Your Repository Updated

There are two basic methods you might use to keep a local repository up to date. Some distributions allow you to store download packages and their headers on a local computer. You can then share the directory with those download packages and point the other computers on your network to that local repository. Red Hat and SUSE make that possible in some cases with their Subscription systems.

Alternatively, you can synchronize your repositories with those available online. This is where the rsync command can help. I detail how you can do this in later chapters, especially Chapter 3, "SUSE's Update Systems and rsync Mirrors." While that chapter is focused on SUSE Linux, the use of the rsync command described in that chapter applies to repositories for all distributions.

Some administrators prefer to wait until updates are available in a more convenient format. For example, RHEL makes quarterly updates of its distributions available, which administrators can configure into a local repository using the techniques described in the last half of this book.

After you've determined how you'll keep your repositories up to date, automate the process so that it happens during off-peak hours. Remember, you might be downloading hundreds of megabytes of packages, so make sure that the download does not interfere with other scheduled work, such as:

Computing-intensive programs. For example, intensive database programs require so much in computer and network resources that they're often run while most users are not at work.
Administrative programs. Backups, log rotations, and more in Linux are often configured in scripts in the /etc/cron.daily directory.
Other downloads. Many Linux users download other distributions. It's best if you can limit large downloads by regular users at least to specific time periods.
Power outages. Some networks may limit available power due to costs, availability, or local conditions.