Chapter 3. Class #3 - Software & User Management

Table of Contents

Introduction to Red Hat Software Management
The RPM Architecture
Querying for Package Information
RPM Package Naming
Uninstalling Packages
RPM over a Network
Upgrading a Kernel
Software Verification
The Red Hat Network (RHN)
Third Party Repositories
Managing & Creating a Software Repository
YUM Update Manager
Intro to User Administration
User Configuration Files
Commands for User Administration
Access Control Lists
Reference Material for this Chapter

In this session we cover two areas of importance. First we'll talk about software on the system, which is managed by the RPM (Red Hat Package Manager). The next topic of will be user management.

Introduction to Red Hat Software Management

Red Hat's RPM system is a mature way of managing software that is installed in the system. There are several working parts to the RPM system which are listed below.

The RPM Architecture

Information about the installed packages on the system (RPM meta-data) is kept in a central location - the RPM database. Running the listed commands to extract information about the packages actually queries that database. Listed below are the key elements of the RPM system.[4]

Table 3.1. RPM Architecture

RPM Component Description
RPM executable binary Located at '/usr/bin/rpm'
RPM packages Files that are installed + SPEC file (metadata)
Local RPM database Retains metadata from all installed packages. Database is kept in '/var/lib/rpm'

Querying for Package Information

Queries are made to the RPM database for information about system software using the commands listed below.

Table 3.2. Common RPM Queries

Query or `rpm` Command Result
`rpm -qa` Lists all installed packages on the system.
`rpm -q <pkg>` Reports the version of the package.
`rpm -qf /path/file` Reports which package provided the file.
`rpm -qc <pkg>` Lists all configuration files of the package.
`rpm -qd <pkg>` Lists all documentation of the package.
`rpm -qi <pkg>` Reports a description of the package.
`rpm -ql <pkg>` Lists all files contained in the package.
`rpm -qR <pkg>` Lists all dependencies of a package.
`rpm -q --scripts` Lists the scripts that run when installing/removing.
`rpm -q{c|d|i|l|R}p /path/to/packagename-ver-rel-arch.rpm` Reports the same info as above, but pulls info from the .rpm file instead of the rpm database.
`less /root/install.log` View a list of the packages originally installed on the system.
`less /var/log/yum.log` View a list of the packages installed through yum.
`man rpm` Always check the man pages.[a]
`man cpio` Man page for the utility that will copy files to and from archives.
`man rpm2cpio` Man page for the utility that will extract one or more files from a package file.

[a] Use the command `man -k <command>` to return all relevant man pages that may be appropriate.

Figure 3.1. RPM Query

RPM Query

RPM Package Naming

Red Hat uses a package naming convention that is specific in its methodology. The system is an extension of a common naming convention that is known as Semantic Versioning . There's more information about Semantic Versioning on Wikipedia . The convention looks like the following listing:


Version is the version of the "upstream" open source code. Release refers to Red Hat internal patches to the source code. Architecture is one of:

Table 3.3. RPM Architecture Naming Convention

Architecture Name Description
i386, i686 32 bit x86 compatible.
x86_64 Intel/AMD 64 bi.t
ppc64 Power PC 64 bit
ia64 Intel Itanium Processor 64 bit.
noarch Architecture independent code (scripts, docs, images, etc).
src Source code.

Listed below is a package naming example:


    Name        Version   Build     RH Release  Arch
    bash        4.1.2     8         .el6            x86_64

This package starts with version 4.1.2 of BASH , which is created and maintained by the upstream vendor - BASH in this case. A Red Hat build identified as 8.el6 specifically for Red Hat 6 has been applied to it. It is then built to run on an Intel/AMD 64 bit processor. All this is clearly indicated in the naming scheme, which is a standard package naming convention.

The process for installing and upgrading packages can take one of three general approaches. The table below shows these three approaches with a description of each.

Table 3.4. Package Installation & Upgrading

Command Description
`rpm -i[v,h] name-ver-rel.arch.rpm` Installs a package.
`rpm -U[v,h] name-ver-rel.arch.rpm` Upgrades a package if an older version was previously installed. Otherwise, simply installs the new version.
`rpm -F[v,h] name-ver-rel.arch.rpm` Upgrades a package if an older version is installed. Otherwise, does nothing; does not install new packages if no older version was installed.[a]

[a] Think of this as Freshen the package.

When packages are upgraded, especially during major or minor version changes, the config files (either the file itself or the format of the file) can be modified by the software developers. The following points show how this is handled during such upgrades:

  1. If the previous version provided a default config file, the changes are detected. Your modified version of the .conf file is saved as /etc/nifty.conf.rpmsave and the new default config is installed. You can compare the files and modify as needed.
  2. If the previous version did NOT provide a default config file, your version of the .conf file is saved as /etc/nifty.conf.rpmorig and the new default config is installed. You can compare the files and modify as needed.

