Understanding Red Hat Content Delivery Network Repositories and their usage with Satellite 6

Authors

Rich Jerrido - Principal Product Manager, Red Hat

Overview

This document provides background to the various content repositories that are available in the Red Hat Content Delivery Network (CDN), what those repositories contain and how they can be used with Red Hat Satellite 6

Requirements

• Red Hat Satellite 6.0.x or newer

Overview

Kickstart Repositories

Kickstart Repositories are found in the Satellite UI by navigating to Content->Red Hat Repositories->Kickstart

Kickstart repositories are leveraged by Red Hat Satellite to provision new systems. Kickstart repositories are effectively equivalent to the Red Hat Enterprise Linux Binary Installation DVD

Kickstart repositories are released when new minor releases of Red Hat Enterprise Linux are released. Kickstart repositories are NOT updated with errata. If you wish to provision systems with Red Hat Satellite 6, then you MUST select a kickstart repository.

UI Example (Click to Enlarge)

Red Hat Software Repositories

Red Hat Software Repositories are provided for each product that you have access to via your subscription manifest. Many repositories are released with a dot-release (6.1, 6.2, 6.3, etc) and a xServer (e.g. 6Server) variant.

Each dot-release repository contains ALL errata (security, bugfix and enhancements) from the GA of that product until the next minor release. At this point, these repositories receive no further errata.

In contrast, the xServer (6Server, 7Server) repositories are updated with ALL errata (security, bugfix and enhancements) from the GA of that product until the product is no longer supported.

Examples

• The Red Hat Enterprise Linux 6 Server RPMs x86_64 RPMs 6.6 repository receives ALL security (RHSA), bugfix (RHBA), & enhancement (RHEA) until the date that Red Hat Enterpise Linux 6.7 is released.
• The Red Hat Enterprise Linux 6 Server RPMs x86_64 RPMs 6Server repository receives ALL released security (RHSA), bugfix (RHBA), & enhancement (RHEA) for the entire life cycle of Red Hat Enterprise Linux, and will always be as current as the Satellite's last sync with the Red Hat Content Delivery Network.

The release cadence of these repositories is listed in the image below:

UI Example (Click to Enlarge)

Red Hat Enterprise Linux - Enterprise Update Support Repositories

Extended Update Support (EUS) is an optional offering for Red Hat Enterprise Linux subscribers. With EUS, Red Hat commits to providing backports of Critical-impact security updates and urgent-priority bug fixes for minor releases of Red Hat Enterprise Linux, even for systems that are still one or two minor releases behind the current one. EUS enables customers to remain with the same minor release of Red Hat Enterprise Linux for up to approximately 24 months, allowing for extremely stable production environments for mission-critical applications.

Extended Update Support (EUS) Repositories are provided via specific Red Hat subscriptions. As such, if you are unsure, contact your account team to confirm if you have access to (EUS)

EUS repositories operate differently than normal repositories. Each dot-release repository contains:

• Each dot-release repository contains ALL errata (security, bugfix and enhancements) from the GA of that product until the next minor release AND
• Selected high priority security & bugfix errata as per the EUS
  inclusion criteria until the end of the EUS period (roughly 18 months)

Example:

• The Red Hat Enterprise Linux 6 Server - Extended Update Support RPMs x86_64 6.6 repository receives all ALL security, bugfix, and enhancement errrata until Red Hat Enterprise Linux 6.7 is released. Afterwards, it only receives the selected backports as per the EUS inclusion criteria.

The release cadence of these repositories is listed in the image below:

UI Example (Click to Enlarge)

Working with Repositories.

The subscription-manager release command can be used to list and set a release version

• Listing a release version:

# subscription-manager release --list
+-------------------------------------------+
          Available Releases
+-------------------------------------------+
6.1
6.2
6.3
6.4
6.5
6.6
6Server

• Setting a release version

# subscription-manager release --set '6.6'
Release set to: 6.6

Recommended Practices for Satellite 6

• It is recommended to use the xServer (6Server, 7Server) repos for Red Hat Enterprise Linux (in non EUS cases) as they provide the most flexibility with Content View Filters. Content View Filters provide a means to restrict which packages and/or errata are available as part of a Content View. This allows the end-user to customize their core build to match their requirements.
• Do not mix the xServer (6Server, 7Server) repos with the dot-release repos. A system has a single release version. Mixing the repository types will lead to HTTP 404 (file not found) errors when attempting to install packages.
  • Content View filters can only restrict content that is provided by the repository. They cannot be use to include content that is not provided via a repository that is not part of the content view.
• Incremental Updates, a part of Satellite 6.1 Errata Management functions similarly, and does not allow usage of content that is not provided by a repository that is part of the content View.
  • Example: A content view is created using the Red Hat Enterprise Linux 6 Server RPMs x86_64 RPMs 6.4 repo and is made available for systems to use. As stated above, the Red Hat Enterprise Linux 6 Server RPMs x86_64 RPMs 6.4 repository only receives updates until when Red Hat Enterprise Linux 6.5 is shipped. If an errata is released after the 6.4 repository is no longer receiving content, such as VENOM, the only way to make that errata available would be to do any of the following:
    • Add the Red Hat Enterprise Linux 6 Server RPMs x86_64 RPMs 6.5 repository to your content view and republish it.
    • Add the Red Hat Enterprise Linux 6 Server RPMs x86_64 RPMs 6Server repository to your content view and republish it.
    • You would not be able to apply it via the Incremental Update process.
  • As such, it is recommended to not leverage the dot-release repos unless you are comfortable with the caveats.