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 www.autorpm.org.

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

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 ftp://ftp.redhat.com/pub/redhat/linux/updates/current/* 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.

AutoUpdate, written by Gerald Teschl, is another Perl script that can be used to automate RPM downloads or installations. Available freely under the terms of the GNU GPL from www.mat.univie.ac.at/~gerald/ftp/autoupdate, AutoUpdate is very similar to AutoRPM in terms of both functionality and potential applications. Unlike AutoRPM, AutoUpdate offers no interactive capability. However, AutoUpdate does have the capability to manage dependencies correctly; when using AutoUpdate to install software that depends upon other uninstalled software, AutoUpdate attempts to resolve the dependencies and to install all necessary software packages.

AutoUpdate bases all decisions about what software to download or install upon its configuration file, /etc/autoupdate.d/autoupdate.conf. By default, AutoUpdate provides several additional configuration files pre-defined for downloading updates for the most popular RPM-based Linux distributions (Red Hat Linux, Mandrake Linux, Caldera/SCO OpenLinux, and SUSE Linux). The autoupdate.conf file can be modified to configure AutoUpdate to install software automatically.

Table 8-3 lists the five commands that compose all the utilities provided by AutoUpdate:

Table 8-3AutoUpdate commands

These tools can access remote files by using a variety of methods. Like AutoRPM, AutoUptodate can download files if given an FTP URL. AutoUpdate can also access HTTP URLs and local files. Its additional dependency-tracking functionality and support for additional file-access methods make it suitable for use in cases where AutoRPM might be inappropriate. AutoUpdate cannot be used interactively, however, making AutoRPM more useful for nonautomated purposes.

Some vendors of RPM-based Linux distributions also provide utilities that can help with management of the distributions they create. Red Hat has created two complementary products, the Red Hat Network (RHN) and up2date, which together provide much the same functionality for managing Red Hat Linux installations as tools such as AutoUpdate and AutoRPM, as well as offering more advanced features.

Red Hat Network is a subscription-based service offered by Red Hat Red Hat Network makes software available for installation via the network. (A free evaluation is also available.) After registering machines with Red Hat Network, administrators can pull updates or new software for installation to those registered machines. In addition, administrators have access to a Web-based administrative console from which they can view the systems they manage and can push software out to those systems.

Red Hat offers two tiers of access to Red Hat Network. Basic Service subscriptions to Red Hat Network provide the ability to manage single systems. Multiple machines can be subscribed by the same administrator for Basic Service level Red Hat Network access, but they must all be managed independently. The administrator must push out errata to each machine separately. Workgroup Service subscriptions provide the same functionality as Basic Service subscriptions, but they also provide the ability to group multiple machines for simultaneous administration. All errata updates for all machines subscribed to Workgroup Service can be pushed out by a single action, for example. Furthermore, Workgroup Service subscriptions can allow management by multiple administrators if desired, making it possible for large organizations to share responsibilities among administrators.

When using Red Hat Network to manage machines with Workgroup Service subscriptions, Red Hat also offers two optional services: Red Hat Network Proxy Server and Red Hat Network Satellite. The Red Hat Network Proxy Server is, as its name suggests, a proxy server for the Red Hat Network. Using it, errata pushed out via Red Hat Network is downloaded by the organization (only once) to a central server in-house. All machines in that organization subscribed to Red Hat Network get their updated software from that in-house proxy server, significantly reducing the network bandwidth requirements needed to keep large organizations up to date.

In addition, the Red Hat Network Proxy Server can be used to provide all subscribed machines with software not provided with Red Hat Linux. Custom “channels” of supplemental software can be created on the Proxy Server, and machines can be subscribed to those channels as desired. Using this feature, different departments in the organization with different software needs can create independent channels for each department, ensuring that machines get only the software needed on them. Similarly, distinct channels can be created for separate classes of machines, ensuring that servers get only software appropriate for server machines and that desktops only get only software that desktop machines need.

The Red Hat Network is normally centrally administered through Red Hat. Machines subscribed to the Red Hat Network have a system profile on file with Red Hat that details the system’s essential configuration information (what software is installed on it, what CPU architecture it contains, and so forth) needed to determine which software errata are appropriate for that system. Similarly, the Web console through which machines subscribed to Red Hat Network can be administered is also located on a Red Hat server. Customers wishing to use Red Hat Network services, but not wanting the dependency upon Internet access to Red Hat, can create an in-house Red Hat Network by using the Red Hat Network Satellite. This solution is often practical for customers who need to keep system information confidential or for customers whose systems are not able to access the Internet.

Red Hat provides several interfaces for administering machines subscribed to the Red Hat Network. A Web-management console is available at https://rhn.redhat.com/. Administrators of machines subscribed to any level of the Red Hat Network can simply log into this Web site and perform a variety of package-management operations from their Web browsers. In addition to viewing other things, administrators can see what software is currently installed, select and install Red Hat Linux errata or new software, or schedule a time for automatic installation of Red Hat Linux errata.

