There's been considerable discussion lately about how Microsoft releases security patches, and how enterprise-level administrators can distribute those patches to the systems under their care. To a Linux administrator, it all seems terribly complicated and messy, and this impression was reinforced for me when I recently had to patch a number of Windows workstations to bring them up to par with a Samba server installation.
Life with Linux is much, much nicer; there's a selection of tools available which you can use to install and update software, either from the command line, on an automatic nightly basis or using a GUI for package selection. Because most Linux software is free (as in beer) the installation tools can simply fetch the software from a repository and install it immediately. If you enjoy instant gratification, this is definitely the way to go!
Most distributions today are based on the RPM package management system - in fact, it is now a requirement of the Linux Standard Base, (although distributions that are not based on RPM sometimes have minimal support). Because of its ubiquity, we'll examine basic RPM first, and then move on to look at more advanced alternatives, including the main competitor to RPM, Debian's .deb package format (also used on Ubuntu).
RPM packages
Many distributions use the Red Hat Package Manager, RPM. RPM provides a way for software packages to be built from pristine source code plus patches, then assembled into a package file which also includes install and uninstall scripts, configuration files, documentation and other software assets. Installing RPM packages is simple - download the package file or find it on CD-ROM, then issue a command like
rpm -i <package-name>.i386.rpm to install it. Note that to install packages, you have to have root privileges, since installation involves writing to system directories and updating the RPM database, which maintains information about what's installed. However, querying the RPM database can be done as an ordinary user.
The rpm command has four main modes of operation:
Installing Packages
It's easy to install software using RPM, as shown above. There are a number of often-forgotten twists that make it even easier, however. First, the rpm command will accept lists of package files or a wildcard on the command line. So, if you have a directory containing a number of related packages - for example, those that make up xfce4, or OpenOffice.org - you can install them all with a single command
rpm -ivh *.rpm The shell will expand this into a list of matching files and install them all. This is particularly useful when there are interdependencies among the various packages (package A requires package B and won't install unless B's installed first, but B requires C and C requires A, as sometimes happens).
In the example above, the v (for verbose) option will cause rpm to print occasional messages about what it's doing, and the h option makes it print hash-marks (#) to show progress.
Wildcard expansion becomes particularly useful with the -U (upgrade) and -F (freshen) options, which can be used to update a system. Here's the distinction between -U and -F:
If you have a directory full of RPM packages and give the command:
rpm -Uvh *.rpm then RPM will attempt to install all the package files. Packages which had been previously installed will be updated, but if they were not previously installed, then they will be installed anyway - which may not be what you want. By contrast,
rpm -Fvh *.rpm compares the list of package files against the database of previously-installed packages and will only upgrade a package if was already installed. New packages will not be added.
Another neat feature is that the rpm command will accept URL's as arguments; this means that you can download files from an ftp or web server and install them with a single command. In practice, this is most commonly used within scripts which automatically maintain systems. However, it is possible to do something like:
[root@loki ~]# rpm -Uvh ftp://ftp.pbone.net/mirror/download.fedora.redhat.com/pub/fedora/linux/core/updates/4/i386/xterm-212-1.FC4.i386.rpm Retrieving ftp://ftp.pbone.net/mirror/download.fedora.redhat.com/pub/fedora/linux/core/updates/4/i386/xterm-212-1.FC4.i386.rpm Preparing... ########################################### [100%] 1:xterm ########################################### [100%] [root@loki ~]# Removing Packages
To uninstall a package, you use the rpm -e option. In this case, you're uninstalling a package, not installing a file, so the argument to the command is the package name, optionally including a version number. So, for example, to remove the xterm package, I could just say
[root@loki ~]# rpm -e xterm error: Failed dependencies: xterm is needed by (installed) xinitrc-4.0.18.1-1.noarch xterm is needed by (installed) xorg-x11-twm-6.8.2-37.FC4.49.2.i386 [root@loki ~]# but as you can see, the xterm package is required by some other packages (and besides, I occasionally use it, so I'm not going to remove it).
In general the version number is unimportant, as you generally don't have two versions of the same package installed simultaneously, but an important exception to this is kernels - where you very often have two or more installed. To delete a specific kernel I would use a command like:
[root@loki etc]# rpm -e kernel-2.6.11-1.1369_FC4 [root@loki etc]# As always, no output indicates successful completion.
Querying the RPM Database
The rpm -q option is very useful when you want to know what you have installed, or want to know about what you have installed. Here are some examples:
What kernels do I have installed?
[root@loki ~]# rpm -q kernel kernel-2.6.11-1.1369_FC4 kernel-2.6.12-1.1398_FC4 kernel-2.6.12-1.1447_FC4 kernel-2.6.14-1.1653_FC4 kernel-2.6.15-1.1831_FC4 kernel-2.6.15-1.1833_FC4 [root@loki ~]# Which version of the Apache web server is installed? (You have to know it's in the httpd package)
[root@loki ~]# rpm -q httpd httpd-2.0.54-10.3 [root@loki ~]# Where did the file /usr/bin/transxx come from?
[root@loki bin]# rpm -qf /usr/bin/transxx kdesdk-3.5.1-0.1.fc4 [root@loki bin]# OK, but what is this "kdesdk" package? (Query package info)
[root@loki bin]# rpm -qi kdesdk Name : kdesdk Relocations: /usr Version : 3.5.1 Vendor: Red Hat, Inc. Release : 0.1.fc4 Build Date: Thu 02 Feb 2006 09:22:23 AM EST Install Date: Thu 02 Mar 2006 04:00:50 PM EST Build Host: hs20-bc1-4.build.redhat.com Group : User Interface/Desktops Source RPM: kdesdk-3.5.1-0.1.fc4.src.rpm Size : 17373018 License: GPL Signature : DSA/SHA1, Sat 04 Feb 2006 04:05:49 AM EST, Key ID b44269d04f2a6fd2 Packager : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla> URL : http://www.kde.org/ Summary : The KDE Software Development Kit (SDK) Description : A collection of applications and tools used by KDE developers. Among other things, kdesdk provides tools for working on the KDE CVS repository. [root@loki bin]# Ah - so it's the KDE Software Development Kit. Is there documentation for this somewhere?
[root@loki bin]# rpm -qd kdesdk /usr/share/doc/HTML/en/cervisia/annotate.png /usr/share/doc/HTML/en/cervisia/checkout.png . . /usr/share/doc/HTML/en/umbrello/use-case-diagram.png /usr/share/doc/HTML/en/umbrello/working_with_umbrello.docbook [root@loki bin]# Other useful options include -ql (query for a list of files in the package) and the -qp option, which allows you to query an uninstalled package file, rather than the RPM database of installed packages. So, for example, looking at files on a CD-ROM:
[root@loki RPMS]# rpm -qip vte-0.11.13-2.fc4.i386.rpm Name : vte Relocations: (not relocatable) Version : 0.11.13 Vendor: Red Hat, Inc. Release : 2.fc4 Build Date: Tue 24 May 2005 04:50:58 AM EST Install Date: (not installed) Build Host: tweety.build.redhat.com Group : User Interface/X Source RPM: vte-0.11.13-2.fc4.src.rpm Size : 1041380 License: LGPL Signature : DSA/SHA1, Wed 25 May 2005 07:22:16 AM EST, Key ID b44269d04f2a6fd2 Packager : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla> Summary : An experimental terminal emulator. Description : VTE is an experimental terminal emulator widget for use with GTK+ 2.0. [root@loki RPMS]# The -qip option gets the package information from the package file, and as you can see, it has not been installed.
Verifying Packages
It's useful to be to verify that a package was installed correctly and was not corrupted. You can do this with the -V (or --verify) option, which compares various characteristics of the installed files - size, permissions, ownership, mtime and an MD5 hash - against those recorded in the RPM database. If everything checks out, the command prints nothing, but if something is wrong, it prints a line for each file with an 8-character string, a dot indicating the characteristic matches, a dash indicating it could not be checked or a letter to indicate a mismatch.
A real-world example: Just yesterday I helped someone online who was complaining that common commands like cp and cat were giving particularly horrible, complex error messages. I used the command rpm -qf /bin/cp to find out which package the cp binary was installed from (coreutils) and then had him verify the files. The output had lots of S's and 5's, indicating that the file sizes and MD5 hashes did not match the values in the RPM database - in other words, the files had been changed. Subsequent investigation showed that the system had been infected with the Linux.RST.B virus (I don't know how it got there and he disappeared into embarrassed silence before I could ask him).
system-config-packages
On Red Hat (where it's called redhat-config-packages) and Fedora systems, this command provides a graphical front-end which allows installation of additional packages from the installation media (CD or DVD). However, it does not connect to repositories of updated versions or allow you to install software which was not provided on the installation media.
This command can be launched from the GUI menus; select System Settings -> Add/Remove Applications and provide the root password when prompted.
Finding RPM Packages
There are various sources from which you can obtain RPM packages, particularly those that are not bundled with a distribution for licensing reasons (such as mp3 and DVD codecs). Always start with the main site for your distribution, of course, but if you cannot find a package there, check the following sites, which provide packages and usually have a search facility:
Red Hat up2date
The up2date command is a graphical front-end for RPM on Red Hat systems. When run, it connects to Red Hat's servers and downloads information about available updates for the target system (based upon membership in channels, as in Red Hat Network). By stepping through the screens, the user can select what to update and have it automatically downloaded and installed. For systems with no graphics, such as servers, a command-line version can be used. up2date is generally considered obsolete, however.
Red Hat Network
Users of Red Hat Enterprise Linux can use Red Hat Network to update their systems. This provides a web interface; each RHEL system connects to RHN every few hours and checks for any updates or commands to be executed. The RHN servers know the installed packages on each registered system and can flag those which require updates; an administrator can log in and schedule an update so that next time the system connects it will download and install the updated packages.
Because the managed systems connect to Red Hat Network, this makes it particularly appropriate for managing distributed systems which are located behind firewalls, such as those in branch offices or customer premises.
yum
yum is the "Yellow Dog Updater, Modified" (to work on RPM-based systems). It has become a standard tool for updating many RPM-based distributions, and can keep them up-to-date with virtually no human intervention.
yum can be run from the command line to install software automatically or can be scheduled to run automatically during the night. The simplest way to run it is simply to use the yum update command:
[root@loki ~]# yum update Setting up Update Process Setting up repositories Reading repository metadata in from local files Resolving Dependencies --> Populating transaction set with selected packages. Please wait. ---> Package openoffice.org-impress.i386 1:2.0.1.1-7.1 set to be updated ---> Package ruby-libs.i386 0:1.8.4-2.fc4 set to be updated ---> Package kdeutils-devel.i386 6:3.5.3-0.1.fc4 set to be updated ---> Package mozilla.i386 37:1.7.13-1.1.fc4 set to be updated and so on it goes for a few minutes. Eventually, we get:
Transaction Summary ============================================================================= Install 12 Package(s) Update 136 Package(s) Remove 0 Package(s) Total download size: 635 M Is this ok [y/N]: y Downloading Packages: (1/148): openoffice.org-i 0% | | 8.0 kB 01:08 ETA and off it goes, downloading packages. Eventually, the last package downloads, and we see:
(148/148): xscreensaver-e 100% |=========================| 2.9 MB 00:29 Running Transaction Test Finished Transaction Test Transaction Test Succeeded Running Transaction Updating : xorg-x11-libs ##################### [ 1/284] Updating : qt ##################### [ 2/284] Updating : popt ##################### [ 3/284] until eventually:
Installed: kernel.i686 0:2.6.17-1.2139_FC4 kernel-devel.i686 0:2.6.17-1.2139_FC4 Dependency Installed: ImageMagick-c++.i386 0:6.2.2.0-3.fc4.2 (and lots more!) Updated: ImageMagick.i386 0:6.2.2.0-3.fc4.2 anacron.i386 0:2.3-36.FC4 arts.i386 8:1.5.3-0.1.fc4 arts-devel.i386 8:1.5.3-0.1.fc4 autofs.i386 1:4.1.4-26 bind.i386 24:9.3.1-20.FC4 bind-libs.i386 24:9.3.1-20.FC4 bind-utils.i386 24:9.3.1-20.FC4 (and many, many more!) Complete! [root@loki ~]# yum can also be used to install individual packages. For example, to install the LAME mp3 encoder:
[root@loki ~]# yum install lame Setting up Install Process Setting up repositories Reading repository metadata in from local files Parsing package install arguments Resolving Dependencies --> Populating transaction set with selected packages. Please wait. ---> Downloading header for lame to pack into transaction set. lame-3.96.1-0.lvn.4.4.i38 100% |=========================| 9.5 kB 00:00 ---> Package lame.i386 0:3.96.1-0.lvn.4.4 set to be updated --> Running transaction check Dependencies Resolved ============================================================================= Package Arch Version Repository Size ============================================================================= Installing: lame i386 3.96.1-0.lvn.4.4 livna 648 k Transaction Summary ============================================================================= Install 1 Package(s) Update 0 Package(s) Remove 0 Package(s) Total download size: 648 k Is this ok [y/N]: y Downloading Packages: (1/1): lame-3.96.1-0.lvn. 100% |=========================| 648 kB 00:11 warning: rpmts_HdrFromFdno: Header V3 DSA signature: NOKEY, key ID a109b1ec Public key for lame-3.96.1-0.lvn.4.4.i386.rpm is not installed Retrieving GPG key from file:///etc/pki/rpm-gpg/RPM-GPG-KEY-livna Importing GPG key 0xA109B1EC "Livna.org rpms <rpm-key@livna.org>" Is this ok [y/N]: y Key imported successfully Running Transaction Test Finished Transaction Test Transaction Test Succeeded Running Transaction Installing: lame ######################### [1/1] Installed: lame.i386 0:3.96.1-0.lvn.4.4 Complete! [root@loki ~]# Other useful yum commands:
Adding a third-party repository is usually a matter of adding a few lines for it in /etc/yum.conf, a file in /etc/yum.repos.d or even installing an RPM package which does one of these things. For example, to add the Livna repository (http://rpm.livna.org) to a Fedora Core 4 system is as simple as typing one command:
[root@loki ~]# rpm -ivh http://rpm.livna.org/livna-release-4.rpm Retrieving http://rpm.livna.org/livna-release-4.rpm warning: /var/tmp/rpm-xfer.VpTRZZ: Header V3 DSA signature: NOKEY, key ID a109b1ec Preparing... ########################################### [100%] 1:livna-release ########################################### [100%] [root@loki ~]# This adds the files livna.repo, livna-devel.repo and livna-testing.repo into the /etc/yum.repos.d directory.
The yum home page is at http://linux.duke.edu/projects/yum/
apt-rpm
Debian enthusiasts often tout its apt utility (see below) as a major advantage over Red Hat and other RPM-based distributions. Debian users who are confronted with an RPM-based distribution can enjoy some of the same benefits with the apt-rpm tool written by Conectiva. This functions in essentially the same way as the Debian apt-get command, only with RPM packages and respositories such as freshrpm.net, which has an excellent page with examples and downloads of apt-rpm: http://freshrpms.net/apt/ The main project page is located at http://apt-rpm.org/.
The Debian World - Debian, Ubuntu, etc.
Debian GNU/Linux has long had an excellent package management tool in the form of Apt (Advanced Package Tool). While the original Debian dpkg command has features similar to RPM, Apt more closely resembles yum, in that it is able to resolve dependencies, install packages from remote repositories, etc.
The main command for apt is the apt-get command. Its syntax is rather similar to yum; typical commands include apt-get install package, apt-get remove package and apt-get upgrade, which will update all packages on a system. You can even upgrade to a new version of Debian with the command apt-get dist-upgrade.
The Apt repository list is stored in the file /etc/apt/sources.list. Debian package files have a name ending in .deb.
Synaptic
Synaptic is a graphical front end for Apt, which is commonly used on Debian, Ubuntu, Conectiva, Yoper and other distributions. It allows searching for packages based on name, description and other attributes, installation, update, downgrade and removal of packages, browsing of documentation and many other advanced features. At the same time, it is extremely easy to use. You can install Synaptic using almost any of the commands previously discussed, or you can download it from http://www.nongnu.org/synaptic/
Conclusions
These aren't the only options available on Linux distributions; for example, Slackware Linux has its own package format based on binary tarballs, and there are distributions which use schemes that are more like the BSD ports system (for example, Gentoo's Portage). That's the great thing about Linux - people are always coming up with new ways of doing things, and you can always find something that fits your own philosophy and preferences. However, for most of us, all we need is yum or apt to keep our systems up-to-date and secure, automatically.
Sidebar - RPM file Naming Conventions
RPM package files are very specific to a particular distribution, distribution version and hardware architecture. It's important, therefore, to make sure that you download and install the correct versions for your system. It helps if you know the naming conventions for RPM package files.
The first part of the name will refer to the software package the file contains. Take the PHP 5 package on Fedora Core 4, for example - the filename is
php-5.0.4-10.i386.rpm Following the first hyphen is the version number of the software, as released by its developers. So we know that this is PHP version 5.0.4, as it was released by the PHP project. Following the next hyphen is the release number of the packager. In this case, the package was built by the Fedora project, and it is release number 10. This probably means that it has had a number of patches applied to the original source - bug fixes, security patches, or patches required to ensure compatibility with the distribution. With a release number of 10, we might speculate that the original release was unpatched and there have been 9 patches applied since then.
The next part of the filename identifies the target architecture, i.e. the processor or computer type this package was compiled for. There's a number of these:
Because RPM files are compiled to link with specific versions of libraries found in a given distribution, it is quite common for the filename to also indicate which distribution it was built for. This is particularly important when downloading RPM's from third-party sites. So, for example, xterm-212-1.FC5.x86_64.rpm is built for Fedora Core 5, while xterm-203-1mdk.i586.rpm is built for Mandriva (formerly Mandrake) Linux 2006.
A .src.rpm file does not contain an architecture-specific executable; it is a Source RPM package, which contains the original source code (usually as a .tar.gz file) along with any patches to be applied, required scripts and a spec file which contains instructions on how to build the installable RPM. Techniques for building RPM's are beyond the scope of this article, but are useful when you cannot obtain a specific RPM for your platform.
Page last updated: 05/Jul/2006 Back to Home Copyright © 1987-2010 Les Bell and Associates Pty Ltd. All rights reserved. webmaster@lesbell.com.au