Search

Overview, concepts, and deployment considerations

download PDF
Red Hat Satellite 6.15

Explore the Satellite architecture and plan Satellite deployment

Red Hat Satellite Documentation Team

Abstract

This document explains architecture concepts of Red Hat Satellite and provides recommendations for your deployment planning.

Providing feedback on Red Hat documentation

We appreciate your feedback on our documentation. Let us know how we can improve it.

Use the Create Issue form in Red Hat Jira to provide your feedback. The Jira issue is created in the Red Hat Satellite Jira project, where you can track its progress.

Prerequisites

Procedure

  1. Click the following link: Create Issue. If Jira displays a login error, log in and proceed after you are redirected to the form.
  2. Complete the Summary and Description fields. In the Description field, include the documentation URL, chapter or section number, and a detailed description of the issue. Do not modify any other fields in the form.
  3. Click Create.

Part I. Satellite overview and concepts

Red Hat Satellite is a centralized tool for provisioning, remote management, and monitoring of multiple Red Hat Enterprise Linux deployments. With Satellite, you can deploy, configure, and maintain your systems across physical, virtual, and cloud environments.

Chapter 1. Content and patch management with Red Hat Satellite

With Red Hat Satellite, you can provide content and apply patches to hosts systematically in all lifecycle stages.

1.1. Content flow in Red Hat Satellite

Content flow in Red Hat Satellite involves management and distribution of content from external sources to hosts.

Content in Satellite flows from external content sources to Satellite Server. Capsule Servers mirror the content from Satellite Server to hosts.

External content sources
You can configure many content sources with Satellite. The supported content sources include the Red Hat Customer Portal, Git repositories, Ansible collections, Docker Hub, SCAP repositories, or internal data stores of your organization.
Satellite Server
On your Satellite Server, you plan and manage the content lifecycle.
Capsule Servers
By creating Capsule Servers, you can establish content sources in various locations based on your needs. For example, you can establish a content source for each geographical location or multiple content sources for a data center with separate networks.
Hosts
By assigning a host system to a Capsule Server or directly to your Satellite Server, you ensure the host receives the content they provide. Hosts can be physical or virtual.
Content flow in Red Hat Satellite

Additional resources

1.2. Content views in Red Hat Satellite

A content view is a deliberately curated subset of content that your hosts can access. By creating a content view, you can define the software versions used by a particular environment or Capsule Server.

Each content view creates a set of repositories across each environment. Your Satellite Server stores and manages these repositories. For example, you can create content views in the following ways:

  • A content view with older package versions for a production environment and another content view with newer package versions for a Development environment.
  • A content view with a package repository required by an operating system and another content view with a package repository required by an application.
  • A composite content view for a modular approach to managing content views. For example, you can use one content view for content for managing an operating system and another content view for content for managing an application. By creating a composite content view that combines both content views, you create a new repository that merges the repositories from each of the content views. However, the repositories for the content views still exist and you can keep managing them separately as well.

Default Organization View

A Default Organization View is an application-controlled content view for all content that is synchronized to Satellite. You can register a host to the Library environment on Satellite to consume the Default Organization View without configuring content views and lifecycle environments.

Promoting a content view across environments

When you promote a content view from one environment to the next environment in the application lifecycle, Satellite updates the repository and publishes the packages.

Example 1.1. Promoting a package from Development to Testing

The repositories for Testing and Production contain the my-software-1.0-0.noarch.rpm package:

 DevelopmentTestingProduction

Version of the content view

Version 2

Version 1

Version 1

Contents of the content view

my-software-1.1-0.noarch.rpm

my-software-1.0-0.noarch.rpm

my-software-1.0-0.noarch.rpm

If you promote Version 2 of the content view from Development to Testing, the repository for Testing updates to contain the my-software-1.1-0.noarch.rpm package:

 DevelopmentTestingProduction

Version of the content view

Version 2

Version 2

Version 1

Contents of the content view

my-software-1.1-0.noarch.rpm

my-software-1.1-0.noarch.rpm

my-software-1.0-0.noarch.rpm

This ensures hosts are designated to a specific environment but receive updates when that environment uses a new version of the content view.

Additional resources

1.3. Content types in Red Hat Satellite

With Red Hat Satellite, you can import and manage many content types.

For example, Satellite supports the following content types:

RPM packages
Import RPM packages from repositories related to your Red Hat subscriptions. Satellite Server downloads the RPM packages from the Red Hat Content Delivery Network and stores them locally. You can use these repositories and their RPM packages in content views.
Kickstart trees
Import the Kickstart trees to provision a host. New systems access these Kickstart trees over a network to use as base content for their installation. Red Hat Satellite contains predefined Kickstart templates. You can also create your own Kickstart templates.
ISO and KVM images
Download and manage media for installation and provisioning. For example, Satellite downloads, stores, and manages ISO images and guest images for specific Red Hat Enterprise Linux and non-Red Hat operating systems.
Custom file type
Manage custom content for any type of file you require, such as SSL certificates, ISO images, and OVAL files.

1.4. Additional resources

  • For information about how to manage content with Satellite, see Managing content.

Chapter 2. Subscription management with Red Hat Satellite

With Red Hat Satellite, you can track usage of software subscriptions and assign subscriptions according to your needs.

2.1. Simple content access (SCA) in Red Hat Satellite

Simple Content Access (SCA) in Satellite simplifies management of software entitlements. With SCA, you can add valid subscriptions to a subscription allocation or manifest and refresh within Satellite. Therefore, with SCA enabled, you do not need to attach subscriptions individually to hosts.

Note

Simple Content Access (SCA) replaces the previous entitlement-based method of subscription management. New organizations default to having SCA enabled. Entitlement-based subscription management is deprecated. For more information, see Release notes.

Additional resources

2.2. Additional resources

  • For more information about how to manage subscriptions with Satellite, see Managing content.

Chapter 3. Provisioning management with Red Hat Satellite

With Red Hat Satellite, you can provision hosts on various compute resources with many provisioning methods from a unified interface.

3.1. Provisioning methods in Red Hat Satellite

With Red Hat Satellite, you can provision hosts by using multiple methods.

Bare-Metal Provisioning

Satellite provisions bare-metal hosts primarily by using PXE boot and MAC address identification. When provisioning bare-metal hosts with Satellite, you can do the following:

  • Create host entries and specify the MAC address of the physical host to provision.
  • Boot blank hosts to use the Satellite Discovery service, which creates a pool of hosts that are ready to be provisioned.
Cloud Providers

Satellite connects to private and public cloud providers to provision instances of hosts from images that are stored with the cloud environment. When provisioning from cloud with Satellite, you can do the following:

  • Select which hardware profile or flavor to use.
  • Provision cloud instances from specific providers by using their APIs.
Virtualization Infrastructure

Satellite connects to virtualization infrastructure services, such as Red Hat Virtualization and VMware. When provisioning virtual machines with Satellite, you can do the following:

  • Provision virtual machines from virtual image templates.
  • Use the same PXE-based boot methods as bare-metal providers.

3.2. Additional resources

Chapter 4. Major Satellite components

A typical Satellite deployment consists of the following components: a Satellite Server, Capsule Servers that mirror content from Satellite Server, and hosts that receive content and configuration from Satellite Server and Capsule Servers.

4.1. Satellite Server overview

Satellite Server is the central component of a Satellite deployment where you plan and manage the content lifecycle.

A typical Satellite deployment includes one Satellite Server on which you perform the following operations:

  • Content lifecycle management
  • Configuration of Capsule Servers
  • Configuration of hosts
  • Host provisioning
  • Patch management
  • Subscription management

Satellite Server delegates content distribution, host provisioning, and communication to Capsule Servers. Satellite Server itself also includes a Capsule.

