Red Hat NETWORK 3.6 - User manual

Red Hat Network 3.6
Channel Management Guide

Red Hat Network 3.6: Channel Management Guide
Copyright © 2002 - 2004 by Red Hat, Inc.
channel-mgmt(EN)-3.6-RHI (2004-11-09T17:48)
Copyright © 2002 - 2004 by Red Hat, Inc.
Red Hat, Red Hat Network, the Red Hat "Shadow Man" logo, RPM, Maximum RPM, the RPM logo, Linux Library,
PowerTools, Linux Undercover, RHmember, RHmember More, Rough Cuts, Rawhide and all Red Hat-based trademarks and
logos are trademarks or registered trademarks of Red Hat, Inc. in the United States and other countries.
Linux is a registered trademark of Linus Torvalds.
All other trademarks and copyrights referred to are the property of their respective owners.

Table of Contents
1. Introduction..................................................................................................................................... 1
2. Introduction to RHN Channels...................................................................................................... 3
2.1. Base Channels and Child Channels ................................................................................... 3
2.2. Subscribing to Channels .................................................................................................... 3
2.3. Channel Availability .......................................................................................................... 4
2.4. Tools, Repositories, and Practices ..................................................................................... 4
3. Building Custom Packages............................................................................................................. 5
3.1. Building packages for Red Hat Network ........................................................................... 5
3.1.1. RPM Benefits ...................................................................................................... 5
3.1.2. RHN RPM Guidelines ........................................................................................ 6
3.2. Digital Signatures for RHN Packages................................................................................ 7
3.2.1. Generating a GnuPG Keypair ............................................................................. 7
3.2.2. Signing packages ................................................................................................ 8
4. Custom Channel and Package Management.............................................................................. 11
4.1. Channel Management Privileges ..................................................................................... 11
4.2. Manage Software Channels ............................................................................................. 11
4.3. Managed Software Channel Details................................................................................. 12
4.4. Manage Software Packages ............................................................................................. 13
4.5. Creating a Software Channel ........................................................................................... 14
4.6. Assigning Packages to Software Channels ...................................................................... 14
4.7. Cloning Software Channels ............................................................................................. 15
4.8. Deleting Software Channels ............................................................................................ 15
5. Custom Errata Management ....................................................................................................... 17
5.1. Manage Errata.................................................................................................................. 17
5.1.1. Published Errata ................................................................................................ 17
5.1.2. Unpublished Errata ........................................................................................... 17
5.2. Managed Errata Details.................................................................................................... 17
5.3. Creating and Editing Errata ............................................................................................. 18
5.4. Assigning Packages to Errata........................................................................................... 18
5.5. Cloning Errata.................................................................................................................. 19
6. Uploading and Maintaining Custom Packages .......................................................................... 21
6.1. Uploading Packages to RHN Proxy Server ..................................................................... 21
6.1.1. Configuring and Using the RHN Package Manager ...................................... 21
6.2. Uploading Packages to RHN Satellite Server.................................................................. 23
6.2.1. Configuring and Using the RHN Push application.......................................... 23
Index................................................................................................................................................... 27

Chapter 1.
Introduction
This document discusses issues surrounding the deployment and maintenance of customized software
channels for RHN Proxy Server and RHN Satellite Server. It should be used after the RHN Satellite
Server or RHN Proxy Server is installed and configured. Refer to the RHN Satellite Server Installation
Guide and the RHN Proxy Server Installation Guide, respectively, for details, followed by the RHN
Client Configuration Guide.
In some instances, this document will refer to actions to be taken on the Red Hat Network Web servers.
For Proxy customers, this will refer to the central Red Hat Network Servers at https://rhn.redhat.com.
For Satellite customers, this will refer to the RHN Satellite Server at the customer site.

2 Chapter 1. Introduction