Uninstalling Packages

Removing or uninstalling a package is called erasing the package. The command `rpm -e name[-ver][-rel]` will remove the package.

[Caution] Removing Packages Can Be Unforgiving & Needs No Options

The following points are important to remember when removing packages with the rpm -e command:

  1. Package removal is never verbose, never shows progress. In otherwords, the -v and -h flags have no effect.
  2. Package removal only needs the name (or when multiple versions of the same package are installed, sometimes the version or release) but not the architecture or the .rpm extension.

RPM over a Network

Packages can be installed over a network, such as from an HTTP or FTP location. The following commands show this in action:

    `rpm -ivh ftp://{Host}/path/to/packagename-ver-rel.arch.rpm`

    `rpm -ivh http://{Host}/path/to/packagename-ver-rel.arch.rpm`

Also, wildcard "globbing" is allowed:

    `rpm -ivh http://{Host}/path/to/packagename*`

Upgrading a Kernel

[Warning] Always Install Newer Kernel Versions

Don't 'upgrade' when a newer version of the kernel is available. The older kernel will remain on the system in case the new kernel becomes problematic.

Upgrading a kernel requires special consideration. Always use `#rpm -i <kernel>`. This leaves the previously installed kernel on the system and in the GRUB menu as a fall-back in case the new version has problems.

Software Verification

The RPM system satisfies two types of security concerns:

  • Is this package authentic? How do I know it came from Red Hat?
  • Has this package retained integrity? How do I know that it hasn't been modified?

Authenticity and integrity of packages can be confirmed prior to installation with GPG signing and MD5 checksums of the RPM packages. Integrity of files can be confirmed after installation with verification of installed files against the recorded metadata in the package.

Validate Package Signatures

Import the Red Hat GPG public key (It can be found on the installation CD or in the /etc/pki/rpm-gpg/ directory):

    `rpm  --import /media/disk/RPM-GPG-KEY-redhat-release`
    `rpm  --import /etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release`

Check the signature of the package in question:

    `rpm  --checksig /path/to/package-ver-rel.arch.rpm`

RPM Checksig Sample Output:

    `rpm  --checksig` (sha1) dsa sha1 md5 gpg OK

Verify Installed Software

`rpm -V (or --verify)` will compare existing files on the system to their pristine state in the packages they came from. There are 8 points of comparison as shown in the following table, in the Michael Jang book, and with `man rpm`.

Table 3.5. Change Codes from rpm --verify

Change Code Meaning
5 MD5 checksum
S File size
L Symbolic Link
T Modification time
D Device
U User
G Group
M Mode

RPM Verify Sample Output:

    `rpm -Va`
    S.5....T  c /etc/ntp.conf
    ..?.....  c /etc/ntp/keys
    S.5....T    /usr/bin/aspell
    .......T    /usr/share/ImageMagick-6.2.8/config/magic.xml
    .......T  d /usr/share/doc/ImageMagick-6.2.8/images/arc.png
    .......T  d /usr/share/doc/ImageMagick-6.2.8/images/background.jpg

The Red Hat Network (RHN)

The primary delivery mechanism for installable software, updates, errata, bug fixes, and systems management functions for an installation of RHEL is the Red Hat Network or RHN. The "cost" of RHEL 6 is really a subscription to this support network. These commands are commonly used in managing an RHN subscription:

    `man -k rhn`
    rhn-profile-sync     (8)  - Update system information on Red Hat Network
    rhn_check            (8)  - Check for and execute queued actions on RHN
    rhn_register         (8)  - Connect to Red Hat Network
    rhnplugin            (8)  - Red Hat Network support for yum(8)
    rhnplugin.conf [rhnplugin] (5)  - Configuration file for the rhnplugin(8) yum(8) plugin
    rhnreg_ks            (8)  - A program for non interactively registering systems to Red Hat Network
    rhnsd                (8)  - A program for querying the Red Hat Network for updates and information

RHN Subscription Activation

A new user of the RHN should receive information similar to this upon first connection to the system:

    Red Hat subscription login:
        Account Number       : *******
        Contract Number      : *******
        Item Description     : Red Hat Enterprise Linux <Edition>
        RHEL Subscription Number : *******************
        Quantity             : #
        Service Dates        : 12-JUN-10 through 11-JUN-11
        Customer Name : *********************************
        Account Number: ************
        Log into the new portal here:
        Login: *************
        Password: **************
        Email address: ****************************

That information can then be used with rhn_register to activate a new subscription.

Third Party Repositories

These are other repositories of installable software, updates, or bugfixes. The `yum` command can be configured to use the additional sources in addition to - or instead of - the RHN. Note that updates for the specific release you are using must come from the update repository for that release.

