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

Review the following guidelines, requirements, and considerations before proceeding with the installation.

1.1. Operating system requirements

Your operating system and installation method must meet the following requirements before you can 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

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

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 satellite-installer 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 the provider did not create the following user accounts on the system. These user accounts can cause conflicts with the local users that Satellite Server creates:

    • apache

    • foreman

    • foreman-proxy

    • postgres

    • pulp

    • puppet

    • redis

    • tomcat

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

    /opt/puppetlabs

    500 MB

    Not Applicable

    /var/lib/pulp

    1 MB

    300 GB

    /var/lib/containers if using Red Hat Lightspeed in Satellite

    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 /tmp directory as a separate file system, use the exec mount option in the /etc/fstab file.

    If /tmp is already mounted with the noexec option, change the option to exec and remount the file system. This is a requirement for the puppetserver service to work.

  • 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

Consider the following storage guidelines for increased storage efficiency.

  • 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. For more information, see Configuring Satellite for UEFI HTTP boot provisioning in an IPv6 network in Integrating provisioning infrastructure services.

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 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 environment for Satellite Server installation

Ensure that your network environment is ready for the Satellite Server installation.

2.1. Opening required ports

By opening the required ports, you ensure that the components of Satellite architecture can communicate. You must also ensure that the required network ports are open on any 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="9090/tcp"

  2. Allow access to services on Satellite Server:

    # firewall-cmd \
--add-service=dns \
--add-service=dhcp \
--add-service=tftp \
--add-service=puppetmaster \
--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. Preparing Satellite for using external databases

By default, the Satellite installation process 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.

Prerequisites
Procedure

  • Install PostgreSQL on an external database host you prepared. For more information, see Installing PostgreSQL in Administering Red Hat Satellite.

Additional resources

2.4. 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

Satellite Server uses SSL to communicate with the Red Hat CDN securely. An SSL interception proxy interferes with this communication. These hosts must be allowlisted on your HTTP proxy.

For a list of IP addresses used by the Red Hat CDN (cdn.redhat.com), see the Knowledgebase article Public CIDR Lists for Red Hat on the Red Hat Customer Portal.

To configure the Subscription Manager with the HTTP proxy, follow the procedure below.

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 =

2.5. 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.6. Configuring repositories

Configure the required repositories.

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.19-for-rhel-9-x86_64-rpms \
--enable=satellite-maintenance-6.19-for-rhel-9-x86_64-rpms
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. Considerations for using the satellite-installer utility

The satellite-installer utility is a collection of Puppet modules. Before using it to install Satellite Server, consider that installations can take tens of minutes and that repeated runs might overwrite manual configuration changes.

  • The installation process can take tens of minutes to complete. If you are connecting remotely to the system, use a utility such as tmux that allows suspending and reattaching a communication session so that you can check the installation progress in case you become disconnected from the remote system. If you lose connection to the shell where the installation command is running, see the log at /var/log/foreman-installer/satellite.log to determine if the process completed successfully.

  • The Satellite installation script is based on Puppet, which means that if you run the installation script more than once, it might overwrite any manual configuration changes.

    To avoid this and determine which future changes apply, use the --noop argument when you run the installation script. This argument ensures that no actual changes are made. Potential changes are written to /var/log/foreman-installer/satellite.log.

    Files are always backed up and so you can revert any unwanted changes. For example, in the logs of foreman-installer, you can see an entry similar to the following about Filebucket:

    /Stage[main]/Dhcp/File[/etc/dhcp/dhcpd.conf]: Filebucketed /etc/dhcp/dhcpd.conf to puppet with sum 622d9820b8e764ab124367c68f5fa3a1

    You can restore the previous file as follows:

    # puppet filebucket -l \
restore /etc/dhcp/dhcpd.conf 622d9820b8e764ab124367c68f5fa3a1

  • Use the satellite-installer --scenario satellite --help command to display the most commonly used options and any default values.

  • Use the satellite-installer --scenario satellite --full-help command to display advanced options.

3.2. Installing Satellite Server packages

Ensure the packages required for Satellite Server installation are available on your system.

Procedure

  1. Upgrade all packages:

    # dnf upgrade

  2. Install the packages:

    # dnf install satellite

3.3. Configuring Satellite Server

Install Satellite Server by using the satellite-installer installation script. This initial configuration procedure creates an organization, location, user name, and password. After the initial configuration, you can create additional organizations and locations if required. The initial configuration also installs PostgreSQL databases on the same server.

This method is performed by running the installation script with one or more command options. The command options override the corresponding default initial configuration options and are recorded in the Satellite answer file. You can run the script as often as needed to configure any necessary options.

