Product SiteDocumentation Site

Red Hat Enterprise Linux 6

Deployment Guide

Deployment, Configuration and Administration of Red Hat Enterprise Linux 6

Edition 1

Douglas Silas

Red Hat, Inc. Engineering Content Services

Martin Prpič

Red Hat, Inc. Engineering Content Services

Florian Nadge

Red Hat, Inc. Engineering Content Services

Jaromír Hradílek

Red Hat, Inc. Engineering Content Services

John Ha

Red Hat, Inc Engineering Content Services

David O'Brien

Red Hat, Inc Engineering Content Services

Michael Hideo

Red Hat, Inc Engineering Content Services

Don Domingo

Red Hat, Inc Engineering Content Services

Legal Notice

Copyright © 2010 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, JBoss, MetaMatrix, Fedora, the Infinity Logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
All other trademarks are the property of their respective owners.


1801 Varsity Drive
 RaleighNC 27606-2072 USA
 Phone: +1 919 754 3700
 Phone: 888 733 4281
 Fax: +1 919 754 3701

Abstract
The Deployment Guide documents relevant information regarding the deployment, configuration and administration of Red Hat Enterprise Linux 6.

Preface
1. Document Conventions
1.1. Typographic Conventions
1.2. Pull-quote Conventions
1.3. Notes and Warnings
2. We Need Feedback!
2.1. Technical Review Requests
3. Acknowledgements
Introduction
I. Package Management
1. Yum
1.1. Checking For and Updating Packages
1.1.1. Checking For Updates
1.1.2. Updating Packages
1.1.3. Updating Security-Related Packages
1.1.4. Preserving Configuration File Changes
1.2. Packages and Package Groups
1.2.1. Searching, Listing and Displaying Package Information
1.2.2. Installing
1.2.3. Removing
1.3. Configuring Yum and Yum Repositories
1.3.1. Setting [main] Options
1.3.2. Setting [repository] Options
1.3.3. Using Yum Variables
1.3.4. Creating a Yum Repository
1.4. Yum Plugins
1.4.1. Enabling, Configuring and Disabling Yum Plugins
1.4.2. Installing More Yum Plugins
1.4.3. Plugin Descriptions
1.5. Additional Resources
2. PackageKit
2.1. Updating Packages with Software Update
2.2. Using Add/Remove Software
2.2.1. Refreshing Software Sources (Yum Repositories)
2.2.2. Finding Packages with Filters
2.2.3. Installing and Removing Packages (and Dependencies)
2.2.4. Installing and Removing Package Groups
2.2.5. Viewing the Transaction Log
2.3. PackageKit Architecture
2.4. Additional Resources
3. RPM
3.1. RPM Design Goals
3.2. Using RPM
3.2.1. Finding RPM Packages
3.2.2. Installing and Upgrading
3.2.3. Configuration File Changes
3.2.4. Uninstalling
3.2.5. Freshening
3.2.6. Querying
3.2.7. Verifying
3.3. Checking a Package's Signature
3.3.1. Importing Keys
3.3.2. Verifying Signature of Packages
3.4. Practical and Common Examples of RPM Usage
3.5. Additional Resources
3.5.1. Installed Documentation
3.5.2. Useful Websites
3.5.3. Related Books
II. Network-Related Configuration
4. Network Interfaces
4.1. Network Configuration Files
4.2. Interface Configuration Files
4.2.1. Ethernet Interfaces
4.2.2. Channel Bonding Interfaces
4.2.3. Alias and Clone Files
4.2.4. Dialup Interfaces
4.2.5. Other Interfaces
4.3. Interface Control Scripts
4.4. Configuring Static Routes
4.5. Network Function Files
4.6. Additional Resources
4.6.1. Installed Documentation
5. Network Configuration
5.1. The NetworkManager Daemon
5.2. Interacting with NetworkManager
5.2.1. Connecting to a Network
5.2.2. Configuring New and Editing Existing Connections
5.2.3. Connecting to a Network Automatically
5.2.4. User and System Connections
5.3. Configuring Connection Settings
5.3.1. Configuring IPv4 Settings
6. Dynamic Host Configuration Protocol (DHCP)
6.1. Why Use DHCP?
6.2. Configuring a DHCP Server
6.2.1. Configuration File
6.2.2. Lease Database
6.2.3. Starting and Stopping the Server
6.2.4. DHCP Relay Agent
6.3. Configuring a DHCP Client
6.4. Configuring a Multihomed DHCP Server
6.4.1. Host Configuration
6.5. DHCP for IPv6 (DHCPv6)
6.6. Additional Resources
6.6.1. Installed Documentation
7. Controlling Access to Services
7.1. Configuring the Default Runlevel
7.2. Configuring the Services
7.2.1. Using the Service Configuration Utility
7.2.2. Using the ntsysv Utility
7.2.3. Using the chkconfig Utility
7.3. Running the Services
7.3.1. Using the service Utility
7.4. Additional Resources
7.4.1. Installed Documentation
7.4.2. Related Books
8. Authentication Configuration
8.1. The Authentication Configuration Tool
8.1.1. Identity & Authentication
8.1.2. Advanced Options
8.1.3. Command Line Version
8.2. The System Security Services Daemon (SSSD)
8.2.1. What is SSSD?
8.2.2. SSSD Features
8.2.3. Setting Up SSSD
8.2.4. Configuring Services
8.2.5. Configuring Domains
8.2.6. Setting Up Kerberos Authentication
8.2.7. Troubleshooting
8.2.8. SSSD Configuration File Format
9. OpenSSH
9.1. The SSH Protocol
9.1.1. Why Use SSH?
9.1.2. Main Features
9.1.3. Protocol Versions
9.1.4. Event Sequence of an SSH Connection
9.2. An OpenSSH Configuration
9.2.1. Configuration Files
9.2.2. Starting an OpenSSH Server
9.2.3. Requiring SSH for Remote Connections
9.2.4. Using a Key-Based Authentication
9.3. OpenSSH Clients
9.3.1. Using the ssh Utility
9.3.2. Using the scp Utility
9.3.3. Using the sftp Utility
9.4. More Than a Secure Shell
9.4.1. X11 Forwarding
9.4.2. Port Forwarding
9.5. Additional Resources
9.5.1. Installed Documentation
9.5.2. Useful Websites
10. The BIND DNS Server
10.1. Introduction to DNS
10.1.1. Nameserver Zones
10.1.2. Nameserver Types
10.1.3. BIND as a Nameserver
10.2. Configuring the named Service
10.2.1. Common Statement Types
10.2.2. Other Statement Types
10.2.3. Comment Tags
10.3. Editing Zone Files
10.3.1. Common Directives
10.3.2. Common Resource Records
10.3.3. Comment Tags
10.3.4. Example Usage
10.4. Using the rndc Utility
10.4.1. Configuring the Utility
10.4.2. Checking the Service Status
10.4.3. Reloading the Configuration and Zones
10.4.4. Updating Zone Keys
10.4.5. Enabling the DNSSEC Validation
10.4.6. Enabling the Query Logging
10.5. Using the dig Utility
10.5.1. Looking Up a Nameserver
10.5.2. Looking Up an IP Address
10.5.3. Looking Up a Hostname
10.6. Advanced Features of BIND
10.6.1. Multiple Views
10.6.2. Incremental Zone Transfers (IXFR)
10.6.3. Transaction SIGnatures (TSIG)
10.6.4. DNS Security Extensions (DNSSEC)
10.6.5. Internet Protocol version 6 (IPv6)
10.7. Common Mistakes to Avoid
10.8. Additional Resources
10.8.1. Installed Documentation
10.8.2. Useful Websites
10.8.3. Related Books
11. The Apache HTTP Server
11.1. The Apache HTTP Server 2.2
11.1.1. New Features
11.1.2. Notable Changes
11.1.3. Updating the Configuration
11.2. Running the httpd Service
11.2.1. Starting the Service
11.2.2. Stopping the Service
11.2.3. Restarting the Service
11.2.4. Checking the Service Status
11.3. Editing the Configuration Files
11.3.1. Common httpd.conf Directives
11.3.2. Common ssl.conf Directives
11.3.3. Common Multi-Processing Module Directives
11.4. Working with Modules
11.4.1. Loading a Module
11.4.2. Writing a Module
11.5. Setting Up Virtual Hosts
11.6. Setting Up an SSL Server
11.6.1. An Overview of Certificates and Security
11.6.2. Enabling the mod_ssl Module
11.6.3. Using an Existing Key and Certificate
11.6.4. Generating a New Key and Certificate
11.7. Additional Resources
11.7.1. Installed Documentation
11.7.2. Useful Websites
12. Email
12.1. Email Protocols
12.1.1. Mail Transport Protocols
12.1.2. Mail Access Protocols
12.2. Email Program Classifications
12.2.1. Mail Transport Agent
12.2.2. Mail Delivery Agent
12.2.3. Mail User Agent
12.3. Mail Transport Agents
12.3.1. Postfix
12.3.2. Sendmail
12.3.3. Fetchmail
12.3.4. Mail Transport Agent (MTA) Configuration
12.4. Mail Delivery Agents
12.4.1. Procmail Configuration
12.4.2. Procmail Recipes
12.5. Mail User Agents
12.5.1. Securing Communication
12.6. Additional Resources
12.6.1. Installed Documentation
12.6.2. Useful Websites
12.6.3. Related Books
III. System Configuration
13. Date and Time Configuration
13.1. Date/Time Properties Tool
13.1.1. Date and Time Properties
13.1.2. Network Time Protocol Properties
13.1.3. Time Zone Properties
13.2. Command Line Configuration
13.2.1. Date and Time Setup
13.2.2. Network Time Protocol Setup
14. Keyboard Configuration
14.1. Changing the Keyboard Layout
14.2. Adding the Keyboard Layout Indicator
14.3. Setting Up a Typing Break
15. Users and Groups
15.1. User and Group Configuration
15.1.1. Adding a New User
15.1.2. Adding a New Group
15.1.3. Modifying Group Properties
15.2. User and Group Management Tools
15.2.1. Command Line Configuration
15.2.2. Explaining the Process
15.3. Standard Users
15.4. Standard Groups
15.5. User Private Groups
15.5.1. Group Directories
15.6. Shadow Passwords
15.7. Additional Resources
15.7.1. Installed Documentation
16. Automated Tasks
16.1. Cron and Anacron
16.1.1. Starting and Stopping the Service
16.1.2. Configuring Anacron Jobs
16.1.3. Configuring Cron Jobs
16.1.4. Controlling Access to Cron
16.1.5. Black/White Listing of Cron Jobs
16.2. At and Batch
16.2.1. Configuring At Jobs
16.2.2. Configuring Batch Jobs
16.2.3. Viewing Pending Jobs
16.2.4. Additional Command Line Options
16.2.5. Controlling Access to At and Batch
16.2.6. Starting and Stopping the Service
16.3. Additional Resources
16.3.1. Installed Documentation
17. Log Files
17.1. Configuring rsyslog
17.1.1. Modules
17.1.2. Global Directives
17.1.3. Rules
17.1.4. Templates
17.1.5. Filter Conditions
17.1.6. Output Channels
17.2. rsyslog Performance
17.3. Locating Log Files
17.3.1. Configuring logrotate
17.4. Viewing Log Files
17.5. Adding a Log File
17.6. Monitoring Log Files
17.7. Additional Resources
17.7.1. Installed Documentation
17.7.2. Useful Websites
18. The sysconfig Directory
18.1. Files in the /etc/sysconfig/ Directory
18.1.1. /etc/sysconfig/arpwatch
18.1.2. /etc/sysconfig/authconfig
18.1.3. /etc/sysconfig/autofs
18.1.4. /etc/sysconfig/clock
18.1.5. /etc/sysconfig/dhcpd
18.1.6. /etc/sysconfig/firstboot
18.1.7. /etc/sysconfig/i18n
18.1.8. /etc/sysconfig/init
18.1.9. /etc/sysconfig/ip6tables-config
18.1.10. /etc/sysconfig/keyboard
18.1.11. /etc/sysconfig/ldap
18.1.12. /etc/sysconfig/named
18.1.13. /etc/sysconfig/network
18.1.14. /etc/sysconfig/ntpd
18.1.15. /etc/sysconfig/quagga
18.1.16. /etc/sysconfig/radvd
18.1.17. /etc/sysconfig/samba
18.1.18. /etc/sysconfig/selinux
18.1.19. /etc/sysconfig/sendmail
18.1.20. /etc/sysconfig/spamassassin
18.1.21. /etc/sysconfig/squid
18.1.22. /etc/sysconfig/system-config-users
18.1.23. /etc/sysconfig/vncservers
18.1.24. /etc/sysconfig/xinetd
18.2. Directories in the /etc/sysconfig/ Directory
18.3. Additional Resources
18.3.1. Installed Documentation
19. The proc File System
19.1. A Virtual File System
19.1.1. Viewing Virtual Files
19.1.2. Changing Virtual Files
19.2. Top-level Files within the proc File System
19.2.1. /proc/buddyinfo
19.2.2. /proc/cmdline
19.2.3. /proc/cpuinfo
19.2.4. /proc/crypto
19.2.5. /proc/devices
19.2.6. /proc/dma
19.2.7. /proc/execdomains
19.2.8. /proc/fb
19.2.9. /proc/filesystems
19.2.10. /proc/interrupts
19.2.11. /proc/iomem
19.2.12. /proc/ioports
19.2.13. /proc/kcore
19.2.14. /proc/kmsg
19.2.15. /proc/loadavg
19.2.16. /proc/locks
19.2.17. /proc/mdstat
19.2.18. /proc/meminfo
19.2.19. /proc/misc
19.2.20. /proc/modules
19.2.21. /proc/mounts
19.2.22. /proc/mtrr
19.2.23. /proc/partitions
19.2.24. /proc/slabinfo
19.2.25. /proc/stat
19.2.26. /proc/swaps
19.2.27. /proc/sysrq-trigger
19.2.28. /proc/uptime
19.2.29. /proc/version
19.3. Directories within /proc/
19.3.1. Process Directories
19.3.2. /proc/bus/
19.3.3. /proc/bus/pci
19.3.4. /proc/driver/
19.3.5. /proc/fs
19.3.6. /proc/irq/
19.3.7. /proc/net/
19.3.8. /proc/scsi/
19.3.9. /proc/sys/
19.3.10. /proc/sysvipc/
19.3.11. /proc/tty/
19.3.12. /proc/PID/
19.4. Using the sysctl Command
19.5. References
IV. System Monitoring
20. Gathering System Information
20.1. System Processes
20.2. Memory Usage
20.3. File Systems
20.4. Hardware
20.5. Additional Resources
20.5.1. Installed Documentation
21. ABRT
21.1. Overview
21.2. Installing and Running ABRT
21.3. ABRT Plugins
21.3.1. Analyzer Plugins
21.3.2. Reporter Plugins
21.3.3. Plugin Configuration in the GUI
21.4. Generating Backtraces
21.4.1. Troubleshooting Backtrace Generation
21.5. Using the Command Line Interface
21.5.1. Viewing Crashes
21.5.2. Reporting Crashes
21.5.3. Deleting Crashes
21.6. Configuring ABRT
21.7. Configuring Centralized Crash Collection
21.7.1. Testing ABRT's Crash Detection
21.7.2. Testing the Upload Method
V. Kernel, Module and Driver Configuration
22. Working with Kernel Modules
22.1. Listing Currently-Loaded Modules
22.2. Displaying Information About a Module
22.3. Loading a Module
22.4. Unloading a Module
22.5. Setting Module Parameters
22.6. Persistent Module Loading
22.7. Specific Kernel Module Capabilities
22.7.1. Using Multiple Ethernet Cards
22.7.2. Using Channel Bonding
22.8. Additional Resources
23. Manually Upgrading the Kernel
23.1. Overview of Kernel Packages
23.2. Preparing to Upgrade
23.3. Downloading the Upgraded Kernel
23.4. Performing the Upgrade
23.5. Verifying the Initial RAM Disk Image
23.6. Verifying the Boot Loader
23.6.1. Configuring the GRUB Boot Loader
23.6.2. Configuring the OS/400® Boot Loader
23.6.3. Configuring the YABOOT Boot Loader
24. The kdump Crash Recovery Service
24.1. Configuring the kdump Service
24.1.1. Configuring the kdump at First Boot
24.1.2. Using the Kernel Dump Configuration Utility
24.1.3. Configuring kdump on the Command Line
24.1.4. Testing the Configuration
24.2. Analyzing the Core Dump
24.2.1. Displaying the Message Buffer
24.2.2. Displaying a Backtrace
24.2.3. Displaying a Process Status
24.2.4. Displaying Virtual Memory Information
24.2.5. Displaying Open Files
24.3. Additional Resources
24.3.1. Installed Documentation
24.3.2. Useful Websites
A. Revision History
Index

