Red Hat Summit Red Hat SummitSupportConsoleDevelopersStart a trialContact

Chapter 2. Satellite deployment planning

2.1. Deployment path for Red Hat Satellite
Copy link

During installation and initial configuration of Satellite, you can customize your deployment to fit your specific needs and operational environment. By customizing each stage of the deployment process, you can choose deployment options that meet the requirements of your organization.

2.1.1. Installing a Satellite Server
Copy link

Installing an instance of Satellite Server on a dedicated server is the first step to a working Satellite infrastructure. You can install a Satellite Server in a connected or disconnected setup:

  • Connected deployment is suitable for networked environments where your Satellite Server is connected to the Red Hat CDN.
  • Disconnected deployment is suitable for high-security environments where direct Internet access is restricted or prohibited.

A disconnected Satellite Server is isolated from Red Hat CDN but you can still provision systems with the latest security updates, errata, packages, and other content. You can use the following methods to import content to a disconnected Satellite Server:

Content ISO

In this setup, you download ISO images with content from the Red Hat Customer Portal and extract them to Satellite Server or a local web server. The content on Satellite Server is then synchronized locally.

This allows for complete network isolation of Satellite Server, however, the release frequency of content ISO images is around six weeks and not all product content is included.

Disconnected Satellite with Inter-Satellite Synchronization

In this setup, you install a connected Satellite Server and export content from it to populate a disconnected Satellite using a storage device.

This allows for exporting both Red Hat provided and custom content at the frequency you choose, but requires deploying an additional server with a separate subscription.

Additional resources

Running the satellite-installer command, used to install a Satellite Server, also installs PostgreSQL databases on the server. However, you can configure your Satellite Server to use external databases instead. Moving to external databases distributes the workload and can reduce overall Satellite memory usage.

Note

Red Hat does not provide support or tools for external database maintenance. If you deploy Satellite with external databases, you will need to support and maintain the external databases yourself.

Consider using external databases if you plan to use your Satellite deployment for the following scenarios:

  • Frequent remote execution tasks. This requires a high volume of records in PostgreSQL and generates heavy database workloads.
  • High disk I/O workloads from frequent repository synchronization or content view publishing. This requires Satellite to create a record in PostgreSQL for each job.
  • High volume of hosts.
  • High volume of synchronized content.

Additional resources

2.1.2. Scenarios for Satellite on AWS
Copy link

You can deploy Satellite on Amazon Web Services (AWS) in several scenarios.

One-region setup

This is the least complex configuration of Satellite in AWS. Deploy both Satellite Server and the hosts residing within the same region and within the Virtual Private Cloud (VPC) You can also use a different availability zone.

One-region setup
View larger image
One-region setup

Connecting on-premises and AWS region

Create a VPN connection between the on-premises location and the AWS region where your Capsule Server is located. It is also possible to use the external host name of Satellite Server when you register the instance that runs Capsule.

Site-to-site VPN connection between the AWS region and the on-premises data center

Site-to-site VPN connection between the AWS region and the on-premises data center
View larger image
Site-to-site VPN connection between the AWS region and the on-premises data center

Direct connection using the external DNS host name

Direct connection using the external DNS host name
View larger image
Direct connection using the external DNS host name

Connecting different regions

Create a site-to-site VPN connection between different regions so that you can use the internal DNS host name when you register the instance that runs Capsule to Satellite Server. If you do not establish a site-to-site VPN connection, use the external DNS host name when you register the instance that runs Capsule to Satellite Server.

Note

Most public cloud providers do not charge for data being transferred into a region or between availability zones within a single region. However, they charge for data leaving the region to the Internet.

Site-to-site VPN connection between AWS regions

Site-to-site VPN connection between AWS regions
View larger image
Site-to-site VPN connection between AWS regions

Direct connection using the external DNS host name

Direct connection using the external DNS host name
View larger image
Direct connection using the external DNS host name

Red Hat Satellite includes native support for authentication with a username and password. If you require additional methods of authentication, configure your Satellite Server to use an external authentication source.

