Configuring and Managing Red Hat Update Infrastructure

Red Hat Update Infrastructure 4

Setting up and revising Red Hat Update Infrastructure 4

Red Hat Customer Content Services

Abstract

This guide describes how to configure and manage Red Hat Update Infrastructure 4 (RHUI 4).

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. We are beginning with these four terms: master, slave, blacklist, and whitelist. Because of the enormity of this endeavor, these changes will be implemented gradually over several upcoming releases. For more details, see our CTO Chris Wright’s message.

Chapter 1. About Red Hat Update Infrastructure 4

Red Hat Update Infrastructure 4 (Red Hat Update Infrastructure 4) is a highly scalable, highly redundant framework that enables you to manage repositories and content. It also enables cloud providers to deliver content and updates to Red Hat Enterprise Linux (RHEL) instances. Based on the upstream Pulp project, RHUI allows cloud providers to locally mirror Red Hat-hosted repository content, create custom repositories with their own content, and make those repositories available to a large group of end users through a load-balanced content delivery system.

As a system administrator, you can prepare your infrastructure for participation in the Red Hat Certified Cloud and Service Provider program by installing and configuring the Red Hat Update Appliance (RHUA), content delivery servers (CDS), repositories, shared storage, and load balancing.

Configuring RHUI comprises the following tasks:

  • Creating and synchronizing a Red Hat repository
  • Creating client entitlement certificates and client configuration RPMs
  • Creating client profiles for the RHUI servers

Experienced RHEL system administrators are the target audience. System administrators with limited RHEL skills should consider engaging Red Hat Consulting to provide a Red Hat Certified Cloud Provider Architecture Service.

Learn about configuring, managing, and updating RHUI with the following topics:

  • the RHUI components
  • content provider types
  • the command line interface (CLI) used to manage the components
  • utility commands
  • certificate management
  • content management

1.1. Installation options

The following table presents the various Red Hat Update Infrastructure 4 components.

Table 1.1. Red Hat Update Infrastructure components and functions

ComponentAcronymFunctionAlternative

Red Hat Update Appliance

RHUA

Downloads new packages from the Red Hat content delivery network and copies new packages to each CDS node

None

Content Delivery Server

CDS

Provides the yum repositories that clients connect to for the updated packages

None

HAProxy

None

Provides load balancing across CDS nodes

Existing load balancing solution

Shared storage

None

Provides shared storage

Existing storage solution

The following table describes how to perform installation tasks.

Table 1.2. Red Hat Update Infrastructure installation tasks

Installation TaskPerformed on

Install RHEL 8

RHUA, CDS, and HAProxy

Subscribe the system

RHUA, CDS, and HAProxy

Attach a RHUI subscription

RHUA, CDS, and HAProxy

Apply updates

RHUA, CDS and HAProxy

Install rhui-installer

RHUA

Run rhui-installer

RHUA

1.1.1. Option 1: Full installation

  • A RHUA
  • Two or more CDS nodes with shared storage
  • One or more HAProxy load-balancers

1.1.2. Option 2: Installation with an existing storage solution

  • A RHUA
  • Two or more CDS nodes with an existing storage solution
  • One or more HAProxy load-balancers

1.1.3. Option 3: Installation with an existing load-balancer solution

  • A RHUA
  • Two or more CDS nodes with shared storage
  • An existing load-balancer

1.1.4. Option 4: Installation with existing storage and load-balancer solutions

  • A RHUA
  • Two or more CDS nodes with existing shared storage
  • An existing load-balancer

The following figure depicts a high-level view of how the various Red Hat Update Infrastructure 4 components interact.

Figure 1.1. Red Hat Update Infrastructure 4 overview

Red Hat Update Infrastructure Overview
Note

You need to subscribe the RHUA as --type rhui and have a Red Hat Certified Cloud and Service Provider subscription to install RHUI. You also need an appropriate content certificate.

Install the RHUA and CDS nodes on separate x86_64 servers (bare metal or virtual machines). Ensure all the servers and networks that connect to RHUI can access the Red Hat Subscription Management service.

1.2. RHUI 4 components

Understanding how each RHUI component interacts with other components will make your job as a system administrator a little easier.

1.2.1. Red Hat Update Appliance

There is one RHUA per RHUI installation, though in many cloud environments there will be one RHUI installation per region or data center, for example, Amazon’s EC2 cloud comprises several regions. In every region, there is a separate RHUI set up with its own RHUA node.

The RHUA allows you to perform the following tasks:

  • Download new packages from the Red Hat content delivery network (CDN). The RHUA is the only RHUI component that connects to Red Hat, and you can configure the synchronization schedule for the RHUA.
  • Copy new packages to the shared network storage.
  • Verify the RHUI installation’s health and write the results to a file located on the RHUA. Monitoring solutions use this file to determine the RHUI installation’s health.
  • Provide a human-readable view of the RHUI installation’s health through a CLI tool.

RHUI uses two main configuration files: /etc/rhui/rhui-tools.conf and /etc/rhui/rhui-subscription-sync.conf.

The /etc/rhui/rhui-tools.conf configuration file contains general options used by the RHUA, such as the default file locations for certificates, and default configuration parameters for the Red Hat CDN synchronization. This file normally does not require editing.

The Red Hat Update Infrastructure Management Tool generates the /etc/rhui/rhui-subscription-sync.conf configuration file based on user-inputted values. It contains all the information that drives the running of a RHUA in a particular region. An example configuration includes the destination on the RHUA to download packages.

The RHUA employs several services to synchronize, organize, and distribute content for easy delivery.

RHUA services

Pulp
The service that oversees management of the supporting services, providing a user interface for users to interact with
PostgreSQL
A PostgreSQL database used to keep track of currently synchronized repositories, packages, and other crucial metadata.

1.2.2. Content delivery server

The CDS nodes provide the repositories that clients connect to for the updated content. There can be as few as one CDS. Because RHUI provides a load-balancer with failover capabilities, we recommended that you use multiple CDS nodes.

The CDS nodes host content to end-user RHEL systems. While there is no required number of systems, the CDS works in a round-robin style load-balanced fashion (A, B, C, A, B, C) to deliver content to end-user systems. The CDS uses HTTP to host content to end-user systems via httpd-based yum repositories.

During configuration, you specify the CDS directory where packages are synchronized. Similar to the RHUA, the only requirement is that you mount the directory on the CDS. It is up to the cloud provider to determine the best course of action when allocating the necessary devices. The Red Hat Update Infrastructure Management Tool configuration RPM linked the package directory with the NGINX configuration to serve it.

Currently, RHUI supports the following shared storage solutions:

NFS

If NFS is used, rhui-installer can configure an NFS share on the RHUA to store the content as well as a directory on the CDS nodes to mount the NFS share. The following rhui-installer options control these settings:

  • --remote-fs-mountpoint is the file system location where the remote file system share should be mounted (default: /var/lib/rhui/remote_share)
  • --remote-fs-server is the remote mount point for a shared file system to use, for example, nfs.example.com:/path/to/share (default: nfs.example.com:/export)
CephFS

If using CephFS, you must configure CephFS separately and then use it with RHUI as a mount point. The following rhui-installer options control these settings:

  • --remote-fs-server is the remote mount point for a shared file system to use, for example, ceph.example.com:/path/to/share (default: ceph.example.com:/export)
Note

This document does not provide instructions to set up or configure Ceph shared file storage. For any Ceph related tasks, consult your system administrator, or see the Ceph documentation.

If these default values are used, the /export directory on the RHUA and the /var/lib/rhui/remote_share directory on each CDS are identical.

The expected usage is that you use one shared network file system on the RHUA and all CDS nodes, for example, NFS. It is possible the cloud provider will use some form of shared storage that the RHUA writes packages to and each CDS reads from.

Note

The storage solution must provide an NFS or CephFS endpoint for mounting on the RHUA and CDS nodes. If local storage is implemented, shared storage is needed for the cluster to work. If you want to provide local storage to the RHUA, configure the RHUA to function as the NFS server with a rhua.example.com:/path/to/nfs/share endpoint configured.

Do not set up Ceph shared file storage on any of the RHUI nodes. You must configure CephFS on independent dedicated machines.

The only nonstandard logic that takes place on each CDS is the entitlement certificate checking. This checking ensures that the client making requests on the yum repositories is authorized by the cloud provider to access those repositories. The check ensures the following conditions:

  • The entitlement certificate was signed by the cloud provider’s Certificate Authority (CA) Certificate. The CA Certificate is installed on the CDS as part of its configuration to facilitate this verification.
  • The requested URI matches an entitlement found in the client’s entitlement certificate.

If the CA verification fails, the client sees an SSL error. See the CDS node’s NGINX logs under /var/log/nginx/ for more information.

[root@cds01 ~]# ls -1 /var/log/nginx/
access.log
error.log
gunicorn-auth.log
gunicorn-content_manager.log
gunicorn-mirror.log
ssl-access.log----
Important

The NGINX configuration is handled through the /etc/nginx/conf.d/ssl.conf file during the CDS installation.

If multiple clients experience problems updating against a repository, this may indicate a problem with the RHUI. See Yum generates 'Errno 14 HTTP Error 401: Authorization Required' while accessing RHUI CDS for more details.

1.2.3. HAProxy load-balancer

If more than one CDS is used, a load-balancing solution must be in place to spread client HTTPS requests across all servers. RHUI ships with HAProxy, but it is up to you to choose what load-balancing solution (for example, the one from the cloud provider) to use during the installation. If HAProxy is used, you must also decide how many nodes to bring in.

Clients are not configured to go directly to a CDS; their repository files are configured to point to HAProxy, the RHUI load-balancer. HAProxy is a TCP/HTTP reverse proxy particularly suited for high-availability environments. HAProxy performs the following tasks:

  • Routes HTTP requests depending on statically assigned cookies
  • Spreads the load among several servers while assuring server persistence through the use of HTTP cookies
  • Switches to backup servers in the event a main server fails
  • Accepts connections to special ports dedicated to service monitoring
  • Stops accepting connections without breaking existing ones
  • Adds, modifies, and deletes HTTP headers in both directions
  • Blocks requests matching particular patterns
  • Persists client connections to the correct application server, depending on application cookies
  • Reports detailed status as HTML pages to authenticated users from a URI intercepted from the application
Note

If you use an existing load-balancer, ensure port 443 is configured in the load-balancer for the cds-lb-hostname forwarded to the pool and that all CDSs in the cluster are in the load-balancer’s pool.

The exact configuration depends on the particular load-balancer software you use. See the following configuration, taken from a typical HAProxy setup, to understand how you should configure your load-balancer:

[root@rhui4proxy ~]# cat /etc/haproxy/haproxy.cfg
# This file managed by Puppet
global
  chroot  /var/lib/haproxy
  daemon
  group  haproxy
  log  10.10.153.149 local0
  maxconn  4000
  pidfile  /run/haproxy.pid
  stats  socket /var/lib/haproxy/stats
  user  haproxy

defaults
  log  global
  maxconn  8000
  option  redispatch
  retries  3
  stats  enable
  timeout  http-request 10s
  timeout  queue 1m
  timeout  connect 10s
  timeout  client 1m
  timeout  server 1m
  timeout  check 10s

listen https00
  bind 10.10.153.149:443
  balance roundrobin
  option tcplog
  option tcp-check
    server cds01.example.com cds01.example.com:443 check
    server cds02.example.com cds02.example.com:443 check

Keep in mind that when clients fail to connect, it is important to review the nginx logs on the CDS under /var/log/nginx/ to ensure that any request reached the CDS. If requests do not reach the CDS, issues such as DNS or general network connectivity may be at fault.

1.2.4. Repositories and content

A repository is a storage location for software packages (RPMs). RHEL uses yum commands to search a repository, download, install, and configure the RPMs. The RPMs contain all the dependencies needed to run an application. RPMs also download updates for software in your repositories.

RHEL uses core technologies such as control groups (cgroups) for resource management, namespaces for process isolation, and SELinux for security, enabling secure multiple tenancy, and reducing the potential for security exploits. These technologies enable rapid application deployment, simpler testing, maintenance, and troubleshooting while improving security.

Content, as it relates to RHUI, is the software (such as RPMs) that you download from the Red Hat CDN for use on the RHUA and the CDS nodes. The RPMs provide the files necessary to run specific applications and tools. Clients are granted access by a set of SSL content certificates and keys provided by an rpm package, which also provides a set of generated yum repository files.

1.3. Content provider types

There are three types of cloud computing environments:

  • public cloud
  • private cloud
  • hybrid cloud

This guide focuses on public and private clouds. We assume the audience understands the implications of using public, private, and hybrid clouds.

1.4. Component communications

All RHUI components use the HTTPS communication protocol over port 443.

Table 1.3. Red Hat Update Infrastructure communication protocols

SourceDestinationProtocolPurpose

Red Hat Update Appliance

Red Hat Content Delivery Network

HTTPS

Downloads packages from Red Hat

Load-Balancer

Content Delivery Server

HTTPS

Forwards the client’s yum

Client

Load-Balancer

HTTPS

Used by yum on the client to download packages from a CDS

Content Delivery Server

Red Hat Update Appliance

HTTPS

Might request information from Pulp API about content

RHUI nodes require the following network access to communicate with each other.

Note

Make sure that the network port is open and that network access is restricted to only those nodes that you plan to use.

Table 1.4. Red Hat Update Infrastructure network access

NodePortAccess

RHUA

443

RHUA, CDS01, CDS02, …​ CDSn

HAProxy

443

Client virtual machines

1.5. Changing the admin password

The rhui-installer sets the initial RHUI login password. It is also written in the /etc/rhui/rhui-subscription-sync.conf file. You can override the initial password with the --rhui-manager-password option.

If you want to change the initial password later, you can change it through the rhui-manager tool or through rhui-installer. Run the rhui-installer --help command to see the full list of rhui-installer options.

