Product SiteDocumentation Site

Fedora 14

Deployment Guide

Deployment, configuration and administration of Fedora 14

Edition 1.0

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, 2011 Red Hat, Inc. and others.
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 The original authors of this document, and Red Hat, designate the Fedora Project as the "Attribution Party" for purposes of CC-BY-SA. 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.
For guidelines on the permitted uses of the Fedora trademarks, refer to
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.
The Deployment Guide documents relevant information regarding the deployment, configuration and administration of Fedora 14.

1. Document Conventions
2. We Need Feedback!
3. Acknowledgements
I. Package Management
1. Yum
1.1. Checking For and Updating Packages
1.2. Packages and Package Groups
1.3. Configuring Yum and Yum Repositories
1.4. Yum Plugins
1.5. Additional Resources
2. PackageKit
2.1. Updating Packages with Software Update
2.2. Using Add/Remove Software
2.3. PackageKit Architecture
2.4. Additional Resources
3. RPM
3.1. RPM Design Goals
3.2. Using RPM
3.3. Checking a Package's Signature
3.4. Practical and Common Examples of RPM Usage
3.5. Additional Resources
II. Network-Related Configuration
4. Network Interfaces
4.1. Network Configuration Files
4.2. Interface Configuration Files
4.3. Interface Control Scripts
4.4. Configuring Static Routes
4.5. Network Function Files
4.6. Additional Resources
5. Network Configuration
5.1. The NetworkManager Daemon
5.2. Interacting with NetworkManager
5.3. Configuring Connection Settings
6. Dynamic Host Configuration Protocol (DHCP)
6.1. Why Use DHCP?
6.2. Configuring a DHCP Server
6.3. Configuring a DHCP Client
6.4. Configuring a Multihomed DHCP Server
6.5. DHCP for IPv6 (DHCPv6)
6.6. Additional Resources
7. Controlling Access to Services
7.1. Configuring the Default Runlevel
7.2. Configuring the Services
7.3. Running the Services
7.4. Additional Resources
8. Authentication Configuration
8.1. The Authentication Configuration Tool
8.2. The System Security Services Daemon (SSSD)
9. OpenSSH
9.1. The SSH Protocol
9.2. An OpenSSH Configuration
9.3. OpenSSH Clients
9.4. More Than a Secure Shell
9.5. Additional Resources
10. The BIND DNS Server
10.1. Introduction to DNS
10.2. Configuring the named Service
10.3. Editing Zone Files
10.4. Using the rndc Utility
10.5. Using the dig Utility
10.6. Advanced Features of BIND
10.7. Common Mistakes to Avoid
10.8. Additional Resources
11. The Apache HTTP Server
11.1. The Apache HTTP Server 2.2
11.2. Running the httpd Service
11.3. Editing the Configuration Files
11.4. Working with Modules
11.5. Setting Up Virtual Hosts
11.6. Setting Up an SSL Server
11.7. Additional Resources
12. Email
12.1. Email Protocols
12.2. Email Program Classifications
12.3. Mail Transport Agents
12.4. Mail Delivery Agents
12.5. Mail User Agents
12.6. Additional Resources
III. System Configuration
13. Date and Time Configuration
13.1. Date/Time Properties Tool
13.2. Command Line Configuration
14. Keyboard Configuration
14.1. Changing the Keyboard Layout
14.2. Using Multiple Keyboard Layouts
14.3. Setting Up a Typing Break
15. Users and Groups
15.1. User and Group Configuration
15.2. User and Group Management Tools
15.3. Standard Users
15.4. Standard Groups
15.5. User Private Groups
15.6. Shadow Passwords
15.7. Additional Resources
16. Automated Tasks
16.1. Cron and Anacron
16.2. At and Batch
16.3. Additional Resources
17. Log Files
17.1. Configuring rsyslog
17.2. rsyslog Performance
17.3. Locating Log Files
17.4. Viewing Log Files
17.5. Adding a Log File
17.6. Monitoring Log Files
17.7. Additional Resources
18. The sysconfig Directory
18.1. Files in the /etc/sysconfig/ Directory
18.2. Directories in the /etc/sysconfig/ Directory
18.3. Additional Resources
19. The proc File System
19.1. A Virtual File System
19.2. Top-level Files within the proc File System
19.3. Directories within /proc/
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
21. ABRT
21.1. Overview
21.2. Installing and Running ABRT
21.3. ABRT Plugins
21.4. Generating Backtraces
21.5. Using the Command Line Interface
21.6. Configuring ABRT
21.7. Configuring Centralized Crash Collection
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.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
24. The kdump Crash Recovery Service
24.1. Configuring the kdump Service
24.2. Analyzing the Core Dump
24.3. Additional Resources
A. Revision History


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 at a shell prompt. If the remote machine is and your username on that machine is john, type ssh
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,, 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:

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.


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 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.


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: against the product Fedora Documentation.
When submitting a bug report, be sure to mention the manual's identifier: deployment-guide and version number: 14.
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."
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."
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."
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."
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
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.