Expand
Table 2.1. External authentication sources supported by Satellite and the authentication features they provide
 Username and passwordSingle sign-on (SSO)One-time password (OTP)Time-based one-time password (TOTP)

Active Directory (direct integration)

Yes

Yes

No

No

Identity Management

Yes (Linux and Active Directory users)

Yes (Linux users only)

No

No

Red Hat Single Sign-On

Yes

Yes

Yes

Yes

LDAP

Yes

No

No

No

Additional resources

2.1.4. Planning organization and location context
Copy link

Context in Satellite consists of organizations and locations. You can associate most resources, for example hosts, subnets, and domains, with at least one organization and location context.

Resources and users can generally only access resources within their own context, which makes configuring organizations and locations an integral part of access management in Satellite.

Important

If you use host groups to bundle provisioning and configuration information, avoid mismatching resources from mutually exclusive contexts. For example, setting a subnet from one organization or location and a compute resource from a different organization or location creates an invalid host group.

Additional resources

2.1.5. Installing Capsule Servers
Copy link

By installing Capsule Servers, you extend the reach and scalability of your Satellite deployment. Setting up a Capsule Server registers the base operating system on which you are installing to Satellite Server and configures the new Capsule Server to provide the required services within your Satellite deployment.

You can install a Capsule Server in each of your geographic locations. By assigning a Capsule to each location, you decrease the load on Satellite Server, increase redundancy, and reduce bandwidth usage.

Note

The maximum number of Capsule Servers that Satellite Server can support has no fixed limit. It was tested that a Satellite Server can support 17 Capsule Servers with 2 vCPUs.

Decide what services you want to enable on each Capsule Server. You can configure the DNS, DHCP, and TFTP services on one of your Capsule Servers or you can use an external server to provide these services to your Capsule Servers.

Additional resources

  • For information on installing Capsule Servers, including prerequisites and configuring external services, see Installing Capsule Server.
  • For information on tuning performance by using Capsules, see Capsule configuration tuning in Tuning performance of Red Hat Satellite.

2.1.6. Adding a Red Hat subscription to Satellite
Copy link

A Red Hat subscription manifest is a set of encrypted files that contains your subscription information. Satellite Server uses this information to access the Red Hat CDN and find what repositories are available for the associated subscription.

Warning

Deleting a subscription manifest removes all the subscriptions attached to running hosts and activation keys.

Additional resources

2.1.7. Defining your content library
Copy link

To ensure that your Satellite Server can manage software and provide it to your hosts, you must create repositories and synchronize them.

Red Hat content

The Red Hat subscription manifest determines what Red Hat repositories your Satellite Server can access. Red Hat content is already organized into products.

For example, Red Hat Enterprise Linux Server is a product in Satellite. The repositories for the Red Hat Enterprise Linux Server product consist of different versions, architectures, and add-ons. When you enable a Red Hat repository, Satellite automatically creates an associated product.

Other sources of content

To distribute content from custom sources, you must create products and repositories manually. You can organize other content into custom products however you want.

For example, you can create an EPEL (Extra Packages for Enterprise Linux) product and add an "EPEL 9 x86_64" repository to it.

Creating repositories allows you to choose the specific software required for your environment. By creating only the necessary repositories, you avoid downloading unnecessary content.

Synchronizing repositories downloads the content from Red Hat CDN or another source to your Satellite Server. The synchronized content is stored on your Satellite Server, eliminating the need for hosts to access the repositories. You can synchronize repositories manually, or you can create a sync plan to ensure synchronization runs on a regular basis.

Additional resources

  • For more information, including procedures for enabling and synchronizing repositories, see Importing custom content in Managing content.

When defining your content lifecycle in Satellite, you can use content views and lifecycle environments to define which hosts can access which content and content versions. By default, Satellite includes the Default Organization View content view and the Library lifecycle environment.