Preface

1. Document Conventions

This manual uses several conventions to highlight certain words and phrases and draw attention to specific pieces of information.
In PDF and paper editions, this manual uses typefaces drawn from the Liberation Fonts set. The Liberation Fonts set is also used in HTML editions if the set is installed on your system. If not, alternative but equivalent typefaces are displayed. Note: Red Hat Enterprise Linux 5 and later includes the Liberation Fonts set by default.

1.1. Typographic Conventions

Four typographic conventions are used to call attention to specific words and phrases. These conventions, and the circumstances they apply to, are as follows.
Mono-spaced Bold
Used to highlight system input, including shell commands, file names and paths. Also used to highlight keycaps and key combinations. For example:
To see the contents of the file my_next_bestselling_novel in your current working directory, enter the cat my_next_bestselling_novel command at the shell prompt and press Enter to execute the command.
The above includes a file name, a shell command and a keycap, all presented in mono-spaced bold and all distinguishable thanks to context.
Key combinations can be distinguished from keycaps by the hyphen connecting each part of a key combination. For example:
Press Enter to execute the command.
Press Ctrl+Alt+F2 to switch to the first virtual terminal. Press Ctrl+Alt+F1 to return to your X-Windows session.
The first paragraph highlights the particular keycap to press. The second highlights two key combinations (each a set of three keycaps with each set pressed simultaneously).
If source code is discussed, class names, methods, functions, variable names and returned values mentioned within a paragraph will be presented as above, in mono-spaced bold. For example:
File-related classes include filesystem for file systems, file for files, and dir for directories. Each class has its own associated set of permissions.
Proportional Bold
This denotes words or phrases encountered on a system, including application names; dialog box text; labeled buttons; check-box and radio button labels; menu titles and sub-menu titles. For example:
Choose SystemPreferencesMouse from the main menu bar to launch Mouse Preferences. In the Buttons tab, click the Left-handed mouse check box and click Close to switch the primary mouse button from the left to the right (making the mouse suitable for use in the left hand).
To insert a special character into a gedit file, choose ApplicationsAccessoriesCharacter Map from the main menu bar. Next, choose SearchFind… from the Character Map menu bar, type the name of the character in the Search field and click Next. The character you sought will be highlighted in the Character Table. Double-click this highlighted character to place it in the Text to copy field and then click the Copy button. Now switch back to your document and choose EditPaste from the gedit menu bar.
The above text includes application names; system-wide menu names and items; application-specific menu names; and buttons and text found within a GUI interface, all presented in proportional bold and all distinguishable by context.
Mono-spaced Bold Italic or Proportional Bold Italic
Whether mono-spaced bold or proportional bold, the addition of italics indicates replaceable or variable text. Italics denotes text you do not input literally or displayed text that changes depending on circumstance. For example:
To connect to a remote machine using ssh, type ssh username@domain.name at a shell prompt. If the remote machine is example.com and your username on that machine is john, type ssh [email protected].
The mount -o remount file-system command remounts the named file system. For example, to remount the /home file system, the command is mount -o remount /home.
To see the version of a currently installed package, use the rpm -q package command. It will return a result as follows: package-version-release.
Note the words in bold italics above — username, domain.name, file-system, package, version and release. Each word is a placeholder, either for text you enter when issuing a command or for text displayed by the system.
Aside from standard usage for presenting the title of a work, italics denotes the first use of a new and important term. For example:
Publican is a DocBook publishing system.

1.2. Pull-quote Conventions

Terminal output and source code listings are set off visually from the surrounding text.
Output sent to a terminal is set in mono-spaced roman and presented thus:
books        Desktop   documentation  drafts  mss    photos   stuff  svn
books_tests  Desktop1  downloads      images  notes  scripts  svgs
Source-code listings are also set in mono-spaced roman but add syntax highlighting as follows:
package org.jboss.book.jca.ex1;

import javax.naming.InitialContext;

public class ExClient
{
   public static void main(String args[]) 
       throws Exception
   {
      InitialContext iniCtx = new InitialContext();
      Object         ref    = iniCtx.lookup("EchoBean");
      EchoHome       home   = (EchoHome) ref;
      Echo           echo   = home.create();

      System.out.println("Created Echo");

      System.out.println("Echo.echo('Hello') = " + echo.echo("Hello"));
   }
}

1.3. Notes and Warnings

Finally, we use three visual styles to draw attention to information that might otherwise be overlooked.

Note

Notes are tips, shortcuts or alternative approaches to the task at hand. Ignoring a note should have no negative consequences, but you might miss out on a trick that makes your life easier.

Important

Important boxes detail things that are easily missed: configuration changes that only apply to the current session, or services that need restarting before an update will apply. Ignoring a box labeled 'Important' will not cause data loss but may cause irritation and frustration.

Warning

Warnings should not be ignored. Ignoring warnings will most likely cause data loss.

2. We Need Feedback!

If you find a typographical error in this manual, or if you have thought of a way to make this manual better, we would love to hear from you! Please submit a report in Bugzilla: http://bugzilla.redhat.com/ against the product Red Hat Enterprise Linux 6.
When submitting a bug report, be sure to mention the manual's identifier: doc-Deployment_Guide and version number: 6.
If you have a suggestion for improving the documentation, try to be as specific as possible when describing it. If you have found an error, please include the section number and some of the surrounding text so we can find it easily.

2.1. Technical Review Requests

All review requests are classified into one of the following five categories:
New Content
content documented for the first time — an entirely new feature, procedure, or concept. For example: "Section now describes the new procedure for creating bootable USB devices."
Correction
a factual error previously present in the text has been corrected. For example: "Section previously stated (incorrectly) that IPv4 and IPv6 were both supported; section now states that IPv6 has never been supported."
Clarification
material that was already factually correct but is now better explained. Clarifications are usually in response to reader feedback that the previous content was confusing or misleading in some way. For example: "Paths described in Example 1.2.3 now better reflect the directory structure of an actual installed system."
Obsoletion
a description of a feature or a procedure has been dropped. Material might be obsolete because of a feature that is no longer supported, a known issue that has been corrected, or hardware that is now obsolete. For example, "Section no longer describes how to update kernel modules using a floppy disk."
Verification
a request to check a fact, procedure, or whether material should be obsoleted. For example, "Section describes how to connect to a generic iSCSI storage device. Please verify this on your hardware" or "Section still describes how to update kernel modules using a LS-120 SuperDisk; please verify that we still need to tell readers about this obsolete hardware."

3. Acknowledgements

Certain portions of this text first appeared in the Deployment Guide, copyright © 2007 Red Hat, Inc., available at http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5/html/Deployment_Guide/index.html.
The authors of this book would like to thank the following people for their valuable contributions: Adam Tkáč, Andrew Fitzsimon, Andrius Benokraitis, Brian Cleary Edward Bailey, Garrett LeSage, Jeffrey Fearn, Joe Orton, Joshua Wulf, KarstenWade, Lucy Ringland, Marcela Mašláňová, Mark Johnson, Michael Behm, Michael Behm, Miroslav Lichvár, Radek Vokál, Rahul Kavalapara, Rahul Sundaram, Sandra Moore, and Zbyšek Mráz, among many others.

Introduction

Welcome to the Red Hat Enterprise Linux 6 Deployment Guide.
The Deployment Guide contains information on how to customize your Red Hat Enterprise Linux 6 system to fit your needs. If you are looking for a comprehensive, task-oriented guide for configuring and customizing your system, this is the manual for you.
This manual discusses many intermediate topics such as the following:
  • Installing and managing packages using the graphical PackageKit and command line Yum package managers
  • Setting up a network—from establishing an Ethernet connection using NetworkManager to configuring channel bonding interfaces to increase server bandwidth
  • Configuring DHCP, BIND, Apache, Postfix, Sendmail and other enterprise-class servers and software
  • Gathering information about your system, including obtaining user-space crash data with the Automatic Bug Reporting Tool, and kernel-space crash data with kdump
  • Easily working with kernel modules and upgrading the kernel