Welcome to the Fedora 14 Deployment Guide.
The Deployment Guide contains information on how to customize your Fedora 14 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 Fedora system. If you need help installing Fedora, refer to the Fedora 14 Installation Guide.

Part I. Package Management

Chapter 1. Yum

Yum is the The Fedora Project 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 The Fedora Project, 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.3-0.1.20090915git.fc12  fedora
PackageKit-glib.x86_64             0.5.3-0.1.20090915git.fc12  fedora
PackageKit-yum.x86_64              0.5.3-0.1.20090915git.fc12  fedora
PackageKit-yum-plugin.x86_64       0.5.3-0.1.20090915git.fc12  fedora
glibc.x86_64                       2.10.90-22                  fedora
glibc-common.x86_64                2.10.90-22                  fedora
kernel.x86_64                      2.6.31-14.fc12              fedora
kernel-firmware.noarch             2.6.31-14.fc12              fedora
rpm.x86_64                         4.7.1-5.fc12                fedora
rpm-libs.x86_64                    4.7.1-5.fc12                fedora
rpm-python.x86_64                  4.7.1-5.fc12                fedora
yum.noarch                         3.2.24-4.fc12               fedora
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.3-0.1.20090915git.fc12 — the version of the updated package to be installed
  • fedora — 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 glibc
Loaded plugins: presto, refresh-packagekit, security
Setting up Install Process
Resolving Dependencies
--> Running transaction check
--> Processing Dependency: glibc = 2.10.90-21 for package: glibc-common-2.10.90-21.x86_64
---> Package glibc.x86_64 0:2.10.90-22 set to be updated
--> Running transaction check
---> Package glibc-common.x86_64 0:2.10.90-22 set to be updated
--> Finished Dependency Resolution
Dependencies Resolved
 Package            Arch         Version          Repository     Size
 glibc              x86_64       2.10.90-22       fedora       2.7 M
Updating for dependencies:
 glibc-common       x86_64       2.10.90-22       fedora       6.0 M
Transaction Summary
Install       0 Package(s)
Upgrade       2 Package(s)
Total download size: 8.7 M
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 Fedora 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, security
=============================== Matched: kompare ===============================
kdesdk.x86_64 : The KDE Software Development Kit (SDK)
komparator.x86_64 : Kompare and merge two folders
================================ Matched: meld =================================
meld.noarch : Visual diff and merge tool
python-meld3.x86_64 : An HTML/XML templating system for Python
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 gimp\*plugin\*
Loaded plugins: presto, refresh-packagekit, security
Available Packages
gimp-fourier-plugin.x86_64       0.3.2-3.fc11        fedora
gimp-lqr-plugin.x86_64           0.6.1-2.fc11        updates

Example 1.3. Filtering results using a double-quoted glob expression
~]# yum list installed "krb?-*"
Loaded plugins: presto, refresh-packagekit, security
Installed Packages
krb5-auth-dialog.x86_64         0.12-2.fc12         @fedora
krb5-libs.x86_64                1.7-8.fc12          @fedora
krb5-workstation.x86_64         1.7-8.fc12          @fedora

  • 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, security
    Installed Packages
    abrt-addon-ccpp.x86_64                          0.0.9-2.fc12            @fedora
    abrt-addon-kerneloops.x86_64                    0.0.9-2.fc12            @fedora
    abrt-addon-python.x86_64                        0.0.9-2.fc12            @fedora
    abrt-plugin-bugzilla.x86_64                     0.0.9-2.fc12            @fedora
    abrt-plugin-kerneloopsreporter.x86_64           0.0.9-2.fc12            @fedora
    abrt-plugin-sqlite3.x86_64                      0.0.9-2.fc12            @fedora
    Available Packages
    abrt-plugin-filetransfer.x86_64                 0.0.9-2.fc12            fedora
    abrt-plugin-logger.x86_64                       0.0.9-2.fc12            fedora
    abrt-plugin-mailx.x86_64                        0.0.9-2.fc12            fedora
    abrt-plugin-runapp.x86_64                       0.0.9-2.fc12            fedora
    abrt-plugin-sosreport.x86_64                    0.0.9-2.fc12            fedora
    abrt-plugin-ticketuploader.x86_64               0.0.9-2.fc12            fedora

  • 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, security
Installed Packages
Name       : abrt
Arch       : x86_64
Version    : 0.0.9
Release    : 2.fc12
Size       : 525 k
Repo       : installed
From repo  : fedora
Summary    : Automatic bug detection and reporting tool
URL        :
License    : GPLv2+
Description: abrt is a tool to help users to detect defects in applications and
           : to create bug reports that include all information required by the
           : maintainer to hopefully resolve it. It uses a 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
     checksum_data = 8d7773ec28c954c69c053ea4bf61dec9fdea11a59c50a2c31d1aa2e24bc611d9
     checksum_type = sha256
     command_line = update
     from_repo = updates
     from_repo_revision = 1272392716
     from_repo_timestamp = 1272414297
     reason = user
     releasever = 12
