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