This manual is divided into the following main categories:
This guide assumes you have a basic understanding of your Red Hat Enterprise Linux system. If you need help installing Red Hat Enterprise Linux, refer to the Red Hat Enterprise Linux 6 Installation Guide.

Part I. Package Management

All software on a Red Hat Enterprise Linux system is divided into RPM packages, which can be installed, upgraded, or removed. This part describes how to manage packages on Red Hat Enterprise Linux using the Yum and RPM package managers and the PackageKit suite of graphical package management tools.

Chapter 1. Yum

Yum is the Red Hat package manager that is able to query for information about packages, fetch packages from repositories, install and uninstall packages using automatic dependency resolution, and update an entire system to the latest available packages. Yum performs automatic dependency resolution on packages you are updating, installing or removing, and thus is able to automatically determine, fetch and install all available dependent packages. Yum can be configured with new, additional repositories, or package sources, and also provides many plugins which enhance and extend its capabilities. Yum is able to perform many of the same tasks that RPM can; additionally, many of the command line options are similar. Yum enables easy and simple package management on a single machine or on groups of them.

Secure Package Management with GPG-Signed Packages

Yum provides secure package management by enabling GPG (Gnu Privacy Guard; also known as GnuPG) signature verification on GPG-signed packages to be turned on for all package repositories (i.e. package sources), or for individual repositories. When signature verification is enabled, Yum will refuse to install any packages not GPG-signed with the correct key for that repository. This means that you can trust that the RPM packages you download and install on your system are from a trusted source, such as Red Hat, and were not modified during transfer. Refer to Section 1.3, “Configuring Yum and Yum Repositories” for details on enabling signature-checking with Yum, or Section 3.3, “Checking a Package's Signature” for information on working with and verifying GPG-signed RPM packages in general.
Yum also enables you to easily set up your own repositories of RPM packages for download and installation on other machines.
Learning Yum is a worthwhile investment because it is often the fastest way to perform system administration tasks, and it provides capabilities beyond those provided by the PackageKit graphical package management tools. Refer to Chapter 2, PackageKit for details on using PackageKit.

1.1. Checking For and Updating Packages

1.1.1. Checking For Updates

You can use the yum check-update command to see which installed packages on your system have updates available.

Note: Yum and Superuser Privileges

You must have superuser privileges in order to use yum to install, update or remove packages on your system. All examples in this chapter assume that you have already obtained superuser privileges by using either the su or sudo command.
~]# yum check-update
Loaded plugins: presto, refresh-packagekit, security
PackageKit.x86_64                  0.5.8-2.el6                rhel
PackageKit-glib.x86_64             0.5.8-2.el6                rhel
PackageKit-yum.x86_64              0.5.8-2.el6                rhel
PackageKit-yum-plugin.x86_64       0.5.8-2.el6                rhel
glibc.x86_64                       2.11.90-20.el6             rhel
glibc-common.x86_64                2.10.90-22                 rhel
kernel.x86_64                      2.6.31-14.el6              rhel
kernel-firmware.noarch             2.6.31-14.el6              rhel
rpm.x86_64                         4.7.1-5.el6                rhel
rpm-libs.x86_64                    4.7.1-5.el6                rhel
rpm-python.x86_64                  4.7.1-5.el6                rhel
udev.x86_64                        147-2.15.el6               rhel
yum.noarch                         3.2.24-4.el6               rhel
These packages are listed as having updates available. The first package in the list is PackageKit, the graphical package manager. The first line of the above output tells us:
  • PackageKit — the name of the package
  • x86_64 — the CPU architecture the package was built for
  • 0.5.8 — the version of the updated package to be installed
  • rhel — the repository in which the updated package is located
The output also shows us that we can update the kernel (the kernel package), Yum and RPM themselves (the yum and rpm packages), as well as their dependencies (such as the kernel-firmware, rpm-libs and rpm-python packages), all using yum.

1.1.2. Updating Packages

You can choose to update a single package, multiple packages, or all packages at once. If any dependencies of the package (or packages) you update have updates available themselves, then they are updated too. To update a single package , enter yum update <package_name>:
~]# yum update udev
Loaded plugins: presto, refresh-packagekit, rhnplugin, security
Setting up Update Process
Resolving Dependencies
--> Running transaction check
---> Package udev.x86_64 0:147-2.15.el6 set to be updated
--> Finished Dependency Resolution
Dependencies Resolved
===========================================================================
 Package       Arch            Version                 Repository     Size
===========================================================================
Updating:
 udev          x86_64          147-2.15.el6            rhel          337 k
Transaction Summary
===========================================================================
Install       0 Package(s)
Upgrade       1 Package(s)
Total download size: 337 k
Is this ok [y/N]:
This output contains several items of interest:
  1. Loaded plugins: presto, refresh-packagekit, securityyum always informs you which Yum plugins are installed and enabled. Here, yum is using the presto, refresh-packagekit and security plugins. Refer to Section 1.4, “Yum Plugins” for general information on Yum plugins, or to Section 1.4.3, “Plugin Descriptions” for descriptions of specific plugins.
  2. kernel.x86_64 — you can download and install new kernels safely with yum.

    Important: Updating and Installing Kernels with Yum

    yum always installs a new kernel in the same sense that RPM installs a new kernel when you use the command rpm -i kernel. Therefore, you do not need to worry about the distinction between installing and upgrading a kernel package when you use yum: it will do the right thing, regardless of whether you are using the yum update or yum install command.
    When using RPM, on the other hand, it is important to use the rpm -i kernel command (which installs a new kernel) instead of rpm -u kernel (which replaces the current kernel). Refer to Section 3.2.2, “Installing and Upgrading” for more information on installing/updating kernels with RPM.
  3. yum presents the update information and then prompts you as to whether you want it to perform the update; yum runs interactively by default. If you already know which transactions yum plans to perform, you can use the -y option to automatically answer yes to any questions yum may ask (in which case it runs non-interactively). However, you should always examine which changes yum plans to make to the system so that you can easily troubleshoot any problems that might arise.
    If a transaction does go awry, you can view Yum's log of transactions by entering cat /var/log/yum.log at the shell prompt. The most recent transactions are listed at the end of the log file.

Updating All Packages and Their Dependencies

To update all packages and their dependencies, simply enter yum update (without any arguments):
Example 1.1. Updating all packages at once
~]# yum update

1.1.4. Preserving Configuration File Changes

You will inevitably make changes to the configuration files installed by packages as you use your Red Hat Enterprise Linux system. RPM, which Yum uses to perform changes to the system, provides a mechanism for ensuring their integrity. Refer to Section 3.2.2, “Installing and Upgrading” for details on how to manage changes to configuration files across package upgrades.

1.2. Packages and Package Groups

1.2.1. Searching, Listing and Displaying Package Information

You can search all RPM package names, descriptions and summaries by using the yum search <term> [more_terms] command. yum displays the list of matches for each term:
~]# yum search meld kompare
Loaded plugins: presto, refresh-packagekit, rhnplugin, security
============================ Matched: kompare =============================
kdesdk.x86_64 : The KDE Software Development Kit (SDK)
Warning: No matches found for: meld
yum search is useful for searching for packages you do not know the name of, but for which you know a related term.

Listing Packages

yum list and related commands provide information about packages, package groups, and repositories.

Tip: Filtering Results with Glob Expressions

All of Yum's various list commands allow you to filter the results by appending one or more glob expressions as arguments. Glob expressions are normal strings of characters which contain one or more of the wildcard characters * (which expands to match any character multiple times) and ? (which expands to match any one character). Be careful to escape both of these glob characters when passing them as arguments to a yum command. If you do not, the bash shell will interpret the glob expressions as pathname expansions, and potentially pass all files in the current directory that match the globs to yum, which is not what you want. Instead, you want to pass the glob expressions themselves to yum, which you can do by either:
  • escaping the wildcard characters
  • double-quoting or single-quoting the entire glob expression.
The following examples show both methods:
Example 1.2. Filtering results using a single glob expression with two escaped wildcard characters
~]# yum list available gstreamer\*plugin\*
Loaded plugins: presto, refresh-packagekit, rhnplugin, security
Available Packages
gstreamer-plugins-bad-free.i686               0.10.17-4.el6            rhel
gstreamer-plugins-base.i686                   0.10.26-1.el6            rhel
gstreamer-plugins-base-devel.i686             0.10.26-1.el6            rhel
gstreamer-plugins-base-devel.x86_64           0.10.26-1.el6            rhel
gstreamer-plugins-good.i686                   0.10.18-1.el6            rhel

Example 1.3. Filtering results using a double-quoted glob expression
~]# yum list installed "krb?-*"
Loaded plugins: presto, refresh-packagekit, rhnplugin, security
Installed Packages
krb5-libs.x86_64                         1.8.1-3.el6                  @rhel
krb5-workstation.x86_64                  1.8.1-3.el6                  @rhel

  • yum list <glob_expr> [more_glob_exprs] — List information on installed and available packages matching all glob expressions.
    Example 1.4. Listing all ABRT addons and plugins using glob expressions
    ~]# yum list abrt-addon\* abrt-plugin\*
    Loaded plugins: presto, refresh-packagekit, rhnplugin, security
    Installed Packages
    abrt-addon-ccpp.x86_64                        1.0.7-5.el6             @rhel
    abrt-addon-kerneloops.x86_64                  1.0.7-5.el6             @rhel
    abrt-addon-python.x86_64                      1.0.7-5.el6             @rhel
    abrt-plugin-bugzilla.x86_64                   1.0.7-5.el6             @rhel
    abrt-plugin-logger.x86_64                     1.0.7-5.el6             @rhel
    abrt-plugin-sosreport.x86_64                  1.0.7-5.el6             @rhel
    abrt-plugin-ticketuploader.x86_64             1.0.7-5.el6             @rhel

  • yum list all List all installed and available packages.
  • yum list installed List all packages installed on your system. The rightmost column in the output lists the repository from which the package was retrieved.
  • yum list available List all available packages in all enabled repositories.
  • yum grouplist List all package groups.
  • yum repolist List the repository ID, name, and number of packages it provides for each enabled repository.

Displaying Package Info

yum info <package_name> [more_names] displays information about one or more packages (glob expressions are valid here as well):
~]# yum info abrt
Loaded plugins: presto, refresh-packagekit, rhnplugin, security
Installed Packages
Name       : abrt
Arch       : x86_64
Version    : 1.0.7
Release    : 5.el6
Size       : 578 k
Repo       : installed
From repo  : rhel
Summary    : Automatic bug detection and reporting tool
URL        : https://fedorahosted.org/abrt/
License    : GPLv2+
Description: abrt is a tool to help users to detect defects in applications
           : and to create a bug report with all informations needed by
           : maintainer to fix it. It uses plugin system to extend its
           : functionality.
yum info <package_name> is similar to the rpm -q --info <package_name> command, but provides as additional information the ID of the Yum repository the RPM package is found in (look for the From repo: line in the output).
yumdb info <package_name> [more_names] can be used to query the Yum database for alternative and useful information about a package, including the checksum of the package (and algorithm used to produce it, such as SHA-256), the command given on the command line that was invoked to install the package (if any), and the reason that the package is installed on the system (where user indicates it was installed by the user, and dep means it was brought in as a dependency):
~]# yumdb info yum
yum-3.2.27-4.el6.noarch
     checksum_data = 15c8eaf583fabad6974a35b9f6c6527e49362fe4e23baec1682ef51a598e4abb
     checksum_type = sha256
     command_line = update
     from_repo = rhel
     from_repo_revision = 1271991599
     from_repo_timestamp = 1271991721
     reason = user
     releasever = 6
See man yumdb for more information on the yumdb command.
Finally, the yum history command, which is new in Red Hat Enterprise Linux 6, can be used to show a timeline of Yum transactions, the dates and times on when they occurred, the number of packages affected, whether transactions succeeded or were aborted, and if the RPM database was changed between transactions. Refer to the history section of man yum for details.

1.2.2. Installing

