Providing feedback on Red Hat documentation

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

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

Procedure

  1. Log in to Atlassian Jira.

  2. Click the following link: Create Issue.

  3. Complete the Summary, Description, and Reporter fields. In the Description field, include the documentation URL, chapter or section number, and a detailed description of the issue. Do not modify any other fields in the form.

  4. Click Create.

1. Planning Satellite Server installation

Before installing Satellite Server, review the operating system requirements, system requirements, storage requirements, and network requirements to ensure your environment meets the specifications.

1.1. Operating system requirements

Ensure that your operating system and installation method meet the necessary requirements before you install Satellite.

The following operating system is supported for deploying Satellite:

  • Red Hat Enterprise Linux 9 (x86_64)

You can install the operating system from a disc, local ISO image, Kickstart, or any other method that Red Hat supports.

Red Hat Satellite Server is supported on the latest version of Red Hat Enterprise Linux 9 available at the time of installation. Previous versions of Red Hat Enterprise Linux including EUS or z-stream are not supported.

Red Hat Satellite Server requires a Red Hat Enterprise Linux installation with the @Base package group with no other package-set modifications, and without third-party configurations or software not directly necessary for the direct operation of the server. This restriction includes hardening and other non-Red Hat security software. If you require such software in your infrastructure, install and verify a complete working Satellite Server first, then create a backup of the system before adding any non-Red Hat software.

1.2. System requirements

System requirements for Satellite Server include minimum CPU, RAM, storage, hostname format, SELinux configuration, and time synchronization to ensure proper installation and operation.

Satellite Server is fully supported on both physical systems and virtual machines that run on hypervisors that are supported to run Red Hat Enterprise Linux. For more information about certified hypervisors, see Certified Guest Operating Systems in Red Hat OpenStack Platform, Red Hat Virtualization, Red Hat OpenShift Virtualization and Red Hat Enterprise Linux with KVM.

Follow these system requirements when installing Satellite Server:

  • Install Satellite Server on a freshly provisioned system that serves no other function except to run Satellite Server. Do not use an existing system because foremanctl affects the configuration of several components.

  • Ensure you have administrative user (root) access to the system.

  • Ensure the system meets the following requirements:

    • 4 CPU cores

    • 20 GB RAM or higher

    • 4 GB RAM of swap space or higher

    • A unique host name, which can contain lower-case letters, numbers, dots (.) and hyphens (-)

  • If you use custom certificates, ensure that the Common Name (CN) of the custom certificate is a fully qualified domain name (FQDN). Satellite Server and Capsule Server do not support shortnames in the hostnames.

  • Ensure SELinux is enabled, either in enforcing or permissive mode. Installation with disabled SELinux is not supported. For more information, see Security considerations in Overview, concepts, and deployment considerations.

  • Ensure the system clock on the system is synchronized across the network. If the system clock is not synchronized, SSL certificate verification might fail. For example, you can use the Chrony suite for timekeeping. For more information, see Configuring time synchronization in Red Hat Enterprise Linux 9 Configuring basic system settings

  • If you are installing in an environment with air-gapped Satellite Servers, ensure that all your Satellite Servers are on the same Satellite version for ISS Export Sync to work. ISS Network Sync works across all Satellite versions that support it. For more information, see Synchronizing Content Between Satellite Servers in Managing content.

  • Ensure the system uses the UTF-8 encoding. If your territory is USA and your language is English, set en_US.utf-8 as the system-wide locale settings. For more information about configuring system locale in Red Hat Enterprise Linux, see Configuring the system locale in Red Hat Enterprise Linux 9 Configuring basic system settings.

  • If you use an external identity provider in your deployment, ensure that the provider did not create the apache user account on the system. This user account can cause conflicts with the local users that Satellite Server creates.

1.3. Storage requirements

Your system must meet the following storage requirements before you can install Satellite Server.

Follow these storage requirements when installing Satellite Server:

  • Ensure that the directories used by Satellite Server have sufficient disk space available:

    Table 1. Storage requirements for a Satellite Server installation
    Directory Installation Size Runtime Size

    /var/log

    10 MB

    10 GB

    /var/lib/pgsql

    1 GB

    20 GB

    /usr

    10 GB

    Not Applicable

    /var/lib/pulp

    1 MB

    300 GB

    /var/lib/containers

    20 GB

    30 GB

    These values are based on expected use case scenarios and can vary according to individual environments. The runtime size was measured with Red Hat Enterprise Linux 7, 8, and 9 repositories synchronized.

  • If you mount the /var/lib/pulp directory as an NFS share, specify the SELinux context of the /var/lib/pulp directory in the file system table. Add the following lines to /etc/fstab:

    nfs.example.com:/nfsshare  /var/lib/pulp  nfs  context="system_u:object_r:pulpcore_var_lib_t:s0"  1 2

    If the NFS share is already mounted, remount it using the above configuration and restore the SELinux context:

    # restorecon -R /var/lib/pulp

    Do not use symbolic links for /var/lib/pulp/.