Default Organization View
The Default Organization View is the default content view in Satellite that contains all the content that is synchronized to Satellite. After you update your content, such as by adding or removing a repository, the update is immediately reflected in Default Organization View.
Library
The Library lifecycle environment is the default lifecycle environment in Satellite. Every newly published content view version is automatically published to the Library lifecycle environment. You can also promote specific content view versions to the Library lifecycle environment if needed.

In smaller deployments or when you do not require content versioning and environment promotion, you can associate a host to the Library environment under the Default Organization View without configuring additional lifecycle environments.

Additional resources

2.1.9. Defining role-based access control policies
Copy link

Users in Satellite can have one or more roles assigned. These roles are associated with permissions that enable users to perform specified administrative actions in Satellite. Permission filters define the actions allowed for a certain resource type.

Satellite provides a set of predefined roles with permissions sufficient for standard tasks. You can also configure custom roles.

Note

One of the predefined roles is the Default role. Satellite assigns the Default role to every user in the system. By default, the Default role grants only a limited set of permissions. Be aware that if you add a permission to the Default role, every Satellite users will gain that permission. Assigning a different role to a user does not remove the Default role from the user.

The following types of roles are commonly defined within various Satellite deployments:

Roles related to applications or parts of infrastructure
For example, roles for owners of Red Hat Enterprise Linux as the operating system as opposed to roles for owners of application servers and database servers.
Roles related to a particular stage of the software lifecycle
For example, roles divided among the development, testing, and production phases, where each phase has one or more owners.
Roles related to specific tasks
For example, you can create a role for security managers and a role for license managers, depending on the specific tasks users need to be able to perform within your organization.

Additional resources

  • For more information, including details about creating custom roles and granting permissions to roles, see Managing users and roles in Administering Red Hat Satellite.
  • Define the expected tasks and responsibilities: Define the subset of the Satellite infrastructure that you want the role to access as well as actions permitted on this subset. Think of the responsibilities of the role and how it differs from other roles.
  • Use predefined roles whenever possible: Satellite provides several sample roles that you can use. Copying and editing an existing role can be a good start for creating a custom role.
  • Adopt a granular approach to user role management: Define roles with specific and well-scoped permissions. Note that each user can have multiple roles assigned and that permissions from these roles are cumulative.
  • Add permissions gradually and test the results: When creating a custom role, start with a limited set of permissions and add permissions one by one, while testing continuously. Ensure to test your custom role to verify that it works as intended.
  • Consider areas of interest and granting read-only access: Even though a role has a limited area of responsibility, it might need a wider set of permissions. Therefore, you can grant the role a read-only access to parts of Satellite infrastructure that influence its area of responsibility.

2.1.10. Configuring provisioning
Copy link

After your basic Satellite infrastructure is in place, you can start configuring provisioning to ensure that Satellite can seamlessly create, configure, and manage hosts.

The process depends on whether you want to provision bare-metal hosts, virtual machines, or cloud instances, but it includes defining installation media, configuring provisioning templates, and other tasks. If you are provisioning virtual machines or cloud instances, you must also integrate your compute provider with Satellite by connecting the provider as a compute resource to Satellite.

The following Satellite features support automating the provisioning of your hosts:

  • Provisioning templates enable you to define the way Satellite installs an operating system on your hosts.
  • The Discovery service enables you to detect unknown hosts and virtual machines on the provisioning network.
  • Host groups enable you to standardize provisioning of host configurations.

Additional resources

2.1.12. Additional deployment tasks
Copy link

Satellite offers a range of additional capabilities that you can use to further enhance your Satellite deployment. For example:

Remote execution commands on hosts

With remote execution, you can perform various tasks on multiple hosts simultaneously. Satellite supports the following modes of transport for remote execution: pull-based mode (over MQTT/HTTPS) and push-based mode (over SSH).

For more information, see Configuring and setting up remote jobs in Managing hosts.

Automating tasks with a configuration management tool

By integrating Satellite with a configuration management tool, you can automate repetitive tasks and ensure consistent configuration of your hosts.

For more information on using Ansible with Satellite, see Managing configurations by using Ansible integration.

For more information on using Puppet with Satellite, see Managing configurations by using Puppet integration.

