Red Hat NETWORK SATELLITE 5.1.0 - CHANNEL MANAGEMENT User manual

Red Hat Network Satellite
Channel Management
Guide 5.1.0
5.1
ISBN: N/A
Publication date:

Red Hat Network Satellite

Red Hat Network Satellite: Channel Management Guide 5.1.0
Copyright ©2008 Red Hat, Inc.
Copyright ©2008 Red Hat, Inc. This material may only be distributed subject to the terms and conditions set forth in the
Open Publication License, V1.0 or later with the restrictions noted below (the latest version of the OPL 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
1801 Varsity Drive
Raleigh, NC 27606-2072
USA
Phone: [phone]
Phone: [phone]
Fax: [phone]
PO Box 13588
Research Triangle Park, NC 27709
USA

Red Hat Network Satellite

1. Introduction ........................................................................................................... 1
2. Introduction to RHN Channels ................................................................................. 3
1. Base Channels and Child Channels ................................................................ 3
2. Subscribing to Channels ................................................................................. 3
3. Channel Availability ........................................................................................ 4
4. Tools, Repositories, and Practices .................................................................. 4
3. Building Custom Packages ..................................................................................... 7
1. Building packages for Red Hat Network ........................................................... 7
1.1. RPM Benefits ...................................................................................... 7
1.2. RHN RPM Guidelines .......................................................................... 8
2. Digital Signatures for RHN Packages .............................................................. 9
2.1. Generating a GnuPG Keypair ..............................................................10
2.2. Signing packages ...............................................................................11
4. Custom Channel and Package Management ..........................................................13
1. Channel Management Privileges ....................................................................13
2. Manage Software Channels ...........................................................................13
3. Managed Software Channel Details ...............................................................14
4. Manage Software Packages ..........................................................................16
5. Creating a Software Channel .........................................................................17
6. Assigning Packages to Software Channels .....................................................17
7. Cloning Software Channels ...........................................................................18
8. Deleting Software Channels ...........................................................................19
5. Custom Errata Management ..................................................................................21
1. Manage Errata ..............................................................................................21
1.1. Published Errata ................................................................................21
1.2. Unpublished Errata .............................................................................21
2. Managed Errata Details .................................................................................22
3. Creating and Editing Errata ............................................................................22
4. Assigning Packages to Errata ........................................................................23
5. Cloning Errata ...............................................................................................24
6. Uploading and Maintaining Custom Packages ........................................................25
1. Uploading Packages to RHN Proxy Server .....................................................25
1.1. Configuring and Using the RHN Package Manager .............................26
2. Uploading Packages to RHN Satellite Server ..................................................29
2.1. Configuring the RHN Push Application ................................................29
2.2. Using the RHN Push application .........................................................31
Index .......................................................................................................................33
v

vi

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.
In some instances, this document refers to actions that are performed on the Red Hat Network
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.
Chapter 1.
1

2

Introduction to RHN Channels
A Red Hat Network channel is a collection of software packages. Channels help you 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.
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 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.
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. Subscribing to Channels
Subscribe systems 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 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.
• 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
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
Chapter 2.
3

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 information on
subscribing to channels online, refer to the Red Hat Network Website chapter of the RHN
Reference Guide.
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
channels, 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.
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:
•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.
Chapter 2. Introduction to RHN Channels
4

•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.
Tools, Repositories, and Practices
5

6

Building Custom Packages
There are many things that might go wrong when building software packages. This is especially
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.
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 available 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, upgrading,
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.
1.1. RPM Benefits
RPM provides the following advantages:
Easy Upgrades
Using RPM, you 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 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 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 reinstall the files
easily. Modified configuration files are preserved during reinstallation.
Chapter 3.
7

1http://www.rpm.org/RPM-HOWTO
2http://www.redhat.com/docs/books/max-rpm/
3http://www.rpm.org/mailing_list/
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.
1.2. RHN RPM Guidelines
The strength of RPM lies in its ability to define dependencies and identify conflicts accurately.
Red Hat Network relies on this aspect of RPM. Red Hat Network offers an automated
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 features of
RPM to build packages properly. For more information about RPM, start with the following
resources:
•http://www.rpm.org/RPM-HOWTO/1
•http://www.redhat.com/docs/books/max-rpm/2
•http://www.rpm.org/mailing_list/3
•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.
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)
Chapter 3. Building Custom Packages
8

must be forced to accept them. Signing packages is highly recommended and is covered in
Section 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
architecture) for each RPM distributed through RHN must correspond 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 dependencies. 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, do n't create files in a %post that you do not clean up in a
%postun section.
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.
Digital Signatures for RHN Packages
9

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 containing
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 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 yto 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 presented
with a summary of the information you entered.
Once you accept your choices, you enter a passphrase.
Chapter 3. Building Custom Packages
10

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:
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.
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
Signing packages
11

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 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, with Your Name
replaced with the name associated with the signing key.
Chapter 3. Building Custom Packages
12

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 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 production
systems. These temporary channels are then deleted using the steps described in Section 8,
“Deleting Software Channels”.
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 Administrators, 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.
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.
2. Manage Software Channels
Chapter 4.
13

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 Software
Channels on the left navigation bar. This button opens the Software Channel Management
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 3, “Managed Software Channel Details” for a full explanation of these areas.
3. Managed Software Channel Details
Virtually all custom channel management tasks are carried out within the Managed Software
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, 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 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 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 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 Organization Administrators and
Chapter 4. Custom Channel and Package Management
14