Additional resources

1.4. Best practices for optimizing storage

You can optimize your storage by following the storage best practices. These include using LVM for /var, high-bandwidth storage for critical directories, and appropriate file systems to improve I/O performance and scalability.

  • The exact amount of storage you require for log messages depends on your installation and setup. You can manage the size of the log files by using logrotate.

  • Consider mounting /var on LVM storage. This can help the system to scale because most Satellite Server data is stored in the /var directory.

  • Use high-bandwidth, low-latency storage for the /var/lib/pulp/ and /var/lib/pgsql directories. Using high latency, low-bandwidth storage causes performance degradation because Red Hat Satellite has many operations that are I/O intensive.

  • Use a file system with low input-output latency. Do not use the GFS2 file system because the input-output latency is too high.

Additional resources

1.5. IPv4 and IPv6 requirements

You can install Satellite in an IPv4 network or in an IPv6 network. Your system must meet the following requirements for a successful installation and operation.

Note

Dual-stack Satellite installations that use both IPv4 and IPv6 are not supported.

The following requirements apply to installations in an IPv4 network:

  • Ensure an IPv6 loopback is configured on the base system. The loopback is typically configured by default. Do not disable it. Using the ipv6.disable=1 kernel parameter or the net.ipv6.conf.lo.disable_ipv6 = 1 sysctl option will break the installation.

The following requirements apply to installations in an IPv6 network:

  • Deploy an external HTTP proxy server that supports both IPv4 and IPv6. This is required because Red Hat Content Delivery Network distributes content only over IPv4 networks, therefore you must use this HTTP proxy to pull content into the Satellite on your IPv6 network. You must configure Satellite to use this dual-stack (supporting both IPv4 and IPv6) HTTP proxy as the default HTTP proxy.

  • Satellite does not support configuring an HTTP proxy using a direct IPv6 address. Instead, configure the HTTP proxy with a FQDN that resolves to the IPv6 address.

If you intend to provision hosts in an IPv6 network, the following requirements also apply:

  • Deploy an external DHCPv6 server and configure it manually to communicate with the network boot process and to manage IP address assignment because Satellite cannot integrate with a DHCPv6 server and manage its configuration. For more information about DHCPv6 server configuration, see Options in unmanaged DHCPv6 in Provisioning hosts.

  • Configure Satellite for UEFI HTTP boot provisioning. Although Satellite provisioning templates include IPv6 support for PXE and HTTP (iPXE) provisioning, the UEFI HTTP Boot provisioning is the only tested and certified provisioning workflow.

Additional resources

1.6. AWS Requirements

Installing and running Satellite Server and Capsule Servers on Amazon Web Services (AWS) has additional requirements to your environment.

Amazon Web Service requirements

  • Use Storage requirements in Installing Satellite Server (containerized) in a connected network environment to understand and assign the correct storage to your AWS EBS volumes. See also an AWS storage optimized instance for further guidance.

  • Create EBS volumes for directories expected to contain larger amounts of data like /var/lib/pulp and ensure they are correctly mounted on start-up and before continuing the installation.

  • Optional: Store other data on a separate EBS volume.

  • If you want Satellite Server and Capsule Server to communicate using external DNS hostnames, open the required ports for communication in the AWS Security Group that is associated with the instance.

AWS permission requirements

  • Create and access Red Hat Enterprise Linux images in AWS

  • Edit network access in AWS Security

  • Create EC2 instances and EBS volumes

  • Launch EC2 instances

  • Import and export of virtual machines in AWS

  • Usage of AWS Direct Connect

Satellite requirements

Ensure that your Amazon EC2 instance meets or exceeds requirements for Satellite:

Red Hat Cloud prerequisites

  • Register with Red Hat Cloud Access.

  • Migrate any Red Hat subscriptions that you want to use.

  • Create an AWS instance and deploy a virtual machine running Red Hat Enterprise Linux to the instance. For more information about deploying Red Hat Enterprise Linux in AWS, see How to Locate Red Hat Cloud Access Gold Images on AWS EC2.

  • Ensure that your subscriptions are eligible for transfer to Red Hat Cloud. For more information, see Red Hat Cloud Access Program Details.

Additional resources

2. Preparing your environment for Satellite Server installation

Prepare your environment for Satellite Server installation by opening required network ports, verifying DNS resolution, and configuring repositories.