Satellite Server also contains a fine-grained authentication system. You can grant Satellite users permissions to access precisely the parts of the infrastructure for which they are responsible.

Additional resources

4.2. Organizations and locations in Red Hat Satellite

On your Satellite Server, you can define multiple organizations and locations to help organize content, hosts, and configurations.

Organizations

Organizations typically represent different business units, departments, or teams, such as Finance, Marketing, or Web Development.

By creating organizations, you can create logical containers to isolate and manage their configurations separately according to their specific requirements.

Locations

Locations typically represent physical locations, such as countries or cities.

By creating locations, you can define geographical sites where hosts are located. For example, this is useful in environments with multiple data centers.

4.3. Capsule overview

With Capsule Servers, you can extend the reach and scalability of your Satellite deployment. Capsule Servers provide the following functionalities in a Red Hat Satellite deployment:

  • Mirroring content from Satellite Server to establish content sources in various geographical or logical locations. By registering a host to a Capsule Server, you can configure this host to receive content and configuration from the Capsule in their location instead of from the central Satellite Server.
  • Running localized services to discover, provision, control, and configure hosts.

By using content views, you can specify the exact subset of content that Capsule Server makes available to hosts. For more information, see Chapter 1, Content and patch management with Red Hat Satellite.

4.4. Overview of hosts in Satellite

A host is any Linux client that Red Hat Satellite manages. Hosts can be physical or virtual.

You can deploy virtual hosts on any platform supported by Red Hat Satellite, such as Amazon EC2, Google Compute Engine, KVM, libvirt, Microsoft Azure, OpenStack, Red Hat Virtualization, Rackspace Cloud Services, or VMware vSphere.

With Satellite, you can manage hosts at scale, including monitoring, provisioning, remote execution, configuration management, software management, and subscription management.

4.5. List of key open source components of Satellite Server

Satellite consists of several open source projects integrated with each other, such as the following:

Foreman
Foreman is a lifecycle management application for physical and virtual systems. It helps manage hosts throughout their lifecycle, from provisioning and configuration to orchestration and monitoring.
Katello
Katello is a plugin of Foreman that extends Foreman capabilities with additional features for content, subscription, and repository management. Katello enables Satellite to subscribe to Red Hat repositories and to download content.
Candlepin
Candlepin is a service for subscription management.
Pulp
Pulp is a service for repository and content management.

Additional resources

  • See Satellite 6 Component Versions for a complete list of the upstream components integrated into Satellite and for information about which upstream component versions were delivered with different versions of Satellite.

4.6. Capsule features

Capsule Servers provide local host management services and can mirror content from Satellite Server.

To mirror content from Satellite Server, Capsule provides the following functionalities:

Repository synchronization
Capsule Servers pull content for selected lifecycle environments from Satellite Server and make this content available to the hosts they manage.
Content delivery
Hosts configured to use Capsule Server download content from that Capsule rather than from Satellite Server.
Host action delivery
Capsule Server executes scheduled actions on hosts.
Red Hat Subscription Management (RHSM) proxy
Hosts are registered to their associated Capsule Servers rather than to the central Satellite Server or the Red Hat Customer Portal.

You can use Capsule to run the following services for infrastructure and host management:

DHCP
Capsule can manage a DHCP server, including integration with an existing solution, such as ISC DHCP servers, Active Directory, and Libvirt instances.
DNS
Capsule can manage a DNS server, including integration with an existing solution, such as ISC BIND and Active Directory.
TFTP
Capsule can integrate with any UNIX-based TFTP server.
Realm
Capsule can manage Kerberos realms or domains so that hosts can join them automatically during provisioning. Capsule can integrate with an existing infrastructure, including Red Hat Identity Management and Active Directory.
Puppet server
Capsule can act as a configuration management server by running a Puppet server.
Puppet Certificate Authority
Capsule can integrate with the Puppet certificate authority (CA) to provide certificates to hosts.
Baseboard Management Controller (BMC)
Capsule can provide power management for hosts by using the Intelligent Platform Management Interface (IPMI) or Redfish standards.
Provisioning template proxy
Capsule can serve provisioning templates to hosts.
OpenSCAP
Capsule can perform security compliance scans on hosts.
Remote Execution (REX)
Capsule can run remote job execution on hosts.

You can configure a Capsule Server for a specific limited purpose by enabling only selected features on that Capsule. Common configurations include the following:

Infrastructure Capsules: DNS + DHCP + TFTP
Capsules with these services provide infrastructure services for hosts and have all necessary services for provisioning new hosts.
Content Capsules: Pulp
Capsules with this service provide content synchronized from Satellite Server to hosts.
Configuration Capsules: Pulp + Puppet + PuppetCA
Capsules with these services provide content and run configuration services for hosts.
Capsules with DNS + DHCP + TFTP + Pulp + Puppet + PuppetCA
Capsules with these services provide a full set of Capsule features. By configuring a Capsule with all these features, you can isolate hosts assigned to that Capsule by providing a single point of connection for the hosts.

4.7. Capsule networking

The communication between Satellite Server and hosts registered to a Capsule Server is routed through that Capsule Server. Capsule Server also provides Satellite services to hosts.

Many of the services that Capsule Server manages use dedicated network ports. However, Capsule Server ensures that all communications from the host to Satellite Server use a single source IP address, which simplifies firewall administration.

Satellite topology with hosts connecting to a Capsule

In this topology, Capsule provides a single endpoint for all host network communications so that in remote network segments, only firewall ports to the Capsule itself must be open.

Figure 4.1. How Satellite components interact when hosts connect to a Capsule

Red Hat Satellite topology with a host

Satellite topology with hosts connecting directly to Satellite Server

In this topology, hosts connect to Satellite Server rather than a Capsule. This applies also to Capsules themselves because the Capsule Server is a host of Satellite Server.

Figure 4.2. How Satellite components interact when hosts connect directly to Satellite Server

Red Hat Satellite topology with a direct host

Additional resources

You can find complete instructions for configuring the host-based firewall to open the required ports in the following documents:

4.8. Additional resources

Chapter 5. Tools for administration of Red Hat Satellite

You can use multiple tools to manage Red Hat Satellite.

5.1. Satellite web UI overview

You can manage and monitor your Satellite infrastructure from a browser with the Satellite web UI. For example, you can use the following navigation features in the Satellite web UI:

Navigation featureDescription

Organization dropdown

Choose the organization you want to manage.

Location dropdown

Choose the location you want to manage.

Monitor

Provides summary dashboards and reports.

Content

Provides content management tools. This includes content views, activation keys, and lifecycle environments.

Hosts

Provides host inventory and provisioning configuration tools.

Configure

Provides general configuration tools and data, including host groups and Ansible content.

Infrastructure

Provides tools on configuring how Satellite interacts with the environment.

notification bell

Provides event notifications to keep administrators informed of important environment changes.

Administer

Provides advanced configuration for settings such as users, role-based access control (RBAC), and general settings.

Additional resources

5.2. Hammer CLI overview

You can configure and manage your Satellite Server with CLI commands by using Hammer.

Using Hammer has the following benefits:

  • Create shell scripts based on Hammer commands for basic task automation.
  • Redirect output from Hammer to other tools.
  • Use the --debug option with Hammer to test responses to API calls before applying the API calls in a script. For example: hammer --debug organization list.

To issue Hammer commands, a user must have access to your Satellite Server.

Note

To ensure a user-friendly and intuitive experience, the Satellite web UI takes priority when developing new functionality. Therefore, some features that are available in the Satellite web UI might not yet be available for Hammer.

In the background, each Hammer command first establishes a binding to the API, then sends a request. This can have performance implications when executing a large number of Hammer commands in sequence. In contrast, scripts that use API commands communicate directly with the Satellite API and they establish the binding only once.

