Red Hat Training

A Red Hat training course is available for Red Hat Satellite

Chapter 1. Introduction

This chapter describes different methods of migrating from Red Hat Satellite 5 to Satellite 6.

1.1. Transition Paths

The two primary strategies for migrating from Red Hat Satellite 5 to Satellite 6 are passive transition and active transition, both of which involve developing a Satellite 6 architecture alongside your Satellite 5 architecture.

Passive Transition

In a passive transition scenario, the existing workloads remain on Satellite 5, and only new workloads and projects are targeted for management by Satellite 6. This strategy is most appropriate if your Satellite deployment is complex and involves significant integration with other applications via APIs or other processes. In this case, Red Hat Satellite 6 is deployed to manage only new workloads and projects, whereas Red Hat Satellite 5 is maintained in order to manage existing workloads until they are retired. Satellite 5 data models might or might not be transitioned to Satellite 6. A passive transition gives administrators the most freedom to reconsider their infrastructure with the least possibility of any disruption to services.

Active Transition

In an active transition scenario, the intention is that all workloads will be moved to Satellite 6. The originating Satellite 5 is then free to be migrated into an archived state and shut down. There are two variations of this strategy:

  • Active Transition with Post-Installation Components
  • Active Transition without Post-Installation Components

Post-installation components refers to anything specific to Satellite 5 that you configured or created after installation. For example, system groups, activation keys and channels.

Active Transition with Post-Installation Components

Build a new Satellite 6 based upon Satellite 5, and migrate clients after translating the Satellite 5 data models to Satellite 6 and registering systems to the new Satellite. This method allows data models to remain somewhat similar and familiar, with all workloads migrated to the new Red Hat Satellite. This method uses the sat5to6 script. See Performing the Transition Using the sat5to6 Script.

Active Transition without Post-Installation Components

Build a new Satellite 6 not based upon Satellite 5, but using the new features of Satellite 6. Existing workloads are only migrated after a period of testing and planing has taken place. No clients profiles are migrated in this scenario, advantage is taken of the new features provided by Puppet. Red Hat gives customers a whole year of duplicate Satellite subscriptions so that you can build and test a Satellite 6 Server before migrating only the Satellite 5 clients to the new system. This version of the active migration strategy is now strongly recommended. This method uses the bootstrap script to migrate the clients. See Chapter 3, Migrating Existing Systems Using The Bootstrap Script.

1.2. Frequently Asked Questions

Can I perform an in-place upgrade from Satellite 5 to Satellite 6?

The underlying technologies between Satellite 5 and 6 are significantly different. For this reason, the in-place upgrade process (such as from version 4.x to 5.x or from 5.x to 5.y) does not apply for version 5 to 6. Satellite 6 needs to be installed on a new server as part of the side-by-side transition process. Consequently, this is referred to as a transition process and not an upgrade process.

Which versions of Satellite 5 are supported for the transition?

The transition path begins with Satellite 5.6 or 5.7. If you are running an earlier version of Satellite you first need to upgrade to at least version 5.6.

Future releases of Satellite will also be supported as platforms for moving from Satellite 5.

Note

If you plan a more passive transition process, the prior Satellite version does not matter. A passive transition process is more of an adoption process where legacy workloads remain on Satellite 5 and new workloads are freshly modeled on Satellite 6 as if it is treated as new infrastructure for your Red Hat Enterprise Linux Systems Management needs.

Which versions of Red Hat Enterprise Linux will Satellite 5 and Satellite 6 support as client systems?

The following support matrix currently applies:

  • Satellite 5.6 supports clients of Red Hat Enterprise Linux versions 4, 5, 6, and 7.
  • Satellite 6 supports clients of Red Hat Enterprise Linux versions 5.7 and later, 6.1 and later, and 7.0 and later.
  • Satellite 6 does not support clients of version Red Hat Enterprise Linux 4.

What is the quick version of how to transition from Satellite 5 to Satellite 6?

  1. Install Satellite 6, activate with a manifest and synchronize Red Hat content from CDN.

    1. Review the documentation, learn and understand the basics of the Satellite 6 Product, including new concepts, such as environments.
    2. Back up the new Satellite 6 Server, including databases, before using the transition tools.
  2. As root on Satellite 5, run the exporter command-line tool.
  3. Copy the resulting data onto Satellite 6.
  4. As root on Satellite 6, run the importer command-line tools.
  5. Validate and test the resulting Satellite 6 system for a subset of end to end functionality and important use cases corresponding to the data types transitioned from Satellite 5 to 6.
Note

Not all of the concepts can be translated between Satellite 5 and 6. Some manual steps are required to fully populate the newly installed Satellite 6 Server.

Will the transition tools work with a disconnected server?

Yes, the transition tools are designed such that a disconnected environment is assumed, and neither Satellite 5 nor 6 can directly communicate with each other or the Internet in general.

Will the transition tools transition all data from Satellite 5 to Satellite 6?

No. In some situations, Satellite 5 and Satellite 6 take different approaches to the tasks of synchronizing and provisioning hosts, managing entitlements, and dealing with disconnected environments. Some configuration, system, and host data is also created and stored differently. Consequently, not all data can be successfully transitioned.

In Satellite 6, the following information cannot be transitioned:

  • Activation-keys that use "Red Hat default"
  • Anything history or audit related (events, oscap runs, and so on)
  • Anything monitoring related
  • Configuration-channel ordering
  • Distribution-channel mapping
  • Kickstart data (other than snippets)
  • Organization entitlement distribution (users need to create their own manifests)
  • Organization-trusts settings
  • Snapshots
  • Stored package profiles
  • Custom system information, such as key-value pairs, system notes, and system properties in general. The latter is completed when a system registers to Satellite 6 and connects to the created profile.
  • User preferences

Can I run the transition tools and process multiple times?

Yes, the transition tools are idempotent. You can reuse the tools to create Satellite 6 data and preserve previous information. A small data file on the Satellite 6 Server preserves the history of previous runs and tracks what has already been imported.

Can I delete imported entities?

Yes. You can use the hammer import command to delete any or all of the entities imported to Satellite 6 from the Satellite 5 export file. This is useful if the import fails for some reason, and you need to update the CSV file and repeat the import. You can also use this procedure to test your import process in a development environment before using it in production.

You can delete a subset of imported entities, for example, users, or you can delete all imported entities. If you delete all imported entities, you effectively revert your Satellite 6 system to its original state before you started the import process.

The following example describes how to delete all imported users.

Example 1.1. Deleting Imported Users

$ hammer import user --csv-file /tmp/exports/users.csv --delete --verbose
Deleting from /tmp/exports/users.csv
Deleting imported user [1->4].
Deleting imported user [2->5].
Deleting imported user [3->6].
Deleting imported user [5->7].
Deleting imported user [6->8].
Deleting imported user [7->9].
Deleting imported user [4->10].
Summary
Deleted 7 users.

To delete all imported entities, use the following command: 

# hammer import all --delete
Important

This command deletes all imported entities, including users, organizations, repositories, and so on.

Can I use the export tools on my production Satellite 5 system?

Yes, assuming that you run the tools with sufficient disk space. Disk space will vary, from 20 MB to several Gigabytes, depending on the total amount of non-Red Hat content stored on the Satellite in /var/satellite/redhat/ and being selected for export by the export tool. When exporting custom or cloned channels, the tool searches for non-Red Hat content associated with the channels, to copy into the export archive. Other than some short-term CPU and memory consumption, the tool only performs read-only file system, and SQL queries on the database to gather data, write the resulting data to files on disk, and create a tar archive of the data.