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.

Chapter 3. Building Custom Packages 7
13. It may be tempting to create an RPM by archiving files and then unarchiving them in the post-
install script, but do not do it. 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.
3.2. Digital Signatures for RHN Packages
All RPM 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 can be 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, as root at a shell
prompt, type the following command:
gpg --gen-key
If you execute this command as a non-root user, you will see the following message:
gpg: Warning: using insecure memory!
This message appears because non-root users cannot lock memory pages. If such users could lock
memory pages, they could perform out-of-memory denial of service attacks. Since you do not want
anyone else to have your private GnuPG key or your passphrase, you should 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 will see an introductory screen containing
key options similar to the following:
gpg (GnuPG) 1.0.7; Copyright (C) 2002 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) ElGamal (sign and encrypt)
(5) RSA (sign only)
Your selection?
Accept the default option: (1) DSA and ElGamal. This option will allow you to create a digital
signature and encrypt (and decrypt) with two types of technologies. Type 1and then press [Enter].
Next, choose the key size or how long the key should be. The longer the key, the more resistant against
attacks your messages will be. Thus, 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 with whom you exchanged your public key will also have to
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 will be asked to confirm your decision:
Key does not expire at all

8 Chapter 3. Building Custom Packages
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 will be requested individually. When you are finished, you will be presented with a
summary of the information you entered.
Once you accept your choices, you will have to 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 will be generated. You will see a message
similar to the following:
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 will be made and placed in the directory
.gnupg in root’s home directory (since you are running the command as root). To list your keys, (still
as root) use the command:
gpg --list-keys
You will see something 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:
gpg --export -a ’Your Name’ > public_key.txt
Your public key will be 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 will
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 follow-
ing:
%_signature gpg
%_gpg_name AB6E2B72

Chapter 3. Building Custom Packages 9
The _gpg_name is the key ID, which tells RPM which signature in your GPG keyring to use. This
value can be derived from the command:
gpg --list-keys
To sign the package package-name-1.0-1.noarch.rpm, use the following command:
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.

10 Chapter 3. Building Custom Packages

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 management activities will take
place in the Channels tab of the RHN website. The instructions here should be used in conjunction
with the RHN website chapter of the RHN Reference Guide.
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 sys-
tems that can be used for staging. For instance, if you have a system group of Web servers that will
receive a set of custom packages, we suggest using your channel management capabilities to install
the packages on a non-critical subset of representative systems first. These temporary channels can
then be 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.
These permissions can be modified through the Red Hat Network website. Permissions are assigned
to users by Organization Administrators. Channel Administrator privileges are assigned as follows:
1. Log into 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 will be
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 Update at the bottom of the page. Note that Organization
Administrators are automatically granted channel administration privileges.
4. Have the user log into the Red Hat Network website, click the Channels tab on the top naviga-
tion bar, and ensure the Manage Software Channels button appears in 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 Satel-
lite Server and RHN Proxy Server customers also have access to Manage Software Channels in
the left navigation bar. This button opens the Software Channel Management interface, where all
custom software channel management work occurs.
Warning
Customers using both RHN Proxy Server and RHN Satellite Server should be managing custom
channels and packages only on the Satellite, since the Proxies should be receiving updates directly
from it. 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 Man-
aged 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 explanation of these areas.