Security management with OpenSCAP

With OpenSCAP, you can manage compliance policies and run security compliance scans on your hosts. After the scan completes, a compliance report is uploaded to your Satellite Server.

For more information, see Managing security compliance.

Load balancing

With load balancing configured on your Capsule Servers, you can improve performance on Capsule Servers while also improving performance and stability for host connections to Satellite.

For more information, see Configuring Capsules with a load balancer.

Incident management with Red Hat Insights

With Red Hat Insights enabled on your Satellite Server, you can identify key risks to stability, security, and performance.

For more information, see Using Red Hat Insights with Satellite Server in Installing Satellite Server in a connected network environment.

2.2. Common deployment scenarios
Copy link

This section provides a brief overview of common deployment scenarios for Red Hat Satellite. Note that many variations and combinations of the following layouts are possible.

2.2.1. Single location with segregated subnets
Copy link

Your infrastructure might require multiple isolated subnets even if Red Hat Satellite is deployed in a single geographic location. This can be achieved for example by deploying multiple Capsule Servers with DHCP and DNS services, but the recommended way is to create segregated subnets using a single Capsule. This Capsule is then used to manage hosts and compute resources in those segregated networks to ensure they only have to access the Capsule for provisioning, configuration, errata, and general management. For more information on configuring subnets, see Managing hosts.

2.2.2. Multiple locations
Copy link

Red Hat recommends to create at least one Capsule Server per geographic location. This practice can save bandwidth since hosts obtain content from a local Capsule Server. Synchronization of content from remote repositories is done only by the Capsule, not by each host in a location. In addition, this layout makes the provisioning infrastructure more reliable and easier to configure.

Content Flow in Red Hat Satellite
View larger image
Content Flow in Red Hat Satellite

2.2.3. Content view scenarios
Copy link

The following section provides general scenarios for deploying content views as well as lifecycle environments.

The default lifecycle environment called Library gathers content from all connected sources. It is not recommended to associate hosts directly with the Library as it prevents any testing of content before making it available to hosts. Instead, create a lifecycle environment path that suits your content workflow. The following scenarios are common:

  • A single lifecycle environment – content from Library is promoted directly to the production stage. This approach limits the complexity but still allows for testing the content within the Library before making it available to hosts.

    A single lifecycle environment
    View larger image
    A single lifecycle environment

  • A single lifecycle environment path – both operating system and applications content is promoted through the same path. The path can consist of several stages (for example Development, QA, Production), which enables thorough testing but requires additional effort.

    A single lifecycle environment path
    View larger image
    A single lifecycle environment path

  • Application specific lifecycle environment paths – each application has a separate path, which allows for individual application release cycles. You can associate specific compute resources with application lifecycle stages to facilitate testing. On the other hand, this scenario increases the maintenance complexity.

    Application specific lifecycle environment paths
    View larger image
    Application specific lifecycle environment paths

The following content view scenarios are common:

  • All in one content view – a content view that contains all necessary content for the majority of your hosts. Reducing the number of content views is an advantage in deployments with constrained resources (time, storage space) or with uniform host types. However, this scenario limits the content view capabilities such as time based snapshots or intelligent filtering. Any change in content sources affects a proportion of hosts.
  • Host specific content view – a dedicated content view for each host type. This approach can be useful in deployments with a small number of host types (up to 30). However, it prevents sharing content across host types as well as separation based on criteria other than the host type (for example between operating system and applications). With critical updates every content view has to be updated, which increases maintenance efforts.
  • Host specific composite content view – a dedicated combination of content views for each host type. This approach enables separating host specific and shared content, for example you can have dedicated content views for the operating system and application content. By using a composite, you can manage your operating system and applications separately and at different frequencies.
  • Component based content view – a dedicated content view for a specific application. For example a database content view can be included into several composite content views. This approach allows for greater standardization but it leads to an increased number of content views.