See man yumdb for more information on the yumdb command.
Finally, the yum history command, which is new in Fedora 14, 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, security
32:bind-9.6.1-0.3.b1.fc11.x86_64 : The Berkeley Internet Name Domain (BIND) DNS (Domain Name System) server
Repo        : fedora
Matched from:
Filename    : /usr/sbin/named
~]# yum install bind


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:
[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:
...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.
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.
...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.
...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.
...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.
...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.
...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.
...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.
This option specifies where yum should send its logging output. By default, yum logs to /var/log/yum.log.
...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.
...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.
...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.
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/.
...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:
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:
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:
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:password@link. For example, if a repository on requires a username of "user" and a password of "password", then the baseurl link could be specified as:
The following is another useful [repository] directive:
...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/.
You can use this variable to reference the release version of Fedora. 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.
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.
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.
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


    Because RPM packages for Fedora 14 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 Fedora 5 to create the package metadata for Fedora 14 packages. The createrepo command relies on rpm to open and inspect the packages, and rpm on Fedora 5 is not able to open the improved Fedora 14 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:
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

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.pre3.fc11       fedora
kernel.x86_64                   fedora
kernel-headers.x86_64           fedora
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- package is installed on your system;
  • the kernel- package was released as a security update;
  • then kernel- was released as a bug fix update,
...then yum update-minimal --security will update you to kernel-, and yum update --security will update you to kernel- 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 —
The Yum Guides section of the wiki contains more Yum documentation.
Managing Software with Yum
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:
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.
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
Software Update Perform package updates
From the GNOME panel: SystemAdministrationSoftware Update
Software Sources Enable and disable Yum repositories
From Add/Remove Software: SystemSoftware sources
Software Log Viewer View the transaction log
From Add/Remove Software: SystemSoftware 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

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 —
Information about and mailing lists for PackageKit.
PackageKit FAQ —
An informative list of Frequently Asked Questions for the PackageKit software suite.
PackageKit Feature Matrix —
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 Fedora 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 Fedora 14. 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.


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.


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:
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 Fedora, 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 Fedora 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 Fedora package repositories.
  • The active Fedora mirrors contains many installable RPMs:
  • Unofficial, third-party repositories not ahffiliated Red Hat also provide RPM packages.


    When considering third-party repositories for use with your Fedora 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 Fedora repositories.

3.2.2. Installing and Upgrading

RPM packages typically have file names like tree-1.5.3-2.fc14.x86_64.rpm. The file name includes the package name (tree), version (1.5.3), release (2), operating system major version (fc14) 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.fc14.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.fc14.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- Header V3 RSA/SHA256 signature: BAD, key ID
If it is a new, header-only, signature, an error message such as the following is displayed:
error: tree- 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- 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. 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.fc14.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.fc14.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. 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.fc14.x86_64 conflicts
with file from package bar-3.1.1.fc14.x86_64
To make RPM ignore this error, use the --replacefiles option:
rpm -Uvh --replacefiles foo-1.0-1.fc14.x86_64.rpm 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: is needed by foo-1.0-1.fc14.x86_64
If you are installing a package from the Fedora installation media, such as from a CD-ROM or DVD, the dependencies may be available. Find the suggested package(s) on the Fedora installation media or on one of the active Fedora mirrors and add it to the command:
rpm -Uvh foo-1.0-1.fc14.x86_64.rpm    bar-3.1.1.fc14.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 ""
If the package that contains is in the RPM database, the name of the package is displayed:

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.fc14.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.fc14.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


Notice that we used the package name foo, not the name of the original package file, foo-1.0-1.fc14.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: is needed by (installed) libspectre-0.2.2-3.fc14.x86_64 is needed by (installed) foomatic-4.0.3-1.fc14.x86_64 is needed by (installed) gutenprint-5.2.4-5.fc14.x86_64
	ghostscript is needed by (installed) printer-filters-1.1-4.fc14.noarch
Similar to how we searched for a shared object library (i.e. a <library_name>.so.<number> file) in Section, “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 ""

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.fc14.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:
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,, 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-
    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, you can examine just the md5sum by entering this command at the shell prompt: (where <rpm_file> is the file name of the RPM package):
rpm -K --nosignature <rpm_file> 
The output <rpm_file>: rsa sha1 (md5) pgp md5 OK (specifically the OK part of it) indicates 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 defaut, which enables you to immediately start using it to verify any packages that you download from the Fedora Project. Before doing so, you first need to import the correct Fedora key.

3.3.1. Importing Keys

Fedora GnuPG keys are located in the /etc/pki/rpm-gpg/ directory. To verify a Fedora Project package, first import the correct key based on your processor architecture:
rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-x86_64
To display a list of all keys installed for RPM verification, execute the command:
rpm -qa gpg-pubkey*
For the Fedora Project key, the output states:
To display details about a specific key, use rpm -qi followed by the output from the previous command:
rpm -qi gpg-pubkey-57bbccba-4a6f97af

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: rsa sha1 (md5) pgp md5 OK. This means that the signature of the package has been verified, that it is not corrupt, and is therefore safe to install and use.
For more information, including a list of currently-used Fedora Project keys and their fingerprints, refer to

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:
  • 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:
  • 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-31.fc14.noarch.rpm
    The output would be similar to the following:
    Name        : crontabs                     Relocations: (not relocatable)
    Size        : 2486                             License: Public Domain and GPLv2
    Signature   : RSA/SHA1, Tue 11 Aug 2009 01:11:19 PM CEST, Key ID 9d1cc34857bbccba
    Packager    : Fedora Project
    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-31.fc14.noarch.rpm
    The output is similar to the following:
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

Chapter 13. Date and Time Configuration

This chapter covers setting the system date and time in Fedora, both manually and using the Network Time Protocol (NTP), as well as setting the adequate time zone. Two methods are covered: setting the date and time using the Date/Time Properties tool, and doing so on the command line.

13.1. Date/Time Properties Tool

The Date/Time Properties tool allows the user to change the system date and time, to configure the time zone used by the system, and to set up the Network Time Protocol daemon to synchronize the system clock with a time server. Note that to use this application, you must be running the X Window System.
To start the tool, select SystemAdministrationDate & Time from the panel, or type the system-config-date command at a shell prompt (e.g., xterm or GNOME Terminal). Unless you are already authenticated, you will be prompted to enter the superuser password.
Authentication Query
Figure 13.1. Authentication Query

13.1.1. Date and Time Properties

As shown in Figure 13.2, “Date and Time Properties”, the Date/Time Properties tool is divided into two separate tabs. The tab containing the configuration of the current date and time is shown by default.
Date and Time Properties
Date and Time Properties
Figure 13.2. Date and Time Properties

To set up your system manually, follow these steps:
  1. Change the current date. Use the arrows to the left and right of the month and year to change the month and year respectively. Then click inside the calendar to select the day of the month.
  2. Change the current time. Use the up and down arrow buttons beside the Hour, Minute, and Second, or replace the values directly.
Click the OK button to apply the changes and exit the application.

13.1.2. Network Time Protocol Properties

If you prefer an automatic setup, select the checkbox labeled Synchronize date and time over the network instead. This will display the list of available NTP servers as shown in Figure 13.3, “Network Time Protocol Properties”.
Network Time Protocol Properties
Network Time Protocol Properties
Figure 13.3. Network Time Protocol Properties

Here you can choose one of the predefined servers, edit a predefined server by clicking the Edit button, or add a new server name by clicking Add. In the Advanced Options, you can also select whether you want to synchronize the system clock before starting the service, and if you wish to use a local time source.


Your system does not start synchronizing with the NTP server until you click the OK button at the bottom of the window to confirm your changes.
Click the OK button to apply any changes made to the date and time settings and exit the application.

13.1.3. Time Zone Properties

To configure the system time zone, click the Time Zone tab as shown in Figure 13.4, “Time Zone Properties”.
Time Zone Properties
Time Zone Properties
Figure 13.4. Time Zone Properties

There are two common approaches to the time zone selection:
  1. Using the interactive map. Click “zoom in” and “zoom out” buttons next to the map, or click on the map itself to zoom into the selected region. Then choose the city specific to your time zone. A red X appears and the time zone selection changes in the list below the map.
  2. Use the list below the map. To make the selection easier, cities and countries are grouped within their specific continents. Note that non-geographic time zones have also been added to address needs in the scientific community.
If your system clock is set to use UTC, select the System clock uses UTC option. UTC stands for the Universal Time, Coordinated, also known as Greenwich Mean Time (GMT). Other time zones are determined by adding or subtracting from the UTC time.
Click OK to apply the changes and exit the program.

13.2. Command Line Configuration

In case your system does not have the Date/Time Properties tool installed, or the X Window Server is not running, you will have to change the system date and time on the command line. Note that in order to perform actions described in this section, you have to be logged in as a superuser:
~]$ su -