When using Red Hat Network, rhnsd is a client-side daemon that should be run on subscribed systems. It periodically launches a helper utility, rhn_check, which connects to the Red Hat Network servers and checks for any actions (such as a scheduled installation of errata) that an administrator has selected in the Web console. If any actions have been scheduled for that client machine, rhn_check on the client initiates those actions. By default, rhnsd runs rhn_check every two hours. This time can be increased to check for configuration changes as frequently as every hour if necessary.

In addition, Red Hat provides client-side tools that can be used in a more interactive fashion to connect to the Red Hat Network from subscribed systems. The up2date program provides a graphical and command-line tool that can be used to install packages from Red Hat Network servers. When installing a new package, up2date automatically installs any necessary dependencies the package requires, making it a very convenient tool for adding software to the system. up2date can also be run in update mode, thus telling it to install all updates available for the software already installed on the system. Commonly used options with up2date include those listed in Table 8-4.

Table 8-4Options for the up2date command

The up2date command, the Red Hat Network client software, is open-source software released by Red Hat under the terms of the GNU GPL. Red Hat Network Proxy Server and Red Hat Network Satellite, the server applications with which up2date interacts, are not freely available, open-source applications. For this reason, an effort is underway to develop servers available under the terms of the GNU GPL that can be used with up2date clients. The main program in this effort is called current, which refers to keeping your systems current.

The current server can be downloaded from http://current.tigris.org. Although not yet as functional as Red Hat Network Proxy Server or Red Hat Network Satellite, current can already be used to create a RPM repository from which up2date-using clients can retrieve and install software. More advanced features, such as support for multiple “channels” of software, will be added to current in future releases.

Mandrake provides a set of software similar to the combination of up2date and Red Hat Network or current that can be used with the Mandrake Linux distribution. Links to the source code for the Mandrake applications can be found at www.linux-mandrake.com/cooker/urpmi.html. This suite of applications is typically referred to as urpmi and includes both the urpmi command and several helper applications. urpmi itself is a command that acts as a wrapper around the rpm command. When given the name of a package to install, urpmi determines what dependencies, if any, required by the application are not already resolved and offers to install the packages necessary to fulfill those dependencies.

When installing packages, urpmi can install from a variety of sources: FTP repositories, Web servers, local or NFS directories, and removable media such as CD-ROMs. The helper application urpmi.addmedia is used to add package sources, and the corresponding utility urpmi.removemedia is used to remove package sources no longer desired.

Mandrake’s urpmi program includes one very handy feature. It comes with an autoirpm helper utility that can be used to configure the system to install packages on demand. This is done by running the command autoirpm.update-all, an application that scans all packages available for installation via urpmi. For every package available through urpmi, autoirpm.update-all determines what executable programs it provides, and it creates a symbolic link from that executable’s name to the autoirpm script. Attempting to execute such a symbolic link executes autoirpm, which in turn automatically uses urpmi to install the associated package. The result: on-demand installation of packages when users on the system attempt to execute the programs that those packages provide.

Two different interfaces are available for urpmi. The urpmi command starts up urpmi in command-line mode, and the gurpmi command (or urpmi --X) starts urpmi in a graphical X-based mode. In addition, Mandrake provides a more full-featured graphical application: RpmDrake. RpmDrake provides the same package-management capabilities as urpmi, including the capability to install all required dependencies whenever installing any new packages.

Another free RPM management utility is available that provides many of the features of both vendor solutions such as up2date or urpmi and of third-party utilities such as autoUpdate or KPackage. This tool is apt-rpm, a port of the Debian Project’s excellent apt (Advanced Package Tool) software.

The Debian Project (www.debian.org/) is a nonprofit volunteer group that develops a Linux distribution, Debian GNU/Linux. The group uses a different package format, dpkg, which was developed independently of and simultaneous to Red Hat’s creation of RPM. The two formats, dpkg and RPM, are very similar in terms of utility and functionality. In addition to having created a package format, the Debian Project later developed a collection of software, apt, which could be used to manage and install dpkg-format software. And, since Debian distributions are typically installed over the Internet, this apt software has to supply advanced distributed package management functionality.

In many respects, Debian’s implementation of apt is very similar to the functionality provided by Red Hat’s up2date/Red Hat Network products or Mandrake’s urpmi software. On Debian systems, apt is a client tool used to select and install new software packages or to update existing packages already installed on the system. To do this, it accesses a user-configured list of resources that supply new packages; these resources are typically the Debian Project’s FTP or Web servers, though they can also be CD-ROMs or local or remote file systems. For apt to be able to download packages from a resource such as a CD-ROM or an FTP server, that resource must supply two things: the software packages being downloaded and a database supplying metadata about all the packages in the repository. These resource databases are essential for apt to operate. For this reason, apt can only be used to update systems from apt-capable repositories.