Note

Any additional run of the satellite-installer 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

  • If you want to use an external PostgreSQL database for your Satellite Server, you must have a corresponding PostgreSQL access available, for example on a dedicated host. For more information, see Preparing Satellite for using external databases.

Procedure

  1. Depending on what type of database you want to use on your Satellite deployment, do one of the following:

    Note

    The options prefixed with foreman-initial- affect only new databases.

    Specify a meaningful value for the foreman-initial-organization option. This can be your company name. The satellite-installer 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.

    • To install Satellite Server with the default local database, enter the following command with any additional options that you want to use:

      # satellite-installer --scenario satellite \
--foreman-initial-organization "My_Organization" \
--foreman-initial-location "My_Location" \
--foreman-initial-admin-username admin_user_name \
--foreman-initial-admin-password admin_password

    • To install Satellite Server with an external PostgreSQL server, enter the following command:

      # satellite-installer --scenario satellite \
--foreman-initial-organization "My_Organization" \
--foreman-initial-location "My_Location" \
--foreman-initial-admin-username admin_user_name \
--foreman-initial-admin-password admin_password \
--katello-candlepin-manage-db false \
--katello-candlepin-db-host postgres.example.com \
--katello-candlepin-db-name candlepin \
--katello-candlepin-db-user candlepin \
--katello-candlepin-db-password Candlepin_Password \
--foreman-proxy-content-pulpcore-manage-postgresql false \
--foreman-proxy-content-pulpcore-postgresql-host postgres.example.com \
--foreman-proxy-content-pulpcore-postgresql-db-name pulpcore \
--foreman-proxy-content-pulpcore-postgresql-user pulp \
--foreman-proxy-content-pulpcore-postgresql-password Pulpcore_Password \
--foreman-db-manage false \
--foreman-db-host postgres.example.com \
--foreman-db-database foreman \
--foreman-db-username foreman \
--foreman-db-password Foreman_Password

      To also enable encrypted connections for these external databases, use the following command instead:

      # satellite-installer --scenario satellite \
--foreman-initial-organization "My_Organization" \
--foreman-initial-location "My_Location" \
--foreman-initial-admin-username admin_user_name \
--foreman-initial-admin-password admin_password \
--katello-candlepin-manage-db false \
--katello-candlepin-db-host postgres.example.com \
--katello-candlepin-db-name candlepin \
--katello-candlepin-db-user candlepin \
--katello-candlepin-db-password Candlepin_Password \
--katello-candlepin-db-ssl true \
--katello-candlepin-db-ssl-ca My_CA_Certificate \
--katello-candlepin-db-ssl-verify true \
--foreman-proxy-content-pulpcore-manage-postgresql false \
--foreman-proxy-content-pulpcore-postgresql-host postgres.example.com \
--foreman-proxy-content-pulpcore-postgresql-db-name pulpcore \
--foreman-proxy-content-pulpcore-postgresql-user pulp \
--foreman-proxy-content-pulpcore-postgresql-password Pulpcore_Password \
--foreman-proxy-content-pulpcore-postgresql-ssl true \
--foreman-proxy-content-pulpcore-postgresql-ssl-root-ca My_CA_Certificate \
--foreman-db-manage false \
--foreman-db-host postgres.example.com \
--foreman-db-database foreman \
--foreman-db-username foreman \
--foreman-db-password Foreman_Password \
--foreman-db-root-cert My_CA_Certificate \
--foreman-db-sslmode verify-full

    The script displays its progress and writes logs to /var/log/foreman-installer/satellite.log.

3.4. 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.4.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.4.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.4.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 Satellite Server 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.

4.1. How predefined tuning profiles apply

When you run the satellite-installer command with the --tuning option, deployment configuration settings from multiple sources are applied to Satellite in a specific order. This order defines the priority of these settings.

Satellite loads tuning configuration settings from the following sources:

Custom Hiera settings

If you use custom Hiera settings on your Satellite Server, you can find them in the /etc/foreman-installer/custom-hiera.yaml file.

Predefined tuning profile

This is the profile that you select when running the satellite-installer command with the --tuning option. The settings for these profiles are defined in the /usr/share/foreman-installer/config/foreman.hiera/tuning/sizes/ directory.

Base tuning profile

The settings for this profile are defined in the /usr/share/foreman-installer/config/foreman.hiera/tuning/common.yaml file.

When merging these settings, Satellite applies them in the following order:

  • Custom settings in the /etc/foreman-installer/custom-hiera.yaml file override the settings in any predefined profile and the base profile.

  • Predefined profile settings override the settings in the base profile.