Procedure

  1. Navigate to the Red Hat Update Infrastructure Management Tool home screen:

    [root@rhua ~]# rhui-manager
  2. Press u to select manage RHUI users.
  3. From the User Manager screen, press p to select change admin’s password (followed by logout):

    -= User Manager =-
    
       p   change admin's password (followed by logout)
    
       rhui (users) => p
    
       Warning: After password change you will be logged out.
       Use ctrl-c to cancel password change.
       New Password:
  4. Enter your new password; reenter it to confirm the change.

    New Password:
    Re-enter Password:
    
    [localhost] env PULP_SETTINGS=/etc/pulp/settings.py /usr/bin/pulpcore-manager reset-admin-password -p ********

Verification

  1. The following message displays after you change the admin password:

    Password successfully updated. For security reasons you have been logged out.
    [root@ip-10-141-150-145 ~]#

1.6. Additional resources

Chapter 2. Managing repositories

2.1. Available channels

Certified Cloud and Service Provider (CCSP) partners control what channels and packages are delivered through their service. See Red Hat Enterprise Linux repositories that can be delivered through Red Hat’s Certified Cloud and Service Provider (CCSP) partners via RHUI for the most current information regarding what channels are available for the various operating system versions.

The repositories available for use with RHEL 8 are as follows:

  • Red Hat Enterprise Linux 8 for x86_64 - AppStream from RHUI (RPMs)
  • Red Hat Enterprise Linux 8 for x86_64 - BaseOS from RHUI (RPMs)
  • Red Hat Enterprise Linux 8 for x86_64 - High Availability (RPMs) from RHUI
  • Red Hat Enterprise Linux 8 for x86_64 - Resilient Storage (RPMs) from RHUI
  • Red Hat Enterprise Linux 8 for x86_64 - Supplementary (RPMs) from RHUI
  • Red Hat CodeReady Linux Builder for RHEL 8 x86_64 (RPMs) from RHUI

Contact your CCSP if a required channel is missing.

Additional resources

2.2. Listing repositories currently managed by RHUI 4

A repository is a server node that contains downloadable software for a Linux distribution. You use yum to search for, install, and control RPMs from the repository to your RHUA and CDS nodes.

Procedure

  1. Navigate to the Red Hat Update Infrastructure Management Tool home screen:

    [root@rhua ~]# rhui-manager
  2. Press r to select manage repositories.
  3. From the Repository Management screen, press l to select list repositories currently managed by the RHUI:

    ...
    
    Red Hat Enterprise Linux 8 for ARM 64 - AppStream (RPMs) from RHUI (8)
    Red Hat Enterprise Linux 8 for ARM 64 - AppStream (RPMs) from RHUI (8.0)
    Red Hat Enterprise Linux 8 for ARM 64 - AppStream (RPMs) from RHUI (8.1)
    Red Hat Enterprise Linux 8 for ARM 64 - AppStream (RPMs) from RHUI (8.2)
    Red Hat Enterprise Linux 8 for ARM 64 - AppStream (RPMs) from RHUI (8.3)
    Red Hat Enterprise Linux 8 for ARM 64 - AppStream (RPMs) from RHUI (8.4)
    Red Hat Enterprise Linux 8 for ARM 64 - AppStream (Source RPMs) from RHUI (8)
    Red Hat Enterprise Linux 8 for ARM 64 - AppStream (Source RPMs) from RHUI (8.0)
    Red Hat Enterprise Linux 8 for ARM 64 - AppStream (Source RPMs) from RHUI (8.1)
    Red Hat Enterprise Linux 8 for ARM 64 - AppStream (Source RPMs) from RHUI (8.2)
    Red Hat Enterprise Linux 8 for ARM 64 - AppStream (Source RPMs) from RHUI (8.3)
    Red Hat Enterprise Linux 8 for ARM 64 - AppStream (Source RPMs) from RHUI (8.4)
    Red Hat Enterprise Linux 8 for ARM 64 - BaseOS (Debug RPMs) from RHUI (8)
    Red Hat Enterprise Linux 8 for ARM 64 - BaseOS (Debug RPMs) from RHUI (8.0)
    Red Hat Enterprise Linux 8 for ARM 64 - BaseOS (Debug RPMs) from RHUI (8.1)
    Red Hat Enterprise Linux 8 for ARM 64 - BaseOS (Debug RPMs) from RHUI (8.2)
    Red Hat Enterprise Linux 8 for ARM 64 - BaseOS (Debug RPMs) from RHUI (8.3)
    Red Hat Enterprise Linux 8 for ARM 64 - BaseOS (Debug RPMs) from RHUI (8.4)
    
    ...

2.3. Displaying detailed information on a repository

You can use the Repository Management screen to display information about a particular repository.

Procedure

  1. Navigate to the Red Hat Update Infrastructure Management Tool home screen:

    [root@rhua ~]# rhui-manager
  2. Press r to select manage repositories.
  3. From the Repository Management screen, press i:

    Enter value (1-1631) to toggle selection, 'c' to confirm selections, or '?' for more commands:
  4. Select the repository by entering the value beside the repository name. Enter one repository selection at a time before confirming your product selection.
  5. Press c to confirm:

    Name:                Red Hat Enterprise Linux 8 for ARM 64 - AppStream (Debug RPMs) from RHUI (8.4)
    ID:                  rhel-8-for-aarch64-appstream-debug-rhui-rpms-8.4
    Type:                Red Hat
    Version:             0
    Relative Path:       content/dist/rhel8/rhui/8.4/aarch64/appstream/debug
    GPG Check:           Yes
    Custom GPG Keys:     (None)
    Red Hat GPG Key:     Yes
    Content Unit Count:
    Last Sync:           2021-11-15 15:56:06
    Next Sync:           2021-11-15 22:00:00
    
    Name:                Red Hat Enterprise Linux 8 for ARM 64 - AppStream (RPMs) from RHUI (8.4)
    ID:                  rhel-8-for-aarch64-appstream-rhui-rpms-8.4
    Type:                Red Hat
    Version:             0
    Relative Path:       content/dist/rhel8/rhui/8.4/aarch64/appstream/os
    GPG Check:           Yes
    Custom GPG Keys:     (None)
    Red Hat GPG Key:     Yes
    Content Unit Count:
    Last Sync:           2021-11-15 19:50:20
    Next Sync:           2021-11-16 01:55:00
    
    Name:                Red Hat Enterprise Linux 8 for ARM 64 - AppStream (Source RPMs) from RHUI (8.4)
    ID:                  rhel-8-for-aarch64-appstream-source-rhui-rpms-8.4
    Type:                Red Hat
    Version:             0
    Relative Path:       content/dist/rhel8/rhui/8.4/aarch64/appstream/source/SRPMS
    GPG Check:           Yes
    Custom GPG Keys:     (None)
    Red Hat GPG Key:     Yes
    Content Unit Count:
    Last Sync:           2021-11-15 15:56:51
    Next Sync:           2021-11-15 22:00:00

Verification

  1. A similar output displays for your selections.

2.4. Generating a repository status file

You can generate a machine-readable JSON file that displays the status of all RHUI repositories as well as provides some additional information. This is useful, for example, if you want to passively monitor the status of the repositories.

2.4.1. Generating a status file for RHUI repositories

You can use the rhui-manager command to obtain the status of each repository in a machine-readable format.

Procedure

2.4.2. List of dictionary keys in the repository status JSON file

A machine-readable JSON file is created when you run the command to get the status of each RHUI repository. The JSON file contains a list of dictionaries with one dictionary for each repository.

List of dictionary keys for custom repositories

Table 2.1. List of dictionary keys for custom repositories

KeyDescription

base_path

The path of the repository.

description

The name of the repository.

group

The group the repository belongs to. It is always set to the string, custom.

id

The repository ID.

name

The name of the repository. It is the same as the repository ID.

List of dictionary keys for Red Hat repositories

Table 2.2. List of dictionary keys for Red Hat repositories

KeyDescription

base_path

The path of the repository.

description

The name of the repository.

group

The group the repository belongs to. It is always set to the string, redhat.

id

The repository ID.

last_sync_date

The date and time the repository was last synchronized. The value is null if the repository was never synchronized.

last_sync_exception

The exception raised if the repository failed to synchronize. The value is null if the repository was synchronized correctly.

last_sync_result

The result of the synchronization task.

The values are:

  • completed: If the repository synchronized correctly.
  • null: If the repository was never synchronized.
  • failed: If the synchronization failed.
  • running: If a synchronization task is currently running.

last_sync_traceback

The traceback that was logged if the repository failed to synchronize. The value is null if the repository was synchronized correctly or was never synchronized.

metadata_available

A boolean value denoting whether metadata is available for the repository.

name

The name of the repository. It is the same as the repository ID.

next_sync_date

The date and time of the next scheduled synchronization of the repository. If a synchronization task is currently running, the value is running.

repo_published

A boolean value denoting whether this repository has been published in RHUI. Note that, by default, RHUI is configured to automatically publish repositories.

2.5. Adding a new Red Hat content repository

Based on the upstream Pulp project, RHUI allows cloud providers to locally mirror Red Hat-hosted repository content, create custom repositories with their own content, and make those repositories available to end users through a load-balanced content delivery system.

Procedure

  1. Navigate to the Red Hat Update Infrastructure Management Tool home screen:

    [root@rhua ~]# rhui-manager
  2. Press r to select manage repositories.
  3. From the Repository Management screen, press a to select add a new Red Hat content repository.
  4. Wait for the Red Hat Update Infrastructure Management Tool to determine the entitled repositories. This might take several minutes:

    rhui (repo) => a
    
    Loading latest entitled products from Red Hat...
    ... listings loaded
    Determining undeployed products...
    ... product list calculated
  5. The Red Hat Update Infrastructure Management Tool prompts for a selection method:

    Import Repositories:
        1 - All in Certificate
        2 - By Product
        3 - By Repository
    Enter value (1-3) or 'b' to abort:
  6. Press 2 to select the By Product method.
  7. Select which repositories to add by typing the number of the repository at the prompt. You can also choose the range of repositories, for instance, by entering 1 - 5.

    Enter value (1-620) to toggle selection, 'c' to confirm selections, or '?' for more commands:
  8. Continue until all repositories you want to add are checked.
  9. Press c when you are finished selecting the repositories. The Red Hat Update Infrastructure Management Tool displays the repositories for deployment and prompts for confirmation:

    The following products will be deployed:
      Red Hat Enterprise Linux 8 for ARM 64 - BaseOS (Debug RPMs) from RHUI
      Red Hat Enterprise Linux 8 for ARM 64 - BaseOS (RPMs) from RHUI
    Proceed? (y/n)
  10. Press y to proceed. A message indicates each successful deployment:

    Importing Red Hat Enterprise Linux 8 for ARM 64 - BaseOS (Debug RPMs) from RHUI...
      Importing product repository Red Hat Enterprise Linux 8 for ARM 64 - BaseOS (Debug RPMs) from RHUI (8.4)...
      Importing product repository Red Hat Enterprise Linux 8 for ARM 64 - BaseOS (Debug RPMs) from RHUI (8.3)...
      Importing product repository Red Hat Enterprise Linux 8 for ARM 64 - BaseOS (Debug RPMs) from RHUI (8.2)...
      Importing product repository Red Hat Enterprise Linux 8 for ARM 64 - BaseOS (Debug RPMs) from RHUI (8.1)...
      Importing product repository Red Hat Enterprise Linux 8 for ARM 64 - BaseOS (Debug RPMs) from RHUI (8.0)...
      Importing product repository Red Hat Enterprise Linux 8 for ARM 64 - BaseOS (Debug RPMs) from RHUI (8)...
    
    Importing Red Hat Enterprise Linux 8 for ARM 64 - BaseOS (RPMs) from RHUI...
      Importing product repository Red Hat Enterprise Linux 8 for ARM 64 - BaseOS (RPMs) from RHUI (8.4)...
      Importing product repository Red Hat Enterprise Linux 8 for ARM 64 - BaseOS (RPMs) from RHUI (8.3)...
      Importing product repository Red Hat Enterprise Linux 8 for ARM 64 - BaseOS (RPMs) from RHUI (8.2)...
      Importing product repository Red Hat Enterprise Linux 8 for ARM 64 - BaseOS (RPMs) from RHUI (8.1)...
      Importing product repository Red Hat Enterprise Linux 8 for ARM 64 - BaseOS (RPMs) from RHUI (8.0)...
      Importing product repository Red Hat Enterprise Linux 8 for ARM 64 - BaseOS (RPMs) from RHUI (8)...
    
    Content will not be downloaded to the newly imported repositories
    until the next sync is run.

Verification

  1. From the Repository Management screen, press l to check that the correct repositories have been installed.

2.6. Adding a new Red Hat content repository using an input file

In Red Hat Update Infrastructure 4.2 and later, you can add custom repositories using a configured YAML input file. You can find an example template of the YAML file on the RHUA node in the /usr/share/rhui-tools/examples/repo_add_by_file.yaml directory.

This functionality is only available in the command-line interface (CLI).

Prerequisites

  • Ensure that you have root access to the RHUA node.