13.2.1. Date and Time Setup

The date command allows the superuser to set the system date and time manually:
  1. Change the current date. Type the command in the following form at a shell prompt, replacing the YYYY with a four-digit year, MM with a two-digit month, and DD with a two-digit day of the month:
    ~]# date +%D -s YYYY-MM-DD
    For example, to set the date to 2 June 2010, type:
    ~]# date +%D -s 2010-06-02
  2. Change the current time. Use the following command, where HH stands for an hour, MM is a minute, and SS is a second, all typed in a two-digit form:
    ~]# date +%T -s HH:MM:SS
    If your system clock is set to use UTC (Coordinated Universal Time), add the following option:
    ~]# date +%T -s HH:MM:SS -u
    For instance, to set the system clock to 11:26 PM using the UTC, type:
    ~]# date +%T -s 23:26:00 -u
You can check your current settings by typing date without any additional argument:
Example 13.1. Displaying the current date and time
~]$ date
Wed Jun  2 11:58:48 CEST 2010

13.2.2. Network Time Protocol Setup

As opposed to the manual setup described above, you can also synchronize the system clock with a remote server over the Network Time Protocol (NTP). For the one-time synchronization only, use the ntpdate command:
  1. Firstly, check whether the selected NTP server is accessible:
    ~]# ntpdate -q server_address
    For example:
    ~]# ntpdate -q
  2. When you find a satisfactory server, run the ntpdate command followed with on or more server addresses:
    ~]# ntpdate server_address...
    For instance:
    ~]# ntpdate
    Unless an error message is displayed, the system time should now be set. You can check the current by setting typing date without any additional arguments as shown in Section 13.2.1, “Date and Time Setup”.
  3. In most cases, these steps are sufficient. Only if you really need one or more system services to always use the correct time, enable running the ntpdate at boot time:
    ~]# chkconfig ntpdate on
    For more information about system services and their setup, see Chapter 7, Controlling Access to Services.


    If the synchronization with the time server at boot time keeps failing, i.e., you find a relevant error message in the /var/log/boot.log system log, try to add the following line to /etc/sysconfig/network:
