Red Hat NETWORK 4.0.5 - User manual

Red Hat Network 4.0.5
Channel Management Guide

Red Hat Network 4.0.5: Channel Management Guide
Copyright © 2002 - 2005 Red Hat, Inc.
Red Hat, Inc.
1801 Varsity Drive
Raleigh NC 27606-2072 USA
Phone: [phone]
Phone: [phone]
Fax: [phone]
PO Box 13588
Research Triangle Park NC 27709 USA
channel-mgmt(EN)-4.0.5-RHI (2005-06-30T16:20)
Copyright © 2005 by Red Hat, Inc. This material may be distributed only subject to the terms and conditions set
forth in the Open Publication License, V1.0 or later (the latest version is presently available at
http://www.opencontent.org/openpub/).
Distribution of substantively modified versions of this document is prohibited without the explicit permission of
the copyright holder.
Distribution of the work or derivative of the work in any standard (paper) book form for commercial purposes is
prohibited unless prior permission is obtained from the copyright holder.
Red Hat and the Red Hat "Shadow Man" logo are registered trademarks of Red Hat, Inc. in the United States
and other countries.
All other trademarks referenced herein are the property of their respective owners.
The GPG fingerprint of the [email protected] key is:
CA 20 86 86 2B D6 9D FC 65 F6 EC C4 21 91 80 CD DB 42 A6 0E

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............................................................................................7
3.1. Building packages for Red Hat Network ..........................................................7
3.1.1. RPM Benefits .....................................................................................7
3.1.2. RHN RPM Guidelines .......................................................................8
3.2. Digital Signatures for RHN Packages.............................................................10
3.2.1. Generating a GnuPG Keypair ..........................................................10
3.2.2. Signing packages .............................................................................12
4. Custom Channel and Package Management.............................................................13
4.1. Channel Management Privileges ....................................................................13
4.2. Manage Software Channels ............................................................................14
4.3. Managed Software Channel Details................................................................14
4.4. Manage Software Packages ............................................................................16
4.5. Creating a Software Channel ..........................................................................17
4.6. Assigning Packages to Software Channels .....................................................18
4.7. Cloning Software Channels ............................................................................18
4.8. Deleting Software Channels ...........................................................................19
5. Custom Errata Management ......................................................................................21
5.1. Manage Errata .................................................................................................21
5.1.1. Published Errata ...............................................................................21
5.1.2. Unpublished Errata ..........................................................................21
5.2. Managed Errata Details...................................................................................22
5.3. Creating and Editing Errata ............................................................................22
5.4. Assigning Packages to Errata..........................................................................23
5.5. Cloning Errata .................................................................................................24
6. Uploading and Maintaining Custom Packages .........................................................25
6.1. Uploading Packages to RHN Proxy Server ....................................................25
6.1.1. Configuring and Using the RHN Package Manager .....................26
6.2. Uploading Packages to RHN Satellite Server.................................................29
6.2.1. Configuring the RHN Push Application .........................................29
6.2.2. Using the RHN Push application ....................................................32
Index..................................................................................................................................35

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 is used
after the RHN Satellite Server or RHN Proxy Server is installed and configured. Refer to
the Red Hat Network 4.0.5 Satellite Installation Guide and the Red Hat Network 4.0 Proxy
Installation Guide for details, as well as the Red Hat Network Client Configuration Guide.
In some instances, this document refers to actions that are performed on the Red Hat Net-
work Web servers. For RHN Proxy Server customers, this refers to the central Red Hat
Network Servers at https://rhn.redhat.com. For Satellite customers, this refers to the RHN
Satellite Server at your site.

2 Chapter 1. Introduction

Chapter 2.
Introduction to RHN Channels
A Red Hat Network channel is a collection of software packages. Channels help you seg-
regate 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 exam-
ple.
2.1. Base Channels and Child Channels
There are two types of channels: base channels and child channels. A base channel consists
of packages 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 only one base channel. A system can be subscribed to
multiple child channels of its base channel. A subscribed system can only install or update
packages available through its Red Hat Network channels.
When a system is registered with Red Hat Network, it is assigned to the base channel that
corresponds to the system’s version of Red Hat Enterprise Linux. Once a system is regis-
tered, its default base channel may be changed to a private base channel on a per-system
basis via the RHN website. Alternately, you can have activation keys associated with a
custom channel so that systems registering with those keys are automatically associated
with the custom channel.
On the Red Hat Network website, the Channels page (located under the Channels tab on
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.
2.2. Subscribing to Channels
Subscribe systems to channels in the following ways:
•Registration through activation keys — Because of the simplicity and speed of activa-
tion keys, this is the preferred method for registering systems as clients of either RHN
Proxy Server or RHN Satellite 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 Red Hat Network Client Configuration Guide and the Red
Hat Network Reference Guide.

4 Chapter 2. Introduction to RHN Channels
•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 as-
signed to the base channel that corresponds to the version of Red Hat Enterprise Linux
on the system. Once a system is registered, its default base channel may be changed to
a private base channel on a per-system basis via the RHN website. Alternately, you can
have activation keys associated with a custom channel so that systems registering with
those keys are automatically associated with the custom channel. 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. If you have created your own base channels, you may
also reassign systems to these custom channels through the website. For more informa-
tion on subscribing to channels online, refer to the Red Hat Network 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 some are available only if you have
purchased access to them. Channels fall into these main categories:
•Paid Service Channels — These channels are available if you who have purchased access
to them either directly or in conjunction with a particular Red Hat solution. Red Hat
Enterprise Linux is an example of a paid service channel.
•Custom Channels — You create these channels to manage custom packages. These chan-
nels, also known as private channels, appear only to the organization who creates them;
they can never be accessed by anyone else.
This document focuses on the process of creating and maintaining custom channels with
an RHN Proxy Server or on an RHN Satellite Server.
2.4. Tools, Repositories, and Practices
Before creating and managing channels, note the differences between the various tools
and repositories at your disposal. This is especially important if you are deploying both
an 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:

Chapter 2. Introduction to RHN Channels 5
•RHN Package Manager - Use this to push custom packages into custom channels on
your RHN Proxy Server.
•RHN Push - Use this to push custom packages into custom channels on your RHN
Satellite Server.
•RHN Satellite Synchronization Tool - Use this to import and synchronize standard
packages from Red Hat Network to your RHN Satellite Server with Red Hat Network.
This is done via the Internet or CD-ROM.
Each of these tools has a corresponding package repository. Both RHN Package Manager
and RHN Push require the creation of a temporary staging directory for placement of
custom packages that are uploaded to the Proxy or Satellite. You need to delete these
staging directories after use.
Tip
Red Hat recommends archiving your custom packages externally from Red Hat Network.
If you are using both RHN Proxy Server and RHN Satellite Server, use only RHN Push and
RHN Satellite Synchronization Tool. The Proxy-Satellite combination requires custom
packages and channels be uploaded to the Satellite only. From there, the Proxy obtains the
packages and distributes them to client systems.

6 Chapter 2. Introduction to RHN Channels

Chapter 3.
Building Custom Packages
There are many things that might go wrong when building software packages. This is espe-
cially true when these packages must be delivered and installed through Red Hat Network.
This chapter provides an overview of how to build packages for successful delivery via Red
Hat Network. Topics covered include why to use RPM, how to build packages for RHN,
and how to properly sign packages.
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. Packages retrieved
from Red Hat Network are usually in RPM format. Entire ISO images, however, are avail-
able through the Software tab of the Red Hat Network website, but are not available in
RHN Satellite Server installations. If your Satellite has Solaris support enabled, you can
use RHN Push to upload Solaris packages to custom channels used by Solaris clients.
RPM is a tool that provides users with a simple method for installing, uninstalling, upgrad-
ing, and verifying software packages. It also allows software developers to package the
source code and compiled versions of a program for end users and developers.
3.1.1. RPM Benefits
RPM provides the following advantages:
Easy Upgrades
Using RPM, you upgrade individual components of a system without completely re-
installing. When Red Hat releases a new version of Red Hat Enterprise Linux, users
do not have to reinstall in order to upgrade. RPM allows intelligent, fully-automated,
in-place upgrades of your system. Configuration files in packages are preserved across
upgrades so users do not lose 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.
Package Querying
RPM provides querying options that allows you to search through your entire RPM
database for all packages or just for certain files. You can also easily find out what
package a file belongs to and from where the package came. The files contained in the
package are in a compressed archive, with a custom binary header containing useful

8 Chapter 3. Building Custom Packages
information about the package and its contents. RPM queries the headers quickly and
easily.
System Verification
Another feature is the ability to verify packages. If you are worried a file related to
a package was deleted, you can verify the package to check the status of the files it
provides. The verification notifies you of any anomalies. If errors do exist, you can re-
install the files easily. Modified configuration files are preserved during reinstallation.
Pristine Sources
A crucial design goal of RPM is 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, you do not necessarily have to start from scratch to make it
compile. You can look at the patch to see what you 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.
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 accu-
rately. Red Hat Network relies on this aspect of RPM. Red Hat Network offers an auto-
mated environment, 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 fea-
tures of RPM to build packages properly. For more information about RPM, start
with the following resources:
•http://www.rpm.org/RPM-HOWTO/
•http://www.redhat.com/docs/books/max-rpm/
•http://www.rpm.org/mailing_list/
•http://fedora.redhat.com/participate/developers-guide/ch-rpm-building.html
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.

Chapter 3. Building Custom Packages 9
3. The RPM package must install without using the --force or --nodeps options. If
you cannot install an RPM cleanly on your build system, Red Hat Network cannot
install it automatically on a 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 highly recom-
mended 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 recom-
piling, the version or release must be increased incrementally. In other words, the
NVRA (including architecture) for each RPM distributed through RHN must corre-
spond to a unique build to avoid ambiguities.
7. No RPM package may obsolete itself.
8. If a package is split into separate packages, be extremely careful with the depen-
dencies. Do not split an existing package unless there is a compelling reason to do
so.
9. No package may rely upon interactive pre-install, post-install, pre-uninstall, or post-
uninstall scripts. If the package requires direct user intervention during installation,
it cannot 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. Otherwise, write them to a file.
11. When creating the spec file, use the group definitions from
/usr/share/doc/rpm-<version>/GROUPS. If there is not an exact match,
select the next best match.
12. Use the RPM dependency feature to make sure the program runs after it is installed.
Important
Do not create an RPM by archiving files and then unarchiving them in the post-install
script. This defeats the purpose of RPM.
If the files in the archive are not included in the file list, they cannot be verified or examined
for conflicts. In the vast majority of cases, RPM itself can pack and unpack archives most
effectively anyway. For instance, don’t create files in a %post that you don’t clean up in a
%postun section.

10 Chapter 3. Building Custom Packages
3.2. Digital Signatures for RHN Packages
All packages distributed through RHN should have a digital signature. A digital signature
is created with a unique private key and can be verified with the corresponding public
key. After creating a package, the SRPM (Source RPM) and the RPM can be digitally
signed with a GnuPG key. Before the package is installed, the public key is used to verify
the package was signed by a trusted party and the package has not changed since it was
signed.
3.2.1. Generating a GnuPG Keypair
A GnuPG keypair consists of the private and public keys. To generate a keypair type the
following command as the root user on the shell prompt:
gpg --gen-key
If you execute this command as a non-root user, you see the following message:
gpg: Warning: using insecure memory!
This message appears because non-root users cannot lock memory pages. Since you do not
want anyone else to have your private GnuPG key or your passphrase, you want to generate
the keypair as root. The root user can lock memory pages, which means the information is
never written to disk.
After executing the command to generate a keypair, you see an introductory screen con-
taining key options similar to the following:
gpg (GnuPG) 1.2.6; Copyright (C) 2004 Free Software Foundation, Inc.
This program comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it
under certain conditions. See the file COPYING for details.
Please select what kind of key you want:
(1) DSA and ElGamal (default)
(2) DSA (sign only)
(4) RSA (sign only)
Your selection?
Accept the default option: (1) DSA and ElGamal. This option allows you to create a
digital signature and encrypt/decrypt with two types of technologies. Type 1and then press
[Enter].
Next, choose the key size, which is how long the key should be. The longer the key, the
more resistant against attacks your messages are. Creating a key of at least 1024 bits in
size is recommended.
The next option asks you to specify how long you want your key to be valid. If you do
choose an expiration date, remember that anyone who is using your public key must also

Chapter 3. Building Custom Packages 11
be informed of its expiration and supplied with a new public key. It is recommended that
you select no expiration date. If you do not choose an expiration date, you are asked to
confirm your decision:
Key does not expire at all
Is this correct (y/n)?
Press [y] to confirm your decision.
Your next task is to provide a User-ID containing your name, your email address, and an
optional comment. Each is requested individually. When you are finished, you are pre-
sented with a summary of the information you entered.
Once you accept your choices, you enter a passphrase.
Tip
Like your account passwords, a good passphrase is essential for optimal security in
GnuPG. Mix your passphrase with uppercase and lowercase letters, use numbers, and/or
include punctuation marks.
Once you enter and verify your passphrase, your keys are generated. A message similar to
the following appears:
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
+++++.+++++.++++++++....++++++++++..+++++.+++++.+++++++.+++++++
+++.++++++++++++++++++++++++++++++++++++++..........................++++
When the activity on the screen ceases, your new keys are placed in the directory .gnupg
in root’s home directory. This location is because you are ran the command as root. To list
your root keys, use the command:
gpg --list-keys
The output is similar to the following:
/root/.gnupg/pubring.gpg
-----------------------------------------
pub 1024D/B7085C8A 2002-02-18 Your Name <[email protected]>
sub 1024g/E12AF9C4 2002-02-18
To retrieve your public key, use the following command:

12 Chapter 3. Building Custom Packages
gpg --export -a ’Your Name’ > public_key.txt
Your public key is written to the file public_key.txt.
This public key is quite important. It’s the key that must be deployed to all client systems
that receive custom software through up2date. Techniques for deploying this key across
an organization are covered in the Red Hat Network Client Configuration Guide.
3.2.2. Signing packages
Before you can sign packages, you need to configure your ~/.rpmmacros file to include
the following:
%_signature gpg
%_gpg_name B7085C8A
Replace the _gpg_name key ID value of B7085C8A with the key ID from your GPG
keyring that you use to sign packages. This value tells RPM which signature to use.
To sign the package package-name-1.0-1.noarch.rpm, use the following com-
mand:
rpm --resign package-name-1.0-1.noarch.rpm
Enter your passphrase. To make sure the package is signed, use the following command:
rpm --checksig -v package-name-1.0-1.noarch.rpm
You should see the phrase Good signature from "Your Name"in the output, with
Your Name replaced with the name associated with the signing key.

Chapter 4.
Custom Channel and Package
Management
Custom channels allow administrators to use the Red Hat Network infrastructure to deploy
packages built and maintained by their organizations. All channel and package manage-
ment activities take place in the Channels tab of the RHN website. The instructions here
are used in conjunction with the RHN website chapter of the RHN Reference Guide.
Tip
Because of the potential problems that may arise from deploying untested packages
throughout your production environment, Red Hat strongly recommends creating beta
channels covering select systems that can be used for staging.
For example, if you have a system group of Web servers that receives a set of custom
packages, create temporary channels to install the packages on a non-critical subset of
representative systems first. These might be development or staging servers, not live pro-
duction systems. These temporary channels are then deleted using the steps described in
Section 4.8 Deleting Software Channels.
4.1. Channel Management Privileges
In order to perform any channel management tasks, users must have obtained the proper
permissions as a Channel Administrator. These permissions can be modified through the
Red Hat Network website. Permissions are assigned to users by Organization Administra-
tors, the highest level of administrator. Channel Administrator privileges are assigned as
follows:
1. Log in to the Red Hat Network website as an Organization Administrator.
2. On the top navigation bar, click the Users tab and then click the name of the user
who is performing channel management functions.
3. On the User Details page, scroll down to the Roles section and select the checkbox
labeled Channel Administrator. Then click Submit at the bottom of the page. Note
that Organization Administrators are automatically granted channel administration
privileges.

14 Chapter 4. Custom Channel and Package Management
4. Have the user log in to the Red Hat Network website, click the Channels tab on the
top navigation bar, and ensure the Manage Software Channels button appears on
the corresponding left navigation bar.
4.2. Manage Software Channels
In addition to the buttons and pages available to standard RHN Management-level users,
RHN Satellite Server and RHN Proxy Server customers also have access to Manage Soft-
ware Channels on the left navigation bar. This button opens the Software Channel Man-
agement interface, where all custom software channel management work occurs.
Warning
If you use both RHN Proxy Server and RHN Satellite Server, manage custom channels
and packages only on the Satellite, since the Proxy servers receive updates directly from
it. Manually managing packages and channels on a Proxy in this combined configuration
risks putting your servers out-of-sync.
Clicking links within the Software Channel Management list takes you to different tabs
of the Managed Software Channel Details page. Clicking a channel name opens the
Details tab, while clicking its number of packages opens the List/Remove subtab of the
Packages tab. Refer to Section 4.3 Managed Software Channel Details for a full explana-
tion of these areas.
4.3. Managed Software Channel Details
Virtually all custom channel management tasks are carried out within the Managed Soft-
ware Channel Details page, accessed by clicking Manage Software Channels on the left
navigation bar and then selecting the name of channel to be altered. This page consists of
two primary tabs: Details and Packages.
•Details — Provides basic information about the channel, such as its parent channel,
name, summary, and description. Some of this information is modifiable. In addition,
aGlobally Subscribable checkbox can be seen by Organization Administrators and
Channel Administrators. This signifies the default behavior of every channel allowing
any user to subscribe systems to it. Unchecking this box and clicking Update Chan-
nel causes the appearance of a Subscribers tab, which is used to grant certain users
subscription permissions to the channel.
•Subscribers — Presents a list of users who have subscription permissions to the custom
channel. This tab appears when two conditions are true. First, the logged in user must be

Chapter 4. Custom Channel and Package Management 15
an Organization Administrator or a Channel Administrator. Second, the Globally Sub-
scribable checkbox on the Details tab must be unchecked, thereby making the channel
subscribable by user. On this tab, select the checkboxes of the users to be allowed to sub-
scribe systems to this channel and click Update. Note that Organization Administrators
and Channel Administrators automatically have subscription access to all channels.
•Managers — Lists users who have management permissions to the custom channel.
This tab appears for Organization Administrators and Channel Administrators. Select
the checkboxes of the users to be allowed full administration of this channel and click
Update. This status does not enable the user to create new channels. Note that Organiza-
tion Administrators and Channel Administrators automatically have management access
to all channels.
•Errata — Provides the errata associated with each of your custom channels. Just as Red
Hat Network produces and delivers errata updates to Red Hat Enterprise Linux software,
you deliver errata updates to your custom channels as part of updating your servers with
the latest code. This tab contains subtabs that allow you to view, add, remove, and clone
erratum: List/Remove,Add and Clone. Note that cloning errata can be done only via
RHN Satellite Server.
•List/Remove — Displays all of the errata currently associated with the custom chan-
nel and provides a means to cancel that association. To remove errata from the chan-
nel, select their checkboxes and click Remove Errata on the bottom right-hand cor-
ner of the page. A confirmation page appears listing the errata to be removed. Click
Confirm to complete the action.
•Add — Enables the addition of errata to the channel. All of the errata potentially
applicable to the channel are listed. To add errata to the channel, select the appropriate
checkboxes and click Add Errata. Refer to Chapter 5 Custom Errata Management
for a discussion of errata management.
•Clone — Allows Satellite customers to replicate errata and associated packages for a
cloned channel. This subtab immediately appears populated for channels that were
cloned with either the original state or select errata option. The Clone tab also gains
errata whenever one is issued for the target (that is, originating) channel. This
makes it useful for channels cloned with the current state option, as well. Refer to
Section 4.7 Cloning Software Channels for a discussion of cloning options.
To include errata from the target channel in the cloned channel, select either Merge
or Clone from each advisory’s dropdown menu. The Merge option exists only if the
erratum has been previously cloned. Use it to associate the erratum across channels
and avoid duplicate entries. Use the Clone option to create a new entry, such as when
modifying it from the previous clone.
By default, cloned errata inherit the label of the original Red Hat advisory with the
"RH" prefix replaced with "CL". For example, RHSA-2003:324 becomes CLSA-
2003:324. Subsequent clones of the same advisory have their second letters sequenced
to denote their order, such as "CM" and "CN". These labels can be altered through the
Managed Errata Details page. Refer to Section 5.2 Managed Errata Details for in-
structions.

16 Chapter 4. Custom Channel and Package Management
In addition to the Merge option, previously cloned errata contain values within the
Owned Errata column. The erratum label is linked to its details page. The pub and
mod flags within parentheses identify whether the cloned erratum has been published
or modified from the original advisory. A plus sign +before the flag indicates affir-
mative, the cloned errata has been published. A minus sign -before the flag denotes
negative. For example, (-mod) may mean a package has been deleted. To find out
more about publishing and editing custom errata, refer to Section 5.1 Manage Errata.
To exclude errata from the cloned channel, select Do Nothing from their dropdown
menus. When satisfied with the changes, click Clone Errata. Review the impending
changes on the confirmation page and click Update Errata.
•Packages — Provides the packages associated with each of your custom channels. This
tab contains subtabs that allow you to view, add, and remove packages: List/Remove,
Add, and Compare.
•List/Remove — Displays all of the packages currently associated with the custom
channel and provides a means to cancel that association. To remove packages from
the channel, select their checkboxes and click Remove Packages on the bottom right-
hand corner of the page. A confirmation page appears with the packages to be removed
listed. Click Confirm to complete the action.
Important
This list differs from the package list available through the standard Software
Channel Details page in that it displays all versions of a package remaining in the
database, rather than just the latest. You may revert to a previous version of a
package simply by removing the latest version.
•Add — Enables the addition of packages to the channel. To see available packages,
select an option from the View dropdown menu and click View. To add packages to
the channel you are editing, select the appropriate checkboxes and click Add Pack-
ages. Refer to Section 4.6 Assigning Packages to Software Channels for a discussion
of this process.
•Compare — Enables the comparison of package lists between different channels. To
see the differences, select another channel from the Compare to: dropdown menu and
click Compare. A list appears showing all packages not contained by both channels
and indicating the existing channel location of each.