2.1. Opening required ports

Open the required network ports to enable communication between Satellite components across your infrastructure, including firewall configurations for both host-based and network-based firewalls.

Note

Some cloud solutions must be specifically configured to allow communications between machines because they isolate machines similarly to network-based firewalls. If you use an application-based firewall, ensure that the application-based firewall permits all applications that are listed in the tables and known to your firewall. If possible, disable the application checking and allow open port communication based on the protocol.
Procedure

  1. Open the ports for clients on Satellite Server:

    # firewall-cmd \
--add-port="8000/tcp" \
--add-port="8443/tcp"

  2. Allow access to services on Satellite Server:

    # firewall-cmd \
--add-service=http \
--add-service=https

  3. Make the changes persistent:

    # firewall-cmd --runtime-to-permanent
Verification

  • View all firewall zones and allowed services:

    # firewall-cmd --list-all
Additional resources

2.2. Verifying DNS resolution

Verify the full forward and reverse DNS resolution using a fully-qualified domain name to prevent issues while installing Satellite.

Procedure

  1. Ensure that the host name and local host resolve correctly:

    # ping -c1 localhost
# ping -c1 `hostname -f` # my_system.domain.com

    Successful name resolution results in output similar to the following:

    # ping -c1 localhost
PING localhost (127.0.0.1) 56(84) bytes of data.
64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64 time=0.043 ms

--- localhost ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.043/0.043/0.043/0.000 ms

# ping -c1 `hostname -f`
PING hostname.gateway (XX.XX.XX.XX) 56(84) bytes of data.
64 bytes from hostname.gateway (XX.XX.XX.XX): icmp_seq=1 ttl=64 time=0.019 ms

--- localhost.gateway ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.019/0.019/0.019/0.000 ms

  2. To avoid discrepancies with static and transient host names, set all the host names on the system by entering the following command:

    # hostnamectl set-hostname name
    Warning

    Name resolution is critical to the operation of Satellite. If Satellite cannot properly resolve its fully qualified domain name, tasks such as content management, subscription management, and provisioning will fail.
Additional resources

2.3. Configuring the HTTP proxy to connect to Red Hat CDN

You can configure an HTTP proxy to connect to Red Hat CDN when your network requires proxy access for subscription management and content delivery.

Prerequisites

  • Your network gateway and the HTTP proxy must allow access to the following hosts:

    Host name Port Protocol

    subscription.rhsm.redhat.com

    443

    HTTPS

    cdn.redhat.com

    443

    HTTPS

    cert.console.redhat.com (if using Red Hat Lightspeed)

    443

    HTTPS

    api.access.redhat.com (if using Red Hat Lightspeed)

    443

    HTTPS

    cert-api.access.redhat.com (if using Red Hat Lightspeed)

    443

    HTTPS

    console.redhat.com (if using Red Hat Lightspeed)

    443

    HTTPS

    connect.cloud.redhat.com (if using Red Hat Lightspeed)

    443

    HTTPS

    *.akamaiedge.net (if using Red Hat Lightspeed in Satellite)

    443

    HTTPS
Procedure

  • On Satellite Server, complete the following details in the /etc/rhsm/rhsm.conf file:

    # an http proxy server to use (enter server FQDN)
proxy_hostname = http-proxy.example.com

# port for http proxy server
proxy_port = 8080

# user name for authenticating to an http proxy, if needed
proxy_user =

# password for basic http proxy auth, if needed
proxy_password =
Additional resources

2.4. Registering to Red Hat Subscription Management

Registering the host to Red Hat Subscription Management enables the host to subscribe to and consume content for any subscriptions available to the user. This includes content such as Red Hat Enterprise Linux and Red Hat Satellite.

Procedure

  • Register your system with the Red Hat Content Delivery Network, entering your Customer Portal user name and password when prompted:

    # subscription-manager register

    The command displays output similar to the following:

    # subscription-manager register
Username: user_name
Password:
The system has been registered with ID: 541084ff2-44cab-4eb1-9fa1-7683431bcf9a

2.5. Configuring repositories

Enable the necessary repositories on your Satellite host to access installation packages and dependencies.

Procedure

  1. Disable all repositories:

    # subscription-manager repos --disable "*"

  2. Enable the following repositories:

    # subscription-manager repos \
--enable=rhel-9-for-x86_64-baseos-rpms \
--enable=rhel-9-for-x86_64-appstream-rpms \
--enable=satellite-6.20-for-rhel-9-x86_64-rpms \
--enable=satellite-maintenance-6.20-for-rhel-9-x86_64-rpms

  3. Install the foreman-release.rpm package:

    # dnf install https://yum.theforeman.org/releases/6.20/el9/x86_64/foreman-release.rpm