4.2. Predefined tuning profiles

The following predefined tuning profiles are available in Satellite to right-size your Satellite Server based on the number of hosts your Satellite manages and available hardware resources.

The predefined tuning profiles are available in the /usr/share/foreman-installer/config/foreman.hiera/tuning/sizes directory. Each profile targets a managed-host range and minimum RAM and CPU cores.

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+

4.3. Applying a predefined tuning profile

Run satellite-installer with the --tuning option to apply a profile. Choosing the right tuning profile helps your Satellite Server use its CPU cores and memory better.

Note

You cannot use predefined tuning profiles on Capsule Servers.
Procedure

  1. If you use a custom-hiera.yaml file on your Satellite Server, perform the following steps:

    1. Optional: Back up your custom-hiera.yaml file:

      # cp /etc/foreman-installer/custom-hiera.yaml \
/etc/foreman-installer/custom-hiera.original.yaml

      This ensures you can restore the custom-hiera.yaml file to its original state if it becomes corrupted.

    2. Review the definitions of the base tuning profile in /usr/share/foreman-installer/config/foreman.hiera/tuning/common.yaml and the tuning profile that you want to apply in /usr/share/foreman-installer/config/foreman.hiera/tuning/sizes/.

    3. Compare the configuration entries against the entries in your /etc/foreman-installer/custom-hiera.yaml file.

    4. Remove any duplicated configuration settings that you find in custom-hiera.yaml. This ensures the settings in custom-hiera.yaml do not override the settings in the base tuning profile and your chosen predefined tuning profile.

  2. Apply the tuning profile:

    # satellite-installer --tuning medium

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 satellite-installer 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:

    # satellite-installer --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. Installing and configuring Red Hat Lightspeed in Satellite

Red Hat Lightspeed in Satellite analyzes system health and configuration by applying predefined rules to a small set of local data, such as installed packages, running services, and configuration settings. When you install Red Hat Lightspeed in Satellite locally, you can generate Red Hat Lightspeed recommendations without sending system data to Red Hat services.

Important

  • With Red Hat Lightspeed in Satellite enabled, you cannot use the hosted Red Hat Lightspeed services for hosts registered to your Satellite. Enabling Red Hat Lightspeed in Satellite prevents you from using any Red Hat Hybrid Cloud Console services on hosts registered to Satellite.

  • If you install Satellite with external databases, you cannot enable Red Hat Lightspeed in Satellite. Enabling Red Hat Lightspeed in Satellite prevents you from using external databases.

Red Hat Lightspeed in Satellite follows the standard lifecycle policy for Red Hat Satellite. To update Red Hat Lightspeed in Satellite, follow the standard update instructions for Satellite.

5.2.1. Configuring Podman to use an HTTP proxy

If your Satellite Server connects to the internet through an HTTP proxy, configure Podman for connections through the same HTTP proxy.

Prerequisites

  • Podman is installed. For more information, see Getting container tools in Red Hat Enterprise Linux 9 Building, running, and managing containers.

Procedure

  • Edit the /etc/containers/containers.conf file to include the following directives:

    [engine]
env = ["https_proxy=https://http-proxy.example.com:port"]

[containers]
http_proxy=false

5.2.2. Installing Red Hat Lightspeed in Satellite on a connected Satellite Server

You can pull the Red Hat Lightspeed in Satellite from the Red Hat container registry if your Satellite Server has access to the registry.

Prerequisites

  • Ensure that the Satellite Server has access to the Red Hat container registry.

  • Ensure that Podman is installed. For more information, see Getting container tools in Red Hat Enterprise Linux 9 Building, running, and managing containers.

Procedure

  1. Log in to the Red Hat registry by using Podman:

    # podman login --authfile /etc/foreman/registry-auth.json registry.redhat.io

    This command creates the /etc/foreman/registry-auth.json file.

  2. Enable the plugin:

    # satellite-installer --enable-iop

  3. If you want to use the Red Hat Lightspeed vulnerability service in Satellite and your Satellite Server connects to https://security.access.redhat.com through an HTTP proxy, configure the iop-cvemap-download service to use the same HTTP proxy:

    1. Edit the iop-cvemap-download service:

      # systemctl edit iop-cvemap-download.service

    2. Input the following content:

      [Service]
Environment = HTTPS_PROXY=http://http-proxy.example.com:port
Environment = NO_PROXY=localhost

5.3. Importing the Red Hat Satellite Client 6 repository