However, the more convenient way is to set the ntpd daemon to synchronize the time at boot time automatically:
  1. Open the NTP configuration file /etc/ntp.conf in a text editor such as vi or nano, or create a new one if it does not already exist:
    ~]# nano /etc/ntp.conf
  2. Now add or edit the list of public NTP servers. If you are using Fedora 14, the file should already contain the following lines, but feel free to change or expand these according to your needs:


    To speed the initial synchronization up, add the iburst directive at the end of each server line:
    server iburst
    server iburst
    server iburst
  3. Once you have the list of servers complete, in the same file, set the proper permissions, giving the unrestricted access to localhost only:
    restrict default kod nomodify notrap nopeer noquery
    restrict -6 default kod nomodify notrap nopeer noquery
    restrict -6 ::1
  4. Save all changes, exit the editor, and restart the NTP daemon:
    ~]# service ntpd restart
  5. Make sure that ntpd daemon is started at boot time:
    ~]# chkconfig ntpd on

Chapter 14. Keyboard Configuration

This chapter describes how to change the keyboard layout and how to allow a user to switch between different keyboard layouts. It also covers the option to enforce a typing break, and explains the advantages of doing so.

14.1. Changing the Keyboard Layout

Although the installation program allows a system administrator to configure a keyboard layout during the system installation, the default settings may not always suit your current needs. Because of this, Fedora allows you to change the keyboard when you log in to the system.
To change the keyboard layout on the login screen, select your name from the list of available users, and click the pulldown list with the symbol of a keyboard that appears at the bottom of the screen. Unless the desired layout is already in the list, click the Other... option for the list of all available keyboard layouts.
Changing the keyboard layout
Changing the keyboard layout
Figure 14.1. Changing the keyboard layout

Alternatively, you can use the Keyboard Preferences utility as described in Section 14.2, “Using Multiple Keyboard Layouts”.

14.2. Using Multiple Keyboard Layouts

To configure additional keyboard layouts, run the Keyboard Preferences utility by selecting SystemPreferencesKeyboard from the panel, and click the Layouts tab.
The Keyboard Preferences utility
The Keyboard Preferences utility
Figure 14.2. The Keyboard Preferences utility

The upper part of the window provides a list of currently enabled layouts. To add a new one, click the Add... button below the list.
Choosing a layout
Choosing a layout
Figure 14.3. Choosing a layout

The Choose a Layout dialog allows you to browse the available layouts either by the country they are associated with, or by the language:
  • To choose a keyboard layout by the country, open the By country tab and select a suitable item from the Country pulldown list. Optionally, select a particular variant from the Variant pulldown list.
  • To choose a keyboard layout by the language, open the By language tab and select a suitable item from the Language pulldown list. Optionally, select a particular variant from the Variant pulldown list.
Confirm the selection by clicking the Add button. When more than one keyboard layout is enabled, a keyboard indicator appears on the panel, allowing you to click on it to switch between the layouts.
The keyboard layout indicator
The keyboard layout indicator
Figure 14.4. The keyboard layout indicator

To make a certain layout the default, click on its name to highlight it, and use the Move Up button to move it to the top of the list.

Tip: Disable Separate Layout for Each Window

By default, changing the keyboard layout affects the active window only. This means that if you change the layout and switch to another window, this window will use the old one, which might be confusing. To turn this behavior off, unselect the Separate layout for each window check box.

14.3. Setting Up a Typing Break

Typing for a long period of time can be not only tiring, but it can also increase the risk of serious health problems, such as the carpal tunnel syndrome. One way of preventing this is to configure the system to enforce a typing break.
To set up a typing break, run the Keyboard Preferences utility by selecting the SystemPreferencesKeyboard option from the panel, click the Typing Break tab, and select the Lock screen to enforce typing break check box.
Changing the typing break properties
Changing the typing break properties
Figure 14.5. Changing the typing break properties