The optimal solution depends on the nature of your host environment. Avoid creating a large number of content views, but keep in mind that the size of a content view affects the speed of related operations (publishing, promoting). Also make sure that when creating a subset of packages for the content view, all dependencies are included as well. Note that Kickstart repositories should not be added to content views, as they are used for host provisioning only.

2.2.4. Satellite Server with multiple manifests
Copy link

If you plan to have more than one Red Hat Network account, or if you want to manage systems belonging to another entity that is also a Red Hat Network account holder, then you and the other account holder can assign subscriptions, as required, to manifests. A customer that does not have a Satellite subscription can create a Subscription Asset Manager manifest, which can be used with Satellite, if they have other valid subscriptions. You can then use the multiple manifests in one Satellite Server to manage multiple organizations.

If you must manage systems but do not have access to the subscriptions for the RPMs, you must use Red Hat Enterprise Linux Satellite Add-On. For more information, see Satellite Add-On.

The following diagram shows two Red Hat Network account holders, who want their systems to be managed by the same Satellite installation. In this scenario, Example Corporation 1 can allocate any subset of their 60 subscriptions, in this example they have allocated 30, to a manifest. This can be imported into the Satellite as a distinct Organization. This allows system administrators the ability to manage Example Corporation 1’s systems using Satellite completely independently of Example Corporation 2’s organizations (R&D, Operations, and Engineering).

Figure 2.1. Satellite Server with multiple manifests

Satellite Server with multiple manifests
View larger image
Satellite Server with multiple manifests

When creating a Red Hat subscription manifest:

  • Add the subscription for Satellite Server to the manifest if planning a disconnected or self-registered Satellite Server. This is not necessary for a connected Satellite Server that is subscribed using the Subscription Manager utility on the base system.
  • Add subscriptions for all Capsule Servers you want to create.
  • Add subscriptions for all Red Hat products you want to manage with Satellite.
  • Note the date when the subscriptions are due to expire and plan for their renewal before the expiry date.
  • Create one manifest per organization. You can use multiple manifests and they can be from different Red Hat subscriptions.

Red Hat Satellite allows the use of future-dated subscriptions in the manifest. This enables uninterrupted access to repositories when future-dated subscriptions are added to a manifest before the expiry date of existing subscriptions.

Note that the Red Hat subscription manifest can be modified and reloaded to Satellite Server in case of any changes in your infrastructure, or when adding more subscriptions. Manifests should not be deleted. If you delete the manifest from the Red Hat Customer Portal or in the Satellite web UI it will unregister all of your content hosts.

2.2.5. Host group structures
Copy link

The fact that host groups can be nested to inherit parameters from each other allows for designing host group hierarchies that fit particular workflows. A well planned host group structure can help to simplify the maintenance of host settings. This section outlines four approaches to organizing host groups.

Figure 2.2. Host group structuring examples

Host group structuring examples
View larger image
Host group structuring examples
Flat structure
The advantage of a flat structure is limited complexity, as inheritance is avoided. In a deployment with few host types, this scenario is the best option. However, without inheritance there is a risk of high duplication of settings between host groups.
Lifecycle environment based structure
In this hierarchy, the first host group level is reserved for parameters specific to a lifecycle environment. The second level contains operating system related definitions, and the third level contains application specific settings. Such structure is useful in scenarios where responsibilities are divided among lifecycle environments (for example, a dedicated owner for the Development, QA, and Production lifecycle stages).
Application based structure
This hierarchy is based on roles of hosts in a specific application. For example, it enables defining network settings for groups of back-end and front-end servers. The selected characteristics of hosts are segregated, which supports Puppet-focused management of complex configurations. However, the content views can only be assigned to host groups at the bottom level of this hierarchy.
Location based structure
In this hierarchy, the distribution of locations is aligned with the host group structure. In a scenario where the location (Capsule Server) topology determines many other attributes, this approach is the best option. On the other hand, this structure complicates sharing parameters across locations, therefore in complex environments with a large number of applications, the number of host group changes required for each configuration change increases significantly.

2.2.6. Inter-Satellite Synchronization scenarios
Copy link

