Chapter 1. Upgrade Overview

This chapter details the prerequisites and available upgrade paths to Red Hat Satellite 6.8. Review this information before upgrading your current Red Hat Satellite 6 installation.

In this guide, the terms update, upgrade, and migrate have the following meanings:

Upgrading
The process of advancing your Satellite Server and Capsule Server installations from a y-stream release to the next, for example Satellite 6.7 to Satellite 6.8.
Updating
The process of advancing your Satellite Server and Capsule Server installations from a z-stream release to the next, for example Satellite 6.8.0 to Satellite 6.8.1.
Migrating
The process of moving an existing Satellite installation to another Red Hat Enterprise Linux server.

For interactive upgrade instructions, you can also use the Red Hat Satellite Upgrade Helper on the Red Hat Customer Portal. This application provides you with an exact guide to match your current version number. You can find instructions that are specific to your upgrade path, as well as steps to prevent known issues. For more information, see Satellite Upgrade Helper on the customer portal.

Note that you can upgrade Capsules separately from Satellite. For more information, see Section 1.4, “Upgrading Capsules Separately from Satellite”.

1.1. Prerequisites

Upgrading to Satellite 6.8 affects your entire Satellite infrastructure. Before proceeding, complete the following:

  • Read the Red Hat Satellite 6.8 Release Notes.
  • Review this guide so that you are aware of the upgrade process and its impact.
  • Plan your upgrade path. For more information, see Section 1.2, “Upgrade Paths”.

  • Plan for the required downtime. Satellite services are shut down during the upgrade. The upgrade process duration might vary depending on your hardware configuration, network speed, and the amount of data that is stored on the server.

    Upgrading Satellite takes approximately 1 - 2 hours.

    Upgrading Capsule takes approximately 10 - 30 minutes.

  • Before the upgrade, create the /var/opt/rh/rh-postgresql12/ volume of the size not smaller than the existing /var/lib/pgsql/ volume. This is required because Satellite 6.8 installs PostgreSQL 12 with the rh-postgresql12-postgresql-server package from the Software Collection repository. This changes the working directory of PostgreSQL to /var/opt/rh/rh-postgresql12/.

    If an upgrade successfully completes, content of the /var/lib/pgsql directory becomes redundant because it contains a database snapshot prior the upgrade. Until there is a specific need, you can remove the directory content and the logical volume after the successful upgrade.

  • Ensure that you have sufficient storage space on your server. For more information, see Storage Requirements in Installing Satellite Server from a Connected Network and Storage Requirements in Installing Capsule Server.
  • Back up your Satellite Server and all Capsule Servers. For more information, see Backing Up Satellite Server and Capsule Server in the Administering Red Hat Satellite 6.7 guide.
  • Plan for updating any scripts you use that contain Satellite API commands because some API commands differ between versions of Satellite. For more information about changes in the API, see the Knowledgebase article API Changes Between Satellite Versions on the Red Hat Customer Portal.
Warning

If you customize configuration files, manually or use a tool such as Hiera, these customizations are overwritten when the installation script runs during upgrading or updating. You can use the --noop option with the satellite-installer script to test for changes. For more information, see the Red Hat Knowledgebase solution How to use the noop option to check for changes in Satellite config files during an upgrade.

1.2. Upgrade Paths

You can upgrade to Red Hat Satellite 6.8 from Red Hat Satellite 6.7. Satellite Servers and Capsule Servers on earlier versions must first be upgraded to Satellite 6.7. For more details, see the Satellite 6.7 Upgrading and Updating Red Hat Satellite guide.

Figure 1.1. Overview of Satellite 6.8 Upgrade Paths

Overview of Satellite 6.8 Upgrade Paths
Warning

Upgrading from the Beta to GA version is not supported.

The high level steps in upgrading to Satellite 6.8 are as follows.

  1. Clone your existing Satellite Servers. For more information, see Chapter 2, Cloning Satellite Server.
  2. Upgrade Satellite Server and all Capsule Servers to Satellite 6.8. For more information, see Section 3.1, “Upgrading Satellite Server”.
  3. Upgrade to Satellite Tools 6.8 on all Satellite clients. For more information, see Section 3.4, “Upgrading Satellite Clients”.

Self-Registered Satellites

You cannot upgrade a self-registered Satellite. You must migrate a self-registered Satellite to the Red Hat Content Delivery Network (CDN) and then perform the upgrade. To migrate a self-registered Satellite to the CDN, see Upgrading Red Hat Satellite in the Satellite 6.3 Upgrading and Updating Red Hat Satellite guide.

1.3. Following the Progress of the Upgrade

Because of the lengthy upgrade time, use a utility such as screen to suspend and reattach a communication session. You can then check the upgrade progress without staying connected to the command shell continuously. For more information about using the screen command, see How do I use the screen command? article in the Red Hat Knowledge Base. You can also see the screen manual page for more information.

If you lose connection to the command shell where the upgrade command is running you can see the logs in /var/log/foreman-installer/satellite.log to check if the process completed successfully.

1.4. Upgrading Capsules Separately from Satellite

You can upgrade Satellite to the version 6.8 and keep Capsules at the version 6.7 until you have bandwidth to upgrade them too.

All the functionality that worked previously works on 6.7 Capsules. However, the functionality added in the 6.8 release will not work until you upgrade Capsules to 6.8.

Upgrading Capsules after upgrading Satellite can be useful in the following example scenarios:

  1. If you want to have several smaller outage windows instead of one larger window.
  2. If Capsules in your organization are managed by several teams and are located in different locations.
  3. If you use a load-balanced configuration, you can upgrade one load-balanced Capsule and keep other load-balanced Capsules at 1 version lower. This allows you to upgrade all Capsules one after another without any outage.