The Red Hat Satellite Client 6 repository provides client integration tools, such as katello-host-tools, for hosts registered to Satellite. You must enable the repository, synchronize the repository to your Satellite Server, and enable the repository on your hosts.

5.3.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
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.

5.3.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. For more information, see Creating a sync plan in Managing content.

5.4. Configuring pull-based transport for remote execution

By default, remote execution uses push-based SSH as the transport mechanism for the Script provider. If your infrastructure prohibits outgoing connections from Satellite Server to hosts, you can use remote execution with pull-based transport instead, because the host initiates the connection to Satellite Server. The use of pull-based transport is not limited to those infrastructures.

The pull-based transport comprises pull-mqtt mode on Capsules in combination with a pull client running on hosts.

Note

The pull-mqtt mode works only with the Script provider. Ansible and other providers will continue to use their default transport settings.
Procedure

  1. Enable the pull-based transport on your Satellite Server:

    # satellite-installer --foreman-proxy-plugin-remote-execution-script-mode pull-mqtt

  2. Configure the firewall to allow the MQTT service on port 1883:

    # firewall-cmd --add-service=mqtt

  3. Make the changes persistent:

    # firewall-cmd --runtime-to-permanent

  4. In pull-mqtt mode, hosts subscribe for job notifications to either your Satellite Server or any Capsule Server through which they are registered. Ensure that Satellite Server sends remote execution jobs to that same Satellite Server or Capsule Server:

    $ hammer settings set \
--name remote_execution_prefer_registered_through_proxy \
--value true
Next steps

5.5. Configuring Satellite Server to use an HTTP proxy

Use the following procedures to configure Satellite to use an HTTP proxy.

5.5.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.5.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.5.3. Configuring SELinux to ensure access to Satellite on custom ports

SELinux ensures access of Red Hat Satellite and Subscription Manager only to specific ports. In the case of the HTTP cache, the TCP ports are 8080, 8118, 8123, and 10001 – 10010. If you use a port that does not have SELinux type http_cache_port_t, complete the following steps.

Procedure

  1. On Satellite, to verify the ports that are permitted by SELinux for the HTTP cache, enter a command as follows:

    # semanage port -l | grep http_cache
http_cache_port_t       tcp    8080, 8118, 8123, 10001-10010
[output truncated]

  2. To configure SELinux to permit a port for the HTTP cache, for example 8088, enter a command as follows:

    # semanage port -a -t http_cache_port_t -p tcp 8088

5.5.4. 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.5.5. 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.5.6. 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.5.7. 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.5.8. 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.5.9. 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.6. Enabling power management on hosts

To perform power management tasks on hosts, you must enable the baseboard management controller (BMC) module on Satellite Server.

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:

    # satellite-installer --foreman-proxy-bmc "true"

  2. Optional: Select the IPMI implementation:

    # satellite-installer --foreman-proxy-bmc-default-provider "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.7. Configuring Satellite Server for outgoing emails

To send email messages from Satellite Server, you can use an SMTP server or the sendmail command.

Important

The sendmail command is a deprecated feature. Deprecated functionality is still included in Satellite and continues to be supported. However, it will be removed in a future release of this product and is not recommended for new deployments.

Use an SMTP service instead.

For the most recent list of major functionality that has been deprecated or removed within Satellite, refer to the Deprecated features section of the Satellite release notes.
Prerequisites

  • Some SMTP servers with anti-spam protection or greylisting features are known to cause problems. To set up outgoing email with such a service, install and configure an SMTP service on Satellite Server for relay or use the sendmail command.

Procedure

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

  2. Click the Email tab and set the configuration options to match your preferred delivery method. The changes have an immediate effect.

    1. The following example shows the configuration options for using an SMTP server:

      Table 3. Using an SMTP server as a delivery method
      Name Example value Additional information

      Delivery method

      SMTP

      SMTP address

      smtp.example.com

      SMTP authentication

      login

      SMTP HELO/EHLO domain

      example.com

      SMTP password

      password

      Use the login credentials for the SMTP server.

      SMTP port

      25

      SMTP username

      user@example.com

      Use the login credentials for the SMTP server.

    2. The following example uses gmail.com as an SMTP server:

      Table 4. Using gmail.com as an SMTP server
      Name Example value Additional information

      Delivery method

      SMTP

      SMTP address

      smtp.gmail.com

      SMTP authentication

      plain

      SMTP HELO/EHLO domain

      smtp.gmail.com

      SMTP enable StartTLS auto

      Yes

      SMTP password

      app password

      Use the Google app password. For more information, see Sign in with app passwords in Google Help Center.

      SMTP port

      587

      SMTP username

      user@gmail.com

      Use the Google account name.

    3. The following example uses the sendmail command as a delivery method:

      Table 5. Using sendmail as a delivery method
      Name Example value Additional information

      Delivery method

      Sendmail

      Sendmail location

      /usr/sbin/sendmail

      For security reasons, both Sendmail location and Sendmail argument settings are read-only and can be only set in /etc/foreman/settings.yaml. Both settings currently cannot be set via satellite-installer. For more information see the sendmail 1 man page.

      Sendmail arguments

      -i

  3. To send email by using an SMTP server that uses TLS authentication, also perform one of the following steps:

    • Mark the CA certificate of the SMTP server as trusted. To do so, execute the following commands on Satellite Server:

      # cp mailca.crt /etc/pki/ca-trust/source/anchors/