12 Chapter 4. Custom Channel and Package Management
4.3. Managed Software Channel Details
Virtually all custom channel management tasks are carried out within the Managed Software Chan-
nel Details page, accessed by clicking Manage Software Channels in the left navigation bar and
then 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, sum-
mary, and description. Some of this information is modifiable. In addition, a Globally 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 Channel causes the appearance of a Subscribers tab, which may then be
used to grant certain users subscription permissions to the channel.
•Subscribers — Lists users who have subscription permissions to the custom channel. This tab
appears on two conditions: First, the logged in user must be an Organization Administrator or a
Channel Administrator. Second, the Globally Subscribable 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 subscribe systems to this channel and click Update. Note that Orga-
nization Administrators and Channel Administrators automatically have subscription access to all
channels.
•Managers — Lists users who have management permissions to the custom channel. This tab ap-
pears 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 Organization Administrators and Channel Administrators
automatically have management access to all channels.
•Errata — Provides the Errata associated with each of your custom channels. This tab contains
subtabs that allow you to view, add, remove, and clone Errata: 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 channel and pro-
vides a means to cancel that association. To remove Errata from the channel, select their check-
boxes and click Remove Errata on the bottom right-hand corner of the page. A confirmation
page appears with the Errata to be removed listed. 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 comprehensive 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 but will also gain Errata whenever one is issued for the
target (or 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 full 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 (ex. RHSA-2003:324)
with the "RH" prefix replaced with "CL". Subsequent clones of the same advisory have their
second letters bumped 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
instructions.
In addition to the Merge option, previously cloned Errata contain values within the Owned Er-
rata column. The Erratum label is linked to its details page. The "pub" and "mod" flags within

Chapter 4. Custom Channel and Package Management 13
parentheses identify whether the cloned Erratum has been published or modified from the orig-
inal advisory. A plus sign (+) before the flag indicates affirmative, the cloned Errata has been
published. A minus sign (-) before the flag denotes negative, for instance "-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 and Add.
•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 con-
firmation page appears with the packages to be removed listed. Click Confirm to complete the
action.
Important
Users should note that 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. Therefore, you may revert to a previous version of a pack-
age 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 Packages. Refer to Section 4.6
Assigning Packages to Software Channels for a comprehensive 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.
4.4. Manage Software Packages
In addition to adding packages to and removing them from channels, RHN Satellite Server and RHN
Proxy Server users also have the option of deleting packages entirely from both the database and
filesystem (although removal from the filesystem is delayed by about one hour). This can be done
through the Software Package Management page, accessed by clicking Manage Software Pack-
ages in the left navigation bar.
Warning
Although deleting packages from the database can be undone by uploading them again, they will
lose their association with any Errata. Upon reloading, they will have to be reassociated with Errata
manually. Refer to Chapter 5 Custom Errata Management for instructions.
To remove packages from the database, in the Software Package Management page, select an option
containing them from the View dropdown menu and click View. Then select the appropriate check-

14 Chapter 4. Custom Channel and Package Management
boxes and click Delete Packages. A confirmation page will appear with the packages listed. Click
Confirm to delete the packages entirely.
Remember, since the actual RPMs are stored on the RHN Proxy Server, its custom packages cannot be
downloaded through the RHN website, although they are listed. They must be retrieved by the client
system using up2date. Since the RHN Satellite Server provides its own website, its custom packages
are accessible via the Web or the Red Hat Update Agent. Regardless, to obtain custom packages, the
client system must be subscribed to the channel containing the packages.
4.5. Creating a Software Channel
Before uploading packages to the server, a custom channel can be created to house them. Refer to
Chapter 6 Uploading and Maintaining Custom Packages for instructions. Once uploaded, packages
may be reassigned through the website, as described in Section 4.6 Assigning Packages to Software
Channels.
Channels are created on the Red Hat Network website as follows:
1. Log into the Red Hat Network website as a Channel Administrator.
2. On the top navigation bar, click the Channels tab and then click the Manage Software Chan-
nels button in the corresponding left navigation bar.
3. On the Software Channel Management page, click create new software channel at the top-
right corner. RHN Satellite Server administrators are presented with the option of cloning a
channel, as well. Refer to Section 4.7 Cloning Software Channels for instructions.
4. On the New Software Channel page, define the details of the channel following the instructions
on the page. Remember, for most channel management actions, the Channel Label will be used
to identify the channel, so select a meaningful label. View the details of existing channels for
ideas.
The GPG key URL will be the location of the key on the server, as defined during the client
configuration process. Refer to the Red Hat Network Client Configuration Guide. The GPG key
ID will be it’s unique identifier, such as "DB42A60E", while the GPG key fingerprint will look
something like "CA20 8686 2BD6 9DFC 65F6 ECC4 2191 80CD DB42 A60E".
5. When finished, click Create Channel at the bottom of the page.
4.6. Assigning Packages to Software Channels
When packages are uploaded initially, they can be assigned to a custom channel, multiple custom
channels, or no channel at all. (See Chapter 6 Uploading and Maintaining Custom Packages for in-
structions.) Once uploaded, they may be reassigned between custom channels and the No Channels
repository.
These functions are made available by clicking the Channels tab in the top navigation bar and then
Manage Software Channels in the left navigation bar. In the Software Channel Management page,
click the name of the channel to receive packages.
In the Managed Software Channel Details page, click the Packages tab and then the Add subtab. To
associate packages with the channel being edited, select the option now containing the packages from
the View dropdown menu and click View. Packages already associated with the channel being edited
are not displayed. Packages not assigned to a specific channel can be found in the Packages in no
channels menu item. Selecting All managed packages will present all available packages.
After clicking View, the package list for the selected option will appear at the bottom. Note that the
page header still lists the channel being edited. In the list, select the checkboxes of the packages to
be assigned to the edited channel and click Add Packages at the bottom-right corner of the page. A

Chapter 4. Custom Channel and Package Management 15
confirmation page will appear with the packages listed. Click Confirm to associate the packages with
the channel. The List/Remove subtab of the Managed Software Channel Details page will appear
with the new packages listed.
Once packages are assigned to a channel, the Errata cache will be updated to reflect the changes. But
this is delayed briefly so that users may finish editing a channel before all of the changes are made
available. To initiate your changes to the cache manually, click the here link within the text at the top
of the List/Remove subtab.
4.7. Cloning Software Channels
RHN Satellite Server Channel Administrators also have the ability to clone software channels for
easy package association. Cloning offers you a complete replica of another channel, enabling you to
immediately associate appropriate packages and Errata with a custom software channel. To access
this functionality, go to the Software Channel Management page and click clone channel at the
top-right corner.
You are immediately presented with three cloning options: current state of the channel, original state
of the channel, or select Errata. These options are described fully on the webpage itself but can be
summarized as:
•Current state of the channel — All of the Errata and all of the latest packages now in the target
channel.
•Original state of the channel — All of the original packages from the target channel but none of
the Errata or associated update packages.
•Select Errata — All of the original packages from the target channel with the ability to include
certain Errata and associated update packages.
Select the option you desire using the radio buttons within the Clone field, identify the target channel
using the Clone From dropdown menu, and click Create Channel.
On the New Software Channel page, complete the fields as described in Section 4.5 Creating a Soft-
ware Channel. Note that the default values will often suffice. When satisfied, click Create Channel.
If you selected either the original or current option, you are directed to the Details tab of Managed
Software Channel Details page, where you may alter settings for the new channel. Refer to Section
4.3 Managed Software Channel Details for instructions.
If you used the select Errata option to clone the channel, you are instead directed to the Clone subtab
of Managed Software Channel Details page, where you may individually select Errata and associ-
ated packages for cloning and inclusion in the new channel. Refer to Section 4.3 Managed Software
Channel Details for specific instructions.
4.8. Deleting Software Channels
RHN Satellite Server and RHN Proxy Server administrators must also have the ability to remove un-
used channels. This action is conducted within the Details tab of the Managed Software Channel
Details page. After opening up this tab, described in detail in Section 4.3 Managed Software Chan-
nel Details, click delete channel at the top-right corner of the page to remove the channel (and all
packages exclusively associated with it) entirely.
Removing a channel via the website will automatically delete all packages associated with it exclu-
sively. Packages also associated with other channels will be retained. Keep in mind, if you’ve estab-
lished that channel on a Proxy connected to a Satellite, you will have to delete the channel on the
Proxy.

16 Chapter 4. Custom Channel and Package Management