Red Hat NETWORK SATELLITE 5.2 - CHANNEL MANAGEMENT Management Manual

Red Hat Network

Satellite 5.2

Channel

Management Guide

Red Hat Network Satellite

Channel Management Guide

Red Hat Network Satellite 5.2 Channel Management Guide
Red Hat Network Satellite
Edition 5.2

iii

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 .............................................................................................. 9

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 ........................................................................................ 14

4.5. Creating a Software Channel ...................................................................................... 14

4.6. Assigning Packages to Software Channels .................................................................. 15

4.7. Cloning Software Channels ......................................................................................... 15

4.8. Deleting Software Channels ........................................................................................ 16

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 ..................................................................................... 19

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 ............................................................... 24

6.2.1. Configuring the RHN Push Application ............................................................. 24

6.2.2. Using the RHN Push application ...................................................................... 26

A. Revision History 29

Index 31

iv

Chapter 1.

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.

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.

2

Chapter 2.

3

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.

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 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.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 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.

Chapter 2. Introduction to RHN Channels

4

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 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.

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:

• 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.

Chapter 3.

5

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.

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 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.

3.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.

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

Chapter 3. Building Custom Packages

6

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 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) must be forced
to accept them. Signing packages is highly 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 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.

Digital Signatures for RHN Packages

7

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.

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 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?