Additional resources

5.3. Satellite API overview

You can write custom scripts and external applications that access the Satellite API over HTTP with the Representational State Transfer (REST) API provided by Satellite Server. Use the REST API to integrate with enterprise IT systems and third-party applications, perform automated maintenance or error checking tasks, and automate repetitive tasks with scripts.

Using the REST API has the following benefits:

  • Configure any programming language, framework, or system with support for HTTP protocol to use the API.
  • Create client applications that require minimal knowledge of the Satellite infrastructure because users discover many details at runtime.
  • Adopt the resource-based REST model for intuitively managing a virtualization platform.

Scripts based on API commands communicate directly with the Satellite API, which makes them faster than scripts based on Hammer commands or Ansible playbooks relying on modules within redhat.satellite.

Important

API commands differ between versions of Satellite. When you prepare to upgrade Satellite Server, update all the scripts that contain Satellite API commands.

Additional resources

  • See API guide for details on using the Satellite API.

5.4. Remote execution in Red Hat Satellite

With remote execution, you can run jobs on hosts remotely from Capsules using shell scripts or Ansible tasks and playbooks.

Use remote execution for the following benefits in Satellite:

  • Run jobs on multiple hosts at once.
  • Use variables in your commands for more granular control over the jobs you run.
  • Use host facts and parameters to populate the variable values.
  • Specify custom values for templates when you run the command.

Communication for remote execution occurs through Capsule Server, which means that Satellite Server does not require direct access to the target host, and can scale to manage many hosts.

To use remote execution, you must define a job template. A job template is a command that you want to apply to remote hosts. You can execute a job template multiple times.

Satellite uses ERB syntax job templates. For more information, see Template Writing Reference in Managing hosts.

By default, Satellite includes several job templates for shell scripts and Ansible. For more information, see Setting up Job Templates in Managing hosts.

Additional resources

5.5. Managing Satellite with Ansible collections

Satellite Ansible Collections is a set of Ansible modules that interact with the Satellite API. You can manage and automate many aspects of Satellite with Satellite Ansible collections.

5.6. Kickstart workflow

You can automate the installation process of a Satellite Server or Capsule Server by creating a Kickstart file that contains all the information that is required for the installation.

When you run a Red Hat Satellite Kickstart script, the script performs the following actions:

  1. It specifies the installation location of a Satellite Server or a Capsule Server.
  2. It installs the predefined packages.
  3. It installs Subscription Manager.
  4. It uses Activation Keys to subscribe the hosts to Red Hat Satellite.
  5. It installs Puppet, and configures a puppet.conf file to indicate the Red Hat Satellite or Capsule instance.
  6. It enables Puppet to run and request a certificate.
  7. It runs user defined snippets.

Additional resources

For more information about Kickstart, see Performing an automated installation using Kickstart in Performing an advanced RHEL 8 installation.

Chapter 6. Supported usage and versions of Satellite components

Satellite supports the following use cases, architectures, and versions.

6.1. Supported usage of Satellite components

Usage of all Red Hat Satellite components is supported within the context of Red Hat Satellite only as described below.

Red Hat Enterprise Linux Server

Each Red Hat Satellite subscription includes one supported instance of Red Hat Enterprise Linux Server. Reserve this instance solely for the purpose of running Red Hat Satellite.

Not supported: Using the operating system included with Satellite to run other daemons, applications, or services within your environment.

SELinux

Ensure SELinux is in enforcing or permissive mode.

Not supported: Installation with disabled SELinux.

Foreman

You can extend Foreman with plugins packaged with Red Hat Satellite. See Satellite 6 Component Versions in Red Hat Knowledgebase for information about supported Foreman plugins.

Not supported: Extending Foreman with plugins in the Red Hat Satellite Optional repository.

Red Hat Satellite also includes components, configuration, and functionality to provision and configure operating systems other than Red Hat Enterprise Linux. While these features are included, Red Hat supports their usage only for Red Hat Enterprise Linux.

Pulp

Interact with Pulp only by using the Satellite web UI, CLI, and API.

Not supported: Direct modification or interaction with the Pulp local API or database. This can cause irreparable damage to the Red Hat Satellite databases.

Candlepin

Interact with Candlepin only by using the Satellite web UI, CLI, and API.

Not supported: Direct interaction with Candlepin, its local API, or database. This can cause irreparable damage to the Red Hat Satellite databases.

Embedded Tomcat Application Server

Interact with the embedded Tomcat application server only by using the Satellite web UI, API, and database.

Not supported: Direct interaction with the embedded Tomcat application server local API or database.

Puppet
When you run the Satellite installation program, you can install and configure Puppet servers as part of Capsule Servers. A Puppet module, running on a Puppet server on your Satellite Server or any Capsule Server, is also supported by Red Hat.

Additional resources

6.2. Supported client architectures for content management

You can use the following combinations of major versions of Red Hat Enterprise Linux and hardware architectures for registering and managing hosts with Satellite. The Satellite Client 6 repositories are also available for these combinations.

Table 6.1. Content management support
PlatformArchitectures

Red Hat Enterprise Linux 9

x86_64, ppc64le, s390x, aarch64

Red Hat Enterprise Linux 8

x86_64, ppc64le, s390x

Red Hat Enterprise Linux 7

x86_64, ppc64 (BE), ppc64le, aarch64, s390x

Red Hat Enterprise Linux 6

x86_64, i386, s390x, ppc64 (BE)

6.3. Supported client architectures for host provisioning

You can use the following combinations of major versions of Red Hat Enterprise Linux and hardware architectures for host provisioning with Satellite.

Table 6.2. Host provisioning support
PlatformArchitectures

Red Hat Enterprise Linux 9

x86_64

Red Hat Enterprise Linux 8

x86_64

Red Hat Enterprise Linux 7

x86_64

Red Hat Enterprise Linux 6

x86_64, i386

6.4. Supported client architectures for configuration management

You can use the following combinations of major versions of Red Hat Enterprise Linux and hardware architectures for configuration management with Satellite.

Table 6.3. Configuration management support
PlatformArchitectures

Red Hat Enterprise Linux 9

x86_64

Red Hat Enterprise Linux 8

x86_64, aarch64

Red Hat Enterprise Linux 7

x86_64

Red Hat Enterprise Linux 6

x86_64, i386

6.5. Additional resources

Part II. Satellite deployment planning

Chapter 7. Common deployment scenarios

This section provides a brief overview of common deployment scenarios for Red Hat Satellite. Note that many variations and combinations of the following layouts are possible.

7.1. Single location

An integrated Capsule is a virtual Capsule Server that is created by default in Satellite Server during the installation process. This means Satellite Server can be used to provision directly connected hosts for Satellite deployment in a single geographical location, therefore only one physical server is needed. The base systems of isolated Capsules can be directly managed by Satellite Server, however it is not recommended to use this layout to manage other hosts in remote locations.

7.2. Single location with segregated subnets

Your infrastructure might require multiple isolated subnets even if Red Hat Satellite is deployed in a single geographic location. This can be achieved for example by deploying multiple Capsule Servers with DHCP and DNS services, but the recommended way is to create segregated subnets using a single Capsule. This Capsule is then used to manage hosts and compute resources in those segregated networks to ensure they only have to access the Capsule for provisioning, configuration, errata, and general management. For more information on configuring subnets see Managing Hosts.

7.3. Multiple locations

It is recommended to create at least one Capsule Server per geographic location. This practice can save bandwidth since hosts obtain content from a local Capsule Server. Synchronization of content from remote repositories is done only by the Capsule, not by each host in a location. In addition, this layout makes the provisioning infrastructure more reliable and easier to configure.