Red Hat Satellite uses Inter-Satellite Synchronization (ISS) to synchronize content between two Satellite Servers including those that are air gapped.

You can use ISS in cases such as:

  • If you want to copy some but not all content from your Satellite Server to other Satellite Servers. For example, you have content views that your IT department consumes from Satellite Server, and you want to copy content from those content views to other Satellite Servers.
  • If you want to copy all Library content from your Satellite Server to other Satellite Servers. For example, you have products and repositories that your IT department consumes from Satellite Server in the Library, and you want to copy all products and repositories in that organization to other Satellite Servers.
Note

You cannot use ISS to synchronize content from Satellite Server to Capsule Server. Capsule Server supports synchronization natively. For more information, see Capsule Server Overview in Overview, concepts, and deployment considerations.

There are different ways of using ISS. The way you can use depends on your multi-server setup that can fall to one of the following scenarios.

In a disconnected scenario, there is the following setup:

  • The upstream Satellite Server is connected to the Internet. This server consumes content from the Red Hat Content Delivery Network (CDN) or custom sources.
  • The downstream Satellite Server is completely isolated from all external networks.
  • The downstream Satellite Server can communicate with a connected upstream Satellite Server over an internal network.

Figure 2.3. Satellite ISS disconnected scenario

Satellite ISS disconnected scenario
View larger image
Satellite ISS disconnected scenario

You can configure your downstream Satellite Server to synchronize content from the upstream Satellite Server over the network.

2.2.6.2. ISS export sync in an air-gapped scenario
Copy link

In an air-gapped scenario, there is the following setup:

  • The upstream Satellite Server is connected to the Internet. This server consumes content from the Red Hat CDN or custom sources.
  • The downstream Satellite Server is completely isolated from all external networks.
  • The downstream Satellite Server does not have a network connection to a connected upstream Satellite Server.

Figure 2.4. Satellite ISS air-gapped scenario

Satellite ISS air-gapped scenario
View larger image
Satellite ISS air-gapped scenario

The only way for an air-gapped downstream Satellite Server to receive content updates is by exporting payload from the upstream Satellite Server, bringing it physically to the downstream Satellite Server, and importing the payload. For more information, see Synchronizing Content Between Satellite Servers in Managing content.

You can configure your downstream Satellite Server to synchronize content by using exports.

2.3. Provisioning requirements
Copy link

An important feature of Red Hat Satellite is unattended provisioning of hosts. To achieve this, Red Hat Satellite uses DNS and DHCP infrastructures, PXE booting, TFTP, and Kickstart. Use this chapter to understand the working principle of these concepts.

2.3.1. PXE booting
Copy link

Preboot execution environment (PXE) provides the ability to boot a system over a network. Instead of using local hard drives or a CD-ROM, PXE uses DHCP to provide host with standard information about the network, to discover a TFTP server, and to download a boot image. For more information about setting up a PXE server see the Red Hat Knowledgebase solution How to set-up/configure a PXE Server.

2.3.1.1. PXE sequence
Copy link

  1. The host boots the PXE image if no other bootable image is found.
  2. A NIC of the host sends a broadcast request to the DHCP server.
  3. The DHCP server receives the request and sends standard information about the network: IP address, subnet mask, gateway, DNS, the location of a TFTP server, and a boot image.
  4. The host obtains the boot loader image/pxelinux.0 and the configuration file pxelinux.cfg/00:MA:CA:AD:D from the TFTP server.
  5. The host configuration specifies the location of a kernel image, initrd and Kickstart.
  6. The host downloads the files and installs the image.

For an example of using PXE Booting by Satellite Server, see Provisioning Workflow in Provisioning hosts.

2.3.1.2. PXE booting requirements
Copy link

To provision machines using PXE booting, ensure that you meet the following requirements:

Network requirements

  • Optional: If the host and the DHCP server are separated by a router, configure the DHCP relay agent and point to the DHCP server.