Although apt was created by the Debian Project and designed for dpkg-format software packages, nothing about apt requires that it inherently be usable only with dpkg-format packages. Because of this, and because of its powerful capabilities, Conectiva, a Brazilian Linux distribution vendor (www.conectiva.com), extended apt to support management of RPM packages in addition to dpkg packages. Conectiva’s work, commonly referred to as apt-rpm, makes the apt client software available for use on any RPM-based Linux distribution. Conectiva also provides its customers with access to apt-capable FTP servers. A related project, apt4rpm (http://apt4rpm.sourceforge.net/), supplies the necessary utilities that can be used to make any RPM repository apt-capable. By creating apt-capable servers using apt4rpm and then installing apt-rpm on the client systems, any RPM-based distribution, such as Red Hat Linux, Mandrake Linux, Caldera/SCO OpenLinux, or SUSE Linux, can then be easily managed using apt.

Note

The freshrpms.net site, mentioned previously, provides a touted apt repository.

Administrators managing multiple dispersed machines as well as those used to Debian administration often find it useful to configure their machines to use apt; its dependency tracking is far better than any other tool, except for Red Hat’s up2date/RHN combination. To use apt, administrators must install it on their machines and have access to an apt-capable RPM repository for the distribution they use. Several public FTP sites that support apt are now available for most of the major RPM-based distributions. Also, the administrator can create another apt-capable repository.

Configuration of machines to use apt is simple. The apt and libapt RPMs simply need to be installed. Although binaries are sometimes available, the best success can usually be obtained by building binary RPMs from the latest Conectiva apt SRPM (source RPM), available at ftp://ftp.conectiva.com/pub/conectiva/EXPERIMENTAL/apt/.

Once apt and libapt RPMs are installed, the sources.list file in /etc/apt needs to be modified to reference the apt-capable software site that will be used. For example, to configure a machine to access the apt-capable Red Hat Linux 7.2 software distributed by the Tuxfamily.org server, the /etc/apt/sources.list file needs to list:

rpm http://apt-rpm.tuxfamily.org/apt redhat-7.2-i386/redhat os

rpm http://apt-rpm.tuxfamily.org/apt redhat-updates-7.2/redhat os

These two lines, respectively, access the Red Hat Linux 7.2 and Red Hat Linux 7.2 errata RPMs being served by the system apt-rpm.tuxfamily.org. If you also want access to source RPMs, the following lines are necessary as well.

rpm-src http://apt-rpm.tuxfamily.org/apt redhat-7.2-i386/redhat os

rpm-src http://apt-rpm.tuxfamily.org/apt redhat-updates-7.2/redhat os

In addition to, or instead of, using public apt-capable servers, many sites want to create their own apt servers. If apt is being used to manage all the machines in the enterprise, a custom apt server might be needed that contains apt-accessible RPMs of all the custom software used in the enterprise. This can be done using the tools provided by the apt4rpm package (http://apt4rpm.sourceforge.net).

Once apt has been installed on clients, and the clients have been configured to access an apt-capable server, keeping systems updated is simple. The command apt-get update updates the client system’s apt database of available software, after which the command apt-get upgrade upgrades all currently installed software to the latest version available in the software repository. By listing a site that provides vendor errata updates in /etc/apt/sources.list and then setting up a nightly cron job to run the apt-get upgrade command, administrators can be sure that client systems always have the latest errata installed. You can use a similar technique to ensure that all client systems are always up to date with the latest custom in-house applications. To do this, set up your own apt server and ensure that the latest custom applications are placed on the apt server.

In addition, apt simplifies interactive installation of RPMs on systems that are using it. The command apt-get install package retrieves the named RPM from the apt-capable software repository and installs it. If the package requires any dependencies that are not already resolved, apt will ask for confirmation, then download and install the package and all dependencies. Similarly, apt-get remove package uninstalls the named RPM. If any other packages depend on it, it will prompt for confirmation, then uninstall the named RPM and all of its dependencies.

In addition to these command-line utilities, several graphical front-end tools for manipulating apt are currently being ported for use with apt-rpm. Because of its ease of use for automating installation of system errata and necessary custom software, and because of the excellent dependency tracking it provides for interactive installation and uninstallation of software, apt-rpm can be excellent for managing RPM-based systems.

Also similar to the Debian apt tool, a utility called the poldek works like apt-get. The poldek was designed to quickly scan through dependencies and install a number of packages at once. You can specify all the packages to install in a file.

The poldek automatically downloads any needed dependencies. The poldek can download files over the Internet and also help create the packages for storage on CD-ROMs. The poldek optimizes the set of packages to reduce the number of times users have to switch CDs.

Cross Reference

For more on the poldek, see poldek.pld.org.pl.