Repository configuration files live in /etc/yum.repos.d/. Look in that directory for files with a .repo extension for information about that repository. Listed below is a typical repository configuration stanza:[5]

    root@intrepid /etc/yum.repos.d/
    --> cat rpmfusion-nonfree.repo 
    name=RPM Fusion for Fedora $releasever - Nonfree

Configuration of repositories other than the RHN is accomplished through text configuration files located in the directory '/etc/yum.repos.d/'. A configuration file for each repository (or group of related repos) should be created in '/etc/yum.repos.d/'. The name of each repo config file should end in ".repo". This allows a repo or a group of repos to be easily disabled temporarily by renaming the file to something like 'myrepo.repo.bak'.

[Tip] Creating a Repository Config File

The ability to create a repository configuration file manually from memory upon demand is a very good skill for a Linux System Administrator to have.

Listed below are the three mandatory items needed to configure a repository for downloading sofware.

Table 3.6. Yum Repository Mandatory Configuration Items

Directive Description
[RepoID] The repository ID is a short name for identifying this repository in reports. It must be in [brackets].
name=Custom Repository The name is a longer description of the repository.
baseurl= Baseurl is a description of protocol and location needed to locate the repository files.

Listed below are three of the many optional directives for configuring access to a repository.

Table 3.7. Yum Repository Common Optional Configuration Items

Directive Description
gpgcheck=1 Defines whether yum should attempt to validate package signatures. "0" = "off", "1" = "on".
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release Defines (via URL) where the keys for signature validation are located (typically file:///etc/pki/rpm-gpg/<key name>)
enabled=0 Defines whether this repository should be currently active. "0" = "off", "1" = "on". The default is "1"

There are many other configuration directives. Read the `man rpm` page for more information.

Managing & Creating a Software Repository

It's possible to create a local repo with installable files. These can be packages that are downloaded and stored locally, or home grown packages of software. The process is listed below, and assumes that the httpd package is already installed, and MyPackage has already been built.

  • `yum -y install createrepo`
  • `mkdir -p /var/www/html/repo/Packages`
  • `cp MyPackage.rpm /var/www/html/repo/Packages`
  • `createrepo -v /var/www/html/repo`
  • `cp /home/me/RPM-GPG-KEY-me /var/www/html/repo`[6]

The local repo can then be configured in /etc/yum.repos.d as any other repository.

YUM Update Manager

The YUM (Yellow Dog Update Manager) utility wraps around the RPM system of commands to manage packages and the installation of software. It is the most convenient way to manage software on the sytem. Listed below are several of the more common `yum` commands.

Table 3.8. Common `yum` Commands

Command Description
`yum help` Displays usage and helpful information about the `yum` command.
`yum list` Lists all available packages and indicates which are installed.
`yum search <keyword>` Searches for packages with a keyword in the package metadata.
`yum info <packagename>` Displays information about a package taken from the package metadata.
`yum install <packagename>` Installs a package (obtained from the repository) and any required dependencies.
`yum localinstall <rpmfilename>` Installs a local .rpm file, but uses the repository to satisfy dependencies.
`yum remove <packagename>` Uninstalls a package and any other packages dependent upon it.
`yum update <packagename>` Installs a newer version of the package, if available.
`yum update [<packagename>]` Updates an installed package (or packages) for which a newer version is available.

The listing below shows several `yum`-related man pages.

[Important] Querying the `man` System for Information About Itself

Please make note of how the command `man -k` gives information about more man pages. In other words, issuing the command `man -k <something> brings back a list of all the man pages with information about <something>.

    `man -k yum`
    qreposync             (1)  - synchronize yum repositories to a local directory
    rhnplugin            (8)  - Red Hat Network support for yum(8)
    rhnplugin.conf [rhnplugin] (5)  - Configuration file for the rhnplugin(8) yum(8) plugin
    yum                  (8)  - Yellowdog Updater Modified
    yum [yum-shell]      (8)  - Yellowdog Updater Modified shell
    yum-groups-manager   (1)  - create and edit yum's group metadata
    yum-utils            (1)  - tools for manipulating repositories and extended package management
    yum.conf [yum]       (5)  - Configuration file for yum(8)
[Caution] Installing Software Outside of YUM

The YUM wrapper for the RPM system takes additional steps to manage the software on the system. It's best to use YUM when installing/upgrading/updating packages - see below. If the system throws an error such as Warning: RPMDB altered outside of yum. it's relatively harmless, but it means that the YUM wrapper to RPM doesn't manage some of the software in the system. It's best to use YUM when installing/upgrading/updating packages.

[4] There's a wealth of information at the Max RPM website.

[5] Even though the listed stanza is for a Fedora repo, not a 3rd party repo, the configuration format is identical.

[6] Only if the package is "signed".