You can install a package and all of its non-installed dependencies by entering:
~]# yum install <package_name> 
You can install multiple packages simultaneously by appending their names as arguments: yum install <package_name> [more_names] .
If you are installing packages on a multilib system, such as an AMD64 or Intel64 machine, you can specify the architecture of the package (as long as it's available in an enabled repository) by appending .arch to the package name:
~]# yum install sqlite2.i586
You can use glob expressions to quickly install multiple similarly-named packages:
~]# yum install audacious-plugins-\*
In addition to package names and glob expressions, you can also provide file names to yum install. If you know the name of the binary you want to install, but not its package name, you can give yum install the path name:
~]# yum install /usr/sbin/named
yum then searches through its package lists, finds the package which provides /usr/sbin/named, if any, and prompts you as to whether you want to install it.
What if you know you want to install the package that contains the named binary, but don't know in which bin or sbin directory that file lives? In that situation, you can give yum provides a glob expression:
Example 1.5. Finding which package owns a file and installing it
~]# yum provides "*bin/named"
Loaded plugins: presto, refresh-packagekit, rhnplugin, security
32:bind-9.7.0-4.P1.el6.x86_64 : The Berkeley Internet Name Domain (BIND)
                              : DNS (Domain Name System) server
Repo        : rhel
Matched from:
Filename    : /usr/sbin/named
~]# yum install bind

Note

yum provides is the same as yum whatprovides.

Tip: yum provides/whatprovides and Glob Expressions

yum provides "*/<file_name>" is a common and useful trick to quickly find the package(s) that contain <file_name>.

Installing a Package Group

A package group is similar to a package: it is not useful by itself, but installing one pulls a group of dependent packages that serve a common purpose. A package group has a name and a groupid. The yum grouplist -v command lists the names of all package groups, and, next to each of them, their groupid in parentheses. The groupid is always the term in the last pair of parentheses, such as kde-desktop and kde-software-development in this example:

Not all packages used in examples may be available on RHN

Some of the software packages—or package groups—queried for and installed with Yum in this chapter may not be available from Red Hat Network. Their use in examples is purely to demonstrate Yum's command usage.
Note that obtaining and installing software packages from unverified or untrusted software sources other than Red Hat Network constitutes a potential security risk, and could lead to security, stability, compatibility maintainability issues.
~]# yum -v grouplist kde\*
KDE (K Desktop Environment) (kde-desktop)
KDE Software Development (kde-software-development)
You can install a package group by passing its full group name (without the groupid part) to groupinstall:
~]# yum groupinstall "KDE (K Desktop Environment)"
You can also install by groupid:
~]# yum groupinstall kde-desktop
You can even pass the groupid (or quoted name) to the install command if you prepend it with an @-symbol (which tells yum that you want to perform a groupinstall):
~]# yum install @kde-desktop

1.2.3. Removing

yum remove <package_name> uninstalls (removes in RPM and Yum terminology) the package, as well as any packages that depend on it. As when you install multiple packages, you can remove several at once by adding more package names to the command:
 yum remove foo bar baz
Similar to install, remove can take these arguments:
  • package names
  • glob expressions
  • file lists
  • package provides

Warning: Removing a Package when Other Packages Depend On It

Yum is not able to remove a package without also removing packages which depend on it. This type of operation can only be performed by RPM, is not advised, and can potentially leave your system in a non-functioning state or cause applications to misbehave and/or crash. For further information, refer to Section 3.2.4, “Uninstalling” in the RPM chapter.

Removing a Package Group

You can remove a package group using syntax congruent with the install syntax.
Example 1.6. Alternative but equivalent ways of removing a package group
~]# yum groupremove "KDE (K Desktop Environment)"
~]# yum groupremove kde-desktop
~]# yum remove @kde-desktop

Smart package group removal

When you tell yum to remove a package group, it will remove every package in that group, even if those packages are members of other package groups or dependencies of other installed packages. However, you can instruct yum to remove only those packages which are not required by any other packages or groups by adding the groupremove_leaf_only=1 directive to the [main] section of the /etc/yum.conf configuration file. For more information on this directive, refer to Section 1.3.1, “Setting [main] Options”.

1.3. Configuring Yum and Yum Repositories

This section shows you how to:
  • set global Yum options by editing the [main] section of the /etc/yum.conf configuration file;
  • set options for individual repositories by editing the [repository] sections in /etc/yum.conf and .repo files in the /etc/yum.repos.d/ directory;
  • use Yum variables in /etc/yum.conf and files in /etc/yum.repos.d/so that dynamic version and architecture values are handled correctly; and,
  • set up your own custom Yum repository.
The /etc/yum.conf configuration file contains one mandatory [main] section under which you can set Yum options. The values that you define in the [main] section of yum.conf have global effect, and may override values set any individual [repository] sections. You can also add [repository] sections to /etc/yum.conf; however, best practice is to define individual repositories in new or existing .repo files in the /etc/yum.repos.d/directory. Refer to Section 1.3.2, “Setting [repository] Options” if you need to add or edit repository-specific information.

1.3.1. Setting [main] Options

The /etc/yum.conf configuration file contains exactly one [main] section. You can add many additional options under the [main] section heading in /etc/yum.conf. Some of the key-value pairs in the [main] section affect how yum operates; others affect how Yum treats repositories. The best source of information for all Yum options is in the [main] OPTIONS and [repository] OPTIONS sections of man yum.conf.
Here is a sample /etc/yum.conf configuration file:
[main]
cachedir=/var/cache/yum/$basearch/$releasever
keepcache=0
debuglevel=2
logfile=/var/log/yum.log
exactarch=1
obsoletes=1
gpgcheck=1
plugins=1
installonly_limit=3
[comments abridged]
# PUT YOUR REPOS HERE OR IN separate files named file.repo
# in /etc/yum.repos.d
Here is a list of the most commonly-used options in the [main] section, and descriptions for each:
assumeyes=<value>
...where <value> is one of:
0yum should prompt for confirmation of critical actions it performs. This is the default.
1 — Do not prompt for confirmation of critical yum actions. If assumeyes=1 is set, yum behaves in the same way that the command line option -y does.
cachedir=/var/cache/yum/$basearch/$releasever
This option specifies the directory where Yum should store its cache and database files. By default, Yum's cache directory is /var/cache/yum/$basearch/$releasever. See Section 1.3.3, “Using Yum Variables” for descriptions of the $basearch and $releasever Yum variables.
debuglevel=value
...where <value> is an integer between 1 and 10. Setting a higher debuglevel value causes yum to display more detailed debugging output. debuglevel=0 disables debugging output, while debuglevel=2 is the default.
exactarch=<value>
...where <value> is one of:
0 — Do not take into account the exact architecture when updating packages.
1 — Consider the exact architecture when updating packages. With this setting, yum will not install an i686 package to update an i386 package already installed on the system. This is the default.
exclude=<package_name> [more_package_names ]
This option allows you to exclude packages by keyword during installation/updates. Listing multiple packages for exclusion can be accomplished by quoting a space-delimited list of packages. Shell globs using wildcards (for example, * and ?) are allowed.
gpgcheck=<value>
...where <value> is one of:
0 — Disable GPG signature-checking on packages in all repositories, including local package installation.
1 — Enable GPG signature-checking on all packages in all repositories, including local package installation. gpgcheck=1 is the default, and thus all packages' signatures are checked.
If this option is set in the [main] section of the /etc/yum.conf file, it sets the GPG-checking rule for all repositories. However, you can also set gpgcheck= <value> for individual repositories instead; i.e., you can enable GPG-checking on one repository while disabling it on another. Setting gpgcheck=<value> for an individual repository in its correpsonding .repo file overrides the default if it is present in /etc/yum.conf. Refer to Section 3.3, “Checking a Package's Signature” for further information on GPG signature-checking.
groupremove_leaf_only=<value>
...where <value> is one of:
0yum should not check the dependencies of each package when removing a package group. With this setting, yum removes all packages in a package group, regardless of whether those packages are required by other packages or groups. groupremove_leaf_only=0 is the default.
1yum should check the dependencies of each package when removing a package group, and remove only those packages which are not not required by any other package or group.
For more information on removing packages, refer to Smart package group removal.
installonlypkgs=<space> <separated> <list> <of> <packages>
Here you can provide a space-separated list of packages which yum can install, but will never update. Refer to man yum.conf for the list of packages which are install-only by default. If you add the installonlypkgs directive to /etc/yum.conf, you should ensure that you list all of the packages that should be install-only, including any of those listed under the installonlypkgs section of man yum.conf. In particular, kernel packages should always be listed in installonlypkgs (as they are by default), and installonly_limit should always be set to a value greater than 2 so that a backup kernel is always available in case the default one fails to boot. Refer to installonly_limit=<value> for details on the installonly_limit directive.
installonly_limit=<value>
...where <value> is an integer representing the maximum number of versions that can be installed simultaneously for any single package listed in the installonlypkgs directive. The defaults for the installonlypkgs directive include several different kernel packages, so be aware that changing the value of installonly_limit will also affect the maximum number of installed versions of any single kernel package. The default value listed in /etc/yum.conf is installonly_limit=3, and it is not recommended to decrease this value, particularly below 2.
keepcache=<value>
...where value is one of:
0 — Do not retain the cache of headers and packages after a successful installation. This is the default.
1 — Retain the cache after a successful installation.
logfile=/var/log/yum.log
This option specifies where yum should send its logging output. By default, yum logs to /var/log/yum.log.
multilib_policy=<value>
...where <value> is one of:
best — install the best-choice architecture for this system. For example, setting multilib_policy=best on an AMD64 system causes yum to install 64-bit versions of all packages.
all — always install every possible architecture for every package. For example, with multilib_policy set to all on an AMD64 system, yum would install both the i586 and AMD64 versions of a package, if both were available.
obsoletes=<value>
...where <value> is one of:
0 — Disable yum's obsoletes processing logic when performing updates.
1 — Enable yum's obsoletes processing logic when performing updates. When one package declares in its spec file that it obsoletes another package, the latter package will be replaced by the former package when the former package is installed. Obsoletes are declared, for example, when a package is renamed. obsoletes=1 the default.
plugins=<value>
...where <value> is one of:
0 — Disable all Yum plugins globally.

Disabling plugins is not advised

Disabling all plugins is not advised because certain plugins provide important Yum services. In particular, rhnplugin enables connecting to Red Hat Network, and the security plugin allows system administrators to easily update the system with (sometimes critical) security updates. Disabling plugins globally is provided as a convenience option, and is generally only recommended when diagnosing a potential problem with Yum.
1 — Enable all Yum plugins globally. With plugins=1, you can still disable a specific Yum plugin by setting enabled=0 in that plugin's configuration file. Refer to Section 1.4, “Yum Plugins” for more information about various Yum plugins, or to Section 1.4.1, “Enabling, Configuring and Disabling Yum Plugins” for further information on controlling plugins.
reposdir=</absolute/path/to/directory/containing/repo/files>
This option allows you to specify a directory where .repo files are located. All .repo files contain repository information (similar to the [repository] section(s) of /etc/yum.conf). yum collects all repository information from .repo files and the [repository] section of the /etc/yum.conf file to create a master list of repositories to use for transactions. Refer to Section 1.3.2, “Setting [repository] Options” for more information about options you can use for both the [repository] section and .repo files. If reposdir is not set, yum uses the default directory /etc/yum.repos.d/.
retries=<value>
...where <value> is an integer 0 or greater. This value sets the number of times yum should attempt to retrieve a file before returning an error. Setting this to 0 makes yum retry forever. The default value is 10.

1.3.2. Setting [repository] Options

You can define individual Yum repositories by adding [repository] sections (where repository is a unique repository ID, such as [my_personal_repo]) to /etc/yum.conf or to .repo files in the /etc/yum.repos.d/directory. All .repo files in /etc/yum.repos.d/are read by yum; best practice is to define your repositories here instead of in /etc/yum.conf. You can create new, custom .repo files in this directory, add [repository] sections to those files, and the next time you run a yum command, it will take all newly-added repositories into account.
Here is a (bare-minimum) example of the form a .repo file should take:
[repository_ID]
name=A Repository Name
baseurl=http://path/to/repo or ftp://path/to/repo or file://path/to/local/repo
Every [repository] section must contain the following minimum parts:
[repository_ID]
The repository ID is a unique, one-word (no spaces; underscores are allowed) string of characters (enclosed by brackets) that serves as a repository identifier.
name=<My Repository Name>
This is a human-readable string describing the repository.
baseurl=http://path/to/repo, ftp://path/to/repo, file://path/to/local/repo
This is a URL to the directory where the repodata directory of a repository is located. Usually this URL is an HTTP link, such as:
baseurl=http://path/to/repo/releases/$releasever/server/$basearch/os/
Yum always expands the $releasever, $arch and $basearch variables in URLs. See the following section for explanations of all Yum variables: Section 1.3.3, “Using Yum Variables”.
  • If the repository is available over FTP, use: ftp://path/to/repo
  • If the repository is local to the machine, use file://path/to/local/repo
  • If a specific online repository requires basic HTTP authentication, you can specify your username and password in the http://path/to/repo by prepending it as username:[email protected]. For example, if a repository on http://www.example.com/repo/ requires a username of "user" and a password of "password", then the baseurl link could be specified as:
    baseurl=http://user:password@www.example.com/repo/