Verification

  • Verify that the required repositories are enabled:

    # dnf repolist enabled

3. Installing Satellite Server

Use the following procedures to install Satellite Server in a connected environment, perform the initial configuration, and import subscription manifests. For more information on subscription manifests, see Managing Red Hat Subscriptions in Managing content.

You can deploy Satellite Server with a default internal database or with an external database.

When you install Satellite Server from a connected network, you can obtain packages and receive updates directly from the Red Hat Content Delivery Network.

Note

You cannot register Satellite Server to itself.

3.1. Deploy Satellite Server configuration with the default database

You can deploy a Satellite Server in a default configuration by using the foremanctl deploy command.

To extend the default deployment, you can select one or more features or add one or more configuration options.

The initial deployment also installs PostgreSQL databases on the same server.

Note

Any additional run of the foremanctl deploy command recreates configuration files used by the Satellite services based on the parameters given in this and previous runs. This way, you can add additional settings to your deployment or change previous configurations.

For more information on how to apply custom configuration on other services, see Performing additional configuration on Satellite Server.
Prerequisites
Procedure

  1. Update the system to the latest available version:

    # dnf upgrade

  2. Optional: Inspect the features available for deployment:

    # foremanctl features

    You can enable one or more features by adding the --add-feature Feature-1 --add-feature Feature-2 option to the foremanctl deploy command.

  3. Deploy the configuration on the server:

    # foremanctl deploy \
--initial-admin-username My_Admin_User_Name \
--initial-admin-password My_Admin_Password \
--initial-organization "My_Organization" \
--initial-location "My_Location"
    Note

    The options prefixed with initial- affect only new databases.

    Specify a meaningful value for the initial-organization option. This can be your company name. The foremanctl tool creates an internal label that matches the value, and you cannot change it later. If you do not specify a value, an organization called Default Organization with the label Default_Organization is created. You can rename the organization name but not the label.

    The script displays its progress and writes logs to /var/log/foremanctl/foremanctl.log.

3.2. Deploy Satellite Server configuration with an external database

By default, the Satellite deployment includes installing a PostgreSQL database on the same host as Satellite Server. However, in certain Satellite deployments, using external databases instead of the default local databases can help with the server load or have other benefits.

To extend the default deployment, you can select one or more features or add one or more configuration options.

Note

Any additional run of the foremanctl deploy command recreates configuration files used by the Satellite services based on the parameters given in this and previous runs. This way, you can add additional settings to your deployment or change previous configurations.

For more information on how to apply custom configuration on other services, see Performing additional configuration on Satellite Server.
Prerequisites
Procedure

  1. Update the system to the latest available version:

    # dnf upgrade

  2. Optional: Inspect the features available for deployment:

    # foremanctl features

    You can enable one or more features by adding the --add-feature Feature-1 --add-feature Feature-2 option to the foremanctl deploy command.

  3. Deploy the configuration on the server:

    # foremanctl deploy \
--initial-admin-username My_Admin_User_Name \
--initial-admin-password My_Admin_Password \
--initial-organization "My_Organization" \
--initial-location "My_Location" \
--database-mode external \
--database-host My_Database_Host \
--database-port My_Database_Port \
--database-ssl-mode {disable,allow,prefer,require,verify-ca,verify-full} \
--database-ssl-ca My_Database_SSL_CA \
--candlepin-database-name My_Candlepin_Database_Name \
--candlepin-database-password My_Candlepin_Database_Password \
--candlepin-database-user My_Candlepin_Database_User \
--pulp-database-name My_Pulp_Database_Name \
--pulp-database-password My_Pulp_Database_Password \
--pulp-database-user My_Pulp_Database_User \
--pulp-worker-count My_Pulp_Worker_Count \
--foreman-database-name My_Foreman_Database_Name \
--foreman-database-user My_Foreman_Database_User \
--foreman-database-password My_Foreman_Database_Password
    Note

    The options prefixed with initial- affect only new databases.

    Specify a meaningful value for the initial-organization option. This can be your company name. The foremanctl tool creates an internal label that matches the value, and you cannot change it later. If you do not specify a value, an organization called Default Organization with the label Default_Organization is created. You can rename the organization name but not the label.

    The script displays its progress and writes logs to /var/log/foremanctl/foremanctl.log.

3.3. Importing Red Hat subscription manifests into Satellite

You can import a Red Hat subscription manifest into Satellite to provide subscription allocation to your organization in Satellite.

Note

Simple Content Access (SCA) is set on the organization, not the manifest. Importing a manifest does not change your organization’s Simple Content Access status.