# update-ca-trust extract

      Where mailca.crt is the CA certificate of the SMTP server.

    • Alternatively, in the Satellite web UI, set the SMTP enable StartTLS auto option to No.

  4. Click Test email to send a test message to the user’s email address to confirm the configuration is working. If a message fails to send, the Satellite web UI displays an error. See the log at /var/log/foreman/production.log for further details.

Additional resources

5.8. 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.8.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. If you have installed Satellite with a default Satellite certificate and want to configure Satellite with an alternate CNAME, generate a new default Satellite SSL certificate with an additional CNAME on Satellite Server:

    # satellite-installer --certs-cname My-Alternate-FQDN.example.com --certs-update-server

  2. If you have not installed Satellite, you can add the --certs-cname My-Alternate-FQDN.example.com option to the satellite-installer command to install Satellite with an alternate CNAME.

  3. 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.8.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 with the bootstrap script, run the bootstrap script with the --server My-Alternate-FQDN.example.com option to register the host to the alternate Satellite CNAME:

    # ./bootstrap.py --server My-Alternate-FQDN.example.com

  • 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.9. 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.9.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 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.9.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, satellite-installer fails to execute while enabling features or upgrading Satellite Server.
Procedure

  • Update certificates on your Satellite Server:

    # satellite-installer \
--certs-server-cert "/root/satellite_cert/satellite_cert.pem" \
--certs-server-key "/root/satellite_cert/satellite_cert_key.pem" \
--certs-server-ca-cert "/root/satellite_cert/ca_cert_bundle.pem" \
--certs-update-server --certs-update-server-ca

    The options used in the command include the following:

    --certs-server-cert

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

    --certs-server-key

    Path to the private key for the Satellite Server certificate.

    --certs-server-ca-cert

    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.

5.9.3. Deploying a custom SSL certificate to hosts

After you configure Satellite to use a custom SSL certificate, you must deploy the certificate to hosts registered to Satellite.

Procedure

  • Update the SSL certificate on each host:

    # dnf install http://satellite.example.com/pub/katello-ca-consumer-latest.noarch.rpm

5.9.4. Deploying a custom SSL certificate to Capsule Servers

If you have Capsule Servers registered to Satellite, configure them with custom SSL certificates.

Procedure

5.10. 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:

    # satellite-installer --certs-reset
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

Appendix A: Restoring manual changes overwritten by a Puppet run

If your manual configuration has been overwritten by a Puppet run, you can restore the files to the previous state.

For example, when you install and configure Satellite for the first time by using satellite-installer, you can use the --foreman-proxy-dns-managed false and --foreman-proxy-dhcp-managed false options to specify that the DNS and DHCP configuration files are not to be managed by Puppet. If you do not use these options during the initial satellite-installer run, rerunning satellite-installer overwrites all manual changes. The following example shows you how to restore a DHCP configuration file overwritten by a Puppet run.

Procedure

  1. Copy the file you intend to restore. This allows you to compare the files to check for any mandatory changes required by the upgrade. This is not common for DNS or DHCP services.

    # cp /etc/dhcp/dhcpd.conf /etc/dhcp/dhcpd.backup

  2. Check the log files to note down the md5sum of the overwritten file. For example:

    # journalctl -xe
...
/Stage[main]/Dhcp/File[/etc/dhcp/dhcpd.conf]: Filebucketed /etc/dhcp/dhcpd.conf to puppet with sum 622d9820b8e764ab124367c68f5fa3a1
...

  3. Restore the overwritten file:

    # puppet filebucket restore --local --bucket \
/var/lib/puppet/clientbucket /etc/dhcp/dhcpd.conf \ 622d9820b8e764ab124367c68f5fa3a1

  4. Compare the backup file and the restored file, and edit the restored file to include any mandatory changes required by the upgrade.