Procedure

  1. On the RHUA node, create a YAML input file in the following format:

    # cat /my_home/example.yaml
    ---
    name: Example_YAML_File
      repo_ids:
        - rhel-8-for-x86_64-baseos-eus-rhui-rpms-8.1
        - rhel-8-for-x86_64-baseos-eus-rhui-rpms-8.2
        - rhel-8-for-x86_64-baseos-eus-rhui-rpms-8.4
        - rhel-8-for-x86_64-baseos-eus-rhui-rpms-8.6
    ---
  2. Add the repositories listed in the input file using the rhui-manager utility:

    # rhui-manager repo add_by_file --file /my_home/example.yaml --sync_now
    The name of the repos being added: Example_YAML_File
    Loading latest entitled products from Red Hat...
    ... listings loaded
    Successfully added Red Hat Enterprise Linux 8 for x86_64 - BaseOS - Extended Update Support from RHUI (RPMs) (8.1) (Yum)
    Successfully added Red Hat Enterprise Linux 8 for x86_64 - BaseOS - Extended Update Support from RHUI (RPMs) (8.2) (Yum)
    Successfully added Red Hat Enterprise Linux 8 for x86_64 - BaseOS - Extended Update Support from RHUI (RPMs) (8.4) (Yum)
    Successfully added Red Hat Enterprise Linux 8 for x86_64 - BaseOS - Extended Update Support from RHUI (RPMs) (8.6) (Yum)
    ... successfully scheduled for the next available timeslot.
    ... successfully scheduled for the next available timeslot.
    ... successfully scheduled for the next available timeslot.
    ... successfully scheduled for the next available timeslot.

Verification

  • In the CLI, use the following command to list all the installed repositories and check whether the correct repositories have been installed:

    # rhui-manager repo list
  • In the RHUI Management Tool, on the Repository Management screen, press l to list all the installed repositories and check whether the correct repositories have been installed.

2.7. Creating a new custom repository (RPM content only)

You can create custom repositories that can be used to distribute updated client configuration packages or other non-Red Hat software to the RHUI clients. A protected repository for 64-bit RHUI servers (for example, client-rhui-x86_64) will be the preferred vehicle for distributing new non-Red Hat packages, such as an updated client configuration package, to the RHUI clients.

Like Red Hat content repositories, all of which are protected, protected custom repositories that differ only in processor architecture (i386 versus AMD64) are consolidated into a single entitlement within an entitlement certificate, using the $basearch yum variable.

In the event of certificate problems, an unprotected repository for RHUI servers can be used as a fallback method for distributing updated RPMs to the RHUI clients.

Procedure

  1. Navigate to the Red Hat Update Infrastructure Management Tool home screen:

    [root@rhua ~]# rhui-manager
  2. Press r to select manage repositories.
  3. From the Repository Management screen, press c to select create a new custom repository (RPM content only).
  4. Enter a unique ID for the repository. Only alphanumeric characters, _ (underscore), and - (hyphen) are permitted. You cannot use spaces in the unique ID. For example, repo1, repo_1, and repo-1 are valid entries.

    Unique ID for the custom repository (alphanumerics, _, and - only):
  5. Enter a display name for the repository. This name is used to identify the repository within the Red Hat Update Infrastructure Management Tool.

    Display name for the custom repository [repo_1]:
  6. Specify the path that will host the repository. The path must be unique across all repositories hosted by RHUI. For example, if you specify the path at this step as some/unique/name, then the repository will be located at //server/pulp/repos/some/unique/name.

    Unique path at which the repository will be served [repo_1]:
  7. Select sha256 as the checksum type to be used for the repository metadata.

    Note

    Use sha256 when you create a custom repository for RHEL 6, RHEL 7, or RHEL 8. Use sha1 if you create repositories for RHEL 5 client.

    Algorithm to use when calculating the checksum values for repository metadata:
    
        1 - sha256 (default)
        2 - sha1 (RHEL 5)
    Enter value (1-2) or 'b' to abort:
  8. Choose whether to protect the new repository. If you answer no to this question, any client can access the repository. If you answer yes, only clients with an appropriate entitlement certificate can access the repository.

    Warning

    As the name implies, the content in an unprotected repository is available to any system that requests it, without any need for a client entitlement certificate. Be careful when using an unprotected repository to distribute any content, particularly content such as updated client configuration RPMs, which will then provide access to protected repositories.

  9. Answer yes or no to the following questions as they appear:

    Should the repository require clients to perform a GPG check and verify packages are signed by a GPG key? (y/n)
    
    Will the repository be used to host any Red Hat GPG signed content? (y/n)
    
    Will the repository be used to host any custom GPG signed content? (y/n)
    
    Enter the absolute path to the public key of the GPG key pair:
    
    Would you like to enter another public key? (y/n)
    
    Enter the absolute path to the public key of the GPG key pair:
    
    Would you like to enter another public key? (y/n)
  10. The details of the new repository displays. Press y at the prompt to confirm the information and create the repository.

Verification

  1. From the Repository Management screen, press l to check that the correct repositories have been installed.

2.8. Deleting a repository from RHUI 4

When the Red Hat Update Infrastructure Management Tool deletes a Red Hat repository, it deletes the repository from the RHUA and all applicable CDS nodes.

Procedure

  1. Navigate to the Red Hat Update Infrastructure Management Tool home screen:

    [root@rhua ~]# rhui-manager
  2. Press r to select manage repositories.
  3. From the Repository Management screen, press d at the prompt to delete a Red Hat repository. A list of all repositories currently being managed by RHUI displays.
  4. Select which repositories to delete by typing the number of the repository at the prompt. Typing the number of a repository places a checkmark next to the name of that repository. You can also choose the range of repositories, for instance, by entering 1 - 5.
  5. Continue until all repositories you want to delete are checked.
  6. Press c at the prompt to confirm.

    Note

    After you delete the repositories, the client configuration RPMs that refer to the deleted repositories will not be available to be used by yum.

2.9. Uploading content to a custom repository (RPM content only)

You can upload multiple packages and upload to more than one repository at a time. Packages are uploaded to the RHUA immediately but are not available on the CDS node until the next time the CDS node synchronizes.

Procedure

  1. Navigate to the Red Hat Update Infrastructure Management Tool home screen:

    [root@rhua ~]# rhui-manager
  2. Press r to select manage repositories.
  3. From the Repository Management screen, press u:

    Select the repositories to upload the package into:
      -    1: test
  4. Enter the value (1-1) to toggle the selection.
  5. Press c to confirm your selection.
  6. Enter the location of the packages to upload. If the location is an RPM, the file will be uploaded. If the location is a directory, all RPMs in that directory will be uploaded:

    /home/localuser/bear-4.1-1.noarch.rpm
    
    The following RPMs will be uploaded:
      bear-4.1-1.noarch.rpm
  7. Press y to proceed or n to cancel:

    Uploaded /home/ec2-user/bear-4.1-1.noarch.rpm

Verification

  1. A similar message displays if the content uploaded successfully:

    Uploaded /home/ec2-user/bear-4.1-1.noarch.rpm
    Total of 1 packages uploaded.
    1 RPM(s) associated to repo test.

2.10. Uploading content from a remote web site (RPM content only)

You can upload packages that are stored on a remote server without having to manually download them first. The packages must be accessible by HTTP, HTTPS, or FTP.

Procedure

  1. Navigate to the Red Hat Update Infrastructure Management Tool home screen:

    [root@rhua ~]# rhui-manager
  2. Press r to select manage repositories.
  3. From the Repository Management screen, press ur:

    Select the repositories to upload the package into:
      -    1: test
  4. Enter the value (1-1) to toggle the selection.
  5. Press c to confirm your selection:

    ### WARNING ### WARNING ### WARNING ### WARNING ### WARNING ### WARNING ###
    #                                                                         #
    #   Content retrieved from non-Red Hat arbitrary places can contain       #
    #   unsupported or malicious software.  Proceed at your own risk.         #
    #                                                                         #
    ###########################################################################
  6. Enter the remote URL of the packages to upload. If the location is an RPM, the file will be uploaded. If the location is a web page, all RPMs linked off that page will be uploaded:

    https://www.google.com/url?q=https://repos.fedorapeople.org/pulp/pulp/demo_repos/zoo/bear-4.1-
    1.noarch.rpm&sa=D&source=docs&ust=1637381734614000&usg=AOvVaw2LGPli3y-CXIVAQJtbtKRw
    Retrieving https://www.google.com/url?q=https://repos.fedorapeople.org/pulp/pulp/demo_repos/zoo/bear-4.1-1.noarch.rpm&sa=D&source=docs&ust=1637381734614000&usg=AOvVaw2LGPli3y-
    CXIVAQJtbtKRw
    Found 1 RPMs to download
    Retrieving https://repos.fedorapeople.org/pulp/pulp/demo_repos/zoo/bear-4.1-1.noarch.rpm
    
    The following RPMs will be uploaded:
      bear-4.1-1.noarch.rpm
  7. Press y to proceed or n to cancel:

    Uploaded /tmp/rhui.318mfp81.tmp/bear-4.1-1.noarch.rpm

Verification

  1. A similar message displays if the content uploaded successfully:

    Uploaded /tmp/rhui.318mfp81.tmp/bear-4.1-1.noarch.rpm
    Total of 1 packages uploaded.
    1 RPM(s) associated to repo test.

2.11. Importing package group metadata to a custom repository

To allow RHUI users to view and install package groups or language packs, you can import a comps.xml or a comps.xml.gz file to a custom repository.

This functionality is only available in the command-line interface.

Prerequisites

  • Ensure that you have a valid comps.xml or comps.xml.gz file.
  • Ensure you have root access to the RHUA node.

Procedure

  • On the RHUA node, import data from a comps file to your custom repository using the rhui-manager utility:

    # rhui-manager repo add_comps --repo_id Example_Custom_Repo --comps /home/Example-Comps.xml

Verification

  • On a client system that uses the custom repository:

    1. Refresh the repository data:

      # yum clean metadata
    2. List the repository data and verify that the comps file has been updated:

      # yum grouplist

2.12. Removing content from a custom repository (Custom RPM content only)

You can remove packages from custom repositories using RHUI’s Text User Interface (TUI).

For the command-line interface (CLI) command, see Section 10.2, “Using RHUI 4 CLI options”.

Procedure

  1. Navigate to the Red Hat Update Infrastructure Management Tool home screen:

    [root@rhua ~]# rhui-manager
  2. Enter r to select manage repositories.
  3. On the Repository Management screen, enter r to select packages to remove from a repository (Custom RPM content only):

    -= Repository Management =-
    
       l   list repositories currently managed by the RHUI
       i   display detailed information on a repository
       a   add a new Red Hat content repository
       ac  add a new Red Hat container
       c   create a new custom repository (RPM content only)
       d   delete a repository from the RHUI
       u   upload content to a custom repository (RPM content only)
       ur  upload content from a remote web site (RPM content only)
       p   list packages in a repository (RPM content only)
       r   select packages to remove from a repository (Custom RPM content only)
  4. Enter the value to select the repository:

    Choose a repository to delete packages from:
        1 - Test-RPM-1
        2 - Test-RPM-2
  5. Enter the value to select the packages to delete.

    Select the packages to remove:
      -    1: example-package-1.noarch.rpm
      -    2: example-package-2.noarch.rpm
  6. Enter c to confirm selection.

    The following packages will be removed:
      example-package-1.noarch.rpm
  7. Enter y to proceed or n to cancel:

    Removed example-package-1.noarch.rpm

2.13. Listing the packages in a repository (RPM content only)

When listing repositories within the Red Hat Update Infrastructure Management Tool, only repositories that contain fewer than 100 packages display their contents. Results with more than 100 packages only display a package count.

Procedure

  1. Navigate to the Red Hat Update Infrastructure Management Tool home screen:

    [root@rhua ~]# rhui-manager
  2. Press r to select manage repositories.
  3. From the Repository Management screen, press p.
  4. Select the number of the repository you want to view. The Red Hat Update Infrastructure Management Tool asks if you want to filter the results. Leave the line blank to see the results without a filter.

    Enter value (1-1631) or 'b' to abort: 1
    
    Enter the first few characters (case insensitive) of an RPM to filter the results
    (blank line for no filter):
    
    Only filtered results that contain less than 100 packages will have their
    contents displayed. Results with more than 100 packages will display
    a package count only.
    
    Packages:
      bear-4.1-1.noarch.rpm

Verification

  1. One of three types of messages displays:

    Packages:
      bear-4.1-1.noarch.rpm
    Package Count: 8001
    No packages in the repository.

Chapter 3. Creating an entitlement certificate and a client configuration RPM

RHUI uses entitlement certificates to ensure that the client making requests on the repositories is authorized by the cloud provider to access those repositories. The entitlement certificate must be signed by the cloud provider’s Certificate Authority (CA) Certificate. The CA Certificate is installed on the CDS as part of its configuration.

3.1. Creating a client entitlement certificate with the Red Hat Update Infrastructure Management Tool

When Red Hat issues the original entitlement certificate, it grants access to the repositories you requested. When you create client entitlement certificates, you decide how to subdivide your clients and create a separate certificate for each one. Each certificate can then be used to create individual RPMs.

Prerequisites

  • The entitlement certificate must be signed by the cloud provider’s CA Certificate.

Procedure

  1. Navigate to the Red Hat Update Infrastructure Management Tool home screen:

    [root@rhua ~]# rhui-manager
  2. Press e to select create entitlement certificates and client configuration RPMs.
  3. Press e to select generate an entitlement certificate.
  4. Select which repositories to include in the entitlement certificate by typing the number of the repository at the prompt. Typing the number of a repository places an x next to the name of that repository. Continue until all repositories you want to add have been checked.

    Important

    Include only repositories for a single RHEL version in a single entitlement. Adding repositories for multiple RHEL versions leads to an unusable yum configuration file.

  5. Press c at the prompt to confirm.
  6. Enter a name for the certificate. This name helps identify the certificate within the Red Hat Update Infrastructure Management Tool and generate the name of the certificate and key files.

    Name of the certificate. This will be used as the name of the certificate file
    (name.crt) and its associated private key (name.key). Choose something that will
    help identify the products contained with it.
  7. Enter a path to save the certificate. Leave the field blank to save it to the current working directory.
  8. Enter the number of days the certificate should be valid for. Leave the field blank for 365 days. The details of the repositories to be included in the certificate display.

    Repositories to be included in the entitlement certificate:
    
      Red Hat Repositories
        Red Hat Enterprise Linux 8 for ARM 64 - AppStream (Debug RPMs) from RHUI
        Red Hat Enterprise Linux 8 for ARM 64 - AppStream (RPMs) from RHUI
        Red Hat Enterprise Linux 8 for ARM 64 - AppStream (Source RPMs) from RHUI
    
        Proceed? (y/n)
  9. Press y at the prompt to confirm the information and create the entitlement certificate.