To increase or decrease the amount of time you want to be allowed to type before the break is enforced, click the up or down button next to the Work interval lasts label respectively. You can do the same with the Break interval lasts setting to alter the length of the break itself. Finally, select the Allow postponing of breaks check box if you want to be able to delay the break in case you need to finish the work.
Taking a typing break
Taking a typing break
Figure 14.6. Taking a typing break

The next time you reach the time limit, you will be presented with a screen advising you to take a break, and a clock displaying the remaining time. If you enabled it, the Postpone Break button is located at the bottom right corner of the screen.

Chapter 15. Users and Groups

The control of users and groups is a core element of Fedora system administration.
Users can be either people (meaning accounts tied to physical users) or accounts which exist for specific applications to use.
Groups are logical expressions of organization, tying users together for a common purpose. Users within a group can read, write, or execute files owned by that group.
Each user is associated with a unique numerical identification number called a userid (UID); likewise, each group is associated with a groupid (GID).
A user who creates a file is also the owner and group owner of that file. The file is assigned separate read, write, and execute permissions for the owner, the group, and everyone else. The file owner can be changed only by the root user, and access permissions can be changed by both the root user and file owner.
Fedora also supports access control lists (ACLs) for files and directories which allow permissions for specific users outside of the owner to be set.

15.1. User and Group Configuration

The User Manager allows you to view, modify, add, and delete local users and groups.
The GNOME User Manager
the gnome user manager lets you manage users
Figure 15.1. The GNOME User Manager

You can start the User Manager by clicking SystemAdministrationUsers and Groups. Alternatively, you can enter system-config-users at the shell prompt to open the User Manager. Viewing and modifying user and group information requires superuser privileges. If you are not the superuser when you open the User Manager, it will prompt you for the superuser password.
To view a list of local users on the system, click the Users tab. To view a list of local groups on the system, click the Groups tab.
To find a specific user or group, type the first few letters of the name in the Search filter field. Press Enter or click the Apply filter button. The filtered list is displayed.
To sort the users, click on the column User Name and for groups click on Group Name. The users or groups are sorted according to the value of that column.
Fedora reserves user IDs below 500 for system users. By default, the User Manager does not display system users. To view all users, including the system users, go to Edit > Preferences and uncheck Hide system users and groups from the dialog box.

15.1.1. Adding a New User

To add a new user, click the Add User button. A window as shown in Figure 15.2, “Creating a new user” appears. Type the username and full name for the new user in the appropriate fields. Type the user's password in the Password and Confirm Password fields. The password must be at least six characters.


It is advisable to use a much longer password, as this makes it more difficult for an intruder to guess it and access the account without permission. It is also recommended that the password not be based on a dictionary term; use a combination of letters, numbers and special characters.
Select a login shell from the pulldown list. If you are not sure which shell to select, accept the default value of /bin/bash. The default home directory is /home/<username>/. You can change the home directory that is created for the user, or you can choose not to create the home directory by unselecting Create home directory.
If you select to create the home directory, default configuration files are copied from the /etc/skel/ directory into the new home directory.
Fedora uses a user private group (UPG) scheme. The UPG scheme does not add or change anything in the standard UNIX way of handling groups; it offers a new convention. Whenever you create a new user, by default, a unique group with the same name as the user is created. If you do not want to create this group, unselect Create a private group for the user.
To specify a user ID for the user, select Specify user ID manually. If the option is not selected, the next available user ID above 500 is assigned to the new user. Because Fedora reserves user IDs below 500 for system users, it is not advisable to manually assign user IDs 1-499.
Click OK to create the user.
Creating a new user
creating a new user with the create new user dialog
Figure 15.2. Creating a new user

To configure more advanced user properties, such as password expiration, modify the user's properties after adding the user.

Modifying User Properties

To view the properties of an existing user, click on the Users tab, select the user from the user list, and click Properties from the menu (or choose File > Properties from the pulldown menu). A window similar to Figure 15.3, “User Properties” appears.
User Properties
Modifying user properties
Figure 15.3. User Properties

The User Properties window is divided into multiple tabbed pages:
  • User Data — Shows the basic user information configured when you added the user. Use this tab to change the user's full name, password, home directory, or login shell.
  • Account Info — Select Enable account expiration if you want the account to expire on a certain date. Enter the date in the provided fields. Select Local password is locked to lock the user account and prevent the user from logging into the system.
  • Password Info — Displays the date that the user's password last changed. To force the user to change passwords after a certain number of days, select Enable password expiration and enter a desired value in the Days before change required: field. The number of days before the user's password expires, the number of days before the user is warned to change passwords, and days before the account becomes inactive can also be changed.
  • Groups — Allows you to view and configure the Primary Group of the user, as well as other groups that you want the user to be a member of.

15.1.2. Adding a New Group

To add a new user group, select Add Group from the toolbar. A window similar to Figure 15.4, “New Group” appears. Type the name of the new group. To specify a group ID for the new group, select Specify group ID manually and select the GID. Note that Fedora also reserves group IDs lower than 500 for system groups.
New Group
Creating a new group
Figure 15.4. New Group

