Chapter 2. Comparing Satellite 5 and Satellite 6

2.1. Design and Concepts

2.1.1. Red Hat Satellite 5

Red Hat Satellite 5 is life cycle management tool that includes the ability to deploy, manage and monitor a large number of systems. Satellite 5 can be set up in a connected or disconnected mode in which Red Hat software is distributed to client systems using the original pooled subscription approach. The pooled subscription concept is similar to the way in which clients consume entitlements from Red Hat Network Classic.

Features and Functionality

The popular functionality of Satellite 5 includes the ability to provision a large number of systems using kickstart files and activation keys to install and configure systems to a predictable state. This provisioning process associates systems to designated organizations, software and configuration channels, as well as placing systems in predefined system groups. The Satellite 5 provisioning functionality enables administrators to provision thousands of systems in a consistent manner.

Another popular feature is the ability to manage software and configuration files across large numbers of systems in local or remote environments after those systems have been provisioned. One of the well understood concepts of managing software and configuration files in Satellite 5 is the concept of channels. All software and configuration is managed and distributed through channels, and any client needing access to software or configuration content needs to be associated with one or more relevant channels. Further, the ability to clone channels enabled administrators to create the much needed development-production environments required by most enterprises.

Red Hat Satellite 5 provides organizations with the benefits of Red Hat Network without the need for public Internet access for servers or client systems. This brings together the tools, services, and information repositories needed to maximize the reliability, security, and performance of your systems.

2.1.2. Red Hat Satellite 6

Red Hat Satellite 6 is the evolution of Red Hat’s life cycle management platform. It provides the capabilities that administrators have come to expect in a tool focused on managing systems and content for a global enterprise. Satellite 6 covers the use cases requested by Satellite 5 customers, but also includes functionality that enables larger scale, federation of content, better control of systems during the provisioning process, and a much more simplified approach to life cycle management. Satellite 6 also further evolves the inherent approach to certificate-based entitlements and integrated subscription management.

2.1.3. Comparison of Concepts

The following table outlines some key concepts and their respective implementation in both Satellite 5 and Satellite 6.

Table 2.1. Comparison of Satellite 5 and Satellite 6 Concepts

ConceptDescriptionSatellite 5Satellite 6

Open source projects

A single project approach versus a modular approach.


Foreman, Katello, Puppet, Candlepin, and Pulp

Subscription types

Pool- or channel-based versus certificate-based. Subscription management has improved over the years from a pool- or channel-based approach to a more specific certificate-based approach. Certificate-based subscription management provides better overall control of subscriptions used by clients.



Subscription methods (or Satellite subscription consumption).

The way that Satellite is enabled to synchronize and distribute Red Hat content. Certificates are activated during installation; manifests are uploaded after installation.

Certificate file

Manifest file

Organization management

Both Satellite 5 and 6 have a concept of multiple organizations, but Satellite 6 also includes functionality to include the context of the location.


Organizations and Locations

Software and configuration content

Distributed through channels versus distributed through content views published and promoted through environments. In Satellite 6 a content view contains a chosen set of software repositories and configuration modules that are published and promoted to an environment. Client systems consume its software and configurations through its environment associations.

Software Channels

Products and repositories



Configuration Channels

Puppet Repositories

Proxy services


Red Hat Satellite Proxy Server

Red Hat Satellite Capsule Server

Command-line tools


Various CLI tools


Virtualization and cloud providers


KVM and Xen

OpenStack, Red Hat Enterprise Virtualization, KVM, VMware, EC2

Database support


Embedded PostgreSQL, managed PostgreSQL, external PostgreSQL, Oracle Database 10g Release 2 or 11g (Standard or Enterprise Edition)

Embedded PostgreSQL for 6.0.

2.2. System Architectures

2.2.1. Red Hat Satellite 5

Red Hat Satellite 5 is based on an open source project called Spacewalk and is comprised of several key components arranged in the following architecture.

Figure 2.1. Red Hat Satellite 5 System Architecture