Verification

  1. You will see a similar message if the entitlement certificate was created:

    ..........................+++++
    ....+++++
    Entitlement certificate created at ./rhel8-for-rhui4.crt
    
    ------------------------------------------------------------------------------

3.2. Creating a client entitlement certificate with the CLI

When Red Hat issues the original entitlement certificate, it grants access to the repositories you requested. When you create client entitlement certificates, you decide how to subdivide your clients and create a separate certificate for each one. Each certificate can then be used to create individual RPMs.

Prerequisites

  • The entitlement certificate must be signed by the cloud provider’s CA Certificate.

Procedure

  1. Use the following command to create an entitlement certificate from the RHUI CLI:

    # rhui-manager client cert --repo_label rhel-8-for-x86_64-appstream-eus-rhui-source-rpms --name rhuiclientexample --days 365 --dir /root/clientcert
    .............................................+++++
    ...............................................................................+++++
    Entitlement certificate created at /root/clientcert/rhuiclientexample.crt
    Note

    Use Red Hat repository labels, not IDs. To get a list of all labels, run the rhui-manager client labels command. If you include a protected custom repository in the certificate, use the repository’s ID instead.

Verification

  1. A similar message displays if you successfully created and entitlement certificate:

    Entitlement certificate created at /root/clientcert/rhuiclientexample.crt

3.3. Verifying whether the client entitlement certificate is compliant with the FUTURE cryptographic policy

You can verify which cryptographic policies your instance of RHUI is compliant with by checking the client entitlement certificate:

  • Certificates that are generated by RHUI versions 3.1 to 4.0 are compliant with FIPS and DEFAULT cryptographic policies.
  • Certificates that are generated by RHUI versions 4.1 and later are compliant with FIPS, DEFAULT and FUTURE cryptographic policy.

Prerequisites

  • Ensure that you know the location of the client entitlement certificate.

    The default location is /etc/pki/rhui/product/content.crt.

Procedure

  1. In your client RPM, or on the machine where the RPM is installed, run the following command specifying the path where the client entitlement certificate is stored:

    # openssl x509 -noout -text -in /etc/pki/rhui/product/content.crt | grep bit
  2. Check the RSA key length:

    • If the length is 2048 bits, then the client entitlement certificate is not compliant with the FUTURE policy.
    • If the length is 4096 bits, then the client entitlement certificate is compliant with the FUTURE policy.

3.4. Changing the repository ID prefix in a client configuration RPM using the CLI

When creating RPMs, you can either set a custom repository ID prefix or remove it entirely. By default, the prefix is rhui-.

Procedure

  • On the RHUA node, use the RHUI installer command to set or remove the prefix:

    • Set a custom prefix:

      rhui-installer --rerun --client-repo-prefix CUSTOM_PREFIX
    • Remove the prefix entirely by using two quotation marks instead of the prefix.

      rhui-installer --rerun --client-repo-prefix ""

3.5. Creating a client configuration RPM with the Red Hat Update Infrastructure Management Tool

When Red Hat issues the original entitlement certificate, it grants access to the repositories you requested. When you create client entitlement certificates, you need to decide how to subdivide your clients and create a separate certificate for each one. You can then use each certificate to create individual RPMs for installation on the appropriate guest images.

Use this procedure to create RPMs with the RHUI Management Tool.

Procedure

  1. Navigate to the Red Hat Update Infrastructure Management Tool home screen:

    [root@rhua ~]# rhui-manager
  2. Press e to select create entitlement certificates and client configuration RPMs.
  3. From the Client Entitlement Management screen, press c to select create a client configuration RPM from an entitlement certificate.
  4. Enter the full path of a local directory to save the configuration files to:

    Full path to local directory in which the client configuration files generated by this tool
    should be stored (if this directory does not exist, it will be created):
  5. Enter the name of the RPM.
  6. Enter the version of the configuration RPM. The default version is 2.0.
  7. Enter the release of the configuration RPM. The default version is 1.
  8. Enter the full path to the entitlement certificate authorizing the client to access specific channels.
  9. Enter the full path to the private key for the entitlement certificate.
  10. Select any unprotected custom repositories to be included in the client configuration.
  11. Press c to confirm selections or ? for more commands.

Verification

  1. A similar message displays if the RPM was successfully created:

    Successfully created client configuration RPM.
    Location: /tmp/clientrpmtest-2.0/build/RPMS/noarch/clientrpmtest-2.0-1.noarch.rpm

3.6. Creating a client configuration RPM with the CLI

When Red Hat issues the original entitlement certificate, it grants access to the repositories you requested. When you create client entitlement certificates, you need to decide how to subdivide your clients and create a separate certificate for each one. You can then use each certificate to create individual RPMs for installation on the appropriate guest images.

Use this procedure to create RPMs with the CLI.

Procedure

  1. Use the following command to create an RPM with the RHUI CLI:

    # rhui-manager client rpm --entitlement_cert /root/clientcert/rhuiclientexample.crt --private_key /root/clientcert/rhuiclientexample.key --rpm_name clientrpmtest --dir /tmp --unprotected_repos unprotected_repo1
    Successfully created client configuration RPM.
    Location: /tmp/clientrpmtest-2.0/build/RPMS/noarch/clientrpmtest-2.0-1.noarch.rpm
    Note

    When using the CLI, you can also specify the URL of the proxy server to use with RHUI repositories, or you can use _none_ (including the underscores) to override any global yum settings on a client machine. To specify a proxy, use the --proxy parameter.

Verification

  1. A similar message displays if you successfully created a client configuration RPM:

    Successfully created client configuration RPM.
    Location: /tmp/clientrpmtest-2.0/build/RPMS/noarch/clientrpmtest-2.0-1.noarch.rpm

Chapter 4. Managing Red Hat entitlement certificates

4.1. Red Hat Update Appliance certificates

The RHUA in RHUI uses the following certificates and keys:

  • Content certificate and private key
  • Entitlement certificate and private key
  • SSL certificate and private key
  • Cloud provider’s CA certificate

The RHUA is configured with the content certificate and the entitlement certificate. The RHUA uses the content certificate to connect to the Red Hat CDN. It also uses the Red Hat CA certificate to verify the connection to the Red Hat CDN. As the RHUA is the only component that connects to the Red Hat CDN, it is the only RHUI component that has this certificate deployed. It should be noted that multiple RHUI installations can use the same content certificate. For instance, the Amazon EC2 cloud runs multiple RHUI installations (one per region), but each RHUI installation uses the same content certificate.

Clients use the entitlement certificate to permit access to packages in RHUI. To perform an environment health check, the RHUA attempts a yum request against each CDS. To succeed, the yum request must specify a valid entitlement certificate.

4.2. Content delivery server certificates

Each CDS node in RHUI uses the following certificates and keys:

  • SSL certificate and private key
  • Cloud provider’s CA certificate

The only certificate necessary for the CDS is an SSL certificate, which permits HTTPS communications between the client and the CDS. The SSL certificates are scoped to a specific hostname, so a unique SSL certificate is required for each CDS node. If SSL errors occur when connecting to a CDS, verify that the certificate’s common name is set to the fully qualified domain name (FQDN) of the CDS on which it is installed.

The CA certificate is used to verify that the entitlement certificate sent by the client as part of a yum request was signed by the cloud provider. This prevents a rogue instance from generating its own entitlement certificate for unauthorized use within RHUI.

4.3. Client certificates

Each client in the RHUI uses an entitlement certificate and private key as well as the cloud provider’s CA certificate.

The entitlement certificate and its private key enable information encryption from the CDS back to the client. Each client uses the entitlement certificate when connecting to the CDS to prove it has permission to download its packages. All clients use a single entitlement certificate.

The cloud provider’s CA certificate is used to verify the CDS’s SSL certificate when connecting to it. This ensures that a rogue instance is not impersonating the CDS and introducing potentially malicious packages into the client.

The CA certificate verifies the SSL certificate, not the entitlement certificate. The reverse is true for the CDS node. The SSL certificate and private key are used to encrypt data from the client to the CDS. The CA certificate present on the CDS verifies that the CDS node should trust the entitlement certificate sent by the client.

4.3.1. Listing the entitled products for a certificate

The Entitlements Manager screen is used to list entitled products in the current Red Hat content certificates and to upload new certificates.

Procedure

  1. Navigate to the Red Hat Update Infrastructure Management Tool home screen:

    [root@rhua ~]# rhui-manager
  2. Press n to select manage Red Hat entitlement certificates.
  3. From the Entitlements Manager screen, press l to list data about the current content certificate:

    rhui (entitlements) => l
    
    Red Hat Enterprise Linux 8 for ARM 64 - AppStream (Debug RPMs) from RHUI
       Expiration: 02-27-2022     Certificate: c885597492374720bb5d398c3f65d1ed.pem
    
       Red Hat Enterprise Linux 8 for ARM 64 - AppStream (RPMs) from RHUI
       Expiration: 02-27-2022     Certificate: c885597492374720bb5d398c3f65d1ed.pem
    
       Red Hat Enterprise Linux 8 for ARM 64 - AppStream (Source RPMs) from RHUI
       Expiration: 02-27-2022     Certificate: c885597492374720bb5d398c3f65d1ed.pem
    
       Red Hat Enterprise Linux 8 for ARM 64 - BaseOS (Debug RPMs) from RHUI
       Expiration: 02-27-2022     Certificate: c885597492374720bb5d398c3f65d1ed.pem
    
       Red Hat Enterprise Linux 8 for ARM 64 - BaseOS (RPMs) from RHUI
       Expiration: 02-27-2022     Certificate: c885597492374720bb5d398c3f65d1ed.pem
    
       Red Hat Enterprise Linux 8 for ARM 64 - BaseOS (Source RPMs) from RHUI
       Expiration: 02-27-2022     Certificate: c885597492374720bb5d398c3f65d1ed.pem

Verification

  1. You will see a list of the entitled products in the current Red Hat content certificates.

4.3.2. Listing custom repository entitlements

You can use the Entitlements Manager screen to list custom repository entitlements.

Procedure

  1. Navigate to the Red Hat Update Infrastructure Management Tool home screen:

    [root@rhua ~]# rhui-manager
  2. Press n to select manage Red Hat entitlement certificates.
  3. From the Entitlements Manager screen, press c to list data about the custom repository entitlements:

    rhui (entitlements) => c
    
    Custom Repository Entitlements
    For each entitlement URL listed, the corresponding repositories that are
    configured with that entitlement are listed.
    
    /protected/$basearch/os
    
     Name: Repo 1
    URL: protected/i386/os
    
    Name: Repo 2
    URL: protected/x86_64/os

Chapter 5. Checking synchronization status and scheduling

A repository is a storage location for software packages (RPMs). RHEL uses yum commands to search a repository, download, install, and configure the RPMs. The RPMs contain all the dependencies needed to run an application. RPMs also download updates for software in your repositories.

The length of the initial synchronization of Red Hat content can vary. If you choose to synchronize repositories as soon as possible, you can synchronize all repositories in Red Hat Update Infrastructure 4 by running rhui-manager repo sync_all in the CLI.

5.1. Displaying repository synchronization summary

You can use the Synchronization Status screen to display information about a particular repository.

Procedure

  1. Navigate to the Red Hat Update Infrastructure Management Tool home screen:

    [root@rhua ~]# rhui-manager
  2. Press s to select synchronization status and scheduling.
  3. From the Synchronization Status screen, press dr:

    -= Repository Summary Synchronization Status =-
    
    Last Refreshed: 02:01:22
    (updated every 5 seconds, ctrl+c to exit)
    
    Last Sync                    Last Result
    -------------------------------------------------
    Red Hat Enterprise Linux 8 for ARM 64 - BaseOS (Debug RPMs) from RHUI (8)
      Never                        None
    ....
    ....
    Red Hat Enterprise Linux 8 for x86_64 - AppStream from RHUI (Debug RPMs) (8.2)
      2021-07-29 17:45:41          Running
    Associating Content: 11001 (97%)
    Downloading Artifacts: 7376

5.2. Displaying running synchronizations

You can use the Synchronization Status screen to check the status on running synchronization tasks.

Procedure

  1. Navigate to the Red Hat Update Infrastructure Management Tool home screen:

    [root@rhua ~]# rhui-manager
  2. Press s to select synchronization status and scheduling.
  3. From the Synchronization Status screen, press rr:

    Last Refreshed: 02:06:46
    (updated every 5 seconds, ctrl+c to exit)
    
    Current Sync                 Result
    -------------------------------------------------
    Red Hat Enterprise Linux 8 for x86_64 - AppStream from RHUI (Debug RPMs) (8.2)
      2021-07-29 17:45:41          Running
    Associating Content: 11001 (97%)
    Downloading Artifacts: 7376

5.3. Viewing the details of the last repository synchronization

You can use the Synchronization Status screen to view the details of the last repository synchronization.

Procedure

  1. Navigate to the Red Hat Update Infrastructure Management Tool home screen:

    [root@rhua ~]# rhui-manager
  2. Press s to select synchronization status and scheduling.
  3. From the Synchronization Status screen, press vr.
  4. Enter the number for the repository that you want to see details for:

    Enter value (1-66) or 'b' to abort:

Verification

  1. A similar message displays if the selected repository has not been synchronized:

    Repo: Red Hat Enterprise Linux 8 for x86_64 - AppStream from RHUI (Debug RPMs) (8.2)
    No syncs have been completed for this repository.

5.4. Synchronizing an individual repository immediately