Simple Content Access simplifies the subscription experience for administrators.

Additional resources

3.3.1. Obtaining a Red Hat subscription manifest

You can create and export a Red Hat subscription manifest to prepare subscriptions for import into Satellite.

Procedure

3.3.2. Importing a Red Hat subscription manifest by using Satellite web UI

You can import a Red Hat subscription manifest into Satellite Server by using Satellite web UI. Import the manifest so that you can enable and synchronize Red Hat repositories in your organization.

Prerequisites
Procedure

  1. In the Satellite web UI, ensure the context is set to the organization you want to use.

  2. Navigate to Content > Subscriptions.

  3. Click Manage Manifest.

  4. In the Manage Manifest window, click Choose File.

  5. Navigate to the location that contains the Red Hat subscription manifest file, then click Open.

3.3.3. Importing a Red Hat subscription manifest by using Hammer CLI

You can import a Red Hat subscription manifest into Satellite Server by using Hammer CLI. Import the manifest so that you can enable and synchronize Red Hat repositories in your organization.

Prerequisites
Procedure

  1. Copy the Red Hat subscription manifest file from your local machine to Satellite Server:

    $ scp ~/manifest_file.zip root@satellite.example.com:~/.

  2. Log in to Satellite Server over SSH as the root user.

  3. Import the Red Hat subscription manifest file:

    $ hammer subscription upload \
--file ~/manifest_file.zip \
--organization "My_Organization"

4. Tuning performance with predefined profiles

If your Satellite deployment includes a large number of hosts, you can use predefined tuning profiles to configure your Satellite Server to use the optimal amount of CPU cores and memory. This can help improve Satellite performance.

Procedure

  1. Select the profile that best matches your use case:

    Table 2. Predefined tuning profiles
    Tuning profile Number of hosts RAM Number of CPU cores

    default

    0 – 5000

    20G

    4

    medium

    5001 – 10000

    32G

    8

    large

    10001 – 20000

    64G

    16

    extra-large

    20001 – 60000

    128G

    32

    extra-extra-large

    60000+

    256G

    48+

  2. Apply a predefined tuning profile to your Satellite Server:

    # foremanctl deploy --tuning My_profile

    Replace My_profile with the name of the profile you want to apply.

5. Performing additional configuration on Satellite Server

You can enable additional features on Satellite Server, such as Red Hat Lightspeed integration, pull-based transport for remote execution, or the usage of HTTP proxies. While you can configure these features after the initial setup, you can also configure many of them during the installation by using the corresponding foremanctl options.

5.1. Configuring Satellite Server as Red Hat Lightspeed client

You can use Red Hat Lightspeed to diagnose systems and downtime related to security exploits, performance degradation, and stability failures. You can use the dashboard to quickly identify key risks to stability, security, and performance. You can sort by category, view details of the impact and resolution, and then determine what systems are affected.

Note that you do not require a Red Hat Lightspeed entitlement in your subscription manifest.

To maintain your Satellite Server, and improve your ability to monitor and diagnose problems you might have with Satellite, install the insights-client tool on Satellite Server and register Satellite Server with Red Hat Lightspeed.

Procedure

  1. Register Satellite Server with Red Hat Lightspeed:

    # DO_NOT_USE_foreman-installer_IN_CONTAINERIZED_BUILDS --register-with-insights

  2. Optional: You can change the default schedule for running insights-client by updating the system systemd settings and the insights-client.timer file on your Satellite Server.

Verification

  • Check that the system is registered with Red Hat Lightspeed:

    # insights-client --status
Next steps

  • If you want to unregister the system from Red Hat Lightspeed:

    # insights-client --unregister
Additional resources

5.2. Importing the Red Hat Satellite Client 6 repository

The Red Hat Satellite Client 6 repository provides essential client integration tools, such as katello-host-tools, that enable communication between hosts and Satellite. To use these tools, you must enable and synchronize the repository on Satellite Server, then enable it on your hosts. These tools are required for features like remote execution, package management, and host reporting.

5.2.1. Enabling the Red Hat Satellite Client 6 repository

Enable the Red Hat Satellite Client 6 repository for every major version of Red Hat Enterprise Linux that you intend to run on your hosts. After enabling a Red Hat repository, Satellite creates a product for this repository automatically.

Prerequisites

  • Ensure that a subscription manifest has been imported to your organization.

Procedure

  1. In the Satellite web UI, navigate to Content > Red Hat Repositories.

  2. Ensure that the RPM repository type is selected.

  3. In the search field, type name = "Red Hat Satellite Client 6" and press Enter. Optionally, enable the Recommended Repositories filter to limit the results.

  4. Click the name of the required repository to expand the repository set.

  5. For the required architecture, click the + icon to enable the repository.