The following is another useful [repository] directive:
enabled=<value>
...where <value> is one of:
0 — do not include this repository as a package source when performing updates and installs. This is an easy way of quickly turning repositories on and off, which is useful when you desire a single package from a repository that you do not want to enable for updates or installs.
1 — include this repository as a package source.
Turning repositories on and off can also be performed quickly by passing either the --enablerepo=<repo_name> or --disablerepo=<repo_name> option to yum, or easily through PackageKit's Add/Remove Software window.
Many more [repository] options exist. Refer to the [repository] OPTIONS section of man yum.conf for the exhaustive list and descriptions for each.

1.3.3. Using Yum Variables

You can use and reference the following variables in yum commands and in all Yum configuration files (/etc/yum.conf and all .repo files in /etc/yum.repos.d/.
$releasever
You can use this variable to reference the release version of Red Hat Enterprise Linux. Yum obtains the value of $releasever from the distroverpkg=<value> line in the /etc/yum.conf configuration file. If there is no such line in /etc/yum.conf, then yum infers the correct value by deriving the version number from the redhat-release package.
$arch
You can use this variable to refer to the system's CPU architecture as returned when calling Python's os.uname() function. Valid values for $arch include: i586, i686 and x86_64.
$basearch
You can use $basearch to reference the base architecture of the system. For example, i686 and i586 machines both have a base architecture of i386, and AMD64 and Intel64 machines have a base architecture of x86_64.
$YUM0-9
These ten variables are each replaced with the value of any shell environment variables with the same name. If one of these variables is referenced (in /etc/yum.conf for example) and a shell environment variable with the same name does not exist, then the configuration file variable is not replaced.

1.3.4. Creating a Yum Repository

To set up a Yum repository, follow these steps:
Procedure 1.1. Setting Up a Yum repository
  1. Install the createrepo package:
    ~]# yum install createrepo
  2. Copy all of the packages into one directory, such as /mnt/local_repo/.
  3. Run the createrepo --database command on that directory:
    ~]# createrepo --database /mnt/local_repo

    Important

    Because RPM packages for Red Hat Enterprise Linux 6 are compressed using the XZ lossless data compression format, and may also be signed using alternative (and stronger) hash algorithms such as SHA-256, it is not possible to run createrepo on Red Hat Enterprise Linux 5 to create the package metadata for Red Hat Enterprise Linux 6 packages. The createrepo command relies on rpm to open and inspect the packages, and rpm on Red Hat Enterprise Linux 5 is not able to open the improved Red Hat Enterprise Linux 6 RPM package format.
This will create the necessary metadata for your Yum repository, as well as the sqlite database for speeding up yum operations.

1.4. Yum Plugins

Yum provides plugins that extend and enhance its operations. Certain plugins are installed by default. Yum always informs you which plugins, if any, are loaded and active whenever you call any yum command:
~]# yum info yum
Loaded plugins: presto, refresh-packagekit, security
[output truncated]
Note that the plugin names which follow Loaded plugins are the names you can provide to the --disableplugins=<plugin_name> option.

1.4.1. Enabling, Configuring and Disabling Yum Plugins

To enable Yum plugins, ensure that a line beginning with plugins= is present in the [main] section of /etc/yum.conf, and that its value is set to 1:
plugins=1
You can disable all plugins by changing this line to plugins=0.

Disabling plugins is not advised

Disabling all plugins is not advised because certain plugins provide important Yum services. In particular, rhnplugin enables connecting to Red Hat Network, and the security plugin allows system administrators to easily update the system with (sometimes critical) security updates. Disabling plugins globally is provided as a convenience option, and is generally only recommended when diagnosing a potential problem with Yum.
Every installed plugin has its own configuration file in the /etc/yum/pluginconf.d/ directory. You can set plugin-specific options in these files. For example, here is the security plugin's security.conf configuration file:
Example 1.7. A minimal Yum plugin configuration file
[main]
enabled=1

Plugin configuration files always contain a [main] section (similar to Yum's /etc/yum.conf file) in which there is (or you can place if it is missing) an enabled= option that controls whether the plugin is enabled when you run yum commands.
If you disable all plugins by setting enabled=0 in /etc/yum.conf, then all plugins are disabled regardless of whether they are enabled in their individual configuration files.
If you merely want to disable all Yum plugins for a single yum command, use the --noplugins option.
If you simply want to disable one or more Yum plugins for a single yum command, then you can add the --disableplugin=<plugin_name> option to the command:
Example 1.8. Disabling the presto plugin while running yum update
~]# yum update --disableplugin=presto

The plugin names you provide to the --disableplugin= option are the same names listed after the Loaded plugins: line in the output of any yum command. You can disable multiple plugins by separating their names with commas. In addition, you can match multiple similarly-named plugin names or simply shorten long ones by using glob expressions: --disableplugin=presto,refresh-pack*.

1.4.2. Installing More Yum Plugins

Yum plugins usually adhere to the yum-plugin-<plugin_name> package-naming convention, but not always: the package which provides the presto plugin is named yum-presto, for example. You can install a Yum plugin in the same way you install other packages:
~]# yum install yum-plugin-security

1.4.3. Plugin Descriptions

Here are descriptions of a few useful Yum plugins:

presto (yum-presto)

The presto plugin adds support to Yum for downloading delta RPM packages, during updates, from repositories which have presto metadata enabled. Delta RPMs contain only the differences between the version of the package installed on the client requesting the RPM package and the updated version in the repository. Downloading a delta RPM is much quicker than downloading the entire updated package, and can speed up updates considerably. Once the delta RPMs are downloaded, they must be rebuilt (the difference applied to the currently-installed package to create the full updated package) on the installing machine, which takes CPU time. Using delta RPMs is therefore a tradeoff between time-to-download, which depends on the network connection, and time-to-rebuild, which is CPU-bound. Using the presto plugin is recommended for fast machines and systems with slower network connections, while slower machines on very fast connections may benefit more from downloading normal RPM packages, i.e. by disabling presto. The presto plugin is enabled by default.

protect-packages (yum-plugin-protect-packages)

The protect-packages plugin prevents the yum package and all packages it depends on from being purposefully or accidentally removed. This simple scheme prevents many of the most important packages necessary for your system to run from being removed. In addition, you can list more packages, one per line, in the /etc/sysconfig/protected-packages file[1] (which you should create if it does not exist), and protect-packages will extend protection-from-removal to those packages as well. To temporarily override package protection, use the --override-protection option with an applicable yum command.

rhnplugin (yum-rhn-plugin)

The rhnplugin for Yum provides support for connecting to Red Hat Network (RHN). Systems registered with RHN are able to update and install packages from Red Hat Network.
Refer to man rhnplugin for more information.

refresh-packagekit (PackageKit-yum-plugin)

This plugin updates metadata for PackageKit whenever yum is run. The refresh-packagekit plugin is installed by default.

security (yum-plugin-security)

Discovering information about and applying security updates easily and often is important to all system administrators. For this reason Yum provides the security plugin, which extends yum with a set of highly-useful security-related commands, subcommands and options.
You can check for all security-related updates as follows:
~]# yum check-update --security
Loaded plugins: presto, refresh-packagekit, security
Limiting package lists to security relevant ones
Needed 3 of 7 packages, for security
elinks.x86_64                   0.12-0.13.el6               rhel
kernel.x86_64                   2.6.30.8-64.el6             rhel
kernel-headers.x86_64           2.6.30.8-64.el6             rhel
You can then use either yum update --security or yum update-minimal --security to update those packages which are affected by security advisories. Both of these commands update all packages on the system for which a security advisiory has been issued. yum update-minimal --security updates them to the latest packages which were released as part of a security advisory, while yum update --security will update all packages affected by a security advisory to the latest version of that package available.
In other words, if:
  • the kernel-2.6.30.8-16 package is installed on your system;
  • the kernel-2.6.30.8-32 package was released as a security update;
  • then kernel-2.6.30.8-64 was released as a bug fix update,
...then yum update-minimal --security will update you to kernel-2.6.30.8-32, and yum update --security will update you to kernel-2.6.30.8-64. Conservative system administrators may want to use update-minimal to reduce the risk incurred by updating packages as much as possible.
Refer to man yum-security for usage details and further explanation of the enhancements the security plugin adds to yum.

1.5. Additional Resources

The Yum home page and wiki — http://yum.baseurl.org/wiki/Guides
The Yum Guides section of the wiki contains more Yum documentation.
Managing Software with Yumhttp://docs.fedoraproject.org/en-US/Fedora_Core/5/html-single/Software_Management_Guide/
A useful resource that provides additional information about using the Yum package manager.


[1] You can also place files with the extension .list in the /etc/sysconfig/protected-packages.d/ directory (which you should create if it does not exist), and list packages—one per line—in these files. protect-packages will protect these too.

Chapter 2. PackageKit

Red Hat provides PackageKit for viewing, managing, updating, installing and uninstalling packages compatible with your system. PackageKit consists of several graphical interfaces that can be opened from the GNOME panel menu, or from the Notification Area when PackageKit alerts you that updates are available. For more information on PackageKit's architecture and available front ends, refer to Section 2.3, “PackageKit Architecture”.

2.1. Updating Packages with Software Update

PackageKit displays a starburst icon in the Notification Area whenever updates are available to be installed on your system.
Clicking on the notification icon opens the Software Update window. Alternatively, you can open Software Updates by clicking SystemAdministrationSoftware Update from the GNOME panel, or running the gpk-update-viewer command at the shell prompt. In the Software Updates window, all available updates are listed along with the names of the packages being updated (minus the .rpm suffix, but including the CPU architecture), a short summary of the package, and, usually, short descriptions of the changes the update provides. Any updates you do not wish to install can be de-selected here by unchecking the checkbox corresponding to the update.
Installing updates with Software Update
installing 12 updates with packagekit's software update window
Figure 2.1. Installing updates with Software Update

The updates presented in the Software Updates window only represent the currently-installed packages on your system for which updates are available; dependencies of those packages, whether they are existing packages on your system or new ones, are not shown until you click Install Updates.
PackageKit utilizes the fine-grained user authentication capabilities provided by the PolicyKit toolkit whenever you request it to make changes to the system. Whenever you instruct PackageKit to update, install or remove packages, you will be prompted to enter the superuser password before changes are made to the system.
PackageKit uses PolicyKit to authenticate
packagekit defers to policykit to provide authentication in order to make changes to the system
Figure 2.2. PackageKit uses PolicyKit to authenticate

If you instruct PackageKit to update the kernel package, then it will prompt you after installation, asking you whether you want to reboot the system and thereby boot into the newly-installed kernel.

Setting the Update-Checking Interval

Right-clicking on PackageKit's Notification Area icon and clicking Preferences opens the Software Update Preferences window, where you can define the interval at which PackageKit checks for package updates, as well as whether or not to automatically install all updates or only security updates, and how often to check for major upgrades. Leaving the Check for updates when using mobile broadband box unchecked is handy for avoiding extraneous bandwidth usage when using a wireless connection on which you are charged for the amount of data you download.
Setting PackageKit's update-checking interval
Setting the update-checking interval for packagekit by right-clicking on the notification area applet
Figure 2.3. Setting PackageKit's update-checking interval

2.2. Using Add/Remove Software

PackageKit's Software Update GUI window is a separate application from its Add/Remove Software application, although the two have intuitively similar interfaces. To find and install a new package, on the GNOME panel click on SystemAdministrationAdd/Remove Software, or run the gpk-application command at the shell prompt.
PackageKit's Add/Remove Software window
viewing packagekit's add/remove softvware window
Figure 2.4. PackageKit's Add/Remove Software window

2.2.1. Refreshing Software Sources (Yum Repositories)