The initial synchronization of content can take a while, typically 10 to 20 minutes. If you choose to synchronize repositories as soon as possible, you can synchronize all repositories in Red Hat Update Infrastructure 4 by running rhui-manager repo sync_all in the CLI.

Procedure

  1. Navigate to the Red Hat Update Infrastructure Management Tool home screen:

    [root@rhua ~]# rhui-manager
  2. Press s to select synchronization status and scheduling.
  3. From the Synchronization Status screen, press sr:

    Select one or more repositories to schedule to be synchronized before its scheduled time.
    The sync will happen as soon as possible depending on other tasks that may be executing
    in the RHUI.  Sync requests for repositories with tasks in running
    or pending state will be ignored.
    
             Last Result  Next Sync              Repository
             -------------------------------------------------
  4. Select the repository by entering the value beside the repository name. Enter one repository selection at a time before confirming your product selection:

    x  714: Error        2021-11-17 20:30:00    Red Hat Enterprise Linux 8 for ARM 64 - AppStream (RPMs) from RHUI (8.4)
  5. Press c to confirm:

    The following repositories will be scheduled for synchronization:
      Red Hat Enterprise Linux 8 for ARM 64 - AppStream (RPMs) from RHUI (8.4)
    Proceed? (y/n) y
  6. Press y to proceed:

    Scheduling sync for Red Hat Enterprise Linux 8 for ARM 64 - AppStream (RPMs) from RHUI (8.4)...
    ... successfully scheduled for the next available timeslot.
    Note

    This message displays if a task for the selected repository is running. Ignoring sync request for Red Hat Enterprise Linux 8 for x86_64 - AppStream from RHUI (Debug RPMs) (8.2) as the repo is currently reserved by a running task.

5.5. Canceling active synchronization tasks

Most environments synchronize repositories on a scheduled basis. You may encounter a situation where you need to cancel active synchronization tasks.

Prerequisites

  • There are existing repositories.
  • There are active synchronization tasks.

Procedure

  1. Navigate to the Red Hat Update Infrastructure Management Tool home screen:

    [root@rhua ~]# rhui-manager
  2. Press s to select synchronization status and scheduling.
  3. From the Synchronization Status screen, press ca to select cancel active sync tasks.
  4. Enter the value for the task or tasks that you want to cancel:

    Select one or more repositories for which you want to cancel their active tasks.
      -    1: Red Hat Enterprise Linux 8 for x86_64 - AppStream from RHUI (Debug RPMs) (8.2)
    Enter value (1-1) to toggle selection, 'c' to confirm selections, or '?' for more commands:
  5. Press c to confirm your selection.
  6. Press y to cancel the synchronization task or tasks:

    The active tasks will be canceled for the following repositories:
      Red Hat Enterprise Linux 8 for x86_64 - AppStream from RHUI (Debug RPMs) (8.2)
    Proceed? (y/n)

Verification

  1. A similar message displays if you cancel an active synchronization task:

    Canceling active task for repo Red Hat Enterprise Linux 8 for x86_64 - AppStream from RHUI (Debug RPMs) (8.2) ...
    ... done

5.6. Canceling waiting synchronization tasks

Most environments synchronize repositories on a scheduled basis. You may encounter a situation where you need to cancel pending synchronization tasks.

Prerequisites

  • There are existing repositories.
  • There are scheduled synchronization tasks.

Procedure

  1. Navigate to the Red Hat Update Infrastructure Management Tool home screen:

    [root@rhua ~]# rhui-manager
  2. Press s to select synchronization status and scheduling.
  3. From the Synchronization Status screen, press cw to select cancel waiting sync tasks.
  4. Enter the value for the task or tasks that you want to cancel:

    Select one or more repositories for which you want to cancel their pending tasks.
      -    1: Single Sign-On 7.4 for RHEL 8 x86_64 (Source RPMs) from RHUI
    Enter value (1-1) to toggle selection, 'c' to confirm selections, or '?' for more commands: 1
  5. Press c to confirm your selection:

    Select one or more repositories for which you want to cancel their pending tasks.
      x    1: Single Sign-On 7.4 for RHEL 8 x86_64 (Source RPMs) from RHUI
    Enter value (1-1) to toggle selection, 'c' to confirm selections, or '?' for more commands: c
  6. Press y to proceed:

    The pending tasks will be canceled for the following repositories:
      Single Sign-On 7.4 for RHEL 8 x86_64 (Source RPMs) from RHUI
    Proceed? (y/n) y

Verification

  1. A similar message displays if the cancellation is successful:

    Canceling pending task for repo Single Sign-On 7.4 for RHEL 8 x86_64 (Source RPMs) from RHUI ...
    ... done
  2. The following message displays if there are no pending synchronization tasks:

    There are no repositories with pending sync related tasks.

5.7. Viewing and changing a repository auto-publish status

You can use the Synchronization Status screen to look at and modify a repository’s auto-publish status.

Procedure

  1. Navigate to the Red Hat Update Infrastructure Management Tool home screen:

    [root@rhua ~]# rhui-manager
  2. Press s to select synchronization status and scheduling.
  3. From the Synchronization Status screen, press ap:

    rhui (sync) => ap
    
    Select one or more repositories to toggle the auto-publish status.
    The operation will be executed as soon as possible depending on other tasks
    that may be executing in the RHUI.
    
                    Status | Repository
               --------------------------------------------------------------------------
    Select one or more repositories:
    
      Custom Repositories
    
      Red Hat Repositories: yum
    
         -  713:       AUTO Red Hat Enterprise Linux 8 for ARM 64 - AppStream (RPMs) from RHUI (8.3)
         -  714:       AUTO Red Hat Enterprise Linux 8 for ARM 64 - AppStream (RPMs) from RHUI (8.4)
         -  719:       AUTO Red Hat Enterprise Linux 8 for ARM 64 - AppStream (Source RPMs) from RHUI (8.3)
         -  720:       AUTO Red Hat Enterprise Linux 8 for ARM 64 - AppStream (Source RPMs) from RHUI (8.4)
  4. Enter a value (1-1631) to toggle the selection, c to confirm selections, or ? for more commands:

    The following repositories will have their auto-publish status changed:
      Red Hat Repositories
        yum
           Red Hat Enterprise Linux 8 for ARM 64 - AppStream (RPMs) from RHUI (8)
  5. Press c to confirm your selection.
  6. Press y to proceed.

Verification

  1. A similar message displays when you make and confirm a selection:

    Scheduling a task to turn off auto-publish status of repository Red Hat Enterprise Linux 8 for ARM 64 - AppStream (RPMs) from RHUI (8)

5.8. Viewing and advancing repository workflow

You can use the Synchronization Status screen to look at and change a repository’s workflow.

Procedure

  1. Navigate to the Red Hat Update Infrastructure Management Tool home screen:

    [root@rhua ~]# rhui-manager
  2. Press s to select synchronization status and scheduling.
  3. From the Synchronization Status screen, press wf.
  4. Enter a value (1-1631) to toggle the selection, c to confirm selections, or ? for more commands:

    The following repositories will be scheduled for workflow push:
      Red Hat Repositories
        yum
           Red Hat Enterprise Linux 8 for ARM 64 - AppStream (RPMs) from RHUI (8.4)
  5. Press y to proceed:

Verification

  1. A similar message displays if the scheduling was successful:

    Scheduling a task for generating metadata version 0 for repo Red Hat Enterprise Linux 8 for ARM 64 - AppStream (RPMs) from RHUI (8.4) ...
      ... task scheduled.

5.9. Exporting a repository to the file system

You can use the Synchronization Status screen to export a repository to a file system.

Procedure

  1. Navigate to the Red Hat Update Infrastructure Management Tool home screen:

    [root@rhua ~]# rhui-manager
  2. Press s to select synchronization status and scheduling.
  3. From the Synchronization Status screen, press ex.
  4. Enter a value to toggle the selection.
  5. Press c to confirm the selection:

    The following repositories will be exported:
      Red Hat Repositories
        yum
           Red Hat Enterprise Linux 8 for ARM 64 - AppStream (Source RPMs) from RHUI (8)
  6. Press y to proceed.

Verification

  1. A similar message displays if the repository is exported to a file system:

    [1/1] Exporting version 1 of the repo Red Hat Enterprise Linux 8 for ARM 64 - AppStream (Source RPMs) from RHUI (8).

Chapter 6. Managing content delivery servers

CDS nodes are the main component of a content delivery network (CDN), offering high availability to the client. Running servers in a geographically dispersed manner can also improve response time.

You can use the Content Delivery Server (CDS) Management screen to list, add, delete, and reinstall CDS nodes.

It is up to the cloud provider to determine the best course of action when allocating the necessary devices. The Red Hat Update Infrastructure Management Tool configuration RPM links the package directory with the NGINX configuration to serve it.

Important

The NGINX configuration is handled through the /etc/nginx/conf.d/ssl.conf file during the CDS installation.

If multiple clients experience problems updating against a repository, this might indicate a problem with the RHUI.

6.1. Listing all known CDS instances managed by RHUI 4

You can use the Content Delivery Server (CDS) Management screen to list all CDS nodes managed by Red Hat Update Infrastructure 4.

Procedure

  1. Navigate to the Red Hat Update Infrastructure Management Tool home screen:

    [root@rhua ~]# rhui-manager
  2. Press c to select manage content delivery servers (CDS):
  3. From the Content Delivery Server (CDS) Management screen, press l to list all known CDS nodes that Red Hat Update Infrastructure 4 manages:

    Hostname:             <cds1.example.com>
    SSH Username:     <cloud-user>
    SSH Private Key:     /<cloud-user>/.ssh/id_rsa_rhua

6.2. Registering a new CDS

The Red Hat Update Infrastructure Management Tool provides several options for configuring a CDS within the RHUI.

Prerequisites

  • Make sure sshd is running on the CDS node and that port 443 is open.

Procedure

  1. Navigate to the Red Hat Update Infrastructure Management Tool home screen:

    [root@rhua ~]# rhui-manager
  2. Press c to select manage content delivery servers (CDS).
  3. From the Content Delivery Server (CDS) Management screen, press a to add a new CDS instance.
  4. Enter the hostname of the CDS to add:

    Hostname of the CDS instance to register:
    cds1.example.com
  5. Enter the user name that will have SSH access to the CDS and have sudo privileges.

    Username with SSH access to <cds1.example.com> and sudo privileges:
    <cloud-user>
  6. Enter the absolute path to the SSH private key for logging in to the CDS and press Enter.

    Absolute path to an SSH private key to log into <cds1.example.com> as <cloud-user>:
    /home/<cloud-user>/.ssh/id_rsa_rhua
  7. Optional: If you wish to use custom SSL certificates, enter the absolute path to the custom SSL certificate, SSL Key, and SSL crt files.

    Note

    If you do not provide an SSL certificate, it will be automatically generated.

    Optional absolute path to user supplied SSL key file:
    /home/<cloud-user>/custom_ssl.key
    
    Optional absolute path to user supplied SSL crt file:
    /home/<cloud-user>/custom_ssl.crt
    
    .........................................................................
    The following CDS has been successfully added:
    
      Hostname:             <cds1.example.com>
      SSH Username:         <cloud-user>
      SSH Private Key:      /home/<cloud-user>/.ssh/id_rsa_rhua
    
    The CDS will now be configured:
    ....................................................................
    The CDS was successfully configured.
  8. If adding the content delivery server fails, check that the firewall rules permit access between the RHUA and the CDS.
  9. Run the mount command to see if shared storage is mounted as read-write.

    [root@rhua ~]# mount | grep rhui
    
    nfs.example.com:/export on /var/lib/rhui/remote_share type nfs4 (rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.8.41.163,local_lock=none,addr=10.8.41.163)
  10. After successful configuration, repeat these steps for all remaining CDS nodes.

6.3. Reinstalling and reapplying configuration to a CDS

You may encounter a situation where you need to reinstall and reapply the configuration for a CDS. The Red Hat Update Infrastructure Management Tool provides an easy way to accomplish this task.

Prerequisites

  • At least one installed CDS

Procedure

  1. Navigate to the Red Hat Update Infrastructure Management Tool home screen:

    [root@rhua ~]# rhui-manager
  2. Press c to select manage content delivery servers (CDS).
  3. From the Content Delivery Server (CDS) Management screen, press r to select reinstall and reapply configuration to an existing CDS instance. The Red Hat Update Infrastructure Management Tool automatically performs all reinstallation and reconfiguration tasks.
  4. Select the CDS to reinstall:

        1 -
        Hostname:             <cds1.example.com>
        SSH Username:     <cloud-user>
        SSH Private Key:     /<cloud-user>/.ssh/id_rsa_rhua
  5. Enter a value or b to abort: 1:

    Checking that the RHUA services are reachable from the instance...
    Done.
    
    
    Installing and configuring the CDS...
    
    PLAY [Registering a CDS instance] **********************************************
    
    
    
    PLAY RECAP *********************************************************************
    cloud-user@cds1.example.com : ok=24   changed=10   unreachable=0    failed=0    skipped=2    rescued=0    ignored=0
    
    Done.

Verification

  1. Check that you successfully reinstalled and reconfigured the CDS by viewing the code output:

    Ensuring that instance ports are reachable ...
    Done.

6.4. Configuring a CDS to accept legacy CAs

By default, a content delivery server (CDS) node only accepts entitlement certificates signed by the Certificate Authority (CA) that is currently configured on your RHUI system. However, you might want to accept previously created CAs so that clients can continue to work in case you change your main CA or when the CA certificate expires.

This procedure provides instructions to support legacy CAs on RHUI by installing CA certificates on your CDS nodes.

Prerequisites

  • Ensure you are running the latest version of RHUI.

    Note

    If you have installed an older version of RHUI, you must reinstall your CDS nodes in rhui-manager.