Click OK to create the group. The new group appears in the group list.

15.1.3. Modifying Group Properties

To view the properties of an existing group, select the group from the group list and click Properties from the menu (or choose File > Properties from the pulldown menu). A window similar to Figure 15.5, “Group Properties” appears.
Group Properties
Modifying group properties
Figure 15.5. Group Properties

The Group Users tab displays which users are members of the group. Use this tab to add or remove users from the group. Click OK to save your changes.

15.2. User and Group Management Tools

Managing users and groups can be tiresome; this is why Fedora provides tools and conventions to make this task easier to manage.
The easiest way to manage users and groups is through the graphical application, User Manager (system-config-users). For more information on User Manager, refer to Section 15.1, “User and Group Configuration”.
The following command line tools can also be used to manage users and groups:
  • useradd, usermod, and userdel — Industry-standard methods of adding, deleting and modifying user accounts
  • groupadd, groupmod, and groupdel — Industry-standard methods of adding, deleting, and modifying user groups
  • gpasswd — Industry-standard method of administering the /etc/group file
  • pwck, grpck — Tools used for the verification of the password, group, and associated shadow files
  • pwconv, pwunconv — Tools used for the conversion of passwords to shadow passwords and back to standard passwords

15.2.1. Command Line Configuration

If you prefer command line tools or do not have the X Window System installed, use following to configure users and groups.

Adding a User

To add a user to the system:
  1. Issue the useradd command to create a locked user account:
    useradd <username> 
  2. Unlock the account by issuing the passwd command to assign a password and set password aging guidelines:
    passwd <username> 
Command line options for useradd are detailed in Table 15.1, “ useradd Command Line Options”.
Table 15.1.  useradd Command Line Options
Option Description
-c '<comment>' <comment> can be replaced with any string. This option is generally used to specify the full name of a user.
-d <home-dir> Home directory to be used instead of default /home/<username>/
-e <date> Date for the account to be disabled in the format YYYY-MM-DD
-f <days> Number of days after the password expires until the account is disabled. If 0 is specified, the account is disabled immediately after the password expires. If -1 is specified, the account is not be disabled after the password expires.
-g <group-name> Group name or group number for the user's default group. The group must exist prior to being specified here.
-G <group-list> List of additional (other than default) group names or group numbers, separated by commas, of which the user is a member. The groups must exist prior to being specified here.
-m Create the home directory if it does not exist.
-M Do not create the home directory.
-N Do not create a user private group for the user.
-p <password> The password encrypted with crypt
-r Create a system account with a UID less than 500 and without a home directory
-s User's login shell, which defaults to /bin/bash
-u <uid> User ID for the user, which must be unique and greater than 499

Adding a Group

To add a group to the system, use the command groupadd:
groupadd <group-name> 
Command line options for groupadd are detailed in Table 15.2, “ groupadd Command Line Options”.
Table 15.2.  groupadd Command Line Options
Option Description
-f, --force When used with -g <gid> and <gid> already exists, groupadd will choose another unique <gid> for the group.
-g <gid> Group ID for the group, which must be unique and greater than 499
-K, --key KEY=VALUE override /etc/login.defs defaults
-o, --non-unique allow to create groups with duplicate
-p, --password PASSWORD use this encrypted password for the new group
-r Create a system group with a GID less than 500

Password Aging

For security reasons, it is advisable to require users to change their passwords periodically. This can be done when adding or editing a user on the Password Info tab of the User Manager.
To configure password expiration for a user from a shell prompt, use the chage command with an option from Table 15.3, “ chage Command Line Options”, followed by the username.


Shadow passwords must be enabled to use the chage command. For more information, see Section 15.6, “Shadow Passwords”.
Table 15.3.  chage Command Line Options
Option Description
-d <days> Specifies the number of days since January 1, 1970 the password was changed
-E <date> Specifies the date on which the account is locked, in the format YYYY-MM-DD. Instead of the date, the number of days since January 1, 1970 can also be used.
-I <days> Specifies the number of inactive days after the password expiration before locking the account. If the value is 0, the account is not locked after the password expires.
-l Lists current account aging settings.
-m <days> Specify the minimum number of days after which the user must change passwords. If the value is 0, the password does not expire.
-M <days> Specify the maximum number of days for which the password is valid. When the number of days specified by this option plus the number of days specified with the -d option is less than the current day, the user must change passwords before using the account.
-W <days> Specifies the number of days before the password expiration date to warn the user.


