Chapter 2. Preparing your environment for installation

The following requirements apply to the networked base system:

Before you install Satellite Server or Capsule Server, ensure that your environment meets the requirements for installation.

Satellite Server must be installed on a freshly provisioned system that serves no other function except to run Satellite Server.

If you have a large number of content hosts, see Appendix A, Large Deployment Considerations to ensure that your environment is set up appropriately.

For more information on scaling your Capsule Servers, see Appendix B, Capsule Server Scalability Considerations.

Ensure that your environment meets the minimum requirements before installing Satellite Server or Capsule Server.

Packages that are duplicated in different repositories are only stored once on the disk. Additional repositories containing duplicate packages require less additional storage. The bulk of storage resides in the /var/lib/mongodb/ and /var/lib/pulp/ directories. These end points are not manually configurable. Make sure that storage is available on the /var file system to prevent storage issues.

The /var/cache/pulp/ directory is used to temporarily store content while it is being synchronized. For content in RPM format, a maximum of 5 RPM files are stored in this directory at any time. After each file is synchronized, it is moved to the /var/lib/pulp/ directory. Up to eight RPM content synchronization tasks can be running simultaneously by default, with each using up to 1 GB of metadata. For content in ISO format, all ISO files per synchronization task are stored in /var/cache/pulp/ until the task is complete, after which they are moved to the /var/lib/pulp/ directory. For example, if you are synchronizing four ISO files, each 4 GB in size, this requires a total of 16 GB in the /var/cache/pulp/ directory. Take into account the number of ISO files you intend synchronizing because the temporary disk space required for them typically exceeds that of RPM content.

The /var/lib/qpidd/ directory uses slightly more than 2 MB per Content Host managed by the goferd service. For example, 10 000 Content Hosts require 20 GB of disk space in /var/lib/qpidd/.

In the following two tables, the runtime size was measured with Red Hat Enterprise Linux 5, 6, and 7 repositories synchronized.

Log files are written to /var/log/messages/, /var/log/httpd/, and /var/lib/foreman-proxy/openscap/content/. You can manage the size of these files using logrotate. For more information, see Log Rotation in the System Administrator’s Guide.

You can install the operating system from disc, local ISO image, kickstart, or any other method that Red Hat supports. Red Hat Satellite Server and Red Hat Satellite Capsule Server are supported only on the latest versions of Red Hat Enterprise Linux 7 Server that is available at the time when Satellite 6.3 is installed. Previous versions of Red Hat Enterprise Linux including EUS or z-stream are not supported.

Red Hat Satellite Server and Red Hat Satellite Capsule Server require Red Hat Enterprise Linux installations 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.

It is recommended that the Satellite Server be a freshly provisioned system. It is also recommended that Capsule Servers be freshly provisioned systems and not registered to the Red Hat CDN. Using the system for anything other than running Satellite is not supported.

If any of the following exist on the system, they must be removed before installation:

The following web browsers are fully supported:

The following web browsers are partially supported. The Satellite web UI interface functions correctly but certain design elements may not align as expected:

Specific network ports must be open and free on the base operating system, as well as open in any network-based firewalls, to enable the components of Satellite architecture to communicate. The tables in this section explain the need for the ports, and the corresponding firewall commands for host-based firewalls are given in the following section. The installation of a Capsule Server fails if the ports between the Satellite Server and the Capsule Server are not open before installation starts.

The tables indicate the destination port and the direction of network traffic, use this information to configure any network-based firewalls. Note that some cloud solutions need to be specifically configured to allow communications between machines as they isolate machines similarly to network-based firewalls.

Systems which are clients of Capsules, other than Satellite’s integrated Capsule, do not need access to the Satellite Server. For more information on Satellite Topology, see Capsule Networking in the Red Hat Satellite Architecture Guide.

Required ports can change based on your configuration.

Except in the case of a disconnected Satellite, the Satellite Server needs access to the Red Hat CDN. 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.

Any managed host that is directly connected to Satellite Server is a client in this context because it is a client of the integrated Capsule. This includes the base system on which a Capsule Server is running.

Note that the base system on which a Capsule Server is running is a client of the Satellite’s integrated Capsule. See the table Ports for Client to Satellite Communication.

Any managed host that is directly connected to Satellite Server is a client in this context because it is a client of the integrated Capsule. This includes the base system on which a Capsule Server is running.

Capsules and Content Hosts that are clients of a Satellite Server’s internal Capsule require access through Satellite’s host-based firewall and any network-based firewalls.

Use this section to configure the host-based firewall on the Red Hat Enterprise Linux 7 system that Satellite is installed on, to enable incoming connections from Clients, and to make the configuration persistent across system reboots. For more information on the ports used, see Section 2.5, “Ports and Firewalls Requirements”.

Follow this procedure to enable incoming connections from a Capsule Server to a Satellite Server, and make these rules persistent across reboots. If you do not use an external Capsule Server, you do not need to enable this connection.

For more information on the ports used, see Section 2.5, “Ports and Firewalls Requirements”.

You can enable incoming connections from Satellite Server and clients to Capsule Server and make these rules persistent during reboots. If you do not use an external Capsule Server, you do not need to enable this connection.

For more information on the ports used, see Ports and Firewalls Requirements.

You can verify changes to firewall settings using the firewall-cmd command.

# firewall-cmd --list-all

For more information, see Configuring the Firewall Using the firewall-cmd Command-Line Tool in the Red Hat Enterprise Linux 7 Security Guide.

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

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

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

For more information, see the Configuring Host Names Using hostnamectl in the Red Hat Enterprise Linux 7 Networking Guide.

Red Hat Satellite 6 uses a set of predefined ports. Because Red Hat recommends that SELinux on Satellite 6 systems be set to permissive or enforcing, if you need to change the port for any service, you also need to change the associated SELinux port type to allow access to the resources. You only need to change these ports if you use non-standard ports.

For example, if you change the Satellite web UI ports (HTTP/HTTPS) to 8018/8019, you need to add these port numbers to the httpd_port_t SELinux port type.

This change is also required for target ports. For example, when Satellite 6 connects to an external source, like Red Hat Virtualization or Red Hat OpenStack Platform.

You only need to make changes to default port assignments once. Updating or upgrading Satellite has no effect on these assignments. Updating only adds default SELinux ports if no assignments exist.

# semanage port -d -t virt_port_t -p tcp 99999