Content Flow in Red Hat Satellite

7.4. Disconnected Satellite

In high security environments where hosts are required to function in a closed network disconnected from the Internet, Red Hat Satellite can provision systems with the latest security updates, errata, packages and other content. In such case, Satellite Server does not have direct access to the Internet, but the layout of other infrastructure components is not affected. For information about installing Satellite Server from a disconnected network, see Installing Satellite Server in a disconnected network environment. For information about upgrading a disconnected Satellite, see Upgrading a Disconnected Satellite Server in Upgrading connected Red Hat Satellite to 6.15.

There are two options for importing content to a disconnected Satellite Server:

  • Disconnected Satellite with content ISO – in this setup, you download ISO images with content from the Red Hat Customer Portal and extract them to Satellite Server or a local web server. The content on Satellite Server is then synchronized locally. This allows for complete network isolation of Satellite Server, however, the release frequency of content ISO images is around six weeks and not all product content is included. To see the products in your subscription for which content ISO images are available, log in to the Red Hat Customer Portal at https://access.redhat.com, navigate to Downloads > Red Hat Satellite, and click Content ISOs. For instructions on how to import content ISOs to a disconnected Satellite, see Configuring Satellite to Synchronize Content with a Local CDN Server in Managing content. Note that Content ISOs previously hosted at redhat.com for import into Satellite Server have been deprecated and will be removed in the next Satellite version.
  • Disconnected Satellite with Inter-Satellite Synchronization – in this setup, you install a connected Satellite Server and export content from it to populate a disconnected Satellite using some storage device. This allows for exporting both Red Hat provided and custom content at the frequency you choose, but requires deploying an additional server with a separate subscription. For instructions on how to configure Inter-Satellite Synchronization in Satellite, see Synchronizing Content Between Satellite Servers in Managing content.

The above methods for importing content to a disconnected Satellite Server can also be used to speed up the initial population of a connected Satellite.

7.5. Capsule with external services

You can configure a Capsule Server (integrated or standalone) to use external DNS, DHCP, or TFTP service. If you already have a server that provides these services in your environment, you can integrate it with your Satellite deployment. For information about how to configure a Capsule with external services, see Configuring Capsule Server with External Services in Installing Capsule Server.

Chapter 8. Deployment considerations

This section provides an overview of general topics to be considered when planning a Red Hat Satellite deployment together with recommendations and references to more specific documentation.

8.1. Satellite Server configuration

The first step to a working Satellite infrastructure is installing an instance of Satellite Server on a dedicated Red Hat Enterprise Linux 8 server.

Adding Red Hat subscription manifests to Satellite Server

A Red Hat Subscription Manifest is a set of encrypted files that contains your subscription information. Satellite Server uses this information to access the CDN and find what repositories are available for the associated subscription. For instructions on how to create and import a Red Hat Subscription Manifest see Managing Red Hat Subscriptions in Managing content.

Red Hat Satellite requires a single manifest for each organization configured on the Satellite. If you plan to use the Organization feature of Satellite to manage separate units of your infrastructure under one Red Hat Network account, then assign subscriptions from the one account to per-organization manifests as required.

If you plan to have more than one Red Hat Network account, or if you want to manage systems belonging to another entity that is also a Red Hat Network account holder, then you and the other account holder can assign subscriptions, as required, to manifests. A customer that does not have a Satellite subscription can create a Subscription Asset Manager manifest, which can be used with Satellite, if they have other valid subscriptions. You can then use the multiple manifests in one Satellite Server to manage multiple organizations.

If you must manage systems but do not have access to the subscriptions for the RPMs, you must use Red Hat Enterprise Linux Satellite Add-On. For more information, see Satellite Add-On.

The following diagram shows two Red Hat Network account holders, who want their systems to be managed by the same Satellite installation. In this scenario, Example Corporation 1 can allocate any subset of their 60 subscriptions, in this example they have allocated 30, to a manifest. This can be imported into the Satellite as a distinct Organization. This allows system administrators the ability to manage Example Corporation 1’s systems using Satellite completely independently of Example Corporation 2’s organizations (R&D, Operations, and Engineering).

Figure 8.1. Satellite Server with multiple manifests

Satellite Server with multiple manifests

When creating a Red Hat Subscription Manifest:

  • Add the subscription for Satellite Server to the manifest if planning a disconnected or self-registered Satellite Server. This is not necessary for a connected Satellite Server that is subscribed using the Subscription Manager utility on the base system.
  • Add subscriptions for all Capsule Servers you want to create.
  • Add subscriptions for all Red Hat Products you want to manage with Satellite.
  • Note the date when the subscriptions are due to expire and plan for their renewal before the expiry date.
  • Create one manifest per organization. You can use multiple manifests and they can be from different Red Hat subscriptions.

Red Hat Satellite allows the use of future-dated subscriptions in the manifest. This enables uninterrupted access to repositories when future-dated subscriptions are added to a manifest before the expiry date of existing subscriptions.

Note that the Red Hat Subscription Manifest can be modified and reloaded to Satellite Server in case of any changes in your infrastructure, or when adding more subscriptions. Manifests should not be deleted. If you delete the manifest from the Red Hat Customer Portal or in the Satellite web UI it will unregister all of your content hosts.

8.2. Satellite Server with external database

When you install Satellite, the satellite-installer command creates databases on the same server that you install Satellite. Depending on your requirements, moving to external databases can provide increased working memory for Satellite, which can improve response times for database operating requests. Moving to external databases distributes the workload and can increase the capacity for performance tuning.

Consider using external databases if you plan to use your Satellite deployment for the following scenarios:

  • Frequent remote execution tasks. This creates a high volume of records in PostgreSQL and generates heavy database workloads.
  • High disk I/O workloads from frequent repository synchronization or Content View publishing. This causes Satellite to create a record in PostgreSQL for each job.
  • High volume of hosts.
  • High volume of synced content.

For more information about using an external database, see Using External Databases with Satellite in Installing Satellite Server in a connected network environment.

8.3. Locations and topology

This section outlines general considerations that should help you to specify your Satellite deployment scenario. The most common deployment scenarios are listed in Chapter 7, Common deployment scenarios. The defining questions are:

  • How many Capsule Servers do I need? – The number of geographic locations where your organization operates should translate to the number of Capsule Servers. By assigning a Capsule to each location, you decrease the load on Satellite Server, increase redundancy, and reduce bandwidth usage. Satellite Server itself can act as a Capsule (it contains an integrated Capsule by default). This can be used in single location deployments and to provision the base system’s of Capsule Servers. Using the integrated Capsule to communicate with hosts in remote locations is not recommended as it can lead to suboptimal network utilization.
  • What services will be provided by Capsule Servers? – After establishing the number of Capsules, decide what services will be enabled on each Capsule. Even though the whole stack of content and configuration management capabilities is available, some infrastructure services (DNS, DHCP, TFTP) can be outside of a Satellite administrator’s control. In such case, Capsules have to integrate with those external services (see Section 7.5, “Capsule with external services”).
  • Is my Satellite Server required to be disconnected from the Internet? – Disconnected Satellite is a common deployment scenario (see Section 7.4, “Disconnected Satellite”). If you require frequent updates of Red Hat content on a disconnected Satellite, plan an additional Satellite instance for Inter-Satellite Synchronization.
  • What compute resources do I need for my hosts? – Apart from provisioning bare-metal hosts, you can use various compute resources supported by Satellite. To learn about provisioning on different compute resources see Provisioning hosts.

8.4. Content sources

The Red Hat Subscription Manifest determines what Red Hat repositories are accessible from your Satellite Server. Once you enable a Red Hat repository, an associated Satellite Product is created automatically. For distributing content from custom sources you need to create products and repositories manually. Red Hat repositories are signed with GPG keys by default, and it is recommended to create GPG keys also for your custom repositories.