PackageKit refers to Yum repositories as software sources. It obtains all packages from enabled software sources. You can view the list of all configured and unfiltered (see below) Yum repositories by opening Add/Remove Software and clicking SystemSoftware sources. The Software Sources dialog shows the repository name, as written on the name=<My Repository Name> field of all [repository] sections in the /etc/yum.conf configuration file, and in all repository.repo files in the /etc/yum.repos.d/ directory.
Entries which are checked in the Enabled column indicate that the corresponding repository will be used to locate packages to satisfy all update and installation requests (including dependency resolution). The Enabled column corresponds to the enabled=<1 or 0> field in [repository] sections. Checking an unchecked box enables the Yum repository, and unchecking it disables it. Performing either function causes PolicyKit to prompt for superuser authentication to enable or disable the repository. PackageKit actually inserts the enabled=<1 or 0> line into the correct [repository] section if it does not exist, or changes the value if it does. This means that enabling or disabling a repository through the Software Sources window causes that change to persist after closing the window or rebooting the system. The ability to quickly enable and disable repositories based on our needs is a highly-convenient feature of PackageKit.
Note that it is not possible to add or remove Yum repositories through PackageKit.

Showing Source RPM, Test and Debuginfo Repositories

Checking the box at the bottom of the Software Sources window causes PackageKit to display source RPM, testing and debuginfo repositories as well. This box is unchecked by defaut.
After enabling and/or disabling the correct Yum repositories, ensure that you have the latest list of available packages. Click on SystemRefresh package lists and PackageKit will obtain the latest lists of packages from all enabled software sources, i.e. Yum repositories.

2.2.2. Finding Packages with Filters

Once the software sources have been updated, it is often beneficial to apply some filters so that PackageKit retrieves the results of our Find queries faster. This is especially helpful when performing many package searches. Four of the filters in the Filters drop-down menu are used to split results by matching or not matching a single criterion. By default when PackageKit starts, these filters are all unapplied (No filter), but once you do filter by one of them, that filter remains set until you either change it or close PackageKit.
Because you are usually searching for available packages that are not installed on the system, click FiltersInstalled and select the Only available radio button.
Filtering out already-installed packages
filtering out packages which are already installed
Figure 2.5. Filtering out already-installed packages

Also, unless we require development files such as C header files, we can filter for Only end user files and, in doing so, filter out all of the <package_name>-devel packages we are not interested in.
Filtering out development packages from the list of Find results
filtering out development packages from our results
Figure 2.6. Filtering out development packages from the list of Find results

The two remaining filters with submenus are:
Graphical
Narrows the search to either applications which provide a GUI interface or those that do not (Only text). This filter is useful when browsing for GUI applications that perform a specific function.
Free
Search for packages which are considered to be free software Refer to the Fedora Licensing List for details on approved licenses.
The remaining checkbox filters are always either checked or unchecked. They are:
Hide subpackages
Checking the Hide subpackages checkbox filters out generally-uninteresting packages that are typically only dependencies of other packages that we want. For example, checking Hide subpackages and searching for <package> would cause the following related packages to be filtered out of the Find results (if it exists):
  • <package>-devel
  • <package>-libs
  • <package>-libs-devel
  • <package>-debuginfo
Only newest items
Checking Only newest items filters out all older versions of the same package from the list of results, which is generally what we want.

Important: Using the Only newest items filter

Checking Only newest items filters out all but the most recent version of any package from the results list. This filter is often combined with the Only available filter to search for the latest available versions of new (not installed) packages.
Only native packages
Checking the Only native packages box on a multilib system causes PackageKit to omit listing results for packages compiled for the architecture that runs in compatibility mode. For example, enabling this filter on a 64-bit system with an AMD64 CPU would cause all packages built for the 32-bit x86 CPU architecture not to be shown in the list of results, even though those packages are able to run on an AMD64 machine. Packages which are architecture-agnostic (i.e. noarch packages such as crontabs-1.10-32.1.el6.noarch.rpm) are never filtered out by checking Only native packages. This filter has no affect on non-multilib systems, such as x86 machines.

2.2.3. Installing and Removing Packages (and Dependencies)

With the two filters selected, Only available and Only end user files, search for the htop interactive process viewer and highlight the package. You now have access to some very useful information about it, including: a clickable link to the project homepage; the Yum package group it is found in, if any; the license of the package; a pointer to the GNOME menu location from where the application can be opened, if applicable (ApplicationsSystem ToolsHtop in our case); and the size of the package, which is relevant when we download and install it.
Viewing and installing a package with PackageKit's Add/Remove Software window
Viewing and installing a package with PackageKit's Add/Remove Software window
Figure 2.7. Viewing and installing a package with PackageKit's Add/Remove Software window

When the checkbox next to a package or group is checked, then that item is already installed on the system. Checking an unchecked box causes it to be marked for installation, which only occurs when the Apply button is clicked. In this way, you can search for and select multiple packages or package groups before performing the actual installation transactions. Additionally, you can remove installed packages by unchecking the checked box, and the removal will occur along with any pending installations when Apply is pressed. Dependency resolution , which may add additional packages to be installed or removed, is performed after pressing Apply. PackageKit will then display a window listing those additional packages to install or remove, and ask for confirmation to proceed.
Check htop and click the Apply button. You will then be prompted for the superuser password; enter it, and PackageKit will install htop. One nice feature of PackageKit is that, following installation, it sometimes presents you with a list of your newly-installed applications and offer you the choice of running them immediately. Alternatively, you will remember that finding a package and selecting it in the Add/Remove Software window shows you the Location of where in the GNOME menus its application shortcut is located, which is helpful when you want to run it.
Once it is installed, you can run htop, an colorful and enhanced version of the top process viewer, by opening a shell prompt and entering:
~]$ htop
Viewing processes with htop!
htop is nifty, but we decide that top is good enough for us and we want to uninstall it. Remembering that we need to change the Only available filter we recently used to install it to Only installed in FiltersInstalled, we search for htop again and uncheck it. The program did not install any dependencies of its own; if it had, those would be automatically removed as well, as long as they were not also dependencies of any other packages still installed on our system.

Warning: Removing a Package when Other Packages Depend On It

Although PackageKit automatically resolves dependencies during package installation and removal, it is unable to remove a package without also removing packages which depend on it. This type of operation can only be performed by RPM, is not advised, and can potentially leave your system in a non-functioning state or cause applications to misbehave and/or crash.
Removing a package with PackageKit's Add/Remove Software window
removing the htop package with packagekit's add/remove software window
Figure 2.8. Removing a package with PackageKit's Add/Remove Software window

2.2.4. Installing and Removing Package Groups

PackageKit also has the ability to install Yum package groups, which it calls Package collections. Clicking on Package collections in the top-left list of categories in the Software Updates window allows us to scroll through and find the package group we want to install. In this case, we want to install Czech language support (the Czech Support group). Checking the box and clicking apply informs us how many additional packages must be installed in order to fulfill the dependencies of the package group.
Installing the Czech Support package group
using PackageKit to install czech language support with PackageKit's add/remove software window
Figure 2.9. Installing the Czech Support package group

Similarly, installed package groups can be uninstalled by selecting Package collections, unchecking the appropriate checkbox, and applying.

2.2.5. Viewing the Transaction Log

PackageKit maintains a log of the transactions that it performs. To view the log, from the Add/Remove Software window, click SystemSoftware log, or run the gpk-log command at the shell prompt.
The Software Log Viewer shows the Action, such as Updated System or Installed Packages, the Date on which that action was performed, the Username of the user who performed the action, and the front end Application the user used (such as Update Icon, or kpackagekit). The Details column provides the types of the transactions, such as Updated, Installed or Removed, as well as the list of packages the transactions were performed on.
Viewing the log of package management transactions with the Software Log Viewer
viewing the log of package management transactions with packagekit's loftware log viewer window
Figure 2.10. Viewing the log of package management transactions with the Software Log Viewer

Typing the name of a package in the top text entry field filters the list of transactions to those which affected that package.

2.3. PackageKit Architecture

Red Hat provides the PackageKit suite of applications for viewing, updating, installing and uninstalling packages and package groups compatible with your system. Architecturally, PackageKit consists of several graphical front ends that communicate with the packagekitd daemon back end, which communicates with a package manager-specific back end that utilizes Yum to perform the actual transactions, such as installing and removing packages, etc.
Table 2.1, “PackageKit GUI Windows, Menu Locations, and Shell Prompt Commands” shows the name of the GUI window, how to start the window from the GNOME desktop or from the Add/Remove Software window, and the name of the command line application that opens that window.
Table 2.1. PackageKit GUI Windows, Menu Locations, and Shell Prompt Commands
Window Title Function How to Open Shell Command
Add/Remove Software Install, remove or view package info
From the GNOME panel: SystemAdministrationAdd/Remove Software
gpk-application
Software Update Perform package updates
From the GNOME panel: SystemAdministrationSoftware Update
gpk-update-viewer
Software Sources Enable and disable Yum repositories
From Add/Remove Software: SystemSoftware sources
gpk-repo
Software Log Viewer View the transaction log
From Add/Remove Software: SystemSoftware log
gpk-log
Software Update Preferences Set PackageKit preferences gpk-prefs
(Notification Area Alert) Alerts you when updates are available
From the GNOME panel: SystemPreferencesStartup Applications, Startup Programs tab
gpk-update-icon

The packagekitd daemon runs outside the user session and communicates with the various graphical front ends. The packagekitd daemon[2] communicates via the DBus system message bus with another back end, which utilizes Yum's Python API to perform queries and make changes to the sytem. On Linux systems other than Red Hat and Fedora, packagekitd can communicate with other back ends that are able to utilize the native package manager for that system. This modular architecture provides the abstraction necessary for the graphical interfaces to work with many different package managers to perform essentially the same types of package management tasks. Learning how to use the PackageKit front ends means that you can use the same familiar graphical interface across many different Linux distributions, even when they utilize a native package manager other than Yum.
In addition, PackageKit's separation of concerns provides reliability in that a crash of one of the GUI windows—or even the user's X Window session—will not affect any package management tasks being supervised by the packagekitd daemon, which runs outside of the user session.
All of the front end graphical applications discussed in this chapter are provided by the gnome-packagekit package instead of by PackageKit and its dependencies. Users working in a KDE environment may prefer to install the kpackagekit package, which provides a KDE interface for PackageKit.
Finally, PackageKit also comes with a console-based frontend called pkcon.

2.4. Additional Resources

PackageKit home page — http://www.packagekit.org/index.html
Information about and mailing lists for PackageKit.
PackageKit FAQ — http://www.packagekit.org/pk-faq.html
An informative list of Frequently Asked Questions for the PackageKit software suite.
PackageKit Feature Matrix — http://www.packagekit.org/pk-matrix.html
Cross-reference PackageKit-provided features with the long list of package manager back ends.


[2] System daemons are typically long-running processes that provide services to the user or to other programs, and which are started, often at boot time, by special initialization scripts (often shortened to init scripts). Daemons respond to the service command and can be turned on or off permanently by using the chkconfig on or chkconfig offcommands. They can typically be recognized by a d appended to their name, such as the packagekitd daemon. Refer to Chapter 7, Controlling Access to Services for information about system services.

Chapter 3. RPM

The RPM Package Manager (RPM) is an open packaging system , which runs on Red Hat Enterprise Linux as well as other Linux and UNIX systems. Red Hat, Inc. and the Fedora Project encourage other vendors to use RPM for their own products. RPM is distributed under the terms of the GPL (GNU General Public License).
The RPM Package Manager only works with packages built to work with the RPM format. RPM is itself provided as a pre-installed rpm package. For the end user, RPM makes system updates easy. Installing, uninstalling and upgrading RPM packages can be accomplished with short commands. RPM maintains a database of installed packages and their files, so you can invoke powerful queries and verifications on your system.
The RPM package format has been improved for Red Hat Enterprise Linux 6. RPM packages are now compressed using the XZ lossless data compression format, which has the benefit of greater compression and less CPU usage during decompression, and support multiple strong hash algorithms, such as SHA-256, for package signing and verification.

Use Yum Instead of RPM Whenever Possible

For most package management tasks, the Yum package manager offers equal and often greater capabilities and utility than RPM . Yum also performs and tracks complicated system dependency resolution, and will complain and force system integrity checks if you use RPM as well to install and remove packages. For these reasons, it is highly recommended that you use Yum instead of RPM whenever possible to perform package management tasks. Refer to Chapter 1, Yum.
If you prefer a graphical interface, you can use the PackageKit GUI application, which uses Yum as its back end, to manage your system's packages. Refer to Chapter 2, PackageKit for details.