Additional resources

5.2.2. Synchronizing the Red Hat Satellite Client 6 repository

Synchronize the Red Hat Satellite Client 6 repository to import the content to your Satellite Server.

Prerequisites

  • You have enabled the Red Hat Satellite Client 6 repository.

Procedure

  1. In the Satellite web UI, navigate to Content > Sync Status.

  2. Click the arrow next to the required product to view available repositories.

  3. Select the repositories you want to synchronize.

  4. Click Synchronize Now.

Next steps

  • You can create a sync plan to update the content regularly.

Additional resources

5.3. Configuring Satellite Server to use an HTTP proxy

Configure Satellite Server to use an HTTP proxy if your environment uses an HTTP proxy to connect to the internet.

5.3.1. Adding a default HTTP proxy by using Satellite web UI

If your network uses an HTTP proxy, you can configure Satellite Server to use an HTTP proxy for requests to the Red Hat Content Delivery Network (CDN) or another content source. Use the FQDN instead of the IP address where possible to avoid losing connectivity because of network changes.

The following procedure configures an HTTP proxy only for downloading content for Satellite.

Procedure

  1. In the Satellite web UI, navigate to Infrastructure > HTTP Proxies.

  2. Click New HTTP Proxy.

  3. In the Name field, enter the name for the HTTP proxy.

  4. In the Url field, enter the URL of the HTTP proxy in the following format: https://http-proxy.example.com:8080.

  5. Optional: If authentication is required, in the Username field, enter the username to authenticate with.

  6. Optional: If authentication is required, in the Password field, enter the password to authenticate with.

  7. To test connection to the proxy, click Test Connection.

  8. Select the Default content HTTP proxy option to set the new HTTP proxy as default for content synchronization.

  9. Click Submit.

5.3.2. Adding a default HTTP proxy by using Hammer CLI

If your network uses an HTTP proxy, you can configure Satellite Server to use an HTTP proxy for requests to the Red Hat Content Delivery Network (CDN) or another content source. Use the FQDN instead of the IP address where possible to avoid losing connectivity because of network changes.

The following procedure configures an HTTP proxy only for downloading content for Satellite.

Procedure

  1. Verify that the http_proxy, https_proxy, and no_proxy variables are not set:

    # unset http_proxy https_proxy no_proxy

  2. Add an HTTP proxy entry to Satellite and set the HTTP proxy as default for content synchronization:

    $ hammer http-proxy create \
--name=My_HTTP_Proxy \
--username=My_HTTP_Proxy_User_Name \
--password=My_HTTP_Proxy_Password \
--url http://http-proxy.example.com:8080 \
--content-default-http-proxy true

5.3.3. Using an HTTP proxy for all Satellite HTTP requests by using Satellite web UI

If your Satellite Server must remain behind a firewall that blocks HTTP and HTTPS, you can configure an HTTP proxy for communication with external systems, including compute resources, by using the Satellite web UI.

Note that if you are using compute resources for provisioning, and you want to use a different HTTP proxy with the compute resources, the HTTP proxy that you set for all Satellite communication takes precedence over the HTTP proxies that you set for compute resources.

Procedure

  1. In the Satellite web UI, navigate to Administer > Settings.

  2. In the HTTP(S) proxy row, select the adjacent Value column and enter the proxy URL.

  3. Click the tick icon to save your changes.

5.3.4. Using an HTTP proxy for all Satellite HTTP requests by using Hammer CLI

If your Satellite Server must remain behind a firewall that blocks HTTP and HTTPS, you can configure an HTTP proxy for communication with external systems, including compute resources, by using Hammer CLI.

Note that if you are using compute resources for provisioning, and you want to use a different HTTP proxy with the compute resources, the HTTP proxy that you set for all Satellite communication takes precedence over the HTTP proxies that you set for compute resources.

Procedure

  • Use an HTTP proxy:

    $ hammer settings set --name=http_proxy --value=My_HTTP_Proxy_URL

5.3.5. Excluding hosts from receiving proxied requests by using Satellite web UI

If you use an HTTP proxy for all Satellite HTTP or HTTPS requests, you can prevent certain hosts from communicating through the HTTP proxy.

Procedure

  1. In the Satellite web UI, navigate to Administer > Settings.

  2. In the HTTP(S) proxy except hosts row, select the adjacent Value column and enter the names of one or more hosts that you want to exclude from proxy requests.

  3. Click the tick icon to save your changes.

5.3.6. Excluding hosts from receiving proxied requests by using Hammer CLI

If you use an HTTP proxy for all Satellite HTTP or HTTPS requests, you can prevent certain hosts from communicating through the HTTP proxy.

