Alternate Content Sources

Alternate Content Sources (ACS) can help speed up populating of new repositories if you have content stored locally or geographically near you. Alternate Content Sources will allow you to use the content you have around if it matches the remote one.
This document will guide you to use the RHUI instance or your local backup as a content source to sync repositories on Red Hat Satellite and save network traffic.

Requirements

• Red Hat Satellite 6.11

Instructions

In the new version of Satellite/Pulp, alternate content sources work as special remotes.
To use this guide, you need to have pulp-cli setup on your Red Hat Satellite server. For detailed instructions, you can follow this KCS.

Note: This is a tech preview feature so it is not fully supported on Satellite 6.11, in upcoming versions of satellite there are plans to support it officially.

Use Case 1: RHUI as an Alternate Content Source (ACS)

This scenario presumes two boxes. One with RHUI 4 installed and another with Pulp 3(Satellite 6.11) installed.
You, or your RHUI admin, need to generate a certificate in the RHUI server to authenticate Satellite against RHUI.

Generate RHUI client certificates

On RHUA instance run

• List repositories synced on RHUA

  rhui-manager repo list
  

• Get the certificates generated for set of repositories that you would like to sync on Red Hat Satellite.

  rhui-manager client cert --name rhuicertfiles --days 365 --dir /root --repo_label <repo_no_1_rhui>,<repo_no_2_rhui>
  

• Now copy generated certificates to the box with Satellite/Pulp installed.

Use Pulp CLI to configure ACS

Please note that you need to create a remote and Alternate Content Source for each repository you want to use as an Alternate Content Source.

On the Red Hat Satellite server with Pulp-cli installed and configured

• Create remote with certificates generated on RHUA. Please note that pulp remote must use policy "on_demand". Also adjust a path to match where you upload RHUI certificates.

  pulp rpm remote create --name ACSRemote --policy on_demand --client-cert "$(cat rhui/content.crt)" --client-key "$(cat rhui/key.pem)" --tls-validation false --url https://ecinstance.eu-west-1.compute.amazonaws.com/pulp/content/content/dist/rhel8/rhui/8/x86_64/baseos/os/
  

• With this remote create ACS and refresh it to update the library of alternate content sources.

  pulp rpm acs create --name ACS --remote rpm:ACSRemote
  pulp rpm acs refresh --name ACS
  

• Next time you sync a repo with any matching content in refreshed ACS, it will be used as a a source to download.

  pulp rpm repository create --name RPMRepo
  pulp rpm remote create --name RPMRemote --url http://repo.example.org/
  pulp rpm repository sync --name RPMRepo --remote rpm:RPMRemote
  

Use Case 2: Speeding up sync with local content

This use case shows how to use ACS when you have repositories synced locally on some other server. Local backup is required to be stored as a repository, which means it has all the packages and metadata as a repository.
Let's say you got a backup copy of two repositories (for example baseos and appstream) on a mounted disk. Check your pulp settings if ALLOWED_IMPORT_PATHS contains (base) path to your local files. In our case ["/mnt/backup"] must be present.

• Create a remote only with a base path to your repositories.

  pulp rpm remote create --name ACSRemote --policy on_demand --url file:///mnt/backup/dist/rhel8/x86_64/
  

• When creating ACS, specify paths under your base path to your repositories

  pulp rpm acs create --name ACS --remote rpm:ACSRemote --path "baseos/" --path "appstream/"
  pulp rpm acs refresh --name ACS
  
  

As in the example above, next time you will sync any of baseos or appstream repositories, both alternate repositories will be used as a source of content.