Red Hat Satellite 5 System Architecture
Web UI
The Satellite web UI runs through an Apache web server and provides the main entry point for Satellite operations.
Front-end API
The front-end API provides the ability to interact with Satellite 5 through an XML-RPC API. This allows system administrators to write scripts to perform repetitive tasks, or develop third-party applications around Satellite. The front-end API exposes most of the web UI functionality using XML-RPC.
Back-end API
The back end provides a set of APIs that the different client utilities (rhn_register, yum) connect to. These are not documented and are used solely by the client utilities.
Taskomatic is a separate service within Red Hat Satellite 5 that runs various asynchronous jobs, such as cleaning up the sessions table, or sending email notifications for new errata. The majority of these jobs run periodically, and you can adjust the frequency with which they occur.
Search Server
Satellite contains a standalone search server that runs as a daemon that allows you to quickly find a system, package, or errata, as opposed to paging through hundreds of items in a list. It uses Apache’s Lucene search engine library, which provides more relevant search results and a richer query language.

2.2.2. Red Hat Satellite 6

Red Hat Satellite 6 is based upon several open source projects arranged in the following architecture.

Figure 2.2. Red Hat Satellite 6 System Architecture

Red Hat Satellite 6 System Architecture
Foreman is an open source application used for provisioning and life cycle management of physical and virtual systems. Foreman automatically configures these systems using various methods, including kickstart and Puppet modules. Foreman also provides historical data for reporting, auditing, and troubleshooting.
Katello is a subscription and repository management application. It provides a means to subscribe to Red Hat repositories and download content. You can create and manage different versions of this content and apply them to specific systems within user-defined stages of the application life cycle.
Candlepin is a service within Katello that handles subscription management.
Pulp is a service within Katello that handles repository and content management.
Hammer is a CLI tool that provides command line and shell equivalents of most web UI functions.
Red Hat Satellite 6 includes a REST-based API service that allows system administrators and developers to write custom scripts and third-party applications that interface with Red Hat Satellite.
Red Hat Satellite Capsule Server acts as a proxy for some of the main Satellite functions including repository storage, DNS, DHCP, and Puppet Master configuration. Each Satellite Server also contains integrated Capsule Server services.

Note that Red Hat Satellite 6 can be installed only on x86_64 architecture systems.

2.3. Content Management

2.3.1. Red Hat Satellite 5

Red Hat Satellite 5 architecture includes Red Hat Satellite Proxy Server, a package-caching mechanism that reduces the bandwidth requirements for Red Hat Satellite and enables custom package deployment. The Satellite Proxy acts as a go-between for client systems and the Satellite Server.

From the client’s perspective, there is no difference between a Satellite Proxy and a Satellite. From the Satellite Server’s perspective, a Satellite Proxy is a special type of Satellite client.

Satellite Proxy servers are exclusive to Satellite 5; you cannot use Satellite Proxy servers with Satellite 6. Instead, Satellite 6 introduces the concept of Capsules, which provide much the same functionality.

2.3.2. Red Hat Satellite 6

Satellite 6 architecture includes Capsule Servers to provide a similar level of functionality for Satellite 6 that Proxy servers provide for Satellite 5.


You cannot tier Capsule Servers the same way you can with Proxy servers. You can see this in the following illustration.

Figure 2.3. Comparison of Satellite 5 Proxy and Satellite 6 Capsule Servers

Comparison of Satellite 5 Proxy and Satellite 6 Capsule Servers

The first release of Capsule Servers, delivered with Satellite 6.0, can provide the following functionality:

  • Mirror repository content (Pulp Node). Content can be staged on a Pulp Node before it is used by a host.
  • Mirror Puppet content (Puppet Master)
  • Use DHCP, DNS, and TFTP, and integrate with Identity Management (IdM).

2.4. Disconnected Content Management

A key difference between Satellite 5 and Satellite 6 is in the area of "disconnected" content management. Both versions of Satellite can provision and keep hosts synchronized without direct connection to the Internet, but the way they achieve this is slightly different.

2.4.1. Red Hat Satellite 5