Important

When installing a package, ensure it is compatible with your operating system and processor architecture. This can usually be determined by checking the package name. Many of the following examples show RPM packages compiled for the AMD64/Intel 64 computer architectures; thus, the RPM file name ends in x86_64.rpm.
During upgrades, RPM handles configuration files carefully, so that you never lose your customizations—something that you cannot accomplish with regular .tar.gz files.
For the developer, RPM allows you to take software source code and package it into source and binary packages for end users. This process is quite simple and is driven from a single file and optional patches that you create. This clear delineation between pristine sources and your patches along with build instructions eases the maintenance of the package as new versions of the software are released.

Note

Because RPM makes changes to your system, you must be logged in as root to install, remove, or upgrade an RPM package.

3.1. RPM Design Goals

To understand how to use RPM, it can be helpful to understand the design goals of RPM:
Upgradability
With RPM, you can upgrade individual components of your system without completely reinstalling. When you get a new release of an operating system based on RPM, such as Red Hat Enterprise Linux, you do not need to reinstall a fresh copy of the operating system your machine (as you might need to with operating systems based on other packaging systems). RPM allows intelligent, fully-automated, in-place upgrades of your system. In addition, configuration files in packages are preserved across upgrades, so you do not lose your customizations. There are no special upgrade files needed to upgrade a package because the same RPM file is used to both install and upgrade the package on your system.
Powerful Querying
RPM is designed to provide powerful querying options. You can perform searches on your entire database for packages or even just certain files. You can also easily find out what package a file belongs to and from where the package came. The files an RPM package contains are in a compressed archive, with a custom binary header containing useful information about the package and its contents, allowing you to query individual packages quickly and easily.
System Verification
Another powerful RPM feature is the ability to verify packages. If you are worried that you deleted an important file for some package, you can verify the package. You are then notified of anomalies, if any—at which point you can reinstall the package, if necessary. Any configuration files that you modified are preserved during reinstallation.
Pristine Sources
A crucial design goal was to allow the use of pristine software sources, as distributed by the original authors of the software. With RPM, you have the pristine sources along with any patches that were used, plus complete build instructions. This is an important advantage for several reasons. For instance, if a new version of a program is released, you do not necessarily have to start from scratch to get it to compile. You can look at the patch to see what you might need to do. All the compiled-in defaults, and all of the changes that were made to get the software to build properly, are easily visible using this technique.
The goal of keeping sources pristine may seem important only for developers, but it results in higher quality software for end users, too.

3.2. Using RPM

RPM has five basic modes of operation (not counting package building): installing, uninstalling, upgrading, querying, and verifying. This section contains an overview of each mode. For complete details and options, try rpm --help or man rpm. You can also refer to Section 3.5, “Additional Resources” for more information on RPM.

3.2.1. Finding RPM Packages

Before using any RPM packages, you must know where to find them. An Internet search returns many RPM repositories, but if you are looking for Red Hat RPM packages, they can be found at the following locations:
  • The Red Hat Enterprise Linux installation media contain many installable RPMs.
  • The initial RPM repositories provided with the YUM package manager . Refer to Chapter 1, Yum for details on how to use the official Red Hat Enterprise Linux package repositories.
  • The Extra Packages for Enterprise Linux (EPEL) is a community effort to provide high-quality add-on packages for Red Hat Enterprise Linux . Refer to http://fedoraproject.org/wiki/EPEL for details on EPEL RPM packages.
  • Unofficial, third-party repositories not ahffiliated Red Hat also provide RPM packages.

    Important

    When considering third-party repositories for use with your Red Hat Enterprise Linux system, pay close attention to the repository's web site with regard to package compatibility before adding the repository as a package source. Alternate package repositories may offer different, incompatible versions of the same software, including packages already included in the Red Hat Enterprise Linux repositories.
  • The Red Hat Errata Page, available at http://www.redhat.com/apps/support/errata/

3.2.2. Installing and Upgrading

RPM packages typically have file names like tree-1.5.3-2.el6.x86_64.rpm. The file name includes the package name (tree), version (1.5.3), release (2), operating system major version (el6) and CPU architecture (x86_64).
You can use rpm's -U option to:
  • upgrade an existing but older package on the system to a newer version, or
  • install the package even if an older version is not already installed.
That is, rpm -U <rpm_file> is able to perform the function of either upgrading or installing as is appropriate for the package.
Assuming the tree-1.5.3-2.el6.x86_64.rpm package is in the current directory, log in as root and type the following command at a shell prompt to either upgrade or install the tree package as determined by rpm:
rpm -Uvh tree-1.5.3-2.el6.x86_64.rpm

Use -Uvh for nicely-formatted RPM installs

The -v and -h options (which are combined with -U) cause rpm to print more verbose output and display a progress meter using hash signs.
If the upgrade/installation is successful, the following output is displayed:
Preparing...                ########################################### [100%]
   1:tree                   ########################################### [100%]

Always use the -i (install) option to install new kernel packages!

rpm provides two different options for installing packages: the aforementioned -U option (which historically stands for upgrade), and the -i option, historically standing for install. Because the -U option subsumes both install and upgrade functions, we recommend to use rpm -Uvh with all packages except kernel packages.
You should always use the -i option to simply install a new kernel package instead of upgrading it. This is because using the -U option to upgrade a kernel package removes the previous (older) kernel package, which could render the system unable to boot if there is a problem with the new kernel. Therefore, use the rpm -i <kernel_package> command to install a new kernel without replacing any older kernel packages. For more information on installing kernel packages, refer to Chapter 23, Manually Upgrading the Kernel.
The signature of a package is checked automatically when installing or upgrading a package. The signature confirms that the package was signed by an authorized party. For example, if the verification of the signature fails, an error message such as the following is displayed:
error: tree-1.5.3-2.el6.x86_64.rpm: Header V3 RSA/SHA256 signature: BAD, key ID
d22e77f2
If it is a new, header-only, signature, an error message such as the following is displayed:
error: tree-1.5.3-2.el6.x86_64.rpm: Header V3 RSA/SHA256 signature: BAD,
key ID d22e77f2
If you do not have the appropriate key installed to verify the signature, the message contains the word NOKEY:
warning: tree-1.5.3-2.el6.x86_64.rpm: Header V3 RSA/SHA1 signature: NOKEY, key ID 57bbccba
Refer to Section 3.3, “Checking a Package's Signature” for more information on checking a package's signature.

3.2.2.1. Package Already Installed

If a package of the same name and version is already installed , the following output is displayed:
Preparing...                ########################################### [100%]
	package tree-1.5.3-2.el6.x86_64 is already installed
However, if you want to install the package anyway, you can use the --replacepkgs option, which tells RPM to ignore the error:
rpm -Uvh --replacepkgs tree-1.5.3-2.el6.x86_64.rpm
This option is helpful if files installed from the RPM were deleted or if you want the original configuration files from the RPM to be installed.

3.2.2.2. Conflicting Files

If you attempt to install a package that contains a file which has already been installed by another package , the following is displayed:
Preparing... ##################################################
 file /usr/bin/foobar from install of foo-1.0-1.el6.x86_64 conflicts
with file from package bar-3.1.1.el6.x86_64
To make RPM ignore this error, use the --replacefiles option:
rpm -Uvh --replacefiles foo-1.0-1.el6.x86_64.rpm

3.2.2.3. Unresolved Dependency

RPM packages may sometimes depend on other packages , which means that they require other packages to be installed to run properly. If you try to install a package which has an unresolved dependency, output similar to the following is displayed:
error: Failed dependencies:
	bar.so.3()(64bit) is needed by foo-1.0-1.el6.x86_64
If you are installing a package from the Red Hat Enterprise Linux installation media, such as from a CD-ROM or DVD, the dependencies may be available. Find the suggested package(s) on the Red Hat Enterprise Linux installation media or on one of the active Red Hat Enterprise Linux mirrors and add it to the command:
rpm -Uvh foo-1.0-1.el6.x86_64.rpm    bar-3.1.1.el6.x86_64.rpm
If installation of both packages is successful, output similar to the following is displayed:
Preparing...                ########################################### [100%]
   1:foo                   ########################################### [ 50%]
   2:bar                   ########################################### [100%]
You can try the --whatprovides option to determine which package contains the required file.
rpm -q --whatprovides "bar.so.3"
If the package that contains bar.so.3 is in the RPM database, the name of the package is displayed:
bar-3.1.1.el6.i586.rpm

Warning: Forcing Package Installation

Although we can force rpm to install a package that gives us a Failed dependencies error (using the --nodeps option), this is not recommended, and will usually result in the installed package failing to run. Installing or removing packages with rpm --nodeps can cause applications to misbehave and/or crash, and can cause serious package management problems or, possibly, system failure. For these reasons, it is best to heed such warnings; the package manager—whether RPM, Yum or PackageKit—shows us these warnings and suggests possible fixes because accounting for dependencies is critical. The Yum package manager can perform dependency resolution and fetch dependencies from online repositories, making it safer, easier and smarter than forcing rpm to carry out actions without regard to resolving dependencies.

3.2.3. Configuration File Changes

Because RPM performs intelligent upgrading of packages with configuration files , you may see one or the other of the following messages:
saving /etc/foo.conf as /etc/foo.conf.rpmsave
This message means that changes you made to the configuration file may not be forward-compatible with the new configuration file in the package, so RPM saved your original file and installed a new one. You should investigate the differences between the two configuration files and resolve them as soon as possible, to ensure that your system continues to function properly.
Alternatively, RPM may save the package's new configuration file as, for example, foo.conf.rpmnew, and leave the configuration file you modified untouched. You should still resolve any conflicts between your modified configuration file and the new one, usually by merging changes from the old one to the new one with a diff program.
If you attempt to upgrade to a package with an older version number (that is, if a higher version of the package is already installed), the output is similar to the following:
package foo-2.0-1.el6.x86_64.rpm (which is newer than foo-1.0-1) is already installed
To force RPM to upgrade anyway, use the --oldpackage option:
rpm -Uvh --oldpackage foo-1.0-1.el6.x86_64.rpm

3.2.4. Uninstalling

Uninstalling a package is just as simple as installing one. Type the following command at a shell prompt:
rpm -e foo

Note

Notice that we used the package name foo, not the name of the original package file, foo-1.0-1.el6.x86_64. If you attempt to uninstall a package using the rpm -e command and the original full file name, you will receive a package name error.
You can encounter dependency errors when uninstalling a package if another installed package depends on the one you are trying to remove. For example:
rpm -e ghostscript
error: Failed dependencies:
	libgs.so.8()(64bit) is needed by (installed) libspectre-0.2.2-3.el6.x86_64
	libgs.so.8()(64bit) is needed by (installed) foomatic-4.0.3-1.el6.x86_64
	libijs-0.35.so()(64bit) is needed by (installed) gutenprint-5.2.4-5.el6.x86_64
	ghostscript is needed by (installed) printer-filters-1.1-4.el6.noarch
Similar to how we searched for a shared object library (i.e. a <library_name>.so.<number> file) in Section 3.2.2.3, “Unresolved Dependency”, we can search for a 64-bit shared object library using this exact syntax (and making sure to quote the file name):
~]# rpm -q --whatprovides "libgs.so.8()(64bit)"
ghostscript-8.70-1.el6.x86_64

Warning: Forcing Package Installation

Although we can force rpm to remove a package that gives us a Failed dependencies error (using the --nodeps option), this is not recommended, and may cause harm to other installed applications. Installing or removing packages with rpm --nodeps can cause applications to misbehave and/or crash, and can cause serious package management problems or, possibly, system failure. For these reasons, it is best to heed such warnings; the package manager—whether RPM, Yum or PackageKit—shows us these warnings and suggests possible fixes because accounting for dependencies is critical. The Yum package manager can perform dependency resolution and fetch dependencies from online repositories, making it safer, easier and smarter than forcing rpm to carry out actions without regard to resolving dependencies.

3.2.5. Freshening

Freshening is similar to upgrading, except that only existent packages are upgraded. Type the following command at a shell prompt:
rpm -Fvh foo-2.0-1.el6.x86_64.rpm
RPM's freshen option checks the versions of the packages specified on the command line against the versions of packages that have already been installed on your system. When a newer version of an already-installed package is processed by RPM's freshen option, it is upgraded to the newer version. However, RPM's freshen option does not install a package if no previously-installed package of the same name exists. This differs from RPM's upgrade option, as an upgrade does install packages whether or not an older version of the package was already installed.
Freshening works for single packages or package groups. If you have just downloaded a large number of different packages, and you only want to upgrade those packages that are already installed on your system, freshening does the job. Thus, you do not have to delete any unwanted packages from the group that you downloaded before using RPM.
In this case, issue the following with the *.rpm glob:
rpm -Fvh *.rpm
RPM then automatically upgrades only those packages that are already installed.

