Product SiteDocumentation Site

Extending RPM Management

RPM makes it very easy to install and uninstall software from systems. One simple command installs an entire application onto the computer, and another removes all files associated with an application. Using RPM to install and uninstall software can become tedious in some situations, however. Manually installing software on one system is no great task, but what if that same software package needs to be installed on all the computers in the department? Or on all the computers in a company? Suddenly, that one rpm -i command has become a major chore!
Similarly, keeping one system up-to-date with the latest vendor errata, although an extremely important administrative task, is not terribly time-consuming or difficult — simply download all the errata and associated packages from the vendor; then use the command rpm -Fvh to install the packages on the system, freshening all installed software with the latest updates of that software.
If several machines are being managed, though, the task becomes slightly more difficult. Now the vendor errata and packages must be manually copied to each machine, and rpm -Fvh must be run on each machine to update it. If many machines are being managed, and those systems are running different versions of the operating system (so that they require different errata), the task becomes even more complicated. Separate errata packages must be downloaded for every operating system version in use; then the appropriate errata collections must be pushed to each machine and manually freshened. To make life as a system administrator even more frustrating, sometimes vendor-supplied errata cannot be installed using the freshen option. A package supplied as one RPM in the initial operating-system release might be split into two RPMs for the errata, for example. When this happens, freshen cannot be used. Instead, the administrator must determine what software is currently installed on the system, and the errata for that software must be manually installed. Typically, this involves several rounds of comparing output from rpm -qa with the list of current errata, using rpm -Uvh to upgrade only the appropriate errata for that system.
Worse yet, errata updating should ideally be done on an automatic basis. While rpm commands can be scheduled using system utilities such as cron or at, obviously this cannot be done when the rpm commands to be scheduled need to be interactive.
Installation of new packages can pose problems as well. New software will often have logical dependencies upon other software that is also not currently installed. Although RPM does track software dependencies, it does not magically find all dependencies an application needs, nor does it automatically install them along with the initial application. Instead, all required “helper” applications must be searched out and manually installed. Then the desired software can be installed.
These and similar problems are very common in the real world. Typically, system administrators manage as many as 200 or more systems. Manually logging into 200 systems and executing an rpm -i command every time another application is needed is not practical. Even when managing one system, downloading errata and manually installing it regularly quickly becomes tedious.
Like any regular system-administration task, it should be automated. When installing new software on machines, managing dependencies and downloading and installing required support software becomes tiresome as well.
To aid with these common problems, a variety of helper applications are available for RPM. These management aids can perform functions such as automatically managing dependencies. When an application is being installed using one of these helpers, the utility also finds and installs any required dependencies. Similarly, when errata are being installed, these management aids can automatically determine which errata are needed by the current system, even in situations in which rpm -F does not work. Some of these tools can even be used to manage clusters of computers. Running one command applies the RPM install or delete on the entire group of machines. All of these commands are designed with scriptability in mind, making them perfect for use automatically via tools such as cron or at.


One popular tool to lessen the work involved with administering RPM-based systems is AutoRPM. Written by Kirk Bauer, AutoRPM is available under a free MIT-style license from the home page
A Perl script, AutoRPM provides several features that make it especially useful. First, it can create local mirrors of RPM repositories. Typically, this feature might be used to create a local archive of errata for a Linux distribution. AutoRPM can also compare all currently installed RPMs against a list stored elsewhere. This list can be either an FTP site or a directory on the local system. After comparing the currently-installed RPMs against the list, AutoRPM can then update any packages from the list site that are newer than what is installed on the local system. This way, you can define one site or directory as the master site of the package versions that need to get installed on all systems and let AutoRPM ensure that all computers on your network are up to date.
Together, these two functions make AutoRPM very convenient for keeping systems current with all errata the vendor releases. They can also be used to create a method of distributing software to a network of systems. For example, every workstation in the department can run AutoRPM, configured to watch a common directory on a local NFS server. Installing new software on every workstation in the department occurs simply by copying an RPM of the software into that directory, letting AutoRPM do the rest of the work.
AutoRPM is designed to be used both automatically from cron and interactively from the command line. By default, AutoRPM runs via a nightly cron job and downloads all updates for software currently installed on the system. It then stores these updates in a local directory, typically /var/spool/autorpm, and e-mails an administrator a notification on the new updates. The administrator can then log onto the system and manually install the updates using the rpm command. AutoRPM can also be easily configured to install automatically any new packages it downloads. If AutoRPM is so configured, the system administrator does not even have to log in and run rpm commands to keep the system up-to-date!
In interactive mode, AutoRPM provides a basic set of commands, listed in Table 8-2.
Table 8-2Basic AutoRPM commands
displays help on the various commands
displays help on the various commands
displays information about an RPM
displays complete information about an RPM
installs RPMs onto the system
adds RPMs to the queue of RPMs to be processed
deletes RPMs from the queue of RPMs waiting to be processed
displays all RPMs currently in the queue waiting to be processed
changes the local directory
executes commands defined in the system-wide configuration file
displays or modifies current AutoRPM settings
exits without saving changes
Exits and saves changes
The commands that manipulate RPMs (such as install, used to install an RPM) accept as arguments both paths to RPM files on the local system, and also URLs pointing to RPMs on an FTP repository. In addition, they support wild cards and directory accesses, so a command such as install* can be used to install all errata for the current release of Red Hat Linux.
In addition to interactive mode, AutoRPM provides a noninteractive mode, suitable for use through cron. In noninteractive mode, invoked by the command autorpm --notty auto, AutoRPM consults the configuration file /etc/autorpm.conf to decide what to do. By default, /etc/autorpm.d/autorpm.conf is configured to download, but not automatically install, all errata for the release of Red Hat Linux running on the local system. Editing this file makes it possible to use AutoRPM to download all errata — or errata for other Linux distributions — or to install errata automatically once downloaded.
Typically, AutoRPM is used to automate installation of errata updates and other software on all machines in the enterprise. To do this, one machine is selected to serve as a file server. On it, AutoRPM is configured to download and install all errata. The directory where the errata are stored on that server is then exported to the other machines in the enterprise, which also run AutoRPM. These other machines have AutoRPM configured to install all files that the file server exports. Using a configuration such as this, all machines in the enterprise get all security updates automatically installed. In addition, installing a desired new software application on all hosts in the enterprise can be done simply by copying an RPM of the application onto the file server, making it available for the AutoRPM nightly updates to access and install automatically.