If the chage command is followed directly by a username (with no options), it displays the current password aging values and allows them to be changed interactively.
You can configure a password to expire the first time a user logs in. This forces users to change passwords immediately.
  1. Set up an initial password — There are two common approaches to this step. The administrator can assign a default password or assign a null password.
    To assign a default password, use the following steps:
    • Start the command line Python interpreter with the python command. It displays the following:
      Python 2.4.3 (#1, Jul 21 2006, 08:46:09)
      [GCC 4.1.1 20060718 (Application Stack 4.1.1-9)] on linux2
      Type "help", "copyright", "credits" or "license" for more information.
    • At the prompt, type the following commands. Replace <password> with the password to encrypt and <salt> with a random combination of at least 2 of the following: any alphanumeric character, the slash (/) character or a dot (.):
      import crypt; print crypt.crypt("<password>","<salt>")
      The output is the encrypted password, similar to '12CsGd8FRcMSM'.
    • Press Ctrl-D to exit the Python interpreter.
    • At the shell, enter the following command (replacing <encrypted-password> with the encrypted output of the Python interpreter):
      usermod -p "<encrypted-password>" <username>
    Alternatively, you can assign a null password instead of an initial password. To do this, use the following command:
    usermod -p "" username


    Using a null password, while convenient, is a highly unsecure practice, as any third party can log in first and access the system using the unsecure username. Always make sure that the user is ready to log in before unlocking an account with a null password.
  2. Force immediate password expiration — Type the following command:
    chage -d 0 username
    This command sets the value for the date the password was last changed to the epoch (January 1, 1970). This value forces immediate password expiration no matter what password aging policy, if any, is in place.
Upon the initial log in, the user is now prompted for a new password.

15.2.2. Explaining the Process

The following steps illustrate what happens if the command useradd juan is issued on a system that has shadow passwords enabled:
  1. A new line for juan is created in /etc/passwd.
    The line has the following characteristics:
    • It begins with the username juan.
    • There is an x for the password field indicating that the system is using shadow passwords.
    • A UID greater than 499 is created. Under Fedora. UIDs and GIDs below 500 are reserved for system use. These should not be assigned to users.
    • A GID greater than 499 is created.
    • The optional GECOS information is left blank.
    • The home directory for juan is set to /home/juan/.
    • The default shell is set to /bin/bash.
  2. A new line for juan is created in /etc/shadow.
    The line has the following characteristics:
    • It begins with the username juan.
    • Two exclamation points (!!) appear in the password field of the /etc/shadow file, which locks the account.


      If an encrypted password is passed using the -p flag, it is placed in the /etc/shadow file on the new line for the user.
    • The password is set to never expire.
  3. A new line for a group named juan is created in /etc/group.
    A group with the same name as a user is called a user private group. For more information on user private groups, refer to Section 15.1.1, “Adding a New User”.
    The line created in /etc/group has the following characteristics:
    • It begins with the group name juan.
    • An x appears in the password field indicating that the system is using shadow group passwords.
    • The GID matches the one listed for user juan in /etc/passwd.
  4. A new line for a group named juan is created in /etc/gshadow.
    The line has the following characteristics:
    • It begins with the group name juan.
    • An exclamation point (!) appears in the password field of the /etc/gshadow file, which locks the group.
    • All other fields are blank.
  5. A directory for user juan is created in the /home/ directory.
    ls -l /home
                  drwx------. 4 juan juan 4096 Jul 9 14:55 juan
    This directory is owned by user juan and group juan. It has read, write, and execute privileges only for the user juan. All other permissions are denied.
  6. The files within the /etc/skel/ directory (which contain default user settings) are copied into the new /home/juan/ directory.
At this point, a locked account called juan exists on the system. To activate it, the administrator must next assign a password to the account using the passwd command and, optionally, set password aging guidelines.

15.3. Standard Users

Table 15.4, “Standard Users” lists the standard users configured in the /etc/passwd file by an Everything installation. The groupid (GID) in this table is the primary group for the user. See Section 15.4, “Standard Groups” for a listing of standard groups.
Table 15.4. Standard Users
User UID GID Home Directory Shell Packages
root 0 0 /root /bin/bash setup
bin 1 1 /bin /sbin/nologin setup
daemon 2 2 /sbin /sbin/nologin setup
sys - 3 - - setup
adm 3 4 /var/adm /bin/bash setup
tty - 5 - - setup
disk - 6 - - setup
lp 4 7 /var/spool/lpd /sbin/nologin setup
mem - 8 - - setup
kmem - 9 - - setup
wheel - 10 - - setup
cdrom - 11 - - udev,MAKEDEV
sync 5 (0) /sbin /bin/sync setup
shutdown 6 (0) /sbin /sbin/shutdown setup
halt 7 (0) /sbin /sbin/halt setup
mail 8 12 /var/spool/mail /sbin/nologin setup
news 9 13 /var/spool/news /sbin/nologin setup
uucp 10 14 /var/spool/uucp /sbin/nologin setup
operator 11 (0) /root /sbin/nologin setup
games 12 (100) /usr/games /sbin/nologin setup
gopher 13 30 /usr/lib/gopher-data /sbin/nologin setup
ftp 14 50 /var/ftp /sbin/nologin setup
man - 15 - - setup
oprofile 16 16 /home/oprofile /sbin/nologin oprofile
pkiuser 17 17 /usr/share/pki /sbin/nologin pki-ca,rhpki-ca
dialout - 18 -