Procedure

  1. On the CDS node, create the /etc/pki/rhui/legacy directory if it does not already exist:

    # mkdir /etc/pki/rhui/legacy
  2. Save the legacy CA certificate in the directory.

Verification

  • The CDS node starts accepting legacy CAs as soon as you store the CA certificate in the directory.

6.5. Configuring a CDS to stop accepting legacy CAs

To limit your content delivery servers (CDS) nodes from accepting legacy certificate authorities (CAs), remove the respective CA certificates.

Prerequisites

  • Clients are no longer using the CA.

Procedure

  1. On the CDS node, navigate to the /etc/pki/rhui/legacy/ directory:

    # cd /etc/pki/rhui/legacy/
  2. Optional: Back up the existing CA certificates:
  3. Delete the CA certificate that corresponds to the CA you want to limit:

    # rm example-legacy.crt

Verification

  • The CDS node stops accepting legacy CAs as soon as you delete the CA certificate.

6.6. Unregistering a CDS

You can unregister (delete) a CDS instance that you are not going to use.

Procedure

  1. Navigate to the Red Hat Update Infrastructure Management Tool home screen:

    [root@rhua ~]# rhui-manager
  2. Press c to select manage content delivery servers (CDS).
  3. From the Content Delivery Server (CDS) Management screen, press d to delete a CDS instance.
  4. Enter the hostname of the CDS to delete:

    Hostname of the CDS instance to unregister:
    cds1.example.com

Chapter 7. Managing an HAProxy load-balancer instance

⁠If more than one CDS is used, a load-balancing solution must be in place to spread client HTTPS requests across all servers. Red Hat Update Infrastructure 4 ships with HAProxy, but it is up to you to choose what load-balancing solution (for example, the one from the cloud provider) to use during the installation. If HAProxy is used, you must also decide how many nodes to bring in.

7.1. Listing all known HAProxy load-balancer instances managed by RHUI 4

You can use Load-balancer (HAProxy) Management screen to show all known HAProxy load-balancer instances that RHUI 4 is managing.

Procedure

  1. Navigate to the Red Hat Update Infrastructure Management Tool home screen:

    [root@rhua ~]# rhui-manager
  2. Press l to select manage HAProxy load-balancer instances.
  3. From the Load-balancer (HAProxy) Management screen, press l to list the load-balancer instances that RHUI manages:

    Hostname:             <haproxy1.example.com>
    SSH Username:     <cloud-user>
    SSH Private Key:     /<cloud-user>/.ssh/id_rsa_rhua

7.2. Registering a new HAProxy load-balancer

Red Hat Update Infrastructure 4 uses DNS to reach the CDN. In most cases, your instance should be preconfigured to talk to the proper DNS servers hosted as part of the cloud’s infrastructure. If you run your own DNS servers or update your client DNS configuration, there is a chance you will see errors similar to yum Could not contact any CDS load balancers. In these cases, check that your DNS server is forwarding to the cloud’s DNS servers for the request or that your DNS client is configured to fall back to the cloud’s DNS server for name resolution.

Using more than one HAProxy node requires a round-robin DNS entry for the hostname used as the value of the --cds-lb-hostname parameter when rhui-installer is run (cds.example.com in this guide) that resolves to the IP addresses of all HAProxy nodes. How to Configure DNS Round Robin presents one way to configure a round-robin DNS. In the context of Red Hat Update Infrastructure 4, these will be the IP addresses of the HAProxy nodes, and they are to be mapped to the hostname specified as --cds-lb-hostname while calling rhui-installer.

Prerequisites

  1. Make sure sshd is running on the HAProxy load-balancer node and that port 443 is open.

Procedure

  1. Navigate to the Red Hat Update Infrastructure Management Tool home screen:

    [root@rhua ~]# rhui-manager
  2. Press l to select manage HAProxy load-balancer instances.
  3. From the Load-balancer (HAProxy) Management screen, press a to add a new load-balancer instance.
  4. Enter the hostname of the new load-balancer:

    Hostname of the HAProxy Load-balancer instance to register:
    <haproxy1.example.com>
  5. Enter the username that will have SSH access to the load-balancer and have sudo privileges:

    Username with SSH access to cds.example.com and sudo privileges:
    <cloud-user>
  6. Enter the absolute path to the SSH private key for logging in to the load-balancer instance and press Enter:

    Absolute path to an SSH private key to log into cds.example.com as <cloud-user>:
    /<cloud-user>/.ssh/id_rsa_rhua
  7. Optional: Enter an optional absolute path to a user supplied HAProxy configuration file and press Enter.

    If you do not specify the path to a custom configuration file, the default file, /usr/share/rhui-tools/templates/haproxy.cfg, is used instead.

    Optional absolute path to user supplied HAProxy config file:
    
    .........................................................................
    The following load-balancer has been successfully added:
    
    Hostname:         <haproxy1.example.com>
    SSH Username:     <cloud-user>
    SSH Private Key:  /<cloud-user>/.ssh/id_rsa_rhua
    
    The load-balancer will now be configured:
  8. If the load-balancer fails to add, check that the firewall rules permit access between the RHUA and the load-balancer.
  9. After successful configuration, repeat these steps for any remaining load-balancer instances.

Verification

  • The following message displays:

    The HAProxy Load-balancer was successfully configured.

Additional resources

7.3. Reinstalling and reapplying the configuration to an HAProxy load-balancer

You may encounter a situation where you need to reinstall and reapply the configuration for an HAProxy load-balancer. The Red Hat Update Infrastructure Management Tool provides an easy way to accomplish this task.

Prerequisites

  • Make sure sshd is running on the HAProxy load-balancer node and that port 443 is open.

Procedure

  1. Navigate to the Red Hat Update Infrastructure Management Tool home screen:

    [root@rhua ~]# rhui-manager
  2. Press l to select manage HAProxy load-balancer instances.
  3. From the Load-balancer (HAProxy) Management screen, press r to reinstall and reapply the configuration to a load-balancer instance.

    Important

    It is crucial that the files included in the restore retain their current attributes.

The Red Hat Update Infrastructure Management Tool automatically performs all reinstallation and reconfiguration tasks.

  1. Select the load-balancer to reinstall:

        1 -
        Hostname:             <haproxy1.example.com>
        SSH Username:     <cloud-user>
        SSH Private Key:     /<cloud-user>/.ssh/id_rsa_rhua
  2. Enter a value or b to abort: 1:

    Installing and configuring the HAProxy Load-balancer...
    
    PLAY [Registering a load balancer instance] ************************************
    
    
    PLAY RECAP *********************************************************************
    cloud-user@haproxy1.example.com : ok=8    changed=3    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0
    
    Done.

Verification

  1. Check that you successfully reinstalled and reconfigured the load-balancer by viewing the code output:

    Ensuring that HAProxy is available...
    Done.

7.4. Unregistering an HAProxy load-balancer

You can unregister (delete) an HAProxy load-balancer instance that you are not going to use.

Prerequisites

  • Make sure sshd is running on the HAProxy load-balancer node and that port 443 is open.

Procedure

  1. Navigate to the Red Hat Update Infrastructure Management Tool home screen:

    [root@rhua ~]# rhui-manager
  2. Press l to select manage HAProxy load-balancer instances.
  3. From the Load-balancer (HAProxy) Management screen, press d to delete a load-balancer instance.
  4. Enter the hostname of the load-balancer to delete:

    Hostname of the load-balancer instance to unregister:
    <haproxy1.example.com>

Chapter 8. Managing Containers

You can automate the deployment of applications inside Linux containers using RHUI. Using containers offers the following advantages:

  • Requires less storage and in-memory space than VMs: Because the containers hold only what is needed to run an application, saving and sharing is more efficient with containers than it is with VMs that include entire operating systems.
  • Improved performance: Because you are not running an entirely separate operating system, a container typically runs faster than an application that carries the overhead of a new VM.
  • Secure: Because a container typically has its own network interfaces, file system, and memory, the application running in that container can be isolated and secured from other activities on a host computer.
  • Flexible: With an application’s runtime requirements included with the application in the container, a container can run in multiple environments.
Note

Support for containers is not enabled by default. You must manually enable support by setting the --container-support-enabled flag.

8.1. Understanding containers in Red Hat Update Infrastructure

A container is an application sandbox. Each container is based on an image that holds necessary configuration data. When you launch a container from an image, a writable layer is added on top of this image. Every time you commit a container, a new image layer is added to store your changes.

An image is a read-only layer that is never modified. All changes are made in the top-most writable layer, and the changes can be saved only by creating a new image. Each image depends on one or more parent images.

A platform image is an image that has no parent. Platform images define the runtime environment, packages, and utilities necessary for a containerized application to run. The platform image is read-only, so any changes are reflected in the copied images stacked on top of it.

8.2. Adding a container to Red Hat Update Infrastructure

You can use the rhui-manager tool to add containers using the Repository Management section.