Procedure

  • Enter the following command:

    $ hammer settings set --name=http_proxy_except_list --value=[hostname1.hostname2...]

5.3.7. Resetting the HTTP proxy by using Satellite web UI

If you want to reset the current HTTP proxy setting, unset the Default HTTP Proxy setting.

Procedure

  1. In the Satellite web UI, navigate to Administer > Settings, and click the Content tab.

  2. Set the Default HTTP Proxy setting to no global default.

5.3.8. Resetting the HTTP proxy by using Hammer CLI

If you want to reset the current HTTP proxy setting, unset the Default HTTP Proxy setting.

Procedure

  • Set the content_default_http_proxy setting to an empty string:

    $ hammer settings set --name=content_default_http_proxy --value=""

5.4. Enabling power management on hosts

Enable the baseboard management controller (BMC) module on Satellite Server to perform remote power management tasks on hosts, including power cycling and monitoring power states.

Red Hat Satellite supports the following BMC providers:

  • Intelligent Platform Management Interface (IPMI)

  • Redfish

Red Hat Satellite supports the following IPMI implementations:

  • freeipmi

  • ipmitool (default)

Prerequisites

  • Your host has a network interface of the BMC type. Satellite Server uses this NIC to pass credentials to the host.

Procedure

  1. Enable the BMC module:

    # foremanctl deploy --add-feature bmc

  2. Optional: Select the IPMI implementation:

    # foremanctl deploy --bmc-ipmi-implementation "freeipmi"

  3. In the Satellite web UI, navigate to Infrastructure > Subnets.

  4. Select the subnet of your host.

  5. On the Capsules tab, select your Satellite Server as BMC Capsule.

  6. Click Submit.

Next steps

5.5. Configuring an alternate CNAME for Satellite

You can configure an alternate CNAME for Satellite. This might be useful if you want to deploy the Satellite web interface on a different domain name than the one that is used by client systems to connect to Satellite. You must plan the alternate CNAME configuration in advance prior to installing Capsules and registering hosts to Satellite to avoid redeploying new certificates to hosts.

5.5.1. Configuring Satellite with an alternate CNAME

You can configure an alternate CNAME for Satellite with the default Satellite certificate. Note that the procedures for users of a default Satellite certificate and custom certificate differ.

Procedure

  1. Add an alternate CNAME to a new installation or an existing deployment of Satellite with a default Satellite certificate:

    # foremanctl --server-alias My-Alternate-FQDN.example.com

  2. If you use Satellite with a custom certificate, when creating a custom certificate, include the alternate CNAME records to the custom certificate. For more information, see Creating a Custom SSL Certificate for Satellite Server.

5.5.2. Configuring hosts to use an alternate Satellite CNAME for content management

If Satellite is configured with an alternate CNAME, you can configure hosts to use the alternate Satellite CNAME for content management. To do this, you must point hosts to the alternate Satellite CNAME prior to registering the hosts to Satellite. You can do this using the bootstrap script or manually.

Perform these steps on the hosts you want to configure.

Procedure

  • To configure the host manually, edit the /etc/rhsm/rhsm.conf file to update hostname and baseurl settings to point to the alternate host name, for example:

    [server]
# Server hostname:
hostname = My-Alternate-FQDN.example.com

content omitted

[rhsm]
# Content base URL:
baseurl=https://My-Alternate-FQDN.example.com/pulp/content/
Next steps

  • Now you can register the host with the subscription-manager.

5.6. Configuring Satellite Server with a custom SSL certificate

By default, Red Hat Satellite uses a self-signed SSL certificate to enable encrypted communications between Satellite Server, Capsule Servers, and all hosts. If you cannot use a Satellite self-signed certificate, you can configure Satellite Server to use an SSL certificate signed by an external certificate authority (CA).

When you configure Red Hat Satellite with custom SSL certificates, you must fulfill the following requirements:

  • You must use the privacy-enhanced mail (PEM) encoding for the SSL certificates.

  • You must not use the same SSL certificate for both Satellite Server and Capsule Server.

  • The same CA must sign certificates for Satellite Server and Capsule Server.

  • An SSL certificate must not also be a CA certificate.

  • An SSL certificate must include a subject alt name (SAN) entry that matches the common name (CN).

  • An SSL certificate must be allowed for Key Encipherment using a Key Usage extension.

  • An SSL certificate must not have a shortname as the CN.

  • You must not set a passphrase for the private key.

  • If you use a certificate signed by an intermediate CA, you must provide the full chain of certificates. Your certificate must start with the Root CA, contain one or more intermediate CAs, and end with your server certificate.

