Red Hat Satellite 6 Administration
Plan a distributed Red Hat Satellite with Satellite Capsule Servers deployment, to meet multiple requirements and scenarios.
Red Hat Satellite is installed in distinct steps, one server component at a time. You usually start with the central Satellite Server installation and initial configuration. You can then install Capsule Servers by using configuration data from the central Satellite Server. You must create organizations on the Satellite Server before importing manifests and repository content. You must estimate the number of managed hosts and content types for each geographic location to determine the number of Capsule Servers to create.
Before you install the central Satellite Server, answer the following questions:
- Is the central Satellite Server intended to be a disconnected installation?
If the Satellite Server is intended to be secure and disconnected (sometimes referred to as air-gapped), then it cannot be connected to the internet or other public networks, and it cannot reach the Red Hat Content Delivery Network (CDN) to obtain content. In this scenario, a second Satellite Server is installed at an internet-connected site to obtain and synchronize CDN content. The connected Satellite Server exports content, which is then validated and securely imported to the disconnected Satellite Server.
- Is a default, dedicated database sufficient for this Red Hat Satellite deployment, or does it require an external database?
A default Satellite Server installation configures a dedicated PostgreSQL database on the same Satellite Server host. Satellite supports use of an external database to distribute the workload and improve response times for database operations. For example, Red Hat recommends use of an external database for the following scenarios:
Many remote execution tasks.
Heavy disk I/O workload from frequent repository synchronization or content view publishing.
Many managed hosts.
High volumes of synchronized content.
- Will the Red Hat Satellite deployment be shared by multiple organizations?
You must create subscription manifests for each organization, which includes entitlement information for the organization's software requirements. Manifest content also includes Satellite Server and Capsule Server subscriptions. Decide whether to enable each organization's Simple Content Access feature before you create the entitlement manifests.
Installing remote or isolated Capsule Servers provides local support for geographically remote locations or for increasing numbers of managed hosts. The plan distributes the Satellite Server and Capsule Servers to best serve each organization's requirements. You can plan different options for Satellite infrastructure design.
The simplest topology is a single Satellite Server, with the default, dedicated Capsule Server. In the following example, hosts in five host groups are registered to Satellite Server. The hosts are grouped into three locations across three organizations. Satellite Server functions are shared among these locations and organizations. All systems are managed through the single Satellite Server instance.
Note
Red Hat recommends that Capsule Servers manage only geographically local hosts due to latency and bandwidth issues. If your host groups and locations are remote, then place an isolated Capsule Server in that remote location.
In a single geographic location, you can add Capsule Servers to scale the workload on Satellite Server. This example topology adds two Capsule Servers that are colocated with the Satellite Server. The workload is distributed among the Capsule Servers to ease the demand on the central Satellite Server with its integrated Capsule Server. New host groups are added in the location and are served by the Capsule Server for that location.
When the locations are geographically remote, install the Capsule Servers in the remote locations. In this example, a Capsule Server services hosts within the remote location. Remote Capsule Servers serve host content more quickly than the Satellite Server, because the communication occurs over a local area network.
In shared environments, Capsule Servers can be dedicated to organizations. In this example, two Capsule Servers are assigned to the same location, but to different organizations. Capsule Servers can also be assigned to multiple organizations in multiple locations. Satellite Server and Capsule Servers can manage any layout of organizations, locations, and host groups.
Red Hat Satellite 6.11 supports both connected and disconnected Satellite Server and Capsule Server. This feature is supported on RHEL 7 and RHEL 8.
In a disconnected environment, whether you choose a deployment with local or remote Capsule Servers, all Satellite Servers and Capsule Servers must be the same version. If the servers do not have a consistent version across the environment, then the content import and content export features do not work.
Red Hat Satellite uses entitlements to provide access to repository content. A manifest might contain multiple subscriptions, to enable access to a collection of repositories. Create a unique manifest for each organization that is configured in Red Hat Satellite. A different Red Hat Customer Portal account might own each manifest, when multiple organizations share the Satellite Server installation. Before you create each organization manifest, consider the following requirements:
Include the Satellite Server subscription in the manifest if you are planning a disconnected Red Hat Satellite installation.
Include subscriptions for all Capsule Servers.
Include subscriptions for all Red Hat products to be managed with Red Hat Satellite.
Consider whether to use Simple Content Access (SCA).
Plan manifest renewals in advance, based on their subscription expiration dates.
Starting in Red Hat Satellite 6.10, you can include future-dated subscriptions in your manifests.
Update an organization's manifest to include additional infrastructure subscriptions. Never delete active manifests for your Satellite installation from the Red Hat Customer Portal, because doing so will unregister the affected hosts.
Red Hat recommends use of the optional Simple Content Access (SCA) feature for managing subscriptions. SCA no longer requires attaching subscriptions to specific hosts. Configuring subscriptions is managed with the organization manifest, so that hosts can access all repositories within the organization.
New manifests that are created at the Red Hat Customer Portal enable SCA by default. An organization administrator can choose to disable SCA. The following list shows some of the benefits of Simple Content Access:
Activation keys are no longer linked to specific subscriptions.
Systems that use auto-attach no longer use up subscriptions that are not required.
It is not needed to attach subscriptions per system.
SCA might be enabled or disabled by organization administrators per organization.
Access is not limited by number of entitlements. Usage might be tracked within Subscription Watch.
If you enable Simple Content Access at the Satellite allocation level, that setting applies to the entire Satellite organization that corresponds to that allocation. However, it is possible within your account (also known as your Red Hat Customer Portal organization) to have a mixed environment where some Satellite organizations are enabled for Simple Content Access and some are not, according to your business needs.
By default, Red Hat Satellite uses the Red Hat Content Delivery Network (CDN), at https://cdn.redhat.com, to obtain content from Red Hat repositories. The CDN is geographically distributed, and provides the latest available updates for Red Hat products.
To configure a disconnected Red Hat Satellite that does not have access to the Red Hat CDN, use a connected Satellite Server with CDN access to export the required content to import to the disconnected Satellite Server.
Note
The download of content ISOs from the Red Hat Customer Portal is now deprecated and no longer supported. This feature will be removed in a future version. Red Hat recommends to use Inter-Server Synchronization (ISS) to synchronize content between a connected Satellite Server and a disconnected Satellite Server.
In this setup, you download ISO images with content from the Red Hat Customer Portal and extract them to Satellite Server or to a local web server. The content on Satellite Server is then synchronized locally. When you synchronize locally, it allows for complete network isolation of the Satellite Server. However, the release frequency of content ISO images is approximately six weeks, and they do not include all product content. To see the products in your subscription for which content ISO images are available, follow these steps:
Log in to the Red Hat Customer Portal at https://access.redhat.com. In the upper left of the window, click , select , and click the tab. This page lists the available products in your subscription.
Click the link for the product name, such as , to download the ISO image.
Copy all the Satellite Content ISO images to a system that you want to use as a local content server.
For example, copy to the /root/isos directory on Satellite Server.
Content does not need to be stored on the same host as where Satellite is installed.
The content can be hosted on another system inside the disconnected network that is accessible to Satellite Server.
On the content server host, create a local directory that is accessible over the httpd service.
For example, create a content directory, mount the ISO to a temporary directory, and copy the content to the new directory.
[root@satellite ~]#mkdir -p /var/www/html/pub/sat-import/[root@satellite ~]#mkdir /mnt/iso[root@satellite ~]#mount -o loop /root/isos/first_iso /mnt/iso[root@satellite ~]#cp -ruv /mnt/iso/ /var/www/html/pub/sat-import/[root@satellite ~]#umount /mnt/iso[root@satellite ~]#rmdir /mnt/iso
If the ISO content spans multiple images, then repeat the task for each ISO image, and copy the additional content to the same content directory. Ensure that the SELinux context for the directory is correct:
[root@satellite ~]# restorecon -rv /var/www/html/pub/sat-import/In the Satellite web UI, navigate to → and click . Edit the field to the name of your local content server host with the new content directory. For the previous example, you would enter the following URL, and then click .
Import From a Downloaded Content ISO:
http://server.example.com/pub/sat-import/
With this method, you install an additional, connected Satellite Server to export content to populate a disconnected Satellite Server. This method can export both Red Hat and custom content at your chosen frequency, and requires deploying a second, connected Satellite Server.
To export by using a Content View, which is discussed in a later chapter, ensure that the exporting Satellite Server meets the following conditions:
The export directory has free storage space to accommodate the export.
The
/var/lib/pulp/directory has equivalent free storage space to the size of the exported repository, for temporary created files during the export process.The
/var/cache/pulpdirectory has equivalent free storage space to twice the size of the exported repository, for temporary created files during the export process.Set the download policy to Immediate for all repositories within the Content View that you export.
Select the checkbox for the repositories that you import, on the repository settings page.
Synchronize the products to export to the required date.
You can control the amount of content to export by creating a Content View with filters that specify the chosen packages. This task can be accomplished in the web UI, but is more efficient from the command line, especially when frequently exporting to keep the disconnected Satellite Server current with the latest Red Hat content.
List the Content Views to determine the ID of a Content View version to export:
[root@satellite ~]# hammer content-view version list \
--organization "Default Organization"Use the --export-dir option to specify the storage directory, and the --id option to specify the Content View version ID to export.
The pulp_export_destination setting does not work for this procedure.
Verify that the Content View version archive is in the export directory.
[root@satellite ~]#hammer content-view version export \ --export-dir export_directory --id content_view_version_ID[root@satellite ~]#ls export_directoryexport-1.tar
Transfer the archive to the disconnected Satellite Server, after verifying the security of the archive. Unpack the archive file in the disconnected Satellite Server's content directory, where it is ready to be imported.
To ensure a successful Satellite Server installation, and to maintain adequate performance as the managed environment grows and workloads increase, you must meet or exceed the hardware and software requirements. Administrators should comprehend how Satellite Server repository content is managed and stored to accurately estimate initial space requirements and to forecast future growth.
The Satellite Server system must be a freshly provisioned system that is dedicated to hosting Satellite Server. No other applications or services should compete for system resources or degrade the Satellite Server performance.
Red Hat Satellite is supported for installation on both physical systems and virtual machines. The hypervisor that runs the virtual machine must be supported to run Red Hat Enterprise Linux.
The Red Hat Satellite 6 host must meet the following minimum specifications:
x86_64 CPU architecture.
Minimum of four 2.0 GHz CPU cores.
Minimum of 20 GB of physical memory, and a minimum of 4 GB of swap space.
Red Hat Satellite 6.11 is supported on the latest version of RHEL 8 and RHEL 7.
This course focuses on a Satellite Server that runs on RHEL 8.
When installing RHEL from an ISO image, use the default base installation and do not add packages.
If you install with the kickstart method, then install only the @Base package group.
To perform software deployment, configuration management, and provisioning, Satellite Server requires the following traffic to be allowed:
| Port | Protocol | Service |
|---|---|---|
| 7 | UDP/TCP | echo |
| 53 | UDP/TCP | DNS |
| 67 | UDP | DHCP |
| 68 | UDP | DHCP |
| 69 | UDP | TFTP |
| 80 | TCP | HTTP |
| 443 | TCP | HTTPS |
| 5646 | TCP | qpid/Katello |
| 5671 | TCP | amqp |
| 8000 | TCP | Anaconda |
| 8140 | TCP | Puppet |
| 9090 | TCP | Foreman Smart Proxy |
SectionFigure 1.8: Satellite Server network topology with an isolated Capsule Server shows the ports and network connections between the Satellite Server, an isolated Capsule Server, and a remote managed host in the Capsule Server's location.
Use the firewall-cmd command to configure access to these network ports.
The --runtime-to-permanent option saves all currently opened ports to the firewalld configuration that is loaded each time the firewall is started.
Red Hat does not recommend using this option on systems with applications that dynamically open ports during runtime, because dynamic ports should not be added to a static firewall configuration.
The option is useful for this installation scenario, because Satellite and Capsule server instances are always installed on dedicated and clean RHEL base systems that are not serving other applications.
You can configure the ports with the following command:
[root@satellite ~]#firewall-cmd \ --add-port="7/udp" --add-port="7/tcp" \ --add-port="53/udp" --add-port="53/tcp" \ --add-port="67/udp" --add-port="68/udp" \ --add-port="69/udp" --add-port="80/tcp" \ --add-port="443/tcp" --add-port="5646/tcp" \ --add-port="5671/tcp" --add-port="8000/tcp" \ --add-port="8140/tcp" --add-port="9090/tcp"success [root@satellite ~]#firewall-cmd --runtime-to-permanentsuccess
On a Red Hat Satellite 6 host, the SELinux permissions must be set to enforcing.
This SELinux mode is a requirement for Red Hat support, and is the default SELinux status for Red Hat Enterprise Linux 7 and later installations.
[root@satellite ~]# getenforce
EnforcingTo ensure accurate time on the Red Hat Satellite 6 host, Red Hat recommends that chronyd is installed and enabled on all RHEL hosts.
[root@satellite ~]#systemctl status chronyd● chronyd.service - NTP client/server Loaded: loaded (/usr/lib/systemd/system/chronyd.service;enabled; vendor preset: enabled) Active:active(running) since Thu 2022-02-17 09:36:34 EST; 5h 26min ago ...output omitted...
The Satellite Server host requires a minimum of 6 GB of storage for the base operating system. In addition, the host requires the following storage space for Satellite Server components and content:
Minimum of 2 GB for Red Hat Satellite 6 software installation for disconnected installations.
Minimum of 100 MB during installation and 20 GB at runtime for
/var/lib/pgsql, which contains the Satellite Server PostgreSQL database.Minimum of 1 MB during installation and 300 GB at runtime for
/var/lib/pulp, which stores Satellite Server synchronized content.Minimum of 25 MB in
/var/lib/qpiddfor each content host to be registered with Satellite Server.
Identical packages that exist in multiple repositories are stored only once in Satellite. New repositories that contain packages from existing repositories use less disk space.
Because most data storage on Satellite Server resides under the /var directory, Red Hat highly recommends that /var is allocated as a separate partition on LVM storage.
With this configuration, you can allocate more storage as the size of the /var directory space increases.
Most software repository storage resides under the /var/lib/pulp directory.
Because of the large I/O for many content management operations, Red Hat recommends that this directory resides on high-bandwidth, low-latency storage, such as on solid-state drives (SSD).
The Pulp3 Content Management component no longer uses the MongoDB database, because MongoDB discontinued its open-source distribution.
The Pulp3 Content Management component uses the PostgreSQL database.
Upgrading Red Hat Satellite to 6.10 or later from previous Red Hat Satellite versions requires a database migration from MongoDB to PostgreSQL.
The listed space requirements here apply only to a fresh installation.
On the host operating system, administrators require root privilege to run the Satellite installation program.
The installation requires forward and reverse DNS resolution of the Satellite host's fully qualified domain name.
Verify that the system's localhost, short hostname, and Fully Qualified Domain Name (FQDN) resolve properly to IP addresses.
Use the hostname command -s and -f options to obtain the short and FQDN hostnames.
[root@satellite ~]#ping -c1 localhostPING localhost (127.0.0.1) 56(84) bytes of data. 64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64 time=1 ms --- localhost ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 0.042/0.042/0.042/0.000 ms [root@satellite ~]#ping -c1 $(hostname -s)PING satellite.example.com (172.25.250.16) 56(84) bytes of data. 64 bytes from satellite.example.com (172.25.250.16): icmp_seq=1 ttl=64 time=1 ms --- satellite.example.com ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 0.067/0.067/0.067/0.000 ms [root@satellite ~]#ping -c1 $(hostname -f)PING satellite.example.com (172.25.250.16) 56(84) bytes of data. 64 bytes from satellite.example.com (172.25.250.16): icmp_seq=1 ttl=64 time=1 ms --- satellite.example.com ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 0.053/0.053/0.053/0.000 ms
Verify the reverse DNS resolution for the Satellite host's IPv4 address.
[root@satellite ~]# dig -x 172.25.250.16
...output omitted...
;; ANSWER SECTION:
16.250.25.172.in-addr.arpa. 3600 IN PTR satellite.example.com.
...output omitted...References
For more information, refer to the Satellite Deployment Planning chapter in the Planning Satellite Deployment guide at https://access.redhat.com/documentation/en-us/red_hat_satellite/6.11/html-single/satellite_overview_concepts_and_deployment_considerations/index#part-Deployment_Planning
For more information, refer to the Red Hat Satellite 6 Performance Tuning solution at https://access.redhat.com/solutions/1257143