Client requirements

  • Ensure that all the network-based firewalls are configured to allow clients on the subnet to access the Capsule. For more information, see Section 1.3.6, “Capsule networking”.
  • Ensure that your client has access to the DHCP and TFTP servers.

Satellite requirements

  • Ensure that both Satellite Server and Capsule have DNS configured and are able to resolve provisioned host names.
  • Ensure that the UDP ports 67 and 68 are accessible by the client to enable the client to receive a DHCP offer with the boot options.
  • Ensure that the UDP port 69 is accessible by the client so that the client can access the TFTP server on the Capsule.
  • Ensure that the TCP port 80 is accessible by the client to allow the client to download files and Kickstart templates from the Capsule.
  • Ensure that the host provisioning interface subnet has a DHCP Capsule set.
  • Ensure that the host provisioning interface subnet has a TFTP Capsule set.
  • Ensure that the host provisioning interface subnet has a Templates Capsule set.
  • Ensure that DHCP with the correct subnet is enabled using the Satellite installer.
  • Enable TFTP using the Satellite installer.

2.3.2. HTTP booting
Copy link

You can use HTTP booting to boot systems over a network using HTTP.

To provision machines through HTTP booting ensure that you meet the following requirements:

Client requirements

For HTTP booting to work, ensure that your environment has the following client-side configurations:

  • All the network-based firewalls are configured to allow clients on the subnet to access the Capsule. For more information, see Section 1.3.6, “Capsule networking”.
  • Your client has access to the DHCP and DNS servers.
  • Your client has access to the HTTP UEFI Boot Capsule.

Network requirements

  • Optional: If the host and the DHCP server are separated by a router, configure the DHCP relay agent and point to the DHCP server.

Satellite requirements

Although TFTP protocol is not used for HTTP UEFI Booting, Satellite uses TFTP Capsule API to deploy boot loader configuration.

For HTTP booting to work, ensure that Satellite has the following configurations:

  • Both Satellite Server and Capsule have DNS configured and are able to resolve provisioned host names.
  • The UDP ports 67 and 68 are accessible by the client so that the client can send and receive a DHCP request and offer.
  • Ensure that the TCP port 8000 is open for the client to download the boot loader and Kickstart templates from the Capsule.
  • The TCP port 9090 is open for the client to download the boot loader from the Capsule using the HTTPS protocol.
  • The subnet that functions as the host’s provisioning interface has a DHCP Capsule, an HTTP Boot Capsule, a TFTP Capsule, and a Templates Capsule

To provision machines through HTTP booting without managed DHCP ensure that you meet the following requirements:

Client requirements

  • HTTP UEFI Boot URL must be set to one of:

    • http://capsule.example.com:8000
    • https://capsule.example.com:9090
  • Ensure that your client has access to the DHCP and DNS servers.
  • Ensure that your client has access to the HTTP UEFI Boot Capsule.
  • Ensure that all the network-based firewalls are configured to allow clients on the subnet to access the Capsule. For more information, see Section 1.3.6, “Capsule networking”.

Network requirements

  • An unmanaged DHCP server available for clients.
  • An unmanaged DNS server available for clients. In case DNS is not available, use IP address to configure clients.

Satellite requirements

Although TFTP protocol is not used for HTTP UEFI Booting, Satellite use TFTP Capsule API to deploy boot loader configuration.

  • Ensure that both Satellite Server and Capsule have DNS configured and are able to resolve provisioned host names.
  • Ensure that the UDP ports 67 and 68 are accessible by the client so that the client can send and receive a DHCP request and offer.
  • Ensure that the TCP port 8000 is open for the client to download boot loader and Kickstart templates from the Capsule.
  • Ensure that the TCP port 9090 is open for the client to download the boot loader from the Capsule through HTTPS.
  • Ensure that the host provisioning interface subnet has an HTTP Boot Capsule set.
  • Ensure that the host provisioning interface subnet has a TFTP Capsule set.
  • Ensure that the host provisioning interface subnet has a Templates Capsule set.
Back to top
Red Hat logoGithubredditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust. Explore our recent updates.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

Theme

© 2025 Red Hat