Red Hat Satellite 5 achieves disconnected content management by using the katello-disconnected utility and a synchronization host. An intermediary system with an Internet connection is needed to act as a synchronization host. This synchronization host is in a separate network from Satellite Server.

The synchronization host imports content from the Red Hat Content Delivery Network (CDN). The content is then exported onto a media, such as DVDs, CDs, or external hard drives and transferred to the disconnected Satellite Server.

2.4.2. Red Hat Satellite 6

Red Hat Satellite 6 achieves disconnected content management by using a second Internet facing Satellite and the Inter-Satellite Synchronization (ISS) feature.

The connected Satellite imports content from the Red Hat Content Delivery Network (CDN). The content is then exported onto a media, such as DVDs, CDs, or external hard drives and transferred to the disconnected Satellite Server. The Inter-Satellite Synchronization feature enables full or incremental updates to be made. See Synchronizing Content Between Satellite Servers in the Content Management Guide for more information.

2.5. Organizational Structures

2.5.1. Red Hat Satellite 5

Red Hat Satellite 5 can group systems, content, and configuration into multiple and distinct organizations. This is useful for companies with multiple divisions, such a Finance, Marketing, Sales, and so forth. Each organization acts as an individually managed Satellite, each with their own configuration and system profiles. However, Satellite can share content (software channels) among multiple organizations.

Red Hat Satellite 5 also has the ability to synchronize content across multiple Satellite Servers. This allows administrators to provide geographically dispersed Satellites that share the same software channels. For example, a company might have offices in three separate locations and each might require a Satellite, but synchronizing content from a chosen parent Satellite Server.

Figure 2.4. Example Topology for Red Hat Satellite 5

Example Topology for Red Hat Satellite 5

All systems management operations occur on the Satellite to which they are registered.

2.5.2. Red Hat Satellite 6

Red Hat Satellite 6 takes a consolidated approach to Organization and Location management. System administrators define multiple Organizations and multiple Locations in a single Satellite Server. For example, a company might have three Organizations (Finance, Marketing, and Sales) across three countries (United States, United Kingdom, and Japan). In this example, the Satellite Server manages all Organizations across all geographical Locations, creating nine distinct contexts for managing systems. In addition, users can define specific locations and nest them to create a hierarchy. For example, Satellite administrators might divide the United States into specific cities, such as Boston, Phoenix, or San Francisco.

Figure 2.5. Example Topology for Red Hat Satellite 6

Example Topology for Red Hat Satellite 6

The main Satellite Server retains the management function, while the content and configuration is synchronized between the main Satellite Server and a Satellite Capsule assigned to certain locations.

2.6. Application Life Cycles

2.6.1. Red Hat Satellite 5

The application life cycle in Red Hat Satellite 5 follows stages in a path. For example, applications might move along a path from "Development" to "Testing" to "General Availability". Each stage in Red Hat Satellite 5 uses System Definitions to manage systems at a particular point in the life cycle. A System Definition in Red Hat Satellite 5 is a set of Software Channels and Configuration Channels that are used in Kickstart Profiles.

Figure 2.6. The Application Life Cycle of Red Hat Satellite 5

The Application Life Cycle of Red Hat Satellite 5

2.6.2. Red Hat Satellite 6

The Red Hat Satellite 6 application life cycle is broken up into two key components: Life Cycle Environments and Content Views.

The application life cycle is divided into life cycle environments, which mimic each stage of the life cycle. These life cycle environments are linked in an environment path. You can promote content along the environment path to the next life cycle stage when required. For example, if development completes on a particular version of an application, you can promote this version to the testing environment and start development on the next version.

Figure 2.7. An Environment Path Containing Four Environments.

An Environment Path Containing Four Environments

Content views are managed selections of content, which contain one or more yum or Puppet repositories with optional filtering. These filters can be either inclusive or exclusive, and tailor a system view of content for life-cycle management. They are used to customize content to be made available to client systems. Content view versions are promoted along an environment path during the application life cycle. Published content views are used with life cycle environments.