Yum repositories that contain only RPM packages support the On demand download policy, which reduces synchronization time and storage space. The On demand download policy saves space and time by only downloading packages when requested by hosts. For detailed instructions on setting up content sources, see Importing Content in Managing content.

A custom repository within Satellite Server is in most cases populated with content from an external staging server. Such servers lie outside of the Satellite infrastructure, however, it is recommended to use a revision control system (such as Git) on these servers to have better control over the custom content.

8.5. Content lifecycle

Satellite provides features for precise management of the content lifecycle. A lifecycle environment represents a stage in the content lifecycle, a Content View is a filtered set of content, and can be considered as a defined subset of content. By associating Content Views with lifecycle environments, you make content available to hosts in a defined way.

Content Lifecycle in Red Hat Satellite

For a detailed overview of the content management process see Importing Custom Content in Managing content. The following section provides general scenarios for deploying content views as well as lifecycle environments.

The default lifecycle environment called Library gathers content from all connected sources. It is not recommended to associate hosts directly with the Library as it prevents any testing of content before making it available to hosts. Instead, create a lifecycle environment path that suits your content workflow. The following scenarios are common:

  • A single lifecycle environment – content from Library is promoted directly to the production stage. This approach limits the complexity but still allows for testing the content within the Library before making it available to hosts.

    A single lifecycle environment
  • A single lifecycle environment path – both operating system and applications content is promoted through the same path. The path can consist of several stages (for example Development, QA, Production), which enables thorough testing but requires additional effort.

    A single lifecycle environment path
  • Application specific lifecycle environment paths – each application has a separate path, which allows for individual application release cycles. You can associate specific compute resources with application lifecycle stages to facilitate testing. On the other hand, this scenario increases the maintenance complexity.

    Application specific lifecycle environment paths

The following content view scenarios are common:

  • All in one content view – a content view that contains all necessary content for the majority of your hosts. Reducing the number of content views is an advantage in deployments with constrained resources (time, storage space) or with uniform host types. However, this scenario limits the content view capabilities such as time based snapshots or intelligent filtering. Any change in content sources affects a proportion of hosts.
  • Host specific content view – a dedicated content view for each host type. This approach can be useful in deployments with a small number of host types (up to 30). However, it prevents sharing content across host types as well as separation based on criteria other than the host type (for example between operating system and applications). With critical updates every content view has to be updated, which increases maintenance efforts.
  • Host specific composite content view – a dedicated combination of content views for each host type. This approach enables separating host specific and shared content, for example you can have dedicated content views for the operating system and application content. By using a composite, you can manage your operating system and applications separately and at different frequencies.
  • Component based content view – a dedicated content view for a specific application. For example a database content view can be included into several composite content views. This approach allows for greater standardization but it leads to an increased number of content views.

The optimal solution depends on the nature of your host environment. Avoid creating a large number of content views, but keep in mind that the size of a content view affects the speed of related operations (publishing, promoting). Also make sure that when creating a subset of packages for the content view, all dependencies are included as well. Note that kickstart repositories should not be added to content views, as they are used for host provisioning only.

8.6. Content deployment

Content deployment manages errata and packages on content hosts. Satellite can be configured to perform remote execution over MQTT/HTTPS (pull-based) or SSH (push-based). While remote execution is enabled on Satellite Server by default, it is disabled on Capsule Servers and content hosts. You must enable it manually.

8.7. Provisioning

Satellite provides several features to help you automate the host provisioning, including provisioning templates, configuration management with Puppet, and host groups for standardized provisioning of host roles. For a description of the provisioning workflow see Provisioning Workflow in Provisioning hosts. The same guide contains instructions for provisioning on various compute resources.

8.8. Role based authentication

Assigning a role to a user enables controlling access to Satellite components based on a set of permissions. You can think of role based authentication as a way of hiding unnecessary objects from users who are not supposed to interact with them.

There are various criteria for distinguishing among different roles within an organization. Apart from the administrator role, the following types are common:

  • Roles related to applications or parts of infrastructure – for example, roles for owners of Red Hat Enterprise Linux as the operating system versus owners of application servers and database servers.
  • Roles related to a particular stage of the software lifecycle – for example, roles divided among the development, testing, and production phases, where each phase has one or more owners.
  • Roles related to specific tasks – such as security manager or license manager.

When defining a custom role, consider the following recommendations:

  • Define the expected tasks and responsibilities – define the subset of the Satellite infrastructure that will be accessible to the role as well as actions permitted on this subset. Think of the responsibilities of the role and how it would differ from other roles.
  • Use predefined roles whenever possible – Satellite provides a number of sample roles that can be used alone or as part of a role combination. Copying and editing an existing role can be a good start for creating a custom role.
  • Consider all affected entities – for example, a content view promotion automatically creates new Puppet Environments for the particular lifecycle environment and content view combination. Therefore, if a role is expected to promote content views, it also needs permissions to create and edit Puppet Environments.
  • Consider areas of interest – even though a role has a limited area of responsibility, there might be a wider area of interest. Therefore, you can grant the role a read only access to parts of Satellite infrastructure that influence its area of responsibility. This allows users to get earlier access to information about potential upcoming changes.
  • Add permissions step by step – test your custom role to make sure it works as intended. A good approach in case of problems is to start with a limited set of permissions, add permissions step by step, and test continuously.

For instructions on defining roles and assigning them to users, see Managing Users and Roles in Administering Red Hat Satellite. The same guide contains information on configuring external authentication sources.

8.9. Additional tasks

This section provides a short overview of selected Satellite capabilities that can be used for automating certain tasks or extending the core usage of Satellite:

  • Discovering bare-metal hosts – the Satellite Discovery plugin enables automatic bare-metal discovery of unknown hosts on the provisioning network. These new hosts register themselves to Satellite Server and the Puppet Agent on the client uploads system facts collected by Facter, such as serial ID, network interface, memory, and disk information. After registration you can initialize provisioning of those discovered hosts. For more information, see Creating Hosts from Discovered Hosts in Provisioning hosts.
  • Backup management – backup and disaster recovery instructions, see Backing Up Satellite Server and Capsule Server in Administering Red Hat Satellite. Using remote execution, you can also configure recurring backup tasks on hosts. For more information on remote execution see Configuring and Setting up Remote Jobs in Managing hosts.
  • Security management – Satellite supports security management in various ways, including update and errata management, OpenSCAP integration for system verification, update and security compliance reporting, and fine grained role based authentication. Find more information on errata management and OpenSCAP concepts in Managing hosts.
  • Incident management – Satellite supports the incident management process by providing a centralized overview of all systems including reporting and email notifications. Detailed information on each host is accessible from Satellite Server, including the event history of recent changes. Satellite is also integrated with Red Hat Insights.
  • Scripting with Hammer and API – Satellite provides a command line tool called Hammer that provides a CLI equivalent to the majority of web UI procedures. In addition, you can use the access to the Satellite API to write automation scripts in a selected programming language. For more information, see Hammer CLI guide and API guide.

Chapter 9. Organizations, locations, and lifecycle environments

Red Hat Satellite 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, 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 9.1. Example topology for Red Hat Satellite

Example topology for Red Hat Satellite

Satellite Server defines all locations and organizations. Each respective Satellite Capsule Server synchronizes content and handles configuration of systems in a different location.

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

9.1. Organizations

Organizations divide Red Hat Satellite resources into logical groups based on ownership, purpose, content, security level, or other divisions. You can create and manage multiple organizations through Red Hat Satellite, then divide and assign your subscriptions to each individual organization. This provides a method of managing the content of several individual organizations under one management system.