Chapter 2.
Introduction to RHN Channels
A Red Hat Network channel is a collection of packages. Channels help to segregate packages by
sensible rules: a channel may contain packages from a specific Red Hat distribution, for instance. A
channel may contain packages for an application or family of applications. Users may also define
channels for their own particular needs; a company may create a channel that contains packages for
all of the organization’s laptops, for example.
2.1. Base Channels and Child Channels
There are two types of channels: base channels and child channels. A base channel consists of pack-
ages based on a specific architecture and Red Hat Enterprise Linux release. A child channel is a
channel associated with a base channel that contains extra packages.
A system must be subscribed to one base channel and one base channel only. A system can be sub-
scribed to multiple child channels of its base channel. Only packages included in a system’s subscribed
channels can be installed or updated on that system through Red Hat Network.
When a system is registered with Red Hat Network, it is assigned to the base channel that corresponds
to system’s version of Red Hat Enterprise Linux. Once a system is registered, its default base channel
may be changed to a private base channel; these changes can be made on a per-system basis in the
RHN website.
On the Red Hat Network website, the Channels page (located under the Channels tab in the top
navigation bar) provides a list of all base channels and their child channels. Clicking on the name
of a channel displays the Channel Details page, which provides a list of all of the packages in that
channel, its Errata, and any associated systems.
Remember, two different types of ISOs are available through the RHN website. Distribution ISOs rep-
resent distributions of the Red Hat Enterprise Linux operating system and contain only the packages.
Channel Content ISOs, visible only to Satellite customers, also contain metadata in the form of XML
that enable the Satellite to properly parse and serve the packages. Distribution ISOs can be found in
the Easy ISOs page and the Downloads tab of the respective Channel Details page. Channel Content
ISOs exist only on the Downloads tab of the Satellite’s Channel Details page.
2.2. Subscribing to Channels
Systems may be subscribed to channels in the following ways:
•Registration through activation keys — Because of the simplicity and speed of activation keys, this
is the preferred method for registering systems as clients of either RHN Proxy Server or RHN Satel-
lite Server. Systems registered using an activation key are subscribed to all channels associated with
that activation key. For more information on activation keys, consult the RHN Client Configuration
Guide and the RHN Management Reference Guide.
•Install registration — When a system is initially registered through either the Red Hat Update
Agent or the Red Hat Network Registration Client, it is automatically assigned to the base chan-
nel that corresponds to the version of Red Hat Enterprise Linux on the system. For more information
on using these applications, refer to the respective chapter of the RHN Reference Guide for your
entitlement level (Management or Provisioning).
•Website subscription — Various specific child channels are available for subscription, depending
on the system’s base channel. The system may be subscribed to the child channel through the RHN
website. Customers who have created their own base channels may also reassign systems to these

4 Chapter 2. Introduction to RHN Channels
custom channels through the website. For more information on subscribing to channels online, refer
to the RHN Website chapter of the RHN Reference Guide.
2.3. Channel Availability
There are many channels in Red Hat Network. Some are available to all users, some are available
to users in a particular organization, and others are available only to customers who have purchased
access to them. Channels fall into three main categories:
•Paid Service Channels - These channels are available to customers who have purchased access to
them either directly or in conjunction with a particular Red Hat product. Red Hat Enterprise Linux
is a paid service channel.
•Custom Channels - These channels are created by customers to manage custom packages. These
channels, also known as private channels, appear only to the organization who creates them; they
can never be accessed by anyone else.
For immediate and secure service, a customer may create a custom channel for an organization and
host the channel on the organization’s private RHN Satellite Server or RHN Proxy Server. This
document focuses on that process.
2.4. Tools, Repositories, and Practices
Before creating and managing channels, you should note the differences between the various tools
and repositories at your disposal. This is especially important if you will be deploying both a RHN
Satellite Server and RHN Proxy Server, as this increases the utilities and storage locations available.
Further, a Proxy-Satellite combination offers certain best practices for optimal performance.
First, become familiar with these package management tools:
•RHN Package Manager - This application is used to push custom packages into custom channels
on an RHN Proxy Server.
•RHN Push - This application is used to push custom packages into custom channels on an RHN
Satellite Server.
•RHN Satellite Synchronization Tool - This application is used to import and synchronize standard
packages on an RHN Satellite Server with Red Hat Network. either via the Internet or CD-ROM.
Each of these tools has a corresponding package repository. Both the RHN Package Manager and
the RHN Push require the creation of a temporary staging directory for placement of custom pack-
ages that will be uploaded to the Proxy or Satellite. The RHN Satellite Synchronization Tool may
also necessitate a temporary directory to hold channel ISOs, if the Satellite is not synchronized over
the Internet. All three of these repositories should be deleted after use. Red Hat recommends first
archiving the custom packages used by RHN Package Manager and RHN Push.
Customers using both RHN Proxy Server and RHN Satellite Server should be using only the RHN
Push (as well as the RHN Satellite Synchronization Tool for importing and syncing) because this
combination requires custom packages and channels be uploaded to the Satellite only. From there, the
Proxies will obtain the packages and distribute them to client systems.

