Paranoid Penguin - Using Yum for RPM Updates

You can eliminate most known security risks by removing unused software and keeping your system up to date. Here's how to do it with the new tool chosen by three of the most popular Linux distributions.
Configuring Yum

Configuring Yum is fairly simple; all you need to do is edit one file, which is named, predictably, /etc/yum.conf. Listing 1 shows the default /etc/yum.conf file that comes with Fedora Core 1's Yum RPM.

As you can see, this file consists of a list of global variable settings, followed by one or more [server] blocks ([base] and [updates-released] in Listing 1), each of which specifies settings for a different type of RPM group. I'm not going to cover every possible global or server block setting; that's what the yum.conf(5) man page is for. But let's discuss a few key settings.

In the global section, debuglevel determines how verbose Yum's output is. This value may range from 0, for no output, to 10, for maximum debugging output. The default value of 2 is shown in Listing 1. As far as I can tell, this debuglevel affects only standard output, not Yum's log file, whose location is specified by logfile. Still, I like to change this value to 4, which I arrived at by playing with the yum command's -d value. For example, (yum -d 4 yum-commands) is equivalent to and overrides debuglevel.

Also in the global section, pkgpolicy specifies how Yum should decide which version to use if a given package turns up across multiple [server] blocks. distroverpkg specifies the name of your local release file package. Your release file, for example, /etc/fedora-release or /etc/redhat-release, contains the name and version of your Linux distribution.

Each [server] block defines a set of RPMs. Personally, I wish these were called [package-type] blocks instead, because they don't distinguish by server but rather by RPM group. A single block may contain the URLs of many servers. In Listing 1, the [base] block contains a single URL pointing to the main Fedora repository at fedora.redhat.com.

Fedora mirrors that contain the same collection of RPMs can be listed with additional baseurl lines. Any line in a [server] block may use the variables $releasever, which resolves to the version number of your Linux distribution, and $basearch, which expands to the CPU family of your system. CPU families exist here in the most generic sense; Athlons are considered part of i386 in this context.

The /etc/yum.conf file installed by your Yum RPM probably works fine, but you should augment each default URL, http://fedora.redhat.com... in Listing 1, with at least one mirror site URL. Doing so minimizes the chance that your updates fail due to one server being unavailable. Be sure to use your favorite Web browser to test-drive any URL you add to yum.conf to make sure it successfully resolves to a directory containing a directory named headers. Also, make sure your URL ends with a trailing slash.

The other thing worth noting in Listing 1 is that one important [server] option is missing: gpgcheck. Listing 2 shows a corrected [base] block that uses this option.

Setting gpgcheck=1 causes Yum to check the GnuPG signature in each RPM it downloads. For this to work, you need the appropriate GnuPG keys incorporated into your RPM database. On Fedora Core 1 systems, these keys were installed on your system as part of the fedora-release package. To copy them to your RPM database, execute this command:

rpm --import /usr/share/doc/fedora-release-1/RPM-GPG*

The rpm --import command also can use a URL as its argument, so if the GnuPG key of your Yum source is on-line, you can use the form:

rpm --import http://your.distro.homepage/GPGsignature

______________________

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

The comment "Garrick, use rea

Anonymous's picture

The comment "Garrick, use really small font in Listing 1 (or make wider than one column) to keep the lines from breaking"
Appears above the listing at the begining of the article, and there are a few times where there are font and other editing/publishing instructions for 'garrick' to follow. Thiis is an old article, but I figure I should make note of it so if anyone monitors this still they can correct it.

Re: Paranoid Penguin: Using Yum for RPM Updates

Anonymous's picture

Thanks I have just started using Yellow Dog Linux this aricle couldn't have been better timed than if you wrote it just for me.

Webinar
One Click, Universal Protection: Implementing Centralized Security Policies on Linux Systems

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Learn More

Sponsored by Bit9

Webinar
Linux Backup and Recovery Webinar

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.

Learn More

Sponsored by Storix