9.2. Locations

Locations divide organizations into logical groups based on geographical location. Each location is created and used by a single account, although each account can manage multiple locations and organizations.

9.3. Lifecycle environments

Application lifecycles are divided into lifecycle environments which represent each stage of the application lifecycle. Lifecycle environments are linked to form an environment path. You can promote content along the environment path to the next lifecycle environment when required. For example, if development ends on a particular version of an application, you can promote this version to the testing environment and start development on the next version.

Figure 9.2. An environment path containing four environments

An environment path containing four environments

Chapter 10. Host grouping concepts

Apart from the physical topology of Capsule Servers, Red Hat Satellite provides several logical units for grouping hosts. Hosts that are members of those groups inherit the group configuration. For example, the simple parameters that define the provisioning environment can be applied at the following levels:

Global > Organization > Location > Domain > Host group > Host

The main logical groups in Red Hat Satellite are:

  • Organizations – the highest level logical groups for hosts. Organizations provide a strong separation of content and configuration. Each organization requires a separate Red Hat Subscription Manifest, and can be thought of as a separate virtual instance of a Satellite Server. Avoid the use of organizations if a lower level host grouping is applicable.
  • Locations – a grouping of hosts that should match the physical location. Locations can be used to map the network infrastructure to prevent incorrect host placement or configuration. For example, you cannot assign a subnet, domain, or compute resources directly to a Capsule Server, only to a location.
  • Host groups – the main carriers of host definitions including assigned Puppet classes, Content View, or operating system. It is recommended to configure the majority of settings at the host group level instead of defining hosts directly. Configuring a new host then largely becomes a matter of adding it to the right host group. As host groups can be nested, you can create a structure that best fits your requirements (see Section 10.1, “Host group structures”).
  • Host collections – a host registered to Satellite Server for the purpose of subscription and content management is called content host. Content hosts can be organized into host collections, which enables performing bulk actions such as package management or errata installation.

Locations and host groups can be nested. Organizations and host collections are flat.

10.1. Host group structures

The fact that host groups can be nested to inherit parameters from each other allows for designing host group hierarchies that fit particular workflows. A well planned host group structure can help to simplify the maintenance of host settings. This section outlines four approaches to organizing host groups.

Figure 10.1. Host group structuring examples

Host group structuring examples

Flat structure

The advantage of a flat structure is limited complexity, as inheritance is avoided. In a deployment with few host types, this scenario is the best option. However, without inheritance there is a risk of high duplication of settings between host groups.

Lifecycle environment based structure

In this hierarchy, the first host group level is reserved for parameters specific to a lifecycle environment. The second level contains operating system related definitions, and the third level contains application specific settings. Such structure is useful in scenarios where responsibilities are divided among lifecycle environments (for example, a dedicated owner for the Development, QA, and Production lifecycle stages).

Application based structure

This hierarchy is based on roles of hosts in a specific application. For example, it enables defining network settings for groups of back-end and front-end servers. The selected characteristics of hosts are segregated, which supports Puppet-focused management of complex configurations. However, the content views can only be assigned to host groups at the bottom level of this hierarchy.

Location based structure

In this hierarchy, the distribution of locations is aligned with the host group structure. In a scenario where the location (Capsule Server) topology determines many other attributes, this approach is the best option. On the other hand, this structure complicates sharing parameters across locations, therefore in complex environments with a large number of applications, the number of host group changes required for each configuration change increases significantly.

Chapter 11. Provisioning concepts

An important feature of Red Hat Satellite is unattended provisioning of hosts. To achieve this, Red Hat Satellite uses DNS and DHCP infrastructures, PXE booting, TFTP, and Kickstart. Use this chapter to understand the working principle of these concepts.

11.1. PXE booting

Preboot execution environment (PXE) provides the ability to boot a system over a network. Instead of using local hard drives or a CD-ROM, PXE uses DHCP to provide host with standard information about the network, to discover a TFTP server, and to download a boot image. For more information about setting up a PXE server see the Red Hat Knowledgebase solution How to set-up/configure a PXE Server.

11.1.1. PXE sequence

  1. The host boots the PXE image if no other bootable image is found.
  2. A NIC of the host sends a broadcast request to the DHCP server.
  3. The DHCP server receives the request and sends standard information about the network: IP address, subnet mask, gateway, DNS, the location of a TFTP server, and a boot image.
  4. The host obtains the boot loader image/pxelinux.0 and the configuration file pxelinux.cfg/00:MA:CA:AD:D from the TFTP server.
  5. The host configuration specifies the location of a kernel image, initrd and Kickstart.
  6. The host downloads the files and installs the image.

For an example of using PXE Booting by Satellite Server, see Provisioning Workflow in Provisioning hosts.

11.1.2. PXE booting requirements

To provision machines using PXE booting, ensure that you meet the following requirements:

Network requirements

  • Optional: If the host and the DHCP server are separated by a router, configure the DHCP relay agent and point to the DHCP server.

Client requirements

  • Ensure that all the network-based firewalls are configured to allow clients on the subnet to access the Capsule. For more information, see Section 4.7, “Capsule networking”.
  • Ensure that your client has access to the DHCP and TFTP servers.

Satellite requirements

  • Ensure that both Satellite Server and Capsule have DNS configured and are able to resolve provisioned host names.
  • Ensure that the UDP ports 67 and 68 are accessible by the client to enable the client to receive a DHCP offer with the boot options.
  • Ensure that the UDP port 69 is accessible by the client so that the client can access the TFTP server on the Capsule.
  • Ensure that the TCP port 80 is accessible by the client to allow the client to download files and Kickstart templates from the Capsule.
  • Ensure that the host provisioning interface subnet has a DHCP Capsule set.
  • Ensure that the host provisioning interface subnet has a TFTP Capsule set.
  • Ensure that the host provisioning interface subnet has a Templates Capsule set.
  • Ensure that DHCP with the correct subnet is enabled using the Satellite installer.
  • Enable TFTP using the Satellite installer.

11.2. HTTP booting

You can use HTTP booting to boot systems over a network using HTTP.

11.2.1. HTTP booting requirements with managed DHCP

To provision machines through HTTP booting ensure that you meet the following requirements:

Client requirements

For HTTP booting to work, ensure that your environment has the following client-side configurations:

  • All the network-based firewalls are configured to allow clients on the subnet to access the Capsule. For more information, see Section 4.7, “Capsule networking”.
  • Your client has access to the DHCP and DNS servers.
  • Your client has access to the HTTP UEFI Boot Capsule.

Network requirements

  • Optional: If the host and the DHCP server are separated by a router, configure the DHCP relay agent and point to the DHCP server.

Satellite requirements

Although TFTP protocol is not used for HTTP UEFI Booting, Satellite uses TFTP Capsule API to deploy bootloader configuration.

For HTTP booting to work, ensure that Satellite has the following configurations:

  • Both Satellite Server and Capsule have DNS configured and are able to resolve provisioned host names.
  • The UDP ports 67 and 68 are accessible by the client so that the client can send and receive a DHCP request and offer.
  • Ensure that the TCP port 8000 is open for the client to download the bootloader and Kickstart templates from the Capsule.
  • The TCP port 9090 is open for the client to download the bootloader from the Capsule using the HTTPS protocol.
  • The subnet that functions as the host’s provisioning interface has a DHCP Capsule, an HTTP Boot Capsule, a TFTP Capsule, and a Templates Capsule
  • The grub2-efi package is updated to the latest version. To update the grub2-efi package to the latest version and execute the installer to copy the recent bootloader from /boot into /var/lib/tftpboot directory, enter the following commands:

    # satellite-maintain packages update grub2-efi
    # satellite-installer