3.2.6. Querying

The RPM database stores information about all RPM packages installed in your system. It is stored in the directory /var/lib/rpm/, and is used to query what packages are installed, what versions each package is, and to calculate any changes to any files in the package since installation, among other use cases.
To query this database, use the -q option. The rpm -q package name command displays the package name, version, and release number of the installed package <package_name>. For example, using rpm -q tree to query installed package tree might generate the following output:
tree-1.5.2.2-4.el6.x86_64
You can also use the following Package Selection Options (which is a subheading in the RPM man page: see man rpm for details) to further refine or qualify your query:
  • -a — queries all currently installed packages.
  • -f <file_name> — queries the RPM database for which package owns <file_name> . Specify the absolute path of the file (for example, rpm -qf /bin/ls instead of rpm -qf ls).
  • -p <package_file> — queries the uninstalled package <package_file> .
There are a number of ways to specify what information to display about queried packages. The following options are used to select the type of information for which you are searching. These are called the Package Query Options.
  • -i displays package information including name, description, release, size, build date, install date, vendor, and other miscellaneous information.
  • -l displays the list of files that the package contains.
  • -s displays the state of all the files in the package.
  • -d displays a list of files marked as documentation (man pages, info pages, READMEs, etc.) in the package.
  • -c displays a list of files marked as configuration files. These are the files you edit after installation to adapt and customize the package to your system (for example, sendmail.cf, passwd, inittab, etc.).
For options that display lists of files, add -v to the command to display the lists in a familiar ls -l format.

3.2.7. Verifying

Verifying a package compares information about files installed from a package with the same information from the original package. Among other things, verifying compares the file size, MD5 sum, permissions, type, owner, and group of each file.
The command rpm -V verifies a package. You can use any of the Verify Options listed for querying to specify the packages you wish to verify. A simple use of verifying is rpm -V tree, which verifies that all the files in the tree package are as they were when they were originally installed. For example:
  • To verify a package containing a particular file:
    rpm -Vf /usr/bin/tree
    In this example, /usr/bin/tree is the absolute path to the file used to query a package.
  • To verify ALL installed packages throughout the system (which will take some time):
    rpm -Va
  • To verify an installed package against an RPM package file:
    rpm -Vp tree-1.5.3-2.el6.x86_64.rpm
    This command can be useful if you suspect that your RPM database is corrupt.
If everything verified properly, there is no output. If there are any discrepancies, they are displayed. The format of the output is a string of eight characters (a "c" denotes a configuration file) and then the file name. Each of the eight characters denotes the result of a comparison of one attribute of the file to the value of that attribute recorded in the RPM database. A single period (.) means the test passed. The following characters denote specific discrepancies:
  • 5 — MD5 checksum
  • S — file size
  • L — symbolic link
  • T — file modification time
  • D — device
  • U — user
  • G — group
  • M — mode (includes permissions and file type)
  • ? — unreadable file (file permission errors, for example)
If you see any output, use your best judgment to determine if you should remove the package, reinstall it, or fix the problem in another way.

3.3. Checking a Package's Signature

If you wish to verify that a package has not been corrupted or tampered with, examine only the md5sum by typing the following command at a shell prompt (where <rpm_file> is the file name of the RPM package):
rpm -K --nosignature <rpm_file> 
The message <rpm_file>: rsa sha1 (md5) pgp md5 OK (specifically the OK part of it) is displayed. This brief message means that the file was not corrupted during download. To see a more verbose message, replace -K with -Kvv in the command.
On the other hand, how trustworthy is the developer who created the package? If the package is signed with the developer's GnuPG key, you know that the developer really is who they say they are.
An RPM package can be signed using Gnu Privacy Guard (or GnuPG), to help you make certain your downloaded package is trustworthy.
GnuPG is a tool for secure communication; it is a complete and free replacement for the encryption technology of PGP, an electronic privacy program. With GnuPG, you can authenticate the validity of documents and encrypt/decrypt data to and from other recipients. GnuPG is capable of decrypting and verifying PGP 5.x files as well.
During installation, GnuPG is installed by default. That way you can immediately start using GnuPG to verify any packages that you receive from Red Hat. Before doing so, you must first import Red Hat's public key.

3.3.1. Importing Keys

To verify Red Hat packages, you must import the Red Hat GPG key. To do so, execute the following command at a shell prompt:
rpm --import /usr/share/rhn/RPM-GPG-KEY
To display a list of all keys installed for RPM verification, execute the command:
rpm -qa gpg-pubkey*
For the Red Hat key, the output includes:
gpg-pubkey-db42a60e-37ea5438
To display details about a specific key, use rpm -qi followed by the output from the previous command:
rpm -qi gpg-pubkey-db42a60e-37ea5438

3.3.2. Verifying Signature of Packages

To check the GnuPG signature of an RPM file after importing the builder's GnuPG key, use the following command (replace <rpm-file> with the filename of the RPM package):
rpm -K <rpm-file> 
If all goes well, the following message is displayed: md5 gpg OK. This means that the signature of the package has been verified, that it is not corrupt, and therefore is safe to install and use.

3.4. Practical and Common Examples of RPM Usage

RPM is a useful tool for both managing your system and diagnosing and fixing problems. The best way to make sense of all its options is to look at some examples.
  • Perhaps you have deleted some files by accident, but you are not sure what you deleted. To verify your entire system and see what might be missing, you could try the following command:
    rpm -Va
    If some files are missing or appear to have been corrupted, you should probably either re-install the package or uninstall and then re-install the package.
  • At some point, you might see a file that you do not recognize. To find out which package owns it, enter:
    rpm -qf /usr/bin/ghostscript
    The output would look like the following:
    ghostscript-8.70-1.el6.x86_64
  • We can combine the above two examples in the following scenario. Say you are having problems with /usr/bin/paste. You would like to verify the package that owns that program, but you do not know which package owns paste. Enter the following command,
    rpm -Vf /usr/bin/paste
    and the appropriate package is verified.
  • Do you want to find out more information about a particular program? You can try the following command to locate the documentation which came with the package that owns that program:
    rpm -qdf /usr/bin/free
    The output would be similar to the following:
    /usr/share/doc/procps-3.2.8/BUGS
    /usr/share/doc/procps-3.2.8/FAQ
    /usr/share/doc/procps-3.2.8/NEWS
    /usr/share/doc/procps-3.2.8/TODO
    /usr/share/man/man1/free.1.gz
    /usr/share/man/man1/pgrep.1.gz
    /usr/share/man/man1/pkill.1.gz
    /usr/share/man/man1/pmap.1.gz
    /usr/share/man/man1/ps.1.gz
    /usr/share/man/man1/pwdx.1.gz
    /usr/share/man/man1/skill.1.gz
    /usr/share/man/man1/slabtop.1.gz
    /usr/share/man/man1/snice.1.gz
    /usr/share/man/man1/tload.1.gz
    /usr/share/man/man1/top.1.gz
    /usr/share/man/man1/uptime.1.gz
    /usr/share/man/man1/w.1.gz
    /usr/share/man/man1/watch.1.gz
    /usr/share/man/man5/sysctl.conf.5.gz
    /usr/share/man/man8/sysctl.8.gz
    /usr/share/man/man8/vmstat.8.gz
  • You may find a new RPM, but you do not know what it does. To find information about it, use the following command:
    rpm -qip crontabs-1.10-32.1.el6.noarch.rpm
    The output would be similar to the following:
    Name        : crontabs                     Relocations: (not relocatable)
    Version     : 1.10                              Vendor: Red Hat, Inc.
    Release     : 32.1.el6                      Build Date: Thu 03 Dec 2009 02:17:44 AM CET
    Install Date: (not installed)               Build Host: js20-bc1-11.build.redhat.com
    Group       : System Environment/Base       Source RPM: crontabs-1.10-32.1.el6.src.rpm
    Size        : 2486                             License: Public Domain and GPLv2
    Signature   : RSA/8, Wed 24 Feb 2010 08:46:13 PM CET, Key ID 938a80caf21541eb
    Packager    : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>
    Summary     : Root crontab files used to schedule the execution of programs
    Description :
    The crontabs package contains root crontab files and directories.
    You will need to install cron daemon to run the jobs from the crontabs.
    The cron daemon such as cronie or fcron checks the crontab files to
    see when particular commands are scheduled to be executed.  If commands
    are scheduled, it executes them.
    Crontabs handles a basic system function, so it should be installed on
    your system.
  • Perhaps you now want to see what files the crontabs RPM package installs. You would enter the following:
    rpm -qlp crontabs-1.10-32.1.el6.noarch.rpm
    The output is similar to the following:
    /etc/cron.daily
    /etc/cron.hourly
    /etc/cron.monthly
    /etc/cron.weekly
    /etc/crontab
    /usr/bin/run-parts
    /usr/share/man/man4/crontabs.4.gz
These are just a few examples. As you use RPM, you may find more uses for it.

3.5. Additional Resources

RPM is an extremely complex utility with many options and methods for querying, installing, upgrading, and removing packages. Refer to the following resources to learn more about RPM.

3.5.1. Installed Documentation

  • rpm --help — This command displays a quick reference of RPM parameters.
  • man rpm — The RPM man page gives more detail about RPM parameters than the rpm --help command.

3.5.2. Useful Websites

Part III. System Configuration

Part of a system administrator's job is configuring the system for various tasks, types of users, and hardware configurations. This section explains how to configure a Red Hat Enterprise Linux system.

Table of Contents

13. Date and Time Configuration
13.1. Date/Time Properties Tool
13.1.1. Date and Time Properties
13.1.2. Network Time Protocol Properties
13.1.3. Time Zone Properties
13.2. Command Line Configuration
13.2.1. Date and Time Setup
13.2.2. Network Time Protocol Setup
14. Keyboard Configuration
14.1. Changing the Keyboard Layout
14.2. Adding the Keyboard Layout Indicator
14.3. Setting Up a Typing Break
15. Users and Groups
15.1. User and Group Configuration
15.1.1. Adding a New User
15.1.2. Adding a New Group
15.1.3. Modifying Group Properties
15.2. User and Group Management Tools
15.2.1. Command Line Configuration
15.2.2. Explaining the Process
15.3. Standard Users
15.4. Standard Groups
15.5. User Private Groups
15.5.1. Group Directories
15.6. Shadow Passwords
15.7. Additional Resources
15.7.1. Installed Documentation
16. Automated Tasks
16.1. Cron and Anacron
16.1.1. Starting and Stopping the Service
16.1.2. Configuring Anacron Jobs
16.1.3. Configuring Cron Jobs
16.1.4. Controlling Access to Cron
16.1.5. Black/White Listing of Cron Jobs
16.2. At and Batch
16.2.1. Configuring At Jobs
16.2.2. Configuring Batch Jobs
16.2.3. Viewing Pending Jobs
16.2.4. Additional Command Line Options
16.2.5. Controlling Access to At and Batch
16.2.6. Starting and Stopping the Service
16.3. Additional Resources
16.3.1. Installed Documentation
17. Log Files
17.1. Configuring rsyslog
17.1.1. Modules
17.1.2. Global Directives
17.1.3. Rules
17.1.4. Templates
17.1.5. Filter Conditions
17.1.6. Output Channels
17.2. rsyslog Performance
17.3. Locating Log Files
17.3.1. Configuring logrotate
17.4. Viewing Log Files
17.5. Adding a Log File
17.6. Monitoring Log Files
17.7. Additional Resources
17.7.1. Installed Documentation
17.7.2. Useful Websites
18. The sysconfig Directory
18.1. Files in the /etc/sysconfig/ Directory
18.1.1. /etc/sysconfig/arpwatch
18.1.2. /etc/sysconfig/authconfig
18.1.3. /etc/sysconfig/autofs
18.1.4. /etc/sysconfig/clock
18.1.5. /etc/sysconfig/dhcpd
18.1.6. /etc/sysconfig/firstboot
18.1.7. /etc/sysconfig/i18n
18.1.8. /etc/sysconfig/init