5.6.1. Creating a custom SSL certificate for Satellite Server

Use this procedure to create a custom SSL certificate for Satellite Server. If you already have a custom SSL certificate for Satellite Server, skip this procedure.

Procedure

  1. To store all the source certificate files, create a directory that is accessible only to the root user:

    # mkdir /root/satellite_cert

  2. Create a private key with which to sign the certificate signing request (CSR). The private key must be unencrypted:

    # openssl genrsa -out /root/satellite_cert/satellite_cert_key.pem 4096

    If you already have a private key, skip this step.

  3. Optional: Verify that the key is unencrypted:

    # openssl pkey -noout -in /root/satellite_cert/satellite_cert_key.pem

    If the command does not ask for a password, the key is unencrypted. If your private key is password-protected, remove the password.

  4. Create the /root/satellite_cert/openssl.cnf configuration file for the CSR and include the following content:

    [ req ]
req_extensions = v3_req
distinguished_name = req_distinguished_name
prompt = no

[ req_distinguished_name ]
commonName = satellite.example.com

[ v3_req ]
basicConstraints = CA:FALSE
keyUsage = digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth, clientAuth
subjectAltName = @alt_names

[ alt_names ]
DNS.1 = satellite.example.com

    For more information about the [ v3_req ] parameters and their purpose, see RFC 5280: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile.

  5. Optional: If you want to add Distinguished Name (DN) details to the CSR, add the following information to the [ req_distinguished_name ] section:

    [req_distinguished_name]
commonName = satellite.example.com
countryName = My_Country_Name
stateOrProvinceName = My_State_Or_Province_Name
localityName = My_Locality_Name
organizationName = My_Organization_Or_Company_Name
organizationalUnitName = My_Organizational_Unit_Name

    The options used in the configuration file include the following:

    countryName

    The country represented by a two-letter code

    stateOrProvinceName

    Full name of the state or province

    localityName

    Full name of the locality (example: New York)

    organizationalUnitName

    Division responsible for the certificate (example: IT department)

  6. Generate the CSR:

    # openssl req -new \
-key /root/satellite_cert/satellite_cert_key.pem \
-config /root/satellite_cert/openssl.cnf \
-out /root/satellite_cert/satellite_cert_csr.pem

    The options used in the configuration file include the following:

    -key

    Path to the private key

    -config

    Path to the configuration file

    -out

    Path to the CSR to generate

  7. Send the certificate signing request to the certificate authority (CA). The same CA must sign certificates for Satellite Server and Capsule Server.

    When you submit the request, specify the lifespan of the certificate. The method for sending the certificate request varies, so consult the CA for the preferred method. In response to the request, you can expect to receive a CA bundle and a signed certificate, in separate files.

5.6.2. Deploying a custom SSL certificate to Satellite Server

Use this procedure to configure your Satellite Server to use a custom SSL certificate signed by a Certificate Authority.

Important

Do not store the SSL certificates or .tar bundles in /tmp or /var/tmp directory. The operating system removes files from these directories periodically. As a result, foremanctl fails to execute while enabling features or upgrading Satellite Server.
Procedure

  • Update certificates on your Satellite Server:

    # foremanctl deploy \
--certificate-source custom_server \
--certificate-server-certificate "/root/satellite_cert/satellite_cert.pem" \
--certificate-server-key "/root/satellite_cert/satellite_cert_key.pem" \
--certificate-server-ca-certificate "/root/satellite_cert/ca_cert_bundle.pem"

    The options used in the command include the following:

    --certificate-source custom_server

    Sets the certificate source to custom server certificates provided by the user.

    --certificate-server-certificate

    Path to Satellite Server certificate file that is signed by a Certificate Authority.

    --certificate-server-key

    Path to the private key for the Satellite Server certificate.

    --certificate-server-ca-certificate

    Path to the Certificate Authority bundle.

Verification

  1. On a computer with network access to Satellite Server, navigate to the following URL: https://satellite.example.com.

  2. In your browser, view the certificate details to verify the deployed certificate.

Next steps

5.7. Resetting custom SSL certificate to default self-signed certificate on Satellite Server

If you want to revert to the default configuration, you can reset a custom SSL certificate to the default self-signed certificate on your Satellite Server.

Procedure

  • Reset the custom SSL certificate to default self-signed certificate:

    # foremanctl deploy --certificate-source default
Verification

  • In your browser, go to your Satellite Server login page, for example, https://satellite.example.com, and inspect the certificate in the browser. This is typically displayed as a shield, padlock, or tune icon next to the address bar depending on your browser.

  • On the command line, display the certificate:

    $ openssl s_client -connect satellite.example.com:443 </dev/null
Additional resources