Chapter 3.
Building Custom Packages
There are many things that might go wrong when building packages. This is especially true when
these packages must be delivered and installed through Red Hat Network. This chapter describes how
to build packages of the highest quality that may be successfully delivered via Red Hat Network.
3.1. Building packages for Red Hat Network
Red Hat Network uses the RPM Package Manager (RPM) technology to determine what software
additions and updates are applicable to each client system. Thus, all packages retrieved from Red
Hat Network must be in RPM format. (Entire ISO images, however, are also available through the
Software tab of the RHN Web interface.)
RPM is an extremely powerful tool that provides users with a simple method for installing, unin-
stalling, upgrading, and verifying software packages. It also allows software developers to package
the source code and compiled versions of a program for end users.
3.1.1. RPM Benefits
RPM provides the following advantages:
Easy Upgrades
Using RPM, you can upgrade individual components of a system without completely reinstalling.
When Red Hat releases a new version of Red Hat Enterprise Linux, users do not have to reinstall
(as they do with operating systems based on other packaging systems). RPM allows intelligent,
fully-automated, in-place upgrades of your system. Configuration files in packages are preserved
across upgrades so users do not lose their customizations. There are no special upgrade files
needed to update a package because the same RPM file is used to install and upgrade the package.
Powerful Querying
RPM is designed to provide powerful querying options. Users can search through their entire
RPM database for all packages or just for certain files. Users 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 feature is the ability to verify packages. If users are worried they deleted an
important file from a package, they can simply verify the package. They will be notified of
any anomalies. If errors do exist, they can reinstall the questionable package easily. Modified
configuration files 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, the pristine sources can be packaged, 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, users do not necessarily
have to start from scratch to make it compile. Users can look at the patch to see what they might
need to do. All the compiled-in defaults and changes made to get the software to build properly
are easily visible using this technique.

6 Chapter 3. Building Custom Packages
Keeping sources pristine may seem important only to developers, but it results in higher quality
software for end users, as well.
3.1.2. RHN RPM Guidelines
The strength of RPM lies in its ability to define dependencies and identify conflicts accurately. Red
Hat Network relies heavily on this aspect of RPM. Red Hat Network offers an automated environ-
ment, which means that no manual intervention can take place during the installation of a package.
Therefore, when building RPMs for distribution through Red Hat Network, it is imperative to follow
these rules:
1. Learn RPM. It is crucial to have a fundamental understanding of the important features of RPM
to build packages properly. For more information about RPM, consult the following resources:
•http://www.rpm.org/RPM-HOWTO/
•http://www.redhat.com/docs/books/max-rpm/
•http://www.rpm.org/mailing_list/
2. When building an RPM for a child channel, build the package on a fresh install of Red Hat
Enterprise Linux of the same version as the child’s base channel. Be sure to apply all updates
from Red Hat Network first.
3. The RPM package must be able to be installed without using the --force or --nodeps op-
tions. If you cannot install an RPM cleanly on your build system, Red Hat Network will not be
able to install it automatically on a user’s system.
4. The RPM package filename must be in the NVR (name, version, release) format and must
contain the architecture for the package. The proper format is name-version-release.arch.rpm.
For example, a valid RPM package filename is pkgname-0.84-1.i386.rpm, where name is
pkgname, version is 0.84, release is 1, and arch is i386.
5. The RPM package should be signed by the maintainer of the package. Unsigned packages may
be distributed through Red Hat Network, but the Red Hat Update Agent (up2date) must be
forced to accept them. Signing packages is recommended and is covered in Section 3.2 Digital
Signatures for RHN Packages.
6. If the package is changed in any way, including changing the signature or recompiling, the
version or release must be increased incrementally. In other words, the NVRA (including ar-
chitecture) for each RPM distributed through RHN must correspond to a unique build to avoid
ambiguities.
7. No RPM package may obsolete itself. This may seem obvious, but it bears mentioning.
8. If an RPM package is split into separate packages, be extremely careful with the dependencies.
Do not split an existing package unless there is a compelling reason to do so.
9. No RPM package may rely upon interactive pre-install, post-install, pre-uninstall or
post-uninstall scripts. If the RPM requires direct user intervention during installation, it will
not work with Red Hat Network.
10. Any pre-install, post-install, pre-uninstall, and post-uninstall scripts should never write anything
to stderr or stdout. Redirect the messages to /dev/null if they are not necessary or write them
to a file.
11. When creating the spec file, use the group definitions from /usr/share/doc/rpm-*/GROUPS.
If there is not an exact match, select the next best match.
12. Use the RPM dependency feature to make sure the program will run after it is installed.