Finding, Downloading, and Installing Software - System Administration - A practical guide to Fedora and Red Hat Enterprise Linux, 7th Edition (2014)

A practical guide to Fedora and Red Hat Enterprise Linux, 7th Edition (2014)

Part III: System Administration

Chapter 12. Finding, Downloading, and Installing Software

In This Chapter

JumpStart: Installing and Removing Software Packages Using yum

Finding the Package That Holds an Application or File You Need

yum: Keeps the System Up-to-Date

yum Commands

yum.conf: Configures yum


RPM: The RPM Package Manager

Keeping Software Up-to-Date

curl: Downloads Files Noninteractively


After reading this chapter you should be able to:

Image Explain the purpose of a software package, a package management system, and a software repository

Image List the uses and benefits of yum

Image Use yum to list installed and available packages

Image Use yum to search for packages containing specific applications or utilities

Image Use yum to install and remove a software package

Image Use yum to update all software packages on the local system.

Image Download large files with BitTorrent

Image Use rpm to display information about a package and install software

Image List common steps for installing non-RPM software from source


Linux is based on millions of lines of code and includes thousands of programs. Each of these programs is updated periodically, and most depend on other programs or files to run. The source code for each program must be compiled for each processor architecture and each release of each Linux distribution. With the first releases of Linux, these tasks were done by hand. Over time, this process has been automated. This chapter explains how you can make your life easier by taking advantage of the facilities Fedora/RHEL provides for finding, installing, updating, and removing software.

Image Software package

A software package, or simply package, is the collection of scripts, programs, files, and directories required to install and run an application, utility, server, or system software. A package also includes a list of other packages the package depends on (dependencies). Using software packages makes it easier to install, update, and uninstall software. A package contains either executable files or source code files. Executable files are precompiled for a specific processor architecture and operating system, whereas source files need to be compiled but will run on a wide range of machines and operating systems.

Image PMS

A PMS, or package management system, is a set of utilities that allow you to install, upgrade, remove, and search software packages easily and in a consistent manner. It is based on a local database that holds information about each installed package, including its dependencies and version information.

One of the biggest advantages of a PMS is how easy it makes it to uninstall a package. If you compile from source, a make install command typically installs the files, but there is frequently no make uninstall command. A PMS keeps track of all the files that belong to a package. These files might be distributed among many directories throughout a system. This tracking allows you to remove all files belonging to a package with a single command. A PMS also enables you to query packages, a great troubleshooting tool that does not come with manual installation. When you manually install a package, you must obtain the source code (again, and in some cases the same version as you installed) to learn which files are a part of the package, what was done during installation, and how to remove the software.

Image Software package formats

Software packages come in different formats. Fedora/RHEL and SUSE use RPM (RPM Package Manager; page 546). Ubuntu and Debian use dpkg (Debian package), which was the first Linux packaging system to incorporate dependency information. Other formats include the GNU Configure and Build System (page 550), and compressed tar. Formats such as compressed tar, which were popular before the introduction of RPM, are used less often today because they require more work on the part of the installer (you) and do not provide the dependency and compatibility checking RPM offers.

Image yum

