RedHat Package Manager (RPM) is one of the most powerful and flexible systems available for keeping Linux systems up to date with the latest versions of applications and important patches for critical applications. However, this power and flexibility comes with a price. RPM packages often requireseveral individual packages to be downloaded and installed before a specific RPM package can be updated.
Greg's RPM Application Builder (GRAB), developed by Greg Kurtzer, simplifies this process by building lists of RPM files available on specified FTP servers. Once these lists are built, GRAB is capable of comparing the RPM packages installed on a Linux system, providing a list of available updates, and performing some basic dependency resolution.
This article covers the procedures for downloading, installing, and configuring GRAB so it will provide RPM updates for your Linux system.
Hot off the presses
The first official version, 1.0, of GRAB has just been released. Although this article covers a pre-release version, the instructions contained in this Daily Drill Down are entirely applicable to the newer version.
What you need
Here are the two packages you will need in order to install GRAB.
- The latest version of GRAB. The home page for the GRAB project is located at RunLevelZero. GRAB is available in RPM, SRPM, and source format. For this article, grab-0.2.32-1.i386.rpm was used.
- Perl-libnet is required for FTP transfers. This package may already be installed on your system. If it isn't, the perl-libnet package is available as either an RPM or source package from RunLevelZero.
Once GRAB and perl-libnet are downloaded, the first step is to install both packages. GRAB is installed with the command:
rpm -ivh grab-0.2.32-1.i386.rpm
If the perl-libnet package needs to be installed, run
rpm -ivh perl-libnet-1.0703-6.noarch.rpm
to install the RPM package.
When GRAB is run for the first time (using the command grab), the /etc/grab directory is created. This directory contains the following three files, which are used to configure GRAB:
The defaults file
The defaults file sets three default actions for GRAB:
- The default Update action
Select Yes for the Update Me option to update the defaults file whenever GRAB is updated, and the /etc/grab/defaults file is changed. Selecting Yes for this option will also mean that any system-specific options entered in the defaults file will be overwritten when GRAB is updated. The default is Yes.
- The default architecture
This specifies the architecture that GRAB searches for (i386, athlon, ppc, etc.). The default is All.
- Search method
There are three search methods available:
This is used when you want to match an exact string to a package name
This is used when you want to specify a string for searches
This allows all search methods to be used, including a search of the rpmfind database. The search will always start with servers defined in the /etc/grab/servers file. The default search method for grab is match.
The servers file
The /etc/grab/servers file specifies the location of FTP servers that may be searched to update GRAB and search for updates to RPM packages.
The first entry in the servers file is the SERVER section. This section specifies the location for the latest GRAB RPM packages. This is the server that is searched for new versions of GRAB whenever GRAB is updated. This section uses the format:
server [ftp-server] [path-to-RPM-packages] [description)
The default for this section is:
server ftp.runlevelzero.net /pub/greg/grab/RPMS GRAB@RUNLEVELZERO.NET
The LOCAL section specifies the location of each local directory that contains RPM packages. This section is useful when the administrator wants to maintain control over RPM packages that are installed on the system. Instead of searching FTP servers, GRAB can be configured to search directories on the local system for updates.
There are two default entries in the LOCAL section:
local /mnt/cdrom/RedHat/RPMS/ Redhat_CDROM
local /var/cache/grab/RPMS/ LOCAL_CACHE
Either of these entries may be changed to reflect the path to a local directory containing RPM files.
The SERVER_LIST section contains pre-defined entries that specify the location of FTP or HTTP servers. This SERVER_LIST is a default listing of servers that GRAB will use when searching for updates related to a specific distribution and/or architecture. Several GRAB contributors have provided servers for six different Linux releases. To use the server list for any distribution, remove the comment (;) from the beginning of any line beginning with the entry server_list, and that server list will then be used for searches.
The server lists used by GRAB are actually text files on the FTP server located at ftp://ftp.runlevelzero.net/pub/. The server list for RedHat 7.2 is shown in Example 1.
Example 1: Default server list for RedHat 7.2
#server altruistic.lbl.gov /pub/repositories/lbnl-extras-RH72/RPMS/ EXTRAS@LBL.GOV
#server altruistic.lbl.gov /pub/repositories/redhat-updates-7.2/RPMS/ UPDATES@LBL.GOV
#server altruistic.lbl.gov /pub/repositories/redhat-7.2-i386/RPMS/ MAIN_OS@LBL.GOV
server altruistic.lbl.gov /pub/repositories/lbnl-extras-RH72/RPMS/ EXTRAS@LBL.GOV
server altruistic.lbl.gov /pub/repositories/redhat-updates-7.2/RPMS/ UPDATES@LBL.GOV
server altruistic.lbl.gov /pub/repositories/redhat-7.2-i386/RPMS/ MAIN_OS@LBL.GOV
The config file
The config file is used to specify some general configuration options for GRAB, and the default behavior for GRAB. In the first section, the line update me = yesallows the config file to be updated when GRAB is updated. The default for this action is yes.
The next entry specifies the architecture that GRAB should search for. The line arch = allspecifies that GRAB should search for all architectures.
The RPM repository is the directory to which GRAB downloads all files. The default is/var/cache/grab/RPMS.
The config file is also used to specify that certain packages will not be updated with newer versions. In these instances, a duplicate of the updated package is installed instead of overwriting the original package. The duplicate packages = kernel entry specifies that only the kernel will be protected from updating.
The duplicate packages entry is very useful when new packages need to be tested against an existing installation for their affect on system stability, security, or any other performance factors.
The config file may also supply a comma-delimited list of packages that must not be updated when GRAB is run as a cron job. The SKIP LIST entry is used to specify which file will be skipped during the GRAB search process. The skip list = kernel, ypbind, mutt, ximian, helix, beo line shows the default list.
Any RPM package name may be added or removed from the list. In addition, entries in this are pattern matched. For example, if kde is added to the skip list, kdebase, kdeutils, kdemultimedia, and all other KDE-based packages will be skipped during the search process.
The first step to using GRAB is to make sure information contained in the local file is up-to-date. The contents of the remote FTP servers can change at any time, so this option should be run regularly. The update option also runs automatically whenever GRAB is run as a cron job or as a daemon. To update the local cache file, run the command grab —update.
Figure A shows the results of running GRAB in update mode. In this example, RPM file lists for RedHat 7.2 were grabbed and indexed from four FTP servers.
|These are the results from a GRAB System Update.|
Running GRAB with the —update switch, GRAB will generate a list of all RPM packages on the local system that have a newer version available on one of the FTP servers (as defined in the /etc/grab/config file). When GRAB is run with the —sysupdate switch, the list of RPM packages available on the remote FTP servers is compared to the list of RPM packages installed on the local system, and a list of packages with an update available is generated. Any, all, or none of the RPM updates may be selected and downloaded from the generated list. Once selected, the RPM package and any packages required to satisfy dependencies for this package will be downloaded. GRAB will then run the rpm -U command to update the selected package(s). Figure B shows an example of GRAB being used for a system update. In this example, the glibc package was selected.
To perform a system update with GRAB, run the command grab —sysupdate.The output from the grab —sysupdate command uses the following format:
This is the corresponding number in the initial package listing from the grab —update command.
There are four descriptors used to indicate the package status: N (new), S (same), U (upgrade), and O (old).
This is the version, release, and build number for the RPM package found during the search.
This is the version of the RPM package installed on the local system.
This is the architecture for which the RPM package is intended.
This is the size of the RPM package.
This is the server holding the RPM package.
Figure B shows the results from running GRAB with the —sysupdate option. From this list, any package listed in the output may be selected for upgrading or installation.From the list generated by the —sysupdate command, the glibc-2.2.4-24.i686.rpm was selected for an upgrade. When the glibc package was selected from the list, GRAB executed the RPM -U to upgrade the version of glibc currently installed on the system. When the update was attempted, RPM reported a problem. The glibc-common-2.2.4-24.i386.rpm package must also be installed with the glibc-2.2.4-24.i686.rpm package. GRAB was able to perform a basic dependency resolution by upgrading both RPM packages.
Searching for specific RPM packages
To search for upgrades for a specific RPM package, the —search option is used with GRAB, followed by a text string indicating the package name. Figure C shows the results of running the command grab —search kernel-source.
|These are the results of a GRAB specific-package search.|
In the example shown in Figure C, the search options found the kernel-source-2.4.9-31.i386.rpm, and automatically began to download the RPM package from the FTP server at Lawrence Berkeley Labs (email@example.com).
Most systems will have RPM packages installed that are not part of any of the pre-defined servers’ database used for GRAB updates. These packages are referred to as strays. To update stray packages, the —strays option is used. The —stray option causes GRAB to search the rpmfind database for updates. A list of stray packages on the local system is generated, and this list is then compared to the rpmfind database, rather than any pre-defined servers.
Searching for architecture-specific packages
The ability to search for RPM packages created for a specific architecture can reduce the time spent searching for updates. To search for architecture-specific packages, the —arch option is used. The command grab —search —arch athlon would search the pre-defined servers for RPM packages to be used on an Athlon-based system.
To search the rpmfind database for Athlon-based RPM packages, use the command grab —search —rpmfind —arch athlon
Problems with GRAB
GRAB performs searches by applying the Versioning Algorithm (VALGOR) to lists of RPM packages on FTP servers. Generally, this algorithm works well in deciding which RPM packages are newer or older than the packages already installed on the local system, but some problems may still occur. The most common issue occurs when RPM packages are misnamed. In this case, VALGOR simply doesn't have the correct package to compare to the package already installed on the machine. When the version, build, and release of the RPM package on the remote server are compared to a package or packages in the local RPM database, the names must be identical or VALGOR will not be able to compare the two packages.
There is no solution to this problem (other than contacting the misnamed package’s maintainer), but you can configure in the /etc/grab.conf to skip (under the skip list directive) the misnamed packages.
Add this to your toolkit
As any system administrator knows, having the right tools around can make doing your job that much easier and GRAB is the right tool for RPM management. GRAB makes maintaining a complex RPM database a no-brainer, and any tool that simplifies the process is worth a look. This utility is especially noteworthy because of its ability to quickly discover any dependencies for RPM packages. So if you’re looking for a utility to simplify package administration on a Linux server, GRAB this tool now.