Procedure

  1. On the RHUA node, enable support for containers and apply it on all CDS nodes:

    # rhui-installer --rerun --container-support-enabled True
    # rhui-manager --noninteractive cds reinstall --all
  2. Optional: Edit the /etc/rhui/rhui-tools.conf file and set the container registry credentials in the RHUI configuration by removing the following lines in the [container] section.

    If you have a clean installation of RHUI 4.1.1 or newer, the last several lines contain a [container] section with podman-specific options and handy comments. If you have updated from an earlier version of RHUI, the section is available at the end of the etc/rhui/rhui-tools.conf.rpmnew file, and you can copy it to the rhui-tools.conf file.

    [container]
    
    registry_username: your_RH_login
    registry_password: your_RH_password
    Note

    If you normally synchronize from a registry different from registry.redhat.io, also change the values of the registry_url and registry_auth options accordingly.

  3. On the RHUA node, run rhui-manager:

    # rhui-manager
  4. Press r to access the Repository Management screen.

    -= Red Hat Update Infrastructure Management Tool =-
    
    
    -= Repository Management =-
    
      l list repositories currently managed by the RHUI
      i display detailed information on a repository
      a add a new Red Hat content repository
      ac add a new Red Hat container
      c create a new custom repository (RPM content only)
      d delete a repository from the RHUI
      u upload content to a custom repository (RPM content only)
      ur upload content from a remote web site (RPM content only)
      p list packages in a repository (RPM content only)
    
    Connected: rhua.example.com
  5. Press ac to add a new Red Hat container.

    rhui (repo) => ac Specify URL of registry [https://registry.redhat.io]:
  6. If the container you want to add exists in a non-default registry, enter the registry URL. Press Enter without entering anything to use the default registry.
  7. Enter the name of the container in the registry:

    jboss-eap-6/eap64-openshift
  8. Enter a unique ID for the container.

    rhui-manager converts the name of the container from the registry to the format that is usable in Pulp by replacing slashes and dots with underscores. You can use such a converted name by pressing Enter or by entering a name of your choice.

  9. Enter a display name for the container.

    jboss-eap-6_eap64-openshift
  10. Optional: Set your login and password in the RHUI configuration if prompted.
  11. Verify the displayed summary.

    The following container will be added:
      Registry URL: http://registry.redhat.io
      Container Id: jboss-eap-6_eap64-openshift
      Display Name: jboss-eap-6_eap64-openshift
      Upstream Container Name: jboss-eap-6/eap64-openshift
    Proceed? (y/n)
  12. Press y to proceed and add the container.

    y
    Successfully added container jboss-eap-6_eap64-openshift

8.3. Synchronizing container repositories

After you add your container to Red Hat Update Infrastructure, you can use the rhui-manager tool to synchronize the container.

Procedure

  1. On the RHUA node, run rhui-manager:

    # rhui-manager
  2. Press s to access the synchronization status and scheduling screen.
  3. Press sr to synchronize an individual repository immediately.
  4. Enter the number of the repository that you wish to synchronize.
  5. Press c to confirm the selection.
  6. Verify the repository and press y to synchronize or n to cancel.

    The following repositories will be scheduled for synchronization: jboss-eap-6_eap64-openshift
    Proceed? (y/n) y
    Scheduling sync for jboss-eap-6_eap64-openshift...
    ... successfully scheduled for the next available timeslot.

8.4. Generating container client configurations

RHUI clients can pull containers from RHUI using client configuration. The RPM contains the load balancer’s certificate and you can use it to add the load balancer to the container registry and to modify container configuration.

Procedure

  1. On the RHUA node, run rhui-manager:

    # rhui-manager
  2. Press e to access the entitlement certificates and client configuration RPMs screen.
  3. Press d to create a container client configuration RPM.
  4. Enter the full path of a local directory where you want to save the configuration files.

    /root/
  5. Enter the name of the RPM.

    containertest
  6. Enter the version number of the configuration RPM. The default is 2.0.
  7. Enter the release number of the configuration RPM. The default is 1.
  8. Enter the number of days the certificate should be valid. The default is 365.

    Successfully created client configuration RPM.
    Location: /root/containertest-2.0/build/RPMS/noarch/containertest-2.0-1.noarch.rpm

8.5. Installing a container configuration RPM on the client

After generating the container configuration RPM, you can install it on a client by importing it to your local machine.

Procedure

  1. Retrieve the RPM from the RHUA node to your local machine:

    # root@rhua.example.com:/root/containertest-2.0/build/RPMS/noarch/containertest-2.0-1.noarch.rpm .
  2. Transfer the RPM from the local machine to the client.

    # scp containertest-2.0-1.noarch.rpm root@cli01.example.com:.
  3. Switch to the client and install the RPM:

    [root@cli01 ~]# yum install containertest-2.0-1.noarch.rpm

8.6. Testing the podman pull command on the client

You can use the podman pull command to verify the content on the container.

Procedure

  1. Run the podman pull command.

    [root@cli01 ~]# podman pull jboss-eap-6_eap64-openshift
    
    Resolving "jboss-eap-6_eap64-openshift" using unqualified-search registries (/etc/containers/registries.conf)
    Trying to pull cds.example.com/jboss-eap-6_eap64-openshift:latest...
    Getting image source signatures
    Copying blob b0e0b761a531 done
    Copying blob aa23ac04e287 done
    Copying blob 0d30ea1353f9 done
    Copying config 3d0728c907 done
    Writing manifest to image destination
    Storing signatures
    3d0728c907d55d9faedc4d19de003f21e2a1ebdf3533b3d670a4e2f77c6b35d2
  2. If the podman pull command fails, check the rhui-manager status. The synchronization probably has not been performed yet and you have to wait until it synchronizes.

    Resolving "jboss-eap-6_eap64-openshift" using unqualified-search registries (/etc/containers/registries.conf)
    Trying to pull cds.example.com/jboss-eap-6_eap64-openshift:latest...
    Error: initializing source docker://cds.example.com/jboss-eap-6_eap64-openshift:latest: reading manifest latest in cds.example.com/jboss-eap-6_eap64-openshift: manifest unknown: Manifest not found.

Chapter 9. Configuration files, exit codes, and log files

The following configuration files, RHUI manager exit codes, and log files are used in Red Hat Update Infrastructure 4.

Configuration Files

Table 9.1. Configuration Files

ComponentFile or DirectoryUsage

Red Hat Update Appliance

/etc/pulp/*

Pulp config files

 

/etc/rhui/rhui-tools.conf

rhui-manager config files

 

/etc/pki/rhui/*

Certificates for Red Hat Update Infrastructure

 

/root/.rhui/answers.yaml

Used to set up the RHUA

 

/etc/rhui/rhui-subscription-sync.conf

Configuration for the subscription synchronization script

Content Delivery Server

/etc/pki/rhui/certs/

Certificates for CDS

HAProxy

/etc/haproxy/haproxy.cfg

HAProxy configuration file

RHUI Manager Exit Codes

RHUI Manager uses the following codes to indicate the result of running the rhui-manager status command and running the rhui-manager CLI commands.

Table 9.2. RHUI Manager Exit Codes

Status CodeDescription

0

Success

1

General error or a repository synchronization error

2

SSL certificate error on a CDS

32

Entitlement CA or SSL certificate expiration warning

64

Entitlement CA or SSL certificate expiration error

128

One or more RHUI services is not running on the RHUA, CDS, or HAProxy nodes

239

A repository could not be deleted because it does not exist.

240

There was an issue with a required resource. For example, it was impossible to build a client configuration RPM because no valid repository was found.

241

A synchronization task could not be scheduled because an unknown repository was specified.

To troubleshoot

* Check the spelling * Add the repository first * Check logs for Pulp issues

242

A custom repository could not be created due to a Pulp issue. Check the message and logs for details.

243

Red Hat repositories could not be added because some of them already exist in RHUI and some of them were not available in the entitlement.

244

A custom repository could not be created because it already exists in RHUI.

245

A Red Hat repository could not be added because it already exists in RHUI.

246

A Red Hat repository could not be added because it is not available in the entitlement. Check the spelling or remove the repository mapping cache using the command rm -f /var/cache/rhui/*, and try again.

247

A Red Hat repository could not be added due to a Pulp issue. Check the message and logs for details.

248

Migration from RHUI 3 to RHUI 4 was stopped because one or more Red Hat repositories are already present in RHUI 4. You must remove the repositories or use the --force flag.

249

The RHUI configuration, /etc/rhui/rhui-tools.conf, is invalid. Check the message for details.

250

The entitlement certificate is not writable.

251

The entitlement certificate has expired.

252

The entitlement certificate is invalid because it does not contain RHUI repositories.

253

The entitlement certificate file is not a valid certificate.

254

Command-line Error: The RHUI CLI could not run due to a network issue.

255

Argument Error: A required argument was not supplied.

Log Files

Table 9.3. Log Files

ComponentFile or DirectoryUsage

Red Hat Update Appliance

/root/.rhui/rhui.log*, assuming rhui-manager is run as root

Red Hat Update Infrastructure Management Tool logs

 

/var/log/messages

The most recent four versions are kept in addition to the currently written file.

 

/var/log/nginx/*

NGINX logs

 

/var/log/messages

Qpid logs

 

/var/log/rhui-subscription-sync.log

Subscription synchronization log

Content Delivery Server

/var/log/nginx/*

NGINX logs

 

/nginx/ssl-access.log

Sample Logging – Successful yum repolist: the CDS nodes log this client activity

Client

/var/log/yum.log for RHEL 7 and earlier versions

yum command logs

Client

/var/log/dnf.log for RHEL 8 and later versions

dnf command logs

 

/var/log/messages

Client syslog

 

Console output from yum/dnf commands

 

Chapter 10. Working with RHUI 4 commands

The screens within the Red Hat Update Infrastructure Management Tool, accessed from the RHUpdate, provide menu options that allow you to configure and update the various Red Hat Update Infrastructure 4 components.

10.1. Using RHUI 4 menu options

The Red Hat Update Infrastructure Management Tool provides interactive commands for configuring and managing RHUI 4.

Table 10.1. Red Hat Update Infrastructure Management Tool menus and commands

ScreenScreen CommandMenu OptionMenu Option Command

manage repositories

r

  

Repository Management

 

list repositories currently managed by the RHUI

l

  

display detailed information on a repository

i

  

add a new Red Hat content repository

a

  

create a new custom repository (RPM content only)

c

  

delete a repository from the RHUI

d

  

upload content to a custom repository (RPM content only)

u

  

upload content from a remote web site (RPM content only)

ur

  

list packages in a repository (RPM content only)

p

manage content delivery servers (CDS)

c

  

Content Delivery Server (CDS) Management

 

list all known CDS instances managed by the RHUI

l

  

register (add) a new CDS instance

a

  

reinstall and reapply configuration to an existing CDS instance

r

  

unregister (delete) a CDS instance from the RHUI

d

manage HAProxy load-balancer instances

l

  

Load-balancer (HAProxy) Management

 

list all known HAProxy Load-balancer instances managed by the RHUI

l

  

register (add) a new HAProxy Load-balancer instance

a

  

reinstall and reapply configuration to an existing HAProxy Load-balancer instance

r

  

unregister (delete) a HAProxy Load-balancer instance from the RHUI

d

synchronization status and scheduling

s

  

Synchronization Status

 

display repo sync summary

dr

  

display running syncs

rr

  

view the details of the last repository sync

vr

  

sync an individual repository immediately

sr

  

cancel active sync tasks

ca

  

cancel waiting sync tasks

cw

  

view/change repository auto-publish status

ap

  

view/advance repository workflow

wf

  

export repo to filesystem

ex

create entitlement certificates and client configuration RPMs

e

  

Client Entitlement Management

 

generate an entitlement certificate

e

  

create a client configuration RPM from an entitlement certificate

c

manage Red Hat entitlement certificates

n

  

Entitlements Manager

 

list Red Hat content certificate entitlements

l

  

list custom repository entitlements

c

  

upload a new or updated Red Hat content certificate

u

manage RHUI users

u

  

User Manager

 

change admin’s password (followed by logout)

p

10.2. Using RHUI 4 CLI options

The majority of administrative tasks for Red Hat Update Infrastructure 4 are in its installation. After installation, it runs on its own, periodically getting updated packages from the Red Hat CDN and automatically making those packages available to clients.

A command line interface called Red Hat Update Infrastructure Management Tool (run with rhui-manager) facilitates the installation. This tool provides interactive prompts for the necessary configuration elements for each RHUI component: RHUA, CDS, and load-balancer. This tool also provides a means for taking the content certificate provided by Red Hat for use when connecting to the Red Hat CDN and generating internal, cloud-specific certificates that clients use to connect to RHUI. The Red Hat Update Infrastructure Management Tool allows the cloud provider to generate a client configuration bundle to install on client RHEL instances. This bundle allows the clients to get updates from the RHUI installation.

Red Hat Update Infrastructure Management Tool uses an interactive shell; some functions can also run from a shell prompt. The Red Hat Update Infrastructure Management Tool uses seven main commands. For each command’s subcommand, a list of options is provided if the subcommand expects one or more options other than -h and --help.

View all options and commands.

[root@ip-10-141-150-145 ~]# rhui-manager --help
Usage: rhui-manager [options]

  OPTIONS
    -h/--help  show this help message and exit
    --debug    enables debug logging
    --noninteractive prevents console input, used for scripting
    --config   absolute path to the configuration file; defaults to /etc/rhui/rhui-tools.conf
    --server   location of the RHUA server (overrides the config file)
    --username if specified, previously saved authentication credentials are ignored and this username is used to login
    --password used in conjunction with --username
    --logout   logout from the active session

  COMMANDS
    cert      : Red Hat content certificate management
    packages  : package manipulation on repositories
    repo      : repository listing and manipulation
    cds       : CDS listing and manipulation
    migrate : Migrate from {RHUI3}
    haproxy   : Load balancer listing and manipulation
    status    : RHUI status and health information
    client    : Red Hat client management

10.2.1. cert

Red Hat content certificate management
    upload    : uploads a new content certificate
    info      : display information about the current content certificate
# rhui-manager cert upload
upload: uploads a new content certificate
    --cert - full path to the new content certificate (required)
    --key - full path to the new content certificate's key

10.2.2. packages

package manipulation on repositories
    list      : lists all packages in a repository
    remove    : removes a package from a custom repository
    upload    : uploads a package or directory of packages to a custom repository
    remote    : uploads RPM content from a remote URL to a custom repository
list: lists all packages in a repository
    --repo_id - id of the repository to list packages for (required)
remove: removes a package from a custom repository
    --repo_id - id of the custom repository to remove a package from (required)
    --package - name of the package to be removed (required)
    --vr - if specified, only the supplied version-release of the package will be removed
    --force - don't ask for confirmation
upload: uploads a package or directory of packages to a custom repository
    --repo_id - id of the custom repository where the packages will be uploaded (required)
    --packages - path to an .rpm file or directory of RPMs that will be uploaded (required)
remote: uploads RPM content from a remote URL to a custom repository
    --repo_id - id of the custom repository where the packages will be uploaded (required)
    --url - remote URL of the package or a web page that will be scraped for RPM content (required)

10.2.3. repo

repository listing and manipulation
    list      : lists all repositories in the RHUI
    info      : displays information on an individual repo
    add       : add a Red Hat repository to the RHUA
    add_by_repo: add Red Hat repositories to the RHUA via repo ID
    add_by_file: add Red Hat repositories to the RHUA using an input file
    add_errata: associate errata metadata with a repository
    delete    : delete a repository
    sync      : sync a repository
    export	  : export a repository to the filesystem
    enable_sync: enable scheduled synchronization of a repository
    disable_sync: disable scheduled synchronization of a repository
    sync_all  : sync all repositories
    metadata : ensure metadata is generated for the latest version of repositories
    enable_autopublish: enable automatic publishing of a new repository version
    disable_autopublish: disable automatic publishing of a new repository version
    create_custom: create a custom repository
    unused    : list of products available but not synced to the RHUA
info: displays information on an individual repo
    --repo_id - identifies the repository to display (required)
add: add a Red Hat repository to the RHUA
    --product_name - product to add the RHUA (required)
add_by_repo: add Red Hat repositories to the RHUA via repo ID
    --repo_ids - repo IDs to add, comma-separated (required)
    --sync-now - Use to sync any repos that are added (optional)
add_by_file: add Red Hat repositories to the RHUA using an input file
    --file - file containing repo IDs to add, one per line (required)
    --sync_now - Use to sync any repos that are added (optional)
add_errata: associate errata metadata with a repository
    --repo_id - repo ID to associate the metadata with (required)
    --updateinfo - updateinfo file to be applied (required)
delete: delete a repository
    --repo_id - identifies the repository to delete (required)
sync: sync a repository
    --repo_id - identifies the repository to sync (required)
export: export a repository to the filesystem
	  --repo_id - identifies the repository to export (required)
metadata : ensure metadata is generated for the latest version of repositories
   --repo_id - explicit repo ID to generate metadata for
enable_sync: enable scheduled synchronization of a repository
    --repo_id - identifies the repository to enable scheduled synchronization for (required)
    --verbose - if present, info on last/next synchronization tasks will be displayed
disable_sync: disable scheduled synchronization of a repository
    --repo_id - identifies the repository to disable scheduled synchronization for (required)
    --verbose - if present, info on last/next synchronization tasks will be displayed
enable_autopublish: enable automatic publishing of a new repository version
    --repo_id - identifies the repository to enable automatic publishing for (required)
disable_autopublish: disable automatic publishing of a new repository version
    --repo_id - identifies the repository to disable automatic publishing for (required)
create_custom: create a custom repository
    --repo_id - identifies the repository to add (required)
    --path - path to the content being served by CDS; defaults to repo_id
    --display_name - display name for the custom repository
    --entitlement - path used in the entitlement certificate; may use yum variable substitutions
    --legacy_md - if present, the repo will use SHA1, otherwise default value is used (SHA256)
    --redhat_content - repository will host Red Hat GPG signed content
    --protected - make the content protected by entitlement certificate
    --gpg_public_keys - comma separated list of public keys used to sign the served content; the filenames must not contain comma
unused: list all unused Red Hat repositories
Loading latest entitled products from Red Hat...
... listings loaded
Available Repositories
--------------------

10.2.4. cds

CDS listing and manipulation
    list      : lists all cds instances in the RHUI
    add       : register a cds instance to the RHUI
    reinstall : reinstalls an already registered cds instance
    delete    : unregisters cds instances from the RHUI
add: register a cds instance to the RHUI
    --hostname - The hostname of the instance to add. (required)
    --ssh_user - Username with SSH access to the instance and sudo privileges. (required)
    --keyfile_path - Absolute path to an SSH private key to use with the given user. (required)
    --hostfile - Absolute path to a known_hosts file to use to determine the identity of the instance; if this is not provided and the instance hostkey is not in the system-wide known_hosts file, this command will fail.
    --user_supplied_ssl_key - Optional absolute path to the user supplied SSL key file.
    --user_supplied_ssl_crt - Optional absolute path to the user supplied SSL crt file.
    --force - Add the system even if the hostname is already registered.
    --unsafe - Proceed even if the instance host key is not in the known_hosts file. This is not secure!
reinstall: reinstalls an already registered cds instance
    --hostname - The hostname of the instance to reinstall on; this instance must be registered already.
    --all - Reinstall all the registered instances.
delete: unregisters cds instances from the RHUI
    --force - Delete the system, even if it is the last of its kind.
    --hostnames - Comma-separated list of hostnames to delete (unregister) from RHUI. (required)

10.2.5. migrate

Migrate from {RHUI3}
   --hostname : the {RHUI3} hostname
   --password  : <your_password>
   --keyfile_path : ~/.ssh/id_rsa_rhua*

10.2.6. haproxy

Load balancer listing and manipulation
    list      : lists all haproxy instances in the RHUI
    add       : register a haproxy instance to the RHUI
    reinstall : reinstalls an already registered haproxy instance
    delete    : unregisters haproxy instances from the RHUI
add: register a haproxy instance to the RHUI
    --hostname - The hostname of the instance to add. (required)
    --ssh_user - Username with SSH access to the instance and sudo privileges. (required)
    --keyfile_path - Absolute path to an SSH private key to use with the given user. (required)
    --hostfile - Absolute path to a known_hosts file to use to determine the identity of the instance; if this is not provided and the instance hostkey is not in the system-wide known_hosts file, this command will fail.
    --config - Optional absolute path to a user supplied HAProxy config file.
    --force - Add the system even if the hostname is already registered.
    --unsafe - Proceed even if the instance host key is not in the known_hosts file. This is not secure!
reinstall: reinstalls an already registered haproxy instance
    --hostname - The hostname of the instance to reinstall on; this instance must be registered already.
    --all - Reinstall all the registered instances.
delete: unregisters haproxy instances from the RHUI
    --force - Delete the system, even if it is the last of its kind.
    --hostnames - Comma-separated list of hostnames to delete (unregister) from RHUI. (required)

10.2.7. status

status: RHUI status and health information
    --code - if specified, only a numeric code for the result will be displayed
    --repo_json - Name of the JSON file for a repo status

10.2.8. client

Red Hat client management
    labels    : list the labels required for client certificate creation
    cert      : create a content certificate for a rhui client
    rpm       : create a client config rpm
    content_source: create an alternate source config rpm
    acs_config: output a JSON representation of the alternate source config
cert: create a content certificate for a rhui client
    --repo_label - identifies the repositories to add. Comma delimited string of repo labels (required)
    --name - identifies the certificate name (required)
    --days - number of days cert will be valid (required)
    --dir - directory where the certificate will be stored (required)
rpm: create a client config rpm
    --private_key - entitlement private key
    --entitlement_cert - entitlement certificate
    --rpm_version - version number of the client config rpm
    --rpm_release - release of rpm package. Default is 1
    --rpm_name - name of the client config rpm (required)
    --dir - directory where the rpm will be created (required)
    --unprotected_repos - comma-separated list of unprotected repos to include
    --cert - generate certificate also before building client config rpm if given
    --ca_cert - full path to the certificate authority of CDS servers
    --repo_label - identifies the repositories to add. Comma delimited string of repo labels
    --name - identifies the certificate name if it is different from rpm name
    --days - number of days cert will be valid
    --proxy - url/string in case proxy option is necessary in yum repo file
content_source: create an alternate source config rpm
    --private_key - entitlement private key
    --entitlement_cert - entitlement certificate
    --rpm_version - version number of the client config rpm
    --rpm_name - name of the client config rpm (required)
    --dir - directory where the rpm will be created (required)
    --unprotected_repos - comma-separated list of unprotected repos to include
    --cert - generate certificate also before building client config rpm if given
    --ca_cert - full path to the certificate authority of CDS servers
    --repo_label - identifies the repositories to add. Comma delimited string of repo labels
    --name - identifies the certificate name if it is different from rpm name
    --days - number of days cert will be valid
acs_config: output a JSON representation of the alternate source config
    --dir - directory where the JSON representation will be stored (required)
    --private_key - entitlement private key
    --entitlement_cert - entitlement certificate
    --cert - generate certificate based on the the repos supplied via --repo_label
    --ssl_ca_cert - full path to the certificate authority of CDS servers (defaults to ssl_ca_crt specified in rhui-tools.conf)
    --repo_label - identifies the repositories to add. Comma delimited string of repo labels
    --days - number of days cert will be valid if new cert is generated

Chapter 11. Certified Cloud and Service Provider certification workflow

The Certified Cloud Provider Agreement requires that Red Hat certifies the images (templates) from which tenant instances are created to ensure a fully supported configuration for end customers.

There are two methods for certifying the images for Red Hat Enterprise Linux. The preferred method is to use the Certified Cloud and Service Provider (CCSP) image certification workflow.

After certifications have been reviewed by Red Hat, a pass/fail will be assigned and certification will be posted to the public Red Hat certification website at Red Hat Ecosystem Catalog.

11.1. Additional resources

Chapter 12. Backing up and restoring Red Hat Update Infrastructure

After you have installed and configured your Red Hat Update Infrastructure(RHUI) servers, you might want to back them up. Backing up RHUI is useful if you encounter any problems or do not configure RHUI correctly. In such cases, you can return to a previous working configuration by restoring RHUI.

To successfully back up RHUI, you must back up all of your RHUA, CDS, and HAProxy nodes.

12.1. Backing up Red Hat Update Appliance

To back up Red Hat Update Appliance, you must back up all the associated files and storage.

Note

To back up RHUA, you must stop the associated services. However, stopping services does not disable any client instances from updating or installing packages because clients are connected only to the content delivery servers (CDSs). Consequently, If you have an automated monitoring solution in place, your monitoring may fail during the backup process.

Procedure

  1. Stop pulp-server services:

    # systemctl stop pulpcore-api pulpcore-content pulpcore-worker\*
  2. Verify whether the services have stopped:

    # systemctl status pulpcore-api pulpcore-content pulpcore-worker\*
  3. Back up the following files.

    # cp -a <source_files_path> <destination_files_path>
    Important

    Ensure that the files retain their current attributes when you back them up.

    List of Files:

    • /etc/pki/rhui/*
    • /etc/pulp/*
    • /etc/rhui/*
    • /etc/rhui/rhui-tools.conf
    • /etc/nginx/*
    • /root/.rhui/*
    • /var/log/rhui/*
    • /var/log/rhui-subscription-sync.log*
    • Optional: /var/lib/rhui/*

      Note

      Backing up this directory backs up all of the downloaded content, which might be a large amount of data.

  4. Back up any generated client entitlement certificates and client configuration RPMs.
  5. Restart RHUI services

    # rhui-services-restart

12.2. Restoring Red Hat Update Appliance

To restore RHUA, you must create a new RHUA node and replace the associated files with the backed up versions.

Procedure

  1. Create a new RHUA node. For more information, see Setting up RHUA nodes.
  2. Stop pulp-server services:

    # systemctl stop pulpcore-api pulpcore-content pulpcore-worker\*
  3. Verify whether the services have stopped:

    # systemctl status pulpcore-api pulpcore-content pulpcore-worker\*
  4. Restore the following files.

    # cp -a <source_files_path> <destination_files_path>
    Important

    Ensure that the files retain their current attributes when you restore them.

    List of Files:

    • /etc/pki/rhui/*
    • /etc/pulp/*
    • /etc/rhui/*
    • /etc/rhui/rhui-tools.conf
    • /etc/nginx/*
    • /root/.rhui/*
    • /var/log/rhui/*
    • /var/log/rhui-subscription-sync.log*
    • Optional: /var/lib/rhui/*

      Note

      Restoring this directory restores all of the downloaded content, which might be a large amount of data.

  5. Restore any generated client entitlement certificates and client configuration RPMs.
  6. Restart RHUI services

    # rhui-services-restart

12.3. Backing up content delivery servers

To back up CDSs, you must back up all the associated files and storage.

Note

To avoid complete loss of service, back up a single CDS node at a time. Clients will automatically switch to other running CDS nodes.

Procedure

  1. Stop the nginx service:

    # systemctl stop nginx
  2. Verify that the nginx service has stopped:

    # systemctl status nginx
  3. Back up the following files.

    # cp -a <source_files_path> <destination_files_path>
    Important

    Ensure that the files retain their current attributes when you back them up.

    List of files:

    • /etc/nginx/*
    • /var/log/nginx/*
    • /etc/pki/rhui/*
  4. Restart RHUI services.

    # rhui-services-restart

12.4. Restoring content delivery servers

To restore content delivery servers, you must create a new CDS node and replace the associated files with the backed up versions.

Procedure

  1. Create a new CDS node. For more information, see Setting up CDS nodes.
  2. Stop the nginx service:

    # systemctl stop nginx
  3. Verify that the nginx service has stopped:

    # systemctl status nginx
  4. Restore the following files.

    # cp -a <source_files_path> <destination_files_path>
    Important

    Ensure that the files retain their current attributes when you restore them.

    List of files:

    • /etc/nginx/*
    • /var/log/nginx/*
    • /etc/pki/rhui/*
  5. Restart RHUI services.

    # rhui-services-restart

12.5. Backing up HAProxy servers

To back up HAProxy servers, you must back up all the associated files and storage.

Procedure

  1. Back up the /etc/haproxy/haproxy.cfg file.

    # cp -a <source_files_path> <destination_files_path>
    Important

    Ensure that the file retains its current attributes when you back it up.

12.6. Restoring HAProxy servers

To restore HAProxy servers, you must create a new HAProxy node and replace the associated files with the backed up versions.

Procedure

  1. Create a new HAProxy node. For more information, see Setting up HAProxy nodes.
  2. Restore the /etc/haproxy/haproxy.cfg file.

    # cp -a <source_files_path> <destination_files_path>
    Important

    Ensure that the file retains its current attributes when you restore it.

Chapter 13. Resolving common problems in RHUI 4

The following table lists known issues with Red Hat Update Infrastructure. If you encounter any of these issues, report the problem through Bugzilla.

Table 13.1. Common problems in Red Hat Update Infrastructure

EventDescription of known issueRecommendation

Installation and Configuration

You experience communication issues between the RHUA and the CDSs.

Verify the fully qualified domain name (FQDN) is set for the RHUA and CDS and is resolvable.

Configure the HTTP proxy properly as described in Bug 726420 – Quick note on proxy URL

Synchronization

You cannot synchronize repositories with Red Hat.

Verify the RHUI SKUs are in your account.

Verify the proper content certificates are loaded to the RHUA.

Look for temporary CDN issues.

Look for any HTTP proxy in your environment and make sure you are not hitting an While syncing repositories to RHUA, it fails with "RepoError: Cannot retrieve repository metadata (repomd.xml) for repository. Please verify its path and try again" when proxy used error.

The RHUA cannot synchronize to CDSs, typically due to expired qpid certificates: See CDS sync fails with error "sslv3 alert certificate expired" due to expired qpid CA certificates on RHUI for more information.

Red Hat Update Appliance/Content Delivery Network Communication

The Red Hat Update Appliance is not communicating with the Content Delivery Network.

Use the content certificate in /etc/pki/rhui/redhat (the .pem file) to test connectivity and access between the RHUA and the CDN.

# cd /etc/pki/rhui/redhatwget --certificate=8a85f98146a087b80146afacb3362499.pem --ca-certificate=/etc/rhsm/ca/redhat-uep.pem

https://cdn.redhat.com/content/dist/rhel/rhui/server/6/6Server/x86_64/os/repodata/repomd.xml

Note from the curl (1) man page: If the NSS PEM PKCS#11 module (lib-nsspem.so) is available, then PEM files may be loaded. If you want to use a file from the current directory, precede it with ./ prefix to avoid confusion with a nickname.

On each CDS, the entitlement certificate in /etc/pki/pulp/content can be used to test the availability of the RHUA content using # curl --cert ./rhui-ec2-20120619.pem.

The URL for the repositories hosted on the RHUA always start with https://fqdn/pulp/content. You can divulge the remaining URL by: -Looking at the file path on the RHUA under /var/lib/rhui/remote_share/symlinks/pulp/content/ -Examining the content certificate directly using openssl commands because the OIDs ending in 1.6 contain the path

Client/Content Delivery Server Communication

curl can be used to verify client communications with the content delivery server nodes as well.

# curl --cert /etc/pki/entitlement/product/content.crt --key /etc/pki/entitlement/key.pem https://ip-10-4-58-34.ec2.internal/pulp/repos/content/dist/rhel/rhui/server/6/6Server/x86_64 /rhui/2.1/os/repodata/repomd.xml -k <?xml version="1.0" encoding="UTF-8"?> <repomd xmlns="http://linux.duke.edu/metadata/repo" xmlns:rpm="http://linux.duke.edu/metadata/rpm"> <revision>1339940325</revision> <data type="other_db"> <location href="repodata/4f86b0ae203bba90d22a8363120c66ed6f37da81-other.sqlite.bz2"/> <checksum type="sha">4f86b0ae203bba90d22a8363120c66ed6f37da81</checksum> <timestamp>1339940328.43</timestamp>

Client/HAProxy communication

All HAProxy nodes are down. Clients have lost access to RHUI repositories.

Add and configure at least one new HAProxy node. If you cannot do so for whatever reason, temporarily change the DNS configuration so that the main load balancer host name (cds.example.com in this guide) resolves to the IP address of one of your CDS nodes. This will allow the clients to avoid the unavailable HAProxy nodes and communicate with the CDS directly.

Legal Notice

Copyright © 2023 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.