Early releases of Red Hat Linux did not include a tool for managing updates. Although RPM could install or upgrade individual software packages, it was up to the user to locate a package and any packages it was dependent on. When Terra Soft produced its Red Hat–based Linux distribution for the PowerPC, the company created the Yellow Dog Updater to fill this gap. This program has since been ported to other architectures and distributions. The result, named Yellow Dog Updater, Modified (yum;, is included with Fedora/RHEL. This chapter covers manyyum commands and features.


PackageKit ( is a front end for several PMSs, providing a uniform interface. Fedora, Kubuntu, and SUSE use PackageKit. The gnome-packagekit package holds graphical tools designed for the GNOME desktop; each of these tools is named gpk*.

Graphical interfaces

This chapter describes yum, which provides a textual interface. The yumex utility (yum extender; yumex package), which this book does not cover, provides a graphical interface to yum. The gpk-application utility, part of PackageKit (previous), also provides a way to work with software packages graphically.

Kernel source code

Chapter 14 discusses downloading, configuring, compiling, and installing kernel source code. See page 582 for an example of downloading kernel source code using yumdownloader.

Image Repositories

The yum utility downloads package headers and packages from servers, called repositories, that can reside on the Internet, a DVD, or the local network. See page 542 for more information. If you need to distribute locally built packages to a group of systems, you might want to consider setting up a local repository.

Keeping software up-to-date

Of the many reasons to keep software up-to-date, one of the most important is security. Although you often hear about software-based security breaches after the fact, you rarely hear about the fixes that were available but never installed before the breach occurred. Timely installation of software updates is critical to system security. Linux open-source software is the ideal environment to find and fix bugs and make repaired software available quickly. When you keep a system and application software up-to-date, you keep abreast of bug fixes, new features, support for new hardware, speed enhancements, and more.

As shipped, Fedora/RHEL checks for updates daily, automatically installs security updates, and advises you when other updates are available. Use the Software Update Preferences window (page 116) to change these options.

Bug tracking

Fedora/RHEL uses Bugzilla (, which belongs to a class of programs formally known as defect tracking systems, to track bugs. You can use Bugzilla to read about existing bugs and to report new ones. See page 552 for information on how Fedora/RHEL handles errata.

Image JumpStart: Installing and Removing Software Packages Using yum

This section explains how to use yum to install packages on and remove packages from the local system. The yum utility provides a textual interface; see “Graphical interfaces” on page 533 if you want to use a GUI.

Tip: Work with root privileges when you install and remove packages

Because installing and removing packages involves writing to directories that only a user working with root privileges can write to, you must work with root privileges when you install and remove packages.

If you do not know the name of the package you want to install, see page 536. If you want yum to download a package that is not supported by Fedora/RHEL, you must add to the /etc/yum.repos.d directory (page 542) a file that specifies the repository that holds the package.

Before using yum to install a package, work with root privileges to give the command yum update (page 538) to update the local RPM installation database. By default, the system updates this database daily. Even so, it is a good idea to give this command periodically until you are sure the script is updating the database properly.

yum install

The following example calls yum to install the tcsh shell, which is part of the tcsh package. After yum determines what it needs to do, it asks for confirmation. Reply y if you want to continue or n to quit.

# yum install tcsh
Loaded plugins: langpacks, refresh-packagekit
Resolving Dependencies
--> Running transaction check
---> Package tcsh.x86_64 0:6.18.01-2.fc19 will be installed
--> Finished Dependency Resolution
Dependencies Resolved

Package Arch Version Repository Size
tcsh x86_64 6.18.01-2.fc19 updates-testing 336 k

Transaction Summary
Install 1 Package

Total download size: 336 k
Installed size: 658 k
Is this ok [y/d/N]: y
Downloading packages:
tcsh-6.18.01-2.fc19.x86_64.rpm | 336 kB 00:00
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
Installing : tcsh-6.18.01-2.fc19.x86_64 1/1
Verifying : tcsh-6.18.01-2.fc19.x86_64 1/1

tcsh.x86_64 0:6.18.01-2.fc19


Tip: Installing a package group

Installing a package group installs a group of related packages. For example, the command yum group install virtualization installs the group of software packages needed to run virtualization programs. See page 540 for more information on groups.

Automatically installs dependencies

The next command installs the ypbind (NIS) package. Because this package depends on another package that is not installed (yp-tools), yum lists the package under Installing for dependencies and installs it automatically. The yum utility asks for confirmation before installing the packages.

# yum install ypbind
Loaded plugins: langpacks, refresh-packagekit
Resolving Dependencies
--> Running transaction check
---> Package ypbind.x86_64 3:1.37.1-3.fc19 will be installed
--> Processing Dependency: yp-tools for package: 3:ypbind-1.37.1-3.fc19.x86_64
--> Running transaction check
---> Package yp-tools.x86_64 0:2.14-1.fc19 will be installed
--> Finished Dependency Resolution

Dependencies Resolved

Package Arch Version Repository Size
ypbind x86_64 3:1.37.1-3.fc19 fedora 62 k
Installing for dependencies:
yp-tools x86_64 2.14-1.fc19 fedora 79 k

Transaction Summary
Install 1 Package (+1 Dependent package)

Total download size: 141 k
Installed size: 299 k
Is this ok [y/d/N]: y

yum remove

You can also use yum to remove packages, using a similar syntax. The following example removes the tcsh package:

# yum remove tcsh
Loaded plugins: langpacks, refresh-packagekit
Resolving Dependencies
--> Running transaction check
---> Package tcsh.x86_64 0:6.18.01-2.fc19 will be erased
--> Finished Dependency Resolution

Dependencies Resolved

Package Arch Version Repository Size
tcsh x86_64 6.18.01-2.fc19 @updates-testing 658 k

Transaction Summary
Remove 1 Package

Installed size: 658 k
Is this ok [y/N]: y
Downloading packages:
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
Erasing : tcsh-6.18.01-2.fc19.x86_64 1/1
Verifying : tcsh-6.18.01-2.fc19.x86_64 1/1

tcsh.x86_64 0:6.18.01-2.fc19


Automatically removes dependencies

When yum removes a package, it also removes packages that are dependent on the package it is removing. The following example removes ypbind and its dependency, yp-tools.

# yum remove ypbind
Loaded plugins: langpacks, refresh-packagekit
Resolving Dependencies
--> Running transaction check
---> Package ypbind.x86_64 3:1.37.1-3.fc19 will be erased
--> Processing Dependency: ypbind for package: yp-tools-2.14-1.fc19.x86_64
--> Running transaction check
---> Package yp-tools.x86_64 0:2.14-1.fc19 will be erased
--> Finished Dependency Resolution

Dependencies Resolved

Package Arch Version Repository Size
ypbind x86_64 3:1.37.1-3.fc19 @fedora 98 k
Removing for dependencies:
yp-tools x86_64 2.14-1.fc19 @fedora 201 k

Transaction Summary
Remove 1 Package (+1 Dependent package)

Installed size: 299 k
Is this ok [y/N]: y

Image Finding the Package That Holds an Application or File You Need

You might know the name of an application, utility, or file you need but not know the name of the package that holds the file. This section describes several ways you can locate the package.

Tip: Finding a package with a name that sounds like...

The yum search command (next page) searches package names, descriptions, and summaries. The yum list command (next page) searches package names only.

Fedora package database

Visit After entering the string you are searching for in the text box labeled Search, click APPLICATIONS or PACKAGES to display software packages with the string you entered in their names or descriptions.


You can use gpk-application to search for packages by filename, program or application name, or package name. When you find the package you want, this program will install it.

yum whatprovides

You can also use yum to search repositories for a package that contains a specified file. For example, suppose you are compiling a program and get the following error message:

xv.h:174:22: error: X11/Xlib.h: No such file or directory

Following, the yum whatprovides (or just provides) command displays a list of packages that contain the file named Xlib.h in the X11 directory:

$ yum whatprovides "*X11/Xlib.h"
Loaded plugins: langpacks, refresh-packagekit
libX11-devel- : Development files for libX11
Repo : fedora
Matched from:
Filename : /usr/include/X11/Xlib.h

The most likely candidate is the entry shown in the preceding example, which is the most generic. You can install this package using the following command:

# yum install libX11-devel

yum search

The yum search command searches for a string in the package description, summary, and name fields. The following example searches for packages that have the string vim in these fields:

$ yum search vim
Loaded plugins: langpacks, refresh-packagekit
updates-testing/19/x86_64/pkgtags | 301 kB 00:00
=============================== N/S matched: vim ===============================
apvlv.x86_64 : PDF viewer which behaves like Vim
drupal6-media_vimeo.noarch : Vimeo Video Module for Drupal6
eclipse-vrapper.noarch : Vim-like editing in Eclipse
vim-X11.x86_64 : The VIM version of the vi editor for the X Window System
vim-clustershell.noarch : VIM files for ClusterShell
vim-command-t.x86_64 : An extremely fast, intuitive mechanism for opening files
: in VIM
vim-common.x86_64 : The common files needed by any version of the VIM editor
vim-enhanced.x86_64 : A version of the VIM editor which includes recent
: enhancements

yum list

The yum list command searches for a package name field that matches a string. Specify list available without an argument to list all packages that can be installed from the yum repositories. The following example searches for packages whose name fields match the string *emacs*:

$ yum list '*emacs*'
Loaded plugins: langpacks, presto, refresh-packagekit
Available Packages
clips-emacs.noarch 6.30.0-0.3.20090722svn.fc15 fedora
coq-emacs.i686 8.2pl1-1.fc12 fedora
crm114-emacs.i686 0-2.14.20100106.fc15 fedora
cvc3-emacs.noarch 2.2-3.fc15 fedora
cvc3-emacs-el.noarch 2.2-3.fc15 fedora
cvc3-xemacs.noarch 2.2-3.fc15 fedora
cvc3-xemacs-el.noarch 2.2-3.fc15 fedora
emacs.i686 1:23.2-17.fc15 fedora

Image yum: Keeps the System Up-to-Date

This section continues to describe yum. It covers updating installed packages, yum commands and groups, downloading RPM package files, configuring yum, and adding a repository specification. Refer to for more information.

Caution: Do not upgrade to a new release using yum

Using yum to upgrade a system from one release to another can be problematic and is not recommended. Visit for more information.

Image Updating Packages

In the following example, yum determines that two packages need to be updated and checks dependencies. By default, Fedora/RHEL notifies you when packages need to be updated. The yum update command, without additional parameters, updates all installed packages. It downloads package headers for installed packages, determines which packages need to be updated, prompts you to continue, and downloads and installs the updated packages.

# yum update
Loaded plugins: langpacks, refresh-packagekit
Resolving Dependencies
--> Running transaction check
---> Package gnome-terminal.x86_64 0:3.8.2-1.fc19 will be updated
---> Package gnome-terminal.x86_64 0:3.8.3-1.fc19 will be an update
---> Package libpcap.x86_64 14:1.3.0-4.fc19 will be updated
---> Package libpcap.x86_64 14:1.4.0-1.fc19 will be an update
--> Finished Dependency Resolution

Dependencies Resolved

Package Arch Version Repository Size
gnome-terminal x86_64 3.8.3-1.fc19 updates-testing 936 k
libpcap x86_64 14:1.4.0-1.fc19 updates-testing 131 k

Transaction Summary
Upgrade 2 Packages

Total download size: 1.0 M
Is this ok [y/d/N]: y
Downloading packages:
Delta RPMs reduced 1.0 M of updates to 223 k (79% saved)
(1/2): gnome-terminal-3.8.2-1.fc19_3.8.3-1.fc19.x86_64.drp | 177 kB 00:00
(2/2): libpcap-1.3.0-4.fc19_1.4.0-1.fc19.x86_64.drpm | 45 kB 00:00
Finishing delta rebuilds of 2 package(s) (1.0 M)
Total 183 kB/s | 223 kB 00:01
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
Updating : gnome-terminal-3.8.3-1.fc19.x86_64 1/4
Updating : 14:libpcap-1.4.0-1.fc19.x86_64 2/4
Cleanup : gnome-terminal-3.8.2-1.fc19.x86_64 3/4
Cleanup : 14:libpcap-1.3.0-4.fc19.x86_64 4/4
Verifying : 14:libpcap-1.4.0-1.fc19.x86_64 1/4
Verifying : gnome-terminal-3.8.3-1.fc19.x86_64 2/4
Verifying : gnome-terminal-3.8.2-1.fc19.x86_64 3/4
Verifying : 14:libpcap-1.3.0-4.fc19.x86_64 4/4

gnome-terminal.x86_64 0:3.8.3-1.fc19 libpcap.x86_64 14:1.4.0-1.fc19


You can update specific packages by specifying the names of the packages on the command line following the word update. The yum check-update command (next) lists packages that can be updated.

yum Commands

This section describes a few commonly used yum commands. The yum man page contains a complete list.


Reports on problems in the local RPM database.


Lists packages that are installed on the local system and have updates available in the yum repositories.

clean all

Removes header files that yum uses for resolving dependencies. Also removes cached packages. However, because yum removes packages after they have been installed, typically no cached packages exist (see keepcache on page 541).

clean metadata

Removes the files yum uses to determine remote package availability. Using this command forces yum to download all metadata the next time you run it.

group list

Lists yum groups (next).

group info group

Lists information about the yum group named group (next).

group install group

Installs the packages in the yum group named group (next).

info word

Displays information about packages in the yum repositories named word. Specify word as "*word*" to search for word anywhere in the package name.

list word

Lists packages in the yum repositories whose name is word. Specify word as "*word*" to search for word anywhere in the package name. See page 537 for an example.

list available

Lists all packages that can be installed from the yum repositories. Use a pipeline and grep to search for packages (e.g., yum list available | grep samba).


Same as whatprovides.

search word

Lists packages in the yum repositories that have word in their descriptions, summaries, or names. See page 537 for an example.

whatprovides word

Searches repositories and displays a list of packages that provides a feature or file that matches word. Specify word as "*word*" to search for word anywhere in a feature or filename. See page 537 for an example.

yum Package Groups

In addition to working with single packages, yum can work with groups of packages. The next example shows how to display a list of installed and available package groups:

$ yum group list
Loaded plugins: langpacks, refresh-packagekit
There is no installed groups file.
Available environment groups:
GNOME Desktop
KDE Plasma Workspaces
Xfce Desktop
Available Groups:
3D Printing
Administration Tools
Authoring and Publishing
Books and Guides
Window Managers

The command yum group info followed by the name of a package group displays information about the package group, including a description and a list of mandatory, default, and optional packages. A plus sign (+) before a package name indicates that the package will be installed with the package group; the absence of a plus sign indicates that you must install the package manually. The next example displays information about the Administration Tools package group. You must quote package group names that include SPACEs.

$ yum group info "Administration Tools"
Loaded plugins: langpacks, refresh-packagekit
There is no installed groups file.

Group: Administration Tools
Group-Id: admin-tools
Description: This group is a collection of graphical administration tools for the
system, such as for managing user accounts and configuring system hardware.
Default Packages:
Optional Packages:

To install a package group, give the command yum group install followed by the name of the package group.

Image Downloading RPM Package Files with yumdownloader

The yumdownloader utility (yum-utils package) locates and downloads—but does not install—RPM files. Because it does not install software, you do not need to work with root privileges to run it; you need only permission to write to the working directory.

The following example downloads the samba RPM file to the working directory:

$ yumdownloader samba
$ yumdownloader samba
Loaded plugins: langpacks, refresh-packagekit
samba-4.0.6-3.fc19.x86_64.rpm | 523 kB 00:00

Downloading source files

You can use yumdownloader with the ––source option to download RPM source package files. The yumdownloader utility automatically enables the necessary source repositories. See page 582 for an example that downloads in the working directory the RPM file for the latest version of the kernel source code for the release installed on the local system. Without the ––source option, yumdownloader would have downloaded an executable RPM file. See page 549 for information on installing this type of file.

Image yum.conf: Configures yum

You do not need to configure yum: As installed, it is ready to use. This section describes the yum configuration files for users who want to modify them. The primary configuration file, /etc/yum.conf, holds global settings. As distributed with Fedora/RHEL, files in the /etc/yum.repos.ddirectory define repositories. Following is the default yum.conf file:

$ cat /etc/yum.conf
# PUT YOUR REPOS HERE OR IN separate files named file.repo
# in /etc/yum.repos.d

The section labeled [main] defines global configuration options. The cachedir specifies the directory where yum stores downloaded packages, although with keepcache set to 0, yum does not store these packages after installing them. The amount of information logged is specified bydebuglevel, with a value of 10 producing the most information. The logfile specifies where yum keeps its log.

Setting exactarch to 1 causes yum to update packages only with packages of the same architecture, thereby preventing an i686 package from replacing an i386 package, for example. You can use retries to specify the number of times yum will try to retrieve a file before returning an error (the default is 6). Set this parameter to 0 to cause yum to continue trying forever.

Setting obsoletes to 1 causes yum to replace obsolete packages when updating packages; it has no effect when you install packages. When gpgcheck is set to 1, yum checks the GPG (page 1160) signatures on packages it installs. This check verifies the authenticity of the packages. Settingplugins to 1 enables yum plugins, which extend yum functionality. The metadata_expire parameter specifies the number of seconds (or minutes if the value is followed by m) that yum uses the metadata (about packages it downloads from the repository) before it downloads the information again. This parameter defaults to 90 minutes.

Although the balance of the yum configuration information, which specifies the yum repositories, can appear in the yum.conf file, Fedora/RHEL puts this information in /etc/yum.repos.d.


Some packages should only be installed; they should not be updated. The parameter installonlypkgs in /etc/yum.conf identifies these packages. Packages related to the kernel default to installonlypkgs: Typically you do not want to update a kernel; you want to install a new one and keep the old one around in case you need it. The installonly_limit parameter specifies the number of versions of installonlypkgs packages that yum keeps. See the yum.conf man page for more information.

Image yum Repositories

As noted in /etc/yum.conf, Fedora/RHEL stores information about each repository in a separate file in the /etc/yum.repos.d directory:

$ ls /etc/yum.repos.d
fedora.repo fedora-updates.repo fedora-updates-testing.repo

A parameter set in one of these files overrides the same parameter set in the [main] section (in yum.conf). Each of these files contains a header, such as [fedora], which provides a unique name for the repository. The name of the file is generally similar to the repository name, with the addition of a fedora- prefix and a .repo filename extension. Commonly used repositories include fedora (held in the fedora.repo file), which contains the packages present on the installation medium (stable packages); updates (held in the fedora-updates.repo file), which contains updated versions of the stable packages; and updates-testing (held in the fedora-updates-testing.repo file), which contains updates that are not ready for release. This last repository is not enabled; do not enable it unless you are testing unstable packages. Never enable the updates-testing repository on a production system.


Each *.repo file includes specifications for several related repositories, which are usually disabled. For example, the fedora.repo file holds [fedora-debuginfo] and [fedora-source] in addition to [fedora]. You cannot download source files using yum. Instead, useyumdownloader (page 540) for this task.

The next example shows part of the fedora.repo file that specifies the parameters for the fedora repository:

$ cat /etc/yum.repos.d/fedora.repo
name=Fedora $releasever - $basearch

Repository specification files

Each repository specification file contains the name of the repository enclosed in brackets ([]), a name, a failovermethod, a baseurl, and a mirrorlist. The name provides an informal name for the repository that yum displays. The failovermethod determines the order in which yum contacts an initial mirror site and additional mirror sites if the first one fails; priority selects the sites in the order in which they appear, while roundrobin selects sites randomly. The baseurl indicates the location of the main repository; it is commented out by default. The mirrorlist specifies the URL of a file that holds a list of baseurls, or mirrors of the main repository. Only baseurl or mirrorlist can be enabled at one time. These definitions use two variables: yum sets $basearch to the architecture of the system (e.g., i686) and $releasever to the version of the release (e.g., 15 for Fedora 15).

The repository described by the file is enabled (yum will use it) if enabled is set to 1 and is disabled if enabled is set to 0. The metadata_expire specifies how long yum considers metadata valid: After this amount of time, yum downloads fresh metadata. Default is six hours. As described earlier, gpgcheck determines whether yum checks GPG signatures on files it downloads. The gpgkey specifies the location of the GPG key. Refer to the yum.conf man page for more options.

Adding a repository

There are many repositories of software packages. For more information and a list of repositories, visit You can also search the Internet for fedora repositories. One of the most interesting of these sites is These sites provide repository specification files for their repositories. Add a repository to the local system by placing a repository specification file in the /etc/yum.repos.d directory but see the following security tip.

Security: Use repositories you trust

Be selective in which repositories you add to a system: When you add a repository, you are trusting the person who runs the repository not to put malicious software in packages you download. In addition, packages that are not supported by Fedora/RHEL can conflict with other packages and/or cause upgrades to fail.


The easiest way to download a BitTorrent file is to click the torrent file object in a Web browser or in the Nautilus File Browser; this action opens a GUI running a transmission BitTorrent client. This section describes how BitTorrent works and explains how to download a BitTorrent file from the command line.

The BitTorrent protocol implements a hybrid client/server and P2P (page 1265) file transfer mechanism. BitTorrent efficiently distributes large amounts of static data, such as the Fedora/RHEL installation ISO images. It can replace protocols such as anonymous FTP, where client authentication is not required. Each BitTorrent client that downloads a file provides additional bandwidth for uploading the file, thereby reducing the load on the initial source. In general, BitTorrent downloads proceed faster than FTP downloads. Unlike protocols such as FTP, BitTorrent groups multiple files into a single package: a BitTorrent file.

Tracker, peer, seed, and swarm

BitTorrent, like other P2P systems, does not use a dedicated server. Instead, the functions of a server are performed by the tracker, peers, and seeds. The tracker is a server that allows clients to communicate with each other. Each client—called a peer when it has downloaded part of the BitTorrent file and a seed after it has downloaded the entire BitTorrent file—acts as an additional source for the BitTorrent file. Peers and seeds are collectively called a swarm. As with a P2P network, a member of a swarm uploads to other clients the sections of the BitTorrent file it has already downloaded. There is nothing special about a seed: It can be removed at any time after the torrent is available for download from other seeds.

The torrent

The first step in downloading a BitTorrent file is to locate or acquire the torrent, a file with the filename extension of .torrent. A torrent contains pertinent information (metadata) about the BitTorrent file to be downloaded, such as its size and the location of the tracker. You can obtain a torrent by accessing its URI, or you can acquire it via the Web, an email attachment, or other means. The BitTorrent client can then connect to the tracker to learn the locations of other members of the swarm it can download the BitTorrent file from.


After you have downloaded a BitTorrent file (the local system has become a seed), it is good manners to allow the local BitTorrent client to continue to run so peers (clients that have not downloaded the entire BitTorrent file) can upload at least as much information as you have downloaded.


Use yum (page 534) to install the transmission-cli package. Put the following lines in the /etc/sysctl.conf file and reboot the system. Without these lines transmission-cli will work more slowly and display messages suggesting you add the lines to sysctl.conf.

$ cat /etc/sysctl.conf
net.core.rmem_max = 4194304
net.core.wmem_max = 1048576

transmission-cli: Downloading a BitTorrent File

The following example shows transmission-cli ( downloading a Fedora DVD ISO image. (Visit for a list of Fedora torrents you can download.) Depending on the speed of the Internet connection and the number of seeds, downloading a large BitTorrent file can take from hours to days. A torrent can download one or more files; the torrent specifies the filename(s) for the downloaded file(s) and, in the case of a multifile torrent, a directory to hold the files. The torrent in the example saves the BitTorrent files in the Fedora-19-x86_64-DVD directory in the working directory.

With a torrent in the working directory, enter a command such as the following, substituting the name of the torrent you want to use for the Fedora torrent:

$ transmission-cli Fedora-19-x86_64-DVD.torrent
[15:20:29.914] Transmission 2.77 (14031) started
[15:20:29.915] RPC Server: Adding address to whitelist:
[15:20:29.916] DHT: Generating new id
[15:20:30.021] Saved "/home/sam/.config/transmission/torrents/Fedora-19-x86_64-DVD.687077ec95f03111.torrent"
[15:20:30.021] Fedora-19-x86_64-DVD: Queued for verification
[15:20:30.022] Fedora-19-x86_64-DVD: Verifying torrent
[15:20:30.248] Port Forwarding (NAT-PMP): initnatpmp succeeded (0)
[15:20:30.248] Port Forwarding (NAT-PMP): sendpublicaddressrequest succeeded (2) Progress: 0.0%, dl
from 0 of 0 peers (0 kB/s), ul to 0 (0 kB/s) [None]
[15:20:38.258] Port Forwarding: State changed from "Not forwarded" to "Starting"
Progress: 0.0%, dl from 0 of 14 peers (0 kB/s), ul to 0 (0 kB/s) [None]
[15:20:49.001] Fedora-19-x86_64-DVD: Starting IPv4 DHT announce (poor, 9 nodes)
Progress: 1.1%, dl from 27 of 36 peers (2.45 MB/s), ul to 1 (123 kB/s) [0.03]
[15:21:23.157] DHT: Attempting bootstrap from
[15:22:38.250] Port Forwarding: State changed from "Starting" to "???"
Progress: 14.1%, dl from 28 of 35 peers (2.10 MB/s), ul to 2 (40 kB/s) [0.02]

The transmission-cli utility displays messages about what it is doing. The lines that begin with Progress show how much of the BitTorrent file transmission-cli has downloaded, the number of peers and the total download speed, and the number of clients it is uploading to and that speed.

You can abort the download by pressing CONTROL-C. The download will automatically resume from where it left off when you download the same torrent to the same location again.

Caution: Make sure you have enough room to download the torrent

Some torrents are huge. Make sure the partition you are working in has enough room to hold the BitTorrent file you are downloading.

See the transmission-cli man page for a list of options. One of the most useful options is –u (––uplimit), which limits how much bandwidth in kilobytes per second the swarm can use while downloading the torrent from the local system (upstream bandwidth). Use –U (––no-uplimit) to place no limit on the bandwidth the swarm can use. The following command prevents BitTorrent from using more than 100 kilobytes per second of upstream bandwidth:

$ transmission-cli -u 100 Fedora-xxxx.torrent

BitTorrent usually allows higher download rates for members of the swarm that upload more data, so it is to your advantage to increase this value if you have spare bandwidth. You need to leave enough free upstream bandwidth for the acknowledgment packets from your download to get through or the download will be very slow.

The name of the file or directory BitTorrent saves a file or files in is specified by the torrent. You can specify a different file or directory name by using the ––save_as option. The transmission-show utility displays the name the BitTorrent file will be saved as, the size of the file, the name of the torrent (metainfo file), and other information:

$ transmission-show Fedora-19-x86_64-DVD.torrent
Name: Fedora-19-x86_64-DVD
File: Fedora-19-x86_64-DVD.torrent


Name: Fedora-19-x86_64-DVD
Hash: 687077ec95f03111a0f7326e42ba518bb7161c29
Created by:
Created on: Mon May 27 20:08:14 2013
Piece Count: 17113
Piece Size: 256.0 KiB
Total Size: 4.49 GB
Privacy: Public torrent


Tier #1


Fedora-19-x86_64-DVD/Fedora-19-x86_64-CHECKSUM (1.14 kB)
Fedora-19-x86_64-DVD/Fedora-19-x86_64-DVD.iso (4.49 GB)

Image RPM: The RPM Package Manager

RPM (RPM Package Manager; works only with software packages built for processing by RPM; it can download, install, uninstall, upgrade, query, and verify RPM packages. The files that hold these packages have a filename extension of .rpm. RPM uses the local RPM installation database to track the locations where software packages are installed, the versions of the installed packages, and the dependencies between the packages. RPM uses the Berkeley Database (Berkeley DB or BDB) and stores the database files in /var/lib/rpm. RPM forms the basis for yum: yum finds packages, downloads them from repositories, and then calls RPM to install/upgrade/remove the packages.

Source RPM packages are frequently found in a directory named SRPMS (source RPMs), whereas binary RPM packages usually reside in Packages. When you download binary packages, make sure they are relevant to the local operating system (both distribution and release—for example, Fedora 15).1 They should also be compiled for the appropriate processor architecture:

1. Many RPM packages run on releases and even distributions other than the ones they were compiled for. However, installing packages intended for other distributions can create problems.

Processor architectures

i386 covers all Intel- and most AMD-based systems; the N and Z Series Atom processors are also based on this architecture.

i586 covers Pentium-class or higher processors.

i686 refers to Pentium II or better and includes MMX extensions.

S390x is for IBM System/390.

ia64 is for the Intel 64-bit Itanium (not compatible with x86_64)

alpha is for the DEC/Compaq Alpha chip.

ppc and ppc64 denotes the Power PC 32- and 64-bit processors.

x86_64 is for Intel and AMD 64-bit processors (not Itanium); the 230 and 330 Series Atom processors are also based on this architecture.

sparc covers the Sun Sparc processor.


The name of the rpm file contains almost all the necessary information. Packages marked noarch (“no architecture”) contain resources, such as images or scripts, that are run by an interpreter. You can install and run noarch packages on any architecture.


See page 540 for instructions on using yumdownloader to download RPM package files.

Image Querying Packages and Files

The following rpm command displays a list of one-line summaries of all packages installed on the system:

$ rpm -qa

The –q option queries the package database; the –a option specifies all packages. Without –a, –q takes the name of a package as an argument and displays information about that package only. For instance, rpm –q ypserv tells you whether the ypserv package is installed and, if so, which version is installed. Use the –ql options to list the files in a package.

$ rpm -q ypserv
package ypserv is not installed

$ rpm -ql logrotate

With the –qi options, rpm displays information about a package:

$ rpm -qi logrotate
Name : logrotate
Version : 3.8.4
Release : 1.fc19
Architecture: x86_64
Install Date: Tue 04 Jun 2013 07:29:46 PM PDT
Group : System Environment/Base
Size : 97523
License : GPL+
Signature : RSA/SHA256, Tue 30 Apr 2013 08:32:12 AM PDT, Key ID 07477e65fb4b18e6
Source RPM : logrotate-3.8.4-1.fc19.src.rpm
Build Date : Tue 30 Apr 2013 02:16:03 AM PDT
Build Host :
Relocations : (not relocatable)
Packager : Fedora Project
Vendor : Fedora Project
Summary : Rotates, compresses, removes and mails system log files
Description :
The logrotate utility is designed to simplify the administration of
log files on a system which generates a lot of log files. Logrotate
allows for the automatic rotation compression, removal and mailing of
log files. Logrotate can be set to handle a log file daily, weekly,
monthly or when the log file gets to a certain size. Normally,
logrotate runs as a daily cron job.

Install the logrotate package if you need a utility to deal with the
log files on your system.

You can use the –qf options to determine which package a file belongs to; it works with installed packages only. Use the yum whatprovides command (page 537) to search repositories for the same information. The following command shows that more is part of the util-linux package:

$ rpm -qf /bin/more

Include the –p option with other options to query an uninstalled RPM package file:

$ $ ls ypser**

$ rpm -qip ypserv-2.31-2.fc19.x86_64.rpm
Name : ypserv
Version : 2.31
Release : 2.fc19

Image Installing, Upgrading, and Removing Packages

Although it is frequently easier to use yum or gpk-application, you can use rpm to download, install, upgrade, or remove a package. Run rpm with root privileges; although you can run rpm as a nonprivileged user, you will not have permission to write to the necessary directories during an install or uninstall, and the procedure will fail. During a query, you do not need to work with root privileges, so you can and should work as a nonprivileged user. Give the –U (upgrade) option, followed by the name of the file that contains the RPM version of the package you want to install. The –U option upgrades existing packages and installs new packages (as though you had used the –i option). For kernels, use –i (not –U) to leave the old kernel intact when you install a new kernel. Add the –v (verbose) option to display more information about what is happening and the –h(or ––hash) option to display hash marks as the package is unpacked and installed.

Installing a package

For example, the following command installs the samba package on the local system:

# ls samba**

# rpm -Uvh samba-4.0.6-3.fc19.x86_64.rpm
Preparing... ################################# [100%]
Updating / installing...
1:samba-2:4.0.6-3.fc19 ################################# [100%]

When you install a package, the rpm file must be in the working directory, or you must use a pathname that points to the rpm file. If you specify an FTP or HTTP URL, rpm will download the package before installing it (but it will not download or install dependencies):

# rpm -Uvh

Removing a package

The following command removes the samba package. You can give the command from any directory:

# rpm -e samba
error: Failed dependencies:
samba is needed by (installed) system-config-samba-1.2.100-1.fc19.noarch

When you run this command, rpm reports that another package, system-config-samba, is dependent on the samba package. To remove the samba package, you have two choices: You can ignore the dependency by including the rpm ––nodeps option or you can remove the dependent package and then remove the samba package.

# rpm -e system-config-samba
# rpm -e samba

If you remove the samba package without removing the package that is dependent on it, the utilities within the dependent package will not work. In the preceding example, the system-config-samba utility will not work.

When you use rpm to remove a package, rpm queries the package database to find the information it needs to uninstall the package and removes links, unloads device drivers, and stops daemons as necessary. Refer to the rpm man page for more rpm options.

Installing a Linux Kernel Binary

The following steps install a Linux kernel binary from an RPM package. If you simply want to install the latest kernel for the local system, give the command yum install kernel instead. Refer to Chapter 14 when you want to configure and rebuild a kernel from source files, rather than installing a new, prebuilt kernel binary.

1. Run rpm with the –i option to install the new kernel. Do not use the –U option: You are installing a new kernel that has a different name than the old kernel; you are not upgrading the existing kernel.

2. Make sure the new kernel works before you remove the old kernel. To verify the new kernel works, reboot the system using the new kernel. You might want to wait a while before removing the old kernel to make sure that no problems arise with the new one.

3. When you are satisfied with the new kernel, remove the old kernel using rpm with the –e option; you must specify the kernel version number. If necessary, you can manually remove an old kernel by removing files whose names contain the release number from /boot or / (root). Remove information about the old kernel from grub.conf (page 590). Removing the kernel manually is not recommended because it is too easy to miss a file and because it does not remove the kernel from the RPM database.

Installing Non-rpm Software

Most software that is not in RPM format comes with detailed instructions on how to configure, build (if necessary), and install it. Some binary distributions (those containing prebuilt executables that run on Fedora/RHEL) require you to unpack the software from the root directory (i.e., you must cd to / before unpacking it).

The /opt and /usr/local Directories

Some newer application packages include scripts that install themselves automatically into a directory hierarchy under /opt, with files in a /opt subdirectory that is named after the package and executables in /opt/bin or /opt/package/bin.

Other software packages allow you to choose where you unpack them. Because many different people develop software for Linux, there is no consistent method for installing it. As you acquire software, install it on the local system in as consistent and predictable a manner as possible. The standard Linux file structure has a directory hierarchy under /usr/local for binaries (/usr/local/bin), manual pages (/usr/local/man), and so forth. Because many GNU build tools search the /usr/local hierarchy by default and could find the wrong version of a utility if you install developer tools there, putting these tools in /opt is a good idea.

To prevent confusion later and to avoid overwriting or losing the software when you install standard software upgrades, avoid installing nonstandard software in standard system directories (such as /usr/bin). On a multiuser system, make sure users know where to find the local software and advise them whenever you install, change, or remove local tools.

GNU Configure and Build System

The GNU Configure and Build System makes it easy to build a program that is distributed as source code (see This process requires a shell, make (make package), and gcc (the GNU C compiler; gcc package). You do not need to work with root privileges except to install the program.

The following example assumes you have downloaded the GNU which program (; page 255) to the working directory. First unpack and decompress the file and cd to the new directory:

$ tar -xvzf which-2.20.tar.gz

$ cd which-2.20

After reading the README and INSTALL files and installing the gcc package, run the configure script, which gathers information about the local system and generates the Makefile file:

$ ./configure
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether to enable maintainer-specific portions of Makefiles... no
config.status: creating Makefile
config.status: creating maintMakefile
config.status: creating tilde/Makefile
config.status: creating config.h
config.status: executing depfiles commands

Refer to the configure info page, specifically the ––prefix option, which causes the install phase to place the software in a directory other than /usr/local. For package-specific options enter the command configure ––help. Next, run make:

$ make
make all-recursive
make[1]: Entering directory `/home/sam/which-2.20'
Making all in tilde
make[2]: Entering directory `/home/sam/which-2.20/tilde'
source='tilde.c' object='tilde.o' libtool=no \
DEPDIR=.deps depmode=pch /bin/bash ../depcomp \
gcc -DHAVE_CONFIG_H -I. -I.. -g -O2 -c tilde.c
source='shell.c' object='shell.o' libtool=no \
DEPDIR=.deps depmode=pch /bin/bash ../depcomp \
gcc -DHAVE_CONFIG_H -I. -I.. -g -O2 -c shell.c
rm -f libtilde.a
ar cru libtilde.a tilde.o shell.o
source='which.c' object='which.o' libtool=no \
DEPDIR=.deps depmode=pch /bin/bash ./depcomp \
gcc -DHAVE_CONFIG_H -I. -g -O2 -c which.c
gcc -g -O2 -o which getopt.o getopt1.o bash.o which.o ./tilde/libtilde.a
make[2]: Leaving directory `/home/sam/which-2.20'
make[1]: Leaving directory `/home/sam/which-2.20'

$ ls which

After make finishes, the which executable is in the working directory. Some packages place the executable in a subdirectory. If you want to install it, give the following command while running with root privileges. By default this command installs which in /usr/local/bin so it is known to be the local version of which.

$ su -c "make install"
make install-recursive
make[1]: Entering directory `/home/sam/which-2.20'
Making install in tilde
make[2]: Entering directory `/home/sam/which-2.20/tilde'
make[3]: Entering directory `/home/sam/which-2.20/tilde'

You can complete the entire task with the following command line:

$ su -c "./configure && make && make install"

The Boolean AND operator (&&) allows the execution of a subsequent command only if the previous step returned a successful exit status.

Keeping Software Up-to-Date

See page 533 for a discussion of why it is important to keep software up-to-date.


A bug is an unwanted and unintended program property, especially one that causes the program to malfunction (definition courtesy of Bugs have been around forever, in many types of systems, machinery, thinking, and so on. All sophisticated software contains bugs. Bugs in system software or application packages can cause the system to crash or programs not to run correctly. Security holes (a type of bug) can compromise the security of the system, allowing malicious users to read and write files, send mail to your contacts in your name, or destroy all data on the system, rendering the system useless.

Even if the engineers fixed all the bugs, there would still be feature requests as long as anyone used the software. Bugs, feature requests, and security holes are here to stay. Thus they must be properly tracked if developers are to fix the most dangerous/ important bugs first, users are to research and report bugs in a logical manner, and administrators are to apply the developers’ fixes quickly and easily.

Bug tracking

Early on, Netscape used an internal bug-tracking system named BugSplat. Later, after Netscape created Mozilla ( as an open-source browser project, the Mozilla team decided that it needed its own bug-tracking system. Netscape’s IS department wrote a very short-lived version of Bugzilla. Terry Weissman, who had been maintaining BugSplat, then wrote a new open-source version of Bugzilla in Tcl, rewriting it in Perl a couple of months later.

Bugzilla belongs to a class of programs formally known as defect-tracking systems, of which Bugzilla is preeminent. Almost all Linux developers use this tool to track problems and enhancement requests for their software. Fedora/RHEL uses Bugzilla to track bugs and bug fixes for its Linux distributions. To use Bugzilla, visit


As the Linux community, including Red Hat and the Fedora Project, finds and fixes operating system and software package bugs, including security holes, Red Hat and the Fedora Project generate RPM files (page 546) that contain the code that fixes the problems. When you upgrade a system software package, rpm renames modified configuration files with a .rpmsave extension. You must manually merge the changes you made to the original files into the new files. The easiest way to learn about, obtain, and install updates is to use yum.

The Fedora Announce List ( holds information about Fedora updates. Under Fedora/RHEL, packagkitd via gpk-update-icon notifies you when updates are available.

curl: Downloads Files Noninteractively

The curl utility is a noninteractive, command-line utility that retrieves files from the Web using HTTP, HTTPS, or FTP. In the following example, curl downloads the Fedora Project home page, named index.html, to a file in the working directory with the same name.

$ curl > index.html
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 23076 100 23076 0 0 71837 0 --:--:-- --:--:-- --:--:-- 72112

The curl ––continue (–c) option with an argument of automatically continues an interrupted download. For example, if you decide to stop a download so you can run it in the background, you can continue it from where it left off with this option.

Chapter Summary

As a system administrator, you need to keep applications and system software current. Of the many reasons to keep the software on a system up-to-date, one of the most important is system security.

A PMS (package management system) is a set of utilities that allow you to install, upgrade, remove, and search software packages easily and in a consistent manner. It is based on a local database that holds information about each installed package, including its dependencies and version information. The development of the RPM PMS has made the process of adding and removing the software packages quite easy. You can use yum, a front end to RPM, to install and upgrade software packages. The yum utility is installed by default and is easy to configure and use.

In addition, you can use the rpm utility to install, uninstall, upgrade, query, and verify RPM packages. For packages distributed as source code, the GNU Configure and Build System makes it easy to build executable files.

BitTorrent is a handy tool for downloading large static data files such as the Fedora installation ISO images. BitTorrent can replace protocols such as anonymous FTP, where client authentication is not required.


1. Which command installs the samba package? Which installs the Web Server package group?

2. Which command would you give to update all installed packages using yum?

3. Why would you build a package from its source code when a (binary) rpm file is available?

4. Suggest two advantages that rpm files have over source distributions.

Advanced Exercises

5. When you compile a package yourself, rather than from an rpm file, which directory hierarchy should you put it in?

6. What are some steps you should take before performing an upgrade on a mission-critical server? When should you use rpm –i instead of rpm –U?