11.2.2. HTTP booting requirements with unmanaged DHCP

To provision machines through HTTP booting without managed DHCP ensure that you meet the following requirements:

Client requirements

  • HTTP UEFI Boot URL must be set to one of:

    • http://capsule.example.com:8000
    • https://capsule.example.com:9090
  • Ensure that your client has access to the DHCP and DNS servers.
  • Ensure that your client has access to the HTTP UEFI Boot Capsule.
  • Ensure that all the network-based firewalls are configured to allow clients on the subnet to access the Capsule. For more information, see Section 4.7, “Capsule networking”.

Network requirements

  • An unmanaged DHCP server available for clients.
  • An unmanaged DNS server available for clients. In case DNS is not available, use IP address to configure clients.

Satellite requirements

Although TFTP protocol is not used for HTTP UEFI Booting, Satellite use TFTP Capsule API to deploy bootloader configuration.

  • Ensure that both Satellite Server and Capsule have DNS configured and are able to resolve provisioned host names.
  • Ensure that the UDP ports 67 and 68 are accessible by the client so that the client can send and receive a DHCP request and offer.
  • Ensure that the TCP port 8000 is open for the client to download bootloader and Kickstart templates from the Capsule.
  • Ensure that the TCP port 9090 is open for the client to download the bootloader from the Capsule through HTTPS.
  • Ensure that the host provisioning interface subnet has an HTTP Boot Capsule set.
  • Ensure that the host provisioning interface subnet has a TFTP Capsule set.
  • Ensure that the host provisioning interface subnet has a Templates Capsule set.
  • Update the grub2-efi package to the latest version and execute the installer to copy the recent bootloader from the /boot directory into the /var/lib/tftpboot directory:

    # satellite-maintain packages update grub2-efi
    # satellite-installer

Appendix A. Technical users provided and required by Satellite

During the installation of Satellite, system accounts are created. They are used to manage files and process ownership of the components integrated into Satellite. Some of these accounts have fixed UIDs and GIDs, while others take the next available UID and GID on the system instead. To control the UIDs and GIDs assigned to accounts, you can define accounts before installing Satellite. Because some of the accounts have hard-coded UIDs and GIDs, it is not possible to do this with all accounts created during Satellite installation.

The following table lists all the accounts created by Satellite during installation. You can predefine accounts that have Yes in the Flexible UID and GID column with custom UID and GID before installing Satellite.

Do not change the home and shell directories of system accounts because they are requirements for Satellite to work correctly.

Because of potential conflicts with local users that Satellite creates, you cannot use external identity providers for the system users of the Satellite base operating system.

Table A.1. Technical users provided and required by Satellite
User nameUIDGroup nameGIDFlexible UID and GIDHomeShell

foreman

N/A

foreman

N/A

yes

/usr/share/foreman

/sbin/nologin

foreman-proxy

N/A

foreman-proxy

N/A

yes

/usr/share/foreman-proxy

/sbin/nologin

apache

48

apache

48

no

/usr/share/httpd

/sbin/nologin

postgres

26

postgres

26

no

/var/lib/pgsql

/bin/bash

pulp

N/A

pulp

N/A

no

N/A

/sbin/nologin

puppet

52

puppet

52

no

/opt/puppetlabs/server/data/puppetserver

/sbin/nologin

saslauth

N/A

saslauth

76

no

/run/saslauthd

/sbin/nologin

tomcat

53

tomcat

53

no

/usr/share/tomcat

/bin/nologin

unbound

N/A

unbound

N/A

yes

/etc/unbound

/sbin/nologin

Appendix B. Glossary of terms used in Satellite

Activation key
A token for host registration and subscription attachment. Activation keys define subscriptions, products, content views, and other parameters to be associated with a newly created host.
Answer file
A configuration file that defines settings for an installation scenario. Answer files are defined in the YAML format and stored in the /etc/foreman-installer/scenarios.d/ directory.
ARF report
The result of an OpenSCAP audit. Summarizes the security compliance of hosts managed by Red Hat Satellite.
Audits
Provide a report on changes made by a specific user. Audits can be viewed in the Satellite web UI under Monitor > Audits.
Baseboard management controller (BMC)
Enables remote power management of bare-metal hosts. In Satellite, you can create a BMC interface to manage selected hosts.
Boot disk
An ISO image used for PXE-less provisioning. This ISO enables the host to connect to Satellite Server, boot the installation media, and install the operating system. There are several kinds of boot disks: host image, full host image, generic image, and subnet image.
Capsule
An additional server that can be used in a Red Hat Satellite deployment to facilitate content federation and distribution (act as a Pulp mirror), and to run other localized services (Puppet server, DHCP, DNS, TFTP, and more). Capsules are useful for Satellite deployment across various geographical locations. In upstream Foreman terminology, Capsule is referred to as Smart Proxy.
Catalog
A document that describes the desired system state for one specific host managed by Puppet. It lists all of the resources that need to be managed, as well as any dependencies between those resources. Catalogs are compiled by a Puppet server from Puppet Manifests and data from Puppet Agents.
Candlepin
A service within Katello responsible for subscription management.
Compliance policy
Refers to a scheduled task executed on Satellite Server that checks the specified hosts for compliance against SCAP content.
Compute profile
Specifies default attributes for new virtual machines on a compute resource.
Compute resource
A virtual or cloud infrastructure, which Red Hat Satellite uses for deployment of hosts and systems. Examples include Red Hat Virtualization, Red Hat OpenStack Platform, EC2, and VMWare.
Container (Docker container)
An isolated application sandbox that contains all runtime dependencies required by an application. Satellite supports container provisioning on a dedicated compute resource.
Container image
A static snapshot of the container’s configuration. Satellite supports various methods of importing container images as well as distributing images to hosts through content views.
Content
A general term for everything Satellite distributes to hosts. Includes software packages (RPM files), or Docker images. Content is synchronized into the Library and then promoted into lifecycle environments using content views so that they can be consumed by hosts.
Content delivery network (CDN)
The mechanism used to deliver Red Hat content to Satellite Server.
Content host
The part of a host that manages tasks related to content and subscriptions.
Content view
A subset of Library content created by intelligent filtering. Once a content view is published, it can be promoted through the lifecycle environment path, or modified using incremental upgrades.
Discovered host
A bare-metal host detected on the provisioning network by the Discovery plugin.
Discovery image
Refers to the minimal operating system based on Red Hat Enterprise Linux that is PXE-booted on hosts to acquire initial hardware information and to communicate with Satellite Server before starting the provisioning process.
Discovery plugin
Enables automatic bare-metal discovery of unknown hosts on the provisioning network. The plugin consists of three components: services running on Satellite Server and Capsule Server, and the Discovery image running on host.
Discovery rule
A set of predefined provisioning rules which assigns a host group to discovered hosts and triggers provisioning automatically.
Docker tag
A mark used to differentiate container images, typically by the version of the application stored in the image. In the Satellite web UI, you can filter images by tag under Content > Docker Tags.
ERB
Embedded Ruby (ERB) is a template syntax used in provisioning and job templates.
Errata
Updated RPM packages containing security fixes, bug fixes, and enhancements. In relationship to a host, erratum is applicable if it updates a package installed on the host and installable if it is present in the host’s content view (which means it is accessible for installation on the host).
External node classifier

A construct that provides additional data for a server to use when configuring hosts. Red Hat Satellite acts as an External Node Classifier to Puppet servers in a Satellite deployment.

The External Node Classifier will be removed in a future Satellite version.

Facter
A program that provides information (facts) about the system on which it is run; for example, Facter can report total memory, operating system version, architecture, and more. Puppet modules enable specific configurations based on host data gathered by Facter.
Facts
Host parameters such as total memory, operating system version, or architecture. Facts are reported by Facter and used by Puppet.
Foreman
The component mainly responsible for provisioning and content lifecycle management. Foreman is the main upstream counterpart of Red Hat Satellite.
Foreman hook

An executable that is automatically triggered when an orchestration event occurs, such as when a host is created or when provisioning of a host has completed.

Foreman hook functionality is deprecated and will be removed in a future Satellite version.

Full host image
A boot disk used for PXE-less provisioning of a specific host. The full host image contains an embedded Linux kernel and init RAM disk of the associated operating system installer.
Generic image
A boot disk for PXE-less provisioning that is not tied to a specific host. The generic image sends the host’s MAC address to Satellite Server, which matches it against the host entry.
Hammer
A command line tool for managing Red Hat Satellite. You can execute Hammer commands from the command line or utilize them in scripts. Hammer also provides an interactive shell.
Host
Refers to any system, either physical or virtual, that Red Hat Satellite manages.
Host collection
A user defined group of one or more Hosts used for bulk actions such as errata installation.
Host group
A template for building a host. Host groups hold shared parameters, such as subnet or lifecycle environment, that are inherited by host group members. Host groups can be nested to create a hierarchical structure.
Host image
A boot disk used for PXE-less provisioning of a specific host. The host image only contains the boot files necessary to access the installation media on Satellite Server.
Incremental upgrade (of a content view)
The act of creating a new (minor) content view version in a lifecycle environment. Incremental upgrades provide a way to make in-place modification of an already published content view. Useful for rapid updates, for example when applying security errata.
Job
A command executed remotely on a host from Satellite Server. Every job is defined in a job template.
Katello
A Foreman plugin responsible for subscription and repository management.
Lazy sync
The ability to change the default download policy of a repository from Immediate to On Demand. The On Demand setting saves storage space and synchronization time by only downloading the packages when requested by a host.
Location
A collection of default settings that represent a physical place.
Library
A container for content from all synchronized repositories on Satellite Server. Libraries exist by default for each organization as the root of every lifecycle environment path and the source of content for every content view.
Lifecycle environment
A container for content view versions consumed by the content hosts. A Lifecycle Environment represents a step in the lifecycle environment path. Content moves through lifecycle environments by publishing and promoting content views.
Lifecycle environment path
A sequence of lifecycle environments through which the content views are promoted. You can promote a content view through a typical promotion path; for example, from development to test to production.
Manifest (Red Hat subscription manifest)
A mechanism for transferring subscriptions from the Red Hat Customer Portal to Red Hat Satellite. Do not confuse with Puppet manifest.
Migrating Satellite
The process of moving an existing Satellite installation to a new instance.
OpenSCAP
A project implementing security compliance auditing according to the Security Content Automation Protocol (SCAP). OpenSCAP is integrated in Satellite to provide compliance auditing for hosts.
Organization
An isolated collection of systems, content, and other functionality within a Satellite deployment.
Parameter
Defines the behavior of Red Hat Satellite components during provisioning. Depending on the parameter scope, we distinguish between global, domain, host group, and host parameters. Depending on the parameter complexity, we distinguish between simple parameters (key-value pair) and smart parameters (conditional arguments, validation, overrides).
Parametrized class (smart class parameter)
A parameter created by importing a class from Puppet server.
Permission
Defines an action related to a selected part of Satellite infrastructure (resource type). Each resource type is associated with a set of permissions, for example the Architecture resource type has the following permissions: view_architectures, create_architectures, edit_architectures, and destroy_architectures. You can group permissions into roles and associate them with users or user groups.
Product
A collection of content repositories. Products are either provided by Red Hat CDN or created by the Satellite administrator to group custom repositories.
Promote (a content view)
The act of moving a content view from one lifecycle environment to another. For more information, see Promoting a content view in Managing content.
Provisioning template
Defines host provisioning settings. Provisioning templates can be associated with host groups, lifecycle environments, or operating systems.
Publish (a content view)
The act of making a content view version available in a lifecycle environment and usable by hosts.
Pulp
A service within Katello responsible for repository and content management.
Pulp mirror
A Capsule Server component that mirrors content.
Puppet
The configuration management component of Satellite.
Puppet agent
A service running on a host that applies configuration changes to that host.
Puppet environment
An isolated set of Puppet Agent nodes that can be associated with a specific set of Puppet Modules.
Puppet manifest

Refers to Puppet scripts, which are files with the .pp extension. The files contain code to define a set of necessary resources, such as packages, services, files, users and groups, and so on, using a set of key-value pairs for their attributes.

Do not confuse with Manifest (Red Hat subscription manifest).

Puppet server
A Capsule Server component that provides Puppet Manifests to hosts for execution by the Puppet Agent.
Puppet module
A self-contained bundle of code (Puppet Manifests) and data (facts) that you can use to manage resources such as users, files, and services.
Recurring logic
A job executed automatically according to a schedule. In the Satellite web UI, you can view those jobs under Monitor > Recurring logics.
Registry
An archive of container images. Satellite supports importing images from local and external registries. Satellite itself can act as an image registry for hosts. However, hosts cannot push changes back to the registry.
Repository
Provides storage for a collection of content.
Resource type
Refers to a part of Satellite infrastructure, for example host, Capsule, or architecture. Used in permission filtering.
Role
Specifies a collection of permissions that are applied to a set of resources, such as hosts. Roles can be assigned to users and user groups. Satellite provides a number of predefined roles.
SCAP content
A file containing the configuration and security baseline against which hosts are checked. Used in compliance policies.
Subnet image
A type of generic image for PXE-less provisioning that communicates through Capsule Server.
Subscription
An entitlement for receiving content and service from Red Hat.
Synchronization
Refers to mirroring content from external resources into the Red Hat Satellite Library.
Sync plan
Provides scheduled execution of content synchronization.
Task
A background process executed on the Satellite or Capsule Server, such as repository synchronization or content view publishing. You can monitor the task status in the Satellite web UI under Monitor > Satellite Tasks > Tasks.
Updating Satellite
The process of advancing your Satellite Server and Capsule Server installations from a z-stream release to the next, for example Satellite 6.15.0 to Satellite 6.15.1.
Upgrading Satellite
The process of advancing your Satellite Server and Capsule Server installations from a y-stream release to the next, for example Satellite 6.14 to Satellite 6.15.
User group
A collection of roles which can be assigned to a collection of users.
User
Anyone registered to use Red Hat Satellite. Authentication and authorization is possible through built-in logic, through external resources (LDAP, Identity Management, or Active Directory), or with Kerberos.
virt-who
An agent for retrieving IDs of virtual machines from the hypervisor. When used with Satellite, virt-who reports those IDs to Satellite Server so that it can provide subscriptions for hosts provisioned on virtual machines.

Appendix C. CLI help

Satellite offers multiple user interfaces: Satellite web UI, Hammer CLI, API, and through Ansible collection redhat.satellite. If you want to administer Satellite on the command line, have a look at the following help output.

Satellite services
A set of services that Satellite Server and Capsule Servers use for operation. You can use the satellite-maintain tool to manage these services. To see the full list of services, enter the satellite-maintain service list command on the machine where Satellite or Capsule Server is installed. For more information, run satellite-maintain --help on your Satellite Server or Capsule Server.
Satellite plugins
You can extend Satellite by installing plugins. For more information, run satellite-installer --full-help on your Satellite Server or Capsule Server.
Hammer CLI
You can manage Satellite on the command line using hammer. For more information on using Hammer CLI, see Hammer CLI guide or run hammer --help on your Satellite Server or Capsule Server.

Legal Notice

Copyright © 2024 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.
Red Hat logoGithubRedditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

© 2024 Red Hat, Inc.