Red Hat Training

A Red Hat training course is available for Red Hat Satellite

Chapter 4. Configuring Networking

Each provisioning type requires some network configuration. Ensure that new hosts can access your Capsule Server. A Capsule Server can either be a Satellite Server’s integrated Capsule or an external Capsule Server. You may want to choose to provision hosts from an external Capsule Server when the desired hosts are on isolated networks and cannot connect to the Satellite Server directly, or when the content is synchronized with the Capsule Server, and provisioning using the external Capsule Server can save on network bandwidth.

Configuring the Capsule Server has two basic requirements:

  • Configuring network services. This includes:

    • Content delivery services
    • Network services (DHCP, DNS, and TFTP)
    • Puppet configuration
  • Defining network resource data in Satellite Server to help configure network interfaces on new hosts.

This chapter focuses on configuring network services in Satellite Server’s integrated Capsule. However, these instructions have similar applications to configuring standalone Capsule Servers managing a specific network. To configure Satellite to use external DHCP, DNS, and TFTP services, see Configuring External Services in the Red Hat Satellite Installation Guide.

For this example, ACME has a private network to provision hosts. The details for this private network are:

Subnet

192.168.140.0/24

 

External Gateway

192.168.140.1

 

Satellite Server

192.168.140.2

 

DHCP Allocation Pool for Discovered and Unmanaged Hosts

192.168.140.10 - 192.168.140.110

 

DHCP Allocation Pool for Host Provisioning

192.168.140.111 - 192.168.140.250

 

While it is possible to define the same DHCP range in Satellite Server for both Discovered and Provisioned systems, it is recommended to use a separate range for each service but still within the same subnet.

4.1. Considerations for Image Based Provisioning

Post-Boot Configuration Method

Images that use the finish post-boot configuration scripts require a managed DHCP server, such as Satellite’s integrated Capsule or an external Capsule. The host must be created with a subnet associated with a DHCP Capsule, and the IP address of the host must be a valid IP address from the DHCP range. It is possible to use an external DHCP service, but IP addresses must be entered manually. The SSH credentials corresponding to the configuration in the image must be configured in Satellite to enable the post-boot configuration to be made.

The following items should be checked when troubleshooting a virtual machine booted from an image that depends on post-configuration scripts:

  • The host has a subnet assigned in Satellite Server.
  • The subnet has a DHCP Capsule assigned in Satellite Server.
  • The host has a valid IP address assigned in Satellite Server.
  • The IP address acquired by the virtual machine using DHCP matches the address configured in Satellite Server.
  • The virtual machine created from an image responds to SSH requests.
  • The virtual machine created from an image authorizes the user and password, over SSH, which are associated with the image being deployed.

Pre-Boot Initialization Configuration Method

Images that use the cloud-init scripts usually require a DHCP server to avoid having to include the IP address in the image. A managed DHCP Capsule is preferred. The image must have the cloud-init service configured to start when the system boots and fetch a script or configuration data to use in completing the configuration.

The following items should be checked when troubleshooting a virtual machine booted from an image that depends on initialization scripts included in the image:

  • There is a DHCP server on the subnet.
  • The virtual machine has the cloud-init service installed and enabled.

For information on the differing levels of support for finish and cloud-init scripts in virtual-machine images, see the Red Hat Knowledgebase Solution What are the supported compute resources for the finish and cloud-init scripts on the Red Hat Customer Portal.

4.2. Configuring Network Services

Some of our provisioning methods use Capsule Server services for various purposes. For example, a network might require the Capsule Server to act as a DHCP server. A network might also require PXE boot services as a means to install the operating system to new hosts. This requires configuring the Capsule Server to use the main PXE boot services: DHCP, DNS, and TFTP. To accomplish this, we run the satellite-installer script with the options to configure these services on the Satellite Server. To configure these services on an external Capsule Server, run satellite-installer --scenario capsule.

In this example, ACME aims to connect Satellite Server’s integrated Capsule to a provisioning network to provide PXE boot services. Satellite Server uses the following NIC configuration:

# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 52:54:00:33:e3:1c brd ff:ff:ff:ff:ff:ff
    inet 192.168.125.35/24 brd 192.168.125.255 scope global dynamic ens3
       valid_lft 3042sec preferred_lft 3042sec
    inet6 fe80::5054:ff:fe33:e31c/64 scope link
       valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
   link/ether 52:54:00:fd:24:ae brd ff:ff:ff:ff:ff:ff
   inet 192.168.140.2/24 brd 192.168.140.255 scope global ens8
      valid_lft forever preferred_lft forever
   inet6 fe80::5054:ff:fefd:24ae/64 scope link
      valid_lft forever preferred_lft forever

Satellite Server uses eth0 for external communication, such as connection to Red Hat’s CDN. ACME aims to use the eth1 interface to connect to a private provisioning network for hosts using the 192.168.140.0/24 subnet. The goal is for Satellite Server’s integrated Capsule to act as a DHCP, DNS, and TFTP server for new hosts on this network.

Note

Satellite Server’s integrated Capsule provides these services. You can also configure these services on additional Satellite Capsules in other networks.

The satellite-installer script uses the following options to configure network services:

DHCP Options

--foreman-proxy-dhcp
Enables the DHCP service. Set this option to true.
--foreman-proxy-dhcp-managed
Enables Foreman to manage the DHCP service. Set this option to true.
--foreman-proxy-dhcp-gateway
The DHCP pool gateway. For this example, set this to 192.168.140.1, which is the address of the external gateway for hosts on ACME’s private network.
--foreman-proxy-dhcp-interface
Sets the interface for the DHCP service to listen for requests. For this example, set this to eth1.
--foreman-proxy-dhcp-nameservers
Sets the addresses of the nameservers provided to clients through DHCP. For this example, set this to 192.168.140.1, which is the address for Satellite Server on eth1.
--foreman-proxy-dhcp-range
A space-separated DHCP pool range for Discovered and Unmanaged services. For this example, set this to 192.168.140.10 192.168.140.110, which provides a pool with 100 addresses.
--foreman-proxy-dhcp-server
Sets the address of the DHCP server to manage. For this example, it is 192.168.140.2.

DNS Options

--foreman-proxy-dns
Enables DNS service. Set this option to true.
--foreman-proxy-dns-managed
Enables Foreman to manage the DNS service. Set this option to true.
--foreman-proxy-dns-forwarders
Sets the DNS forwarders. This example sets this to 8.8.8.8; 4.4.4.4, which uses two public DNS servers. For your purposes, use your own DNS servers instead.
--foreman-proxy-dns-interface
Sets the interface to listen for DNS requests. For this example, set this to eth1.
--foreman-proxy-dns-reverse
The DNS reverse zone name. This example uses 140.168.192.in-addr.arpa.
--foreman-proxy-dns-server
Sets the address of the DNS server to manage. For this example, it is 192.168.140.2.
--foreman-proxy-dns-zone
Sets the DNS zone name. This example uses example.com.

TFTP Options

--foreman-proxy-tftp
Enables TFTP service. Set this option to true.
--foreman-proxy-tftp-managed
Enables Foreman to manage the TFTP service. Set this option to true.
Note

Run satellite-installer --scenario capsule --help to view more options related to DHCP, DNS, TFTP, and other Satellite Capsule services

To Configure Network Services

  1. Enter the satellite-installer command to configure the required network services:

    # satellite-installer --foreman-proxy-dhcp true \
    --foreman-proxy-dhcp-managed true \
    --foreman-proxy-dhcp-gateway "192.168.140.1" \
    --foreman-proxy-dhcp-interface "eth1" \
    --foreman-proxy-dhcp-nameservers "192.168.140.2" \
    --foreman-proxy-dhcp-range "192.168.140.10 192.168.140.110" \
    --foreman-proxy-dhcp-server "192.168.140.2" \
    --foreman-proxy-dns true \
    --foreman-proxy-dns-managed true \
    --foreman-proxy-dns-forwarders "8.8.8.8; 4.4.4.4" \
    --foreman-proxy-dns-interface "eth1" \
    --foreman-proxy-dns-reverse "140.168.192.in-addr.arpa" \
    --foreman-proxy-dns-server "192.168.140.2" \
    --foreman-proxy-dns-zone "example.com" \
    --foreman-proxy-tftp true
    --foreman-proxy-tftp-managed true

    This example configures the Satellite Server’s integrated Capsule Server. If you are running this command on an external Capsule Server, use satellite-installer --scenario capsule.

  2. On the Satellite Server’s CLI, refresh the features of the Capsule Server to view the changes.

    1. Determine the Capsule Server that you configure:

      # hammer proxy list
    2. Refresh features of the Capsule Server:

      # hammer proxy refresh-features --name "satellite.example.com"
  3. Verify the services configured on the Capsule Server:

    # hammer proxy info --name "satellite.example.com"

4.3. Adding a Domain to Satellite Server

Satellite Server defines domain names for each host on the network. This means Satellite Server needs to know about the domain and the Capsule Server responsible for domain name assignment. For this example, we create the example.com domain for ACME’s internal network.

Note

Satellite Server might already have the relevant domain created as part of Satellite Server installation. Switch the context to Any Organization and Any Location then check the domain list to see if it exists. If so, modify this domain entry, define the DNS capsule, set the organization, and set the location.

For Web UI Users

Navigate to Infrastructure > Domains and click New Domain. The UI provides a set of fields where you can input details for the domain:

  • In the Domain tab:

    • DNS Domain - The domain name. For this example: example.com
    • Description - A plain text description of the domain. For this example: ACME's example domain.
    • DNS Capsule - The capsule to use for DNS assignments. For this example, use Satellite Server’s integrated Capsule.
  • In the Locations tab:

    • Select the locations that use this domain. For example, select the New York location.
  • In the Organizations tab:

    • Select the organizations that use this domain. For example, select ACME.

For CLI Users

Create the domain with the following command:

# hammer domain create --name "example.com" \
--description "ACME's example domain" --dns_id 1 \
--locations "New York" --organizations "ACME"
Note

In this example, the --dns-id option uses 1, which is the ID of Satellite Server’s integrated Capsule.

4.4. Adding a Subnet to Satellite Server

Satellite Server configures interfaces for new hosts. This is why Satellite Server needs to know about the network that connects these interfaces. This means you must add information for each of your subnets into Satellite Server. This includes information such as the gateway, DHCP, and DNS. For this example, we create a subnet mapping for the ‘192.168.140.0/24’ network, which Satellite Server’s integrated Capsule manages.

For Web UI Users

Navigate to Infrastructure > Subnets and click New Subnet. The UI provides a set of fields where you can input details for the subnet:

  • In the Subnet tab:

    • Name - Plain text name for the subnet. For this example: ACME's Internal Network
    • Network address - The network address for the subnet. For this example: 192.168.140.0
    • Network prefix - The network prefix for the subnet. For this example: 24
    • Network mask - The network mask for the subnet. For this example: 255.255.255.0
    • Gateway address - The external gateway for the subnet. For this example: 192.168.140.1
    • Primary DNS server - Primary DNS for the subnet. For this example: 192.168.140.2
    • Secondary DNS server - Primary DNS for the subnet. For this example: 8.8.8.8
    • IPAM - The method to use for IP address management (IPAM):

      • DHCP - The subnet contains a DHCP server.
      • Internal DB - The subnet does not contain a DHCP server but you aim for Satellite to manage IP address assignment and record IP addresses in its internal database.
      • None - No IP address management.

        For this example, use DHCP since Satellite Server acts as a DHCP server.

    • Start of IP range - Defines the start of the IP assignment range for provisioning services. For this example: 192.168.140.111.
    • End of IP range - Defines the end of the IP assignment range for provisioning services. For this example: 192.168.140.250.
    • VLAN ID - The VLAN ID number for the subnet to isolate broadcasts. This example does not use VLANs, so leave this field blank.
    • Boot mode - Defines the default boot mode for network interfaces on this network.

      • Static boot mode means that network interfaces assigned to this subnet will set the IP address and network mask directly to the configuration file, avoiding using DHCP to obtain them. Note that gateway and DNS servers will not be fetched from DHCP. Therefore, if you want to configure them, provide correct values in Gateway address and Primary DNS server fields. You can omit these only if you do not route traffic outside your network (installation medium is local) and you use IP addresses directly without DNS resolution.
      • DHCP boot mode means that network interfaces assigned to this subnet are configured over DHCP.
  • In the Remote Execution tab:

    • Select the capsule that controls the remote execution. In this example, it is Satellite Server itself.
  • In the Domains tab:

    • Select the domains that apply to this subnet.
  • In the Capsules tab:

    • Select the capsule that applies to each service in the subnet, including DHCP, TFTP, and reverse DNS services. This example uses Satellite Server’s integrated Capsule for each.
  • In the Parameters tab, configure any subnet level parameters to apply to hosts attached to this subnet. For example, user defined Boolean or string parameters that can be used in templates.
  • In the Locations tab:

    • Select the locations that use this capsule. For example, select the New York location.
  • In the Organizations tab:

    • Select the organizations that use this capsule. For example, select ACME.

Click Submit to save the subnet information.

For CLI Users

Create the subnet with the following command:

# hammer subnet create --name "ACME's Internal Network" \
--network "192.168.140.0" --mask "255.255.255.0" \
--gateway "192.168.140.1" --dns-primary "192.168.140.2" \
--dns-secondary "8.8.8.8" --ipam "DHCP" \
--from "192.168.140.111" --to "192.168.140.250" --boot-mode "DHCP" \
--domains "example.com" --dhcp-id 1 --dns-id 1 --tftp-id 1 \
--locations "New York" --organizations "ACME"
Note

In this example, the --dhcp-id, --dns-id, and --tftp-id options use 1, which is the ID of the integrated Capsule in Satellite Server.

4.5. Configuring iPXE to Reduce Provisioning Times

In Red Hat Satellite 6.3, you can configure PXELinux to chainboot iPXE and boot using the HTTP protocol, which is faster and more reliable on high latency networks than TFTP.

There are three methods of using iPXE with Red Hat Satellite 6.3:

  1. Chainbooting virtual machines using hypervisors that use iPXE as primary firmware
  2. Using PXELinux through TFTP to chainload iPXE directly on bare metal hosts
  3. Using PXELinux through UNDI, which uses HTTP to transfer the kernel and the initial RAM disk on bare metal hosts

Prerequisites

Before you begin, ensure that the following conditions are met:

  • A host exists on Red Hat Satellite to use
  • The MAC address of the provisioning interface matches the host configuration
  • The provisioning interface of the host has a valid DHCP reservation
  • The NIC is capable of PXE booting. For more information, see http://ipxe.org/appnote/hardware_drivers
  • The NIC is compatible with iPXE

4.5.1. Chainbooting virtual machines

Most virtualization hypervisors use iPXE as primary firmware for PXE booting. Because of this, you can chainboot without TFTP and PXELinux.

Chainbooting virtual machine workflow

Using virtualization hypervisors removes the need for TFTP and PXELinux. It has the following workflow:

  1. Virtual machine starts
  2. iPXE retrieves the network credentials using DHCP
  3. iPXE retrieves the HTTP address using DHCP
  4. iPXE chainloads the iPXE template from Red Hat Satellite
  5. iPXE loads the kernel and initial RAM disk of the installer

Ensure that the hypervisor that you want to use supports iPXE. The following virtualization hypervisors support iPXE:

  • libvirt
  • oVirt
  • RHEV

Configuring Red Hat Satellite Server to use iPXE

You can use the default template to configure iPXE booting for hosts. If you want to change the default values in the template, clone the template and edit the clone.

  1. In the Satellite web UI, navigate to Hosts > Provisioning Templates, enter Kickstart default iPXE and click Search.
  2. Optional: If you want to change the template, click Clone, enter a unique name, and click Submit.
  3. Click the name of the template you want to use.
  4. If you clone the template, you can make changes you require on the Template tab.
  5. Click the Association tab, and select the operating systems that your host uses.
  6. Click the Locations tab, and add the location where the host resides.
  7. Click the Organizations tab, and add the organization that the host belongs to.
  8. Click Submit to save the changes.
  9. Navigate to Hosts > Operating systems and select the operating system of your host.
  10. Click the Templates tab.
  11. From the iPXE Template list, select the template you want to use.
  12. Click Submit to save the changes.
  13. Navigate to Hosts > All Hosts.
  14. In the Hosts page, select the host that you want to use.
  15. Select the Templates tab.
  16. From the iPXE template list, select Review and verify that the Kickstart default iPXE template is the correct template.
  17. To prevent an endless loop of chainbooting iPXE firmware, edit the /etc/dhcp/dhcpd.conf file to match the following example. If you use an isolated network, use a Capsule Server URL with TCP port 8000, instead of Satellite Server’s URL.

    1. Locate the following lines in the Bootfile Handoff section of the /etc/dhcp/dhcpd.conf file:

      } else {
        filename "pxelinux.0";
      }
    2. Add the following extra elsif statement before the else statement:

      elsif exists user-class and option user-class = "iPXE" {
        filename "http://satellite.example.com/unattended/iPXE";
      }
    3. Verify that the if section matches the following example:

      if option architecture = 00:06 {
        filename "grub2/shim.efi";
      } elsif option architecture = 00:07 {
        filename "grub2/shim.efi";
      } elsif option architecture = 00:09 {
        filename "grub2/shim.efi";
      } elsif exists user-class and option user-class = "iPXE" {
        filename "http://satellite.example.com/unattended/iPXE";
      } else {
        filename "pxelinux.0";
      }
      Note

      For http://satellite.example.com/unattended/iPXE, you can also use a Red Hat Satellite Capsule http://capsule.example.com:8000/unattended/iPXE. You must update the /etc/dhcp/dhcpd.conf file after every upgrade. The content of the /etc/dhcp/dhcpd.conf file is case sensitive.

4.5.2. Chainbooting iPXE directly

You can use this procedure to chainboot iPXE directly using the built-in driver for network communication. There are separate procedures to configure Red Hat Satellite Capsules and Servers to use iPXE.

You can use this procedure only with bare metal hosts.

Chainbooting iPXE directly or with UNDI workflow

  1. Host powers on
  2. PXE driver retrieves the network credentials using DHCP
  3. PXE driver retrieves the PXELinux firmware pxelinux.0 using TFTP
  4. PXELinux searches for the configuration file on the TFTP server
  5. PXELinux chainloads iPXE ipxe.lkrn or undionly-ipxe.0
  6. iPXE retrieves the network credentials using DHCP again
  7. iPXE retrieves HTTP address using DHCP
  8. iPXE chainloads the iPXE template from Red Hat Satellite
  9. iPXE loads the kernel and initial RAM disk of the installer

Configuring Red Hat Satellite Capsule to use iPXE

You can use this procedure to configure Capsules to use iPXE.

You must perform this procedure on all Capsules.

To configure the Capsule to chainboot iPXE:

  1. Install the ipxe-bootimgs RPM package:

    # yum install ipxe-bootimgs
  2. Copy the iPXE firmware to the TFTP server’s root directory:

    # cp /usr/share/ipxe/ipxe.lkrn /var/lib/tftpboot/

    Do not use symbolic links because TFTP runs in the chroot environment.

  3. Correct the file contexts:

    # restorecon -RvF /var/lib/tftpboot/

Configuring Red Hat Satellite Server to use iPXE

You can use the default template to configure iPXE booting for hosts. If you want to change the default values in the template, clone the template and edit the clone.

  1. In the Satellite web UI, navigate to Hosts > Provisioning Templates, enter PXELinux chain iPXE and click Search.
  2. Optional: If you want to change the template, click Clone, enter a unique name, and click Submit.
  3. Click the name of the template you want to use.
  4. If you clone the template, you can make changes you require on the Template tab.
  5. Click the Association tab, and select the operating systems that your host uses.
  6. Click the Locations tab, and add the location where the host resides.
  7. Click the Organizations tab, and add the organization that the host belongs to.
  8. Click Submit to save the changes.
  9. In the Provisioning Templates page, enter Kickstart default iPXE into the search field and click Search.
  10. Optional: If you want to change the template, click Clone, enter a unique name, and click Submit.
  11. Click the name of the template you want to use.
  12. If you clone the template, you can make changes you require on the Template tab.
  13. Click the Association tab, and associate the template with the operating system that your host uses.
  14. Click the Locations tab, and add the location where the host resides.
  15. Click the Organizations tab, and add the organization that the host belongs to.
  16. Click Submit to save the changes.
  17. Navigate to Hosts > Operating systems and select the operating system of your host.
  18. Click the Templates tab.
  19. From the PXELinux template list, select the template you want to use.
  20. From the iPXE template list, select the template you want to use.
  21. Click Submit to save the changes.
  22. Navigate to Hosts > All Hosts, and select the host you want to use.
  23. Select the Templates tab, and from the PXELinux template list, select Review and verify the template is the correct template.
  24. From the iPXE template list, select Review and verify the template is the correct template.

    Note

    If there is no PXELinux entry, or you cannot find the new template, navigate to Hosts > All Hosts, and on your host, click Edit. Click the Operating system tab and click the Provisioning Template Resolve button to refresh the list of templates.

4.5.3. Chainbooting iPXE using UNDI

You can use this procedure to chainboot iPXE using UNDI. There are separate procedures to configure Red Hat Satellite Capsules and Servers to use iPXE.

You can use this procedure only with bare metal hosts.

Chainbooting iPXE directly or with UNDI workflow

  1. Host powers on
  2. PXE driver retrieves the network credentials using DHCP
  3. PXE driver retrieves the PXELinux firmware pxelinux.0 using TFTP
  4. PXELinux searches for the configuration file on the TFTP server
  5. PXELinux chainloads iPXE ipxe.lkrn or undionly-ipxe.0
  6. iPXE retrieves the network credentials using DHCP again
  7. iPXE retrieves HTTP address using DHCP
  8. iPXE chainloads the iPXE template from Red Hat Satellite
  9. iPXE loads the kernel and initial RAM disk of the installer

Configuring Red Hat Satellite Capsule to use iPXE

You can use this procedure to configure Capsules to use iPXE.

You must perform this procedure on all Capsules.

To configure the Capsule to chainboot iPXE:

  1. Install the ipxe-bootimgs RPM package:

    # yum install ipxe-bootimgs
  2. Copy the iPXE firmware to the TFTP server’s root directory and rename the file:

    # cp /usr/share/ipxe/undionly.kpxe /var/lib/tftpboot/undionly-ipxe.0

    Do not use symbolic links because the TFTP runs in the chroot environment.

  3. Correct the file contexts:

    # restorecon -RvF /var/lib/tftpboot/

Configuring Red Hat Satellite Server to use iPXE

You can use the default template to configure iPXE booting for hosts. If you want to change the default values in the template, clone the template and edit the clone.

  1. In the Satellite web UI, navigate to Hosts > Provisioning Templates, enter PXELinux chain iPXE UNDI and click Search.
  2. Optional: If you want to change the template, click Clone, enter a unique name, and click Submit.
  3. Click the name of the template you want to use.
  4. If you clone the template, you can make changes you require on the Template tab.
  5. Click the Association tab, and select the operating systems that your host uses.
  6. Click the Locations tab, and add the location where the host resides.
  7. Click the Organizations tab, and add the organization that the host belongs to.
  8. Click Submit to save the changes.
  9. In the Provisioning Templates page, enter Kickstart default iPXE into the search field and click Search.
  10. Optional: If you want to change the template, click Clone, enter a unique name, and click Submit.
  11. Click the name of the template you want to use.
  12. If you clone the template, you can make changes you require on the Template tab.
  13. Click the Association tab, and associate the template with the operating system that your host uses.
  14. Click the Locations tab, and add the location where the host resides.
  15. Click the Organizations tab, and add the organization that the host belongs to.
  16. Click Submit to save the changes.
  17. Navigate to Hosts > Operating systems and select the operating system of your host.
  18. Click the Templates tab.
  19. From the PXELinux template list, select the template you want to use.
  20. From the iPXE template list, select the template you want to use.
  21. Click Submit to save the changes.
  22. Navigate to Hosts > All Hosts, and select the host you want to use.
  23. Select the Templates tab, and from the PXELinux template list, select Review and verify the template is the correct template.
  24. From the iPXE template list, select Review and verify the template is the correct template.

    Note

    If there is no PXELinux entry, or you cannot find the new template, navigate to Hosts > All Hosts, and on your host, click Edit. Click the Operating system tab and click the Provisioning Template Resolve button to refresh the list of templates.

  25. To prevent an endless loop of chainbooting iPXE firmware, edit the /etc/dhcp/dhcpd.conf file to match the following example. If you use an isolated network, use a Capsule Server URL with TCP port 8000, instead of Satellite Server’s URL.

    1. Locate the following lines in the Bootfile Handoff section of the /etc/dhcp/dhcpd.conf file:

      } else {
        filename "pxelinux.0";
      }
    2. Add the following extra elsif statement before the else statement:

      elsif exists user-class and option user-class = "iPXE" {
        filename "http://satellite.example.com/unattended/iPXE";
      }
    3. Verify that the if section matches the following example:

      if option architecture = 00:06 {
        filename "grub2/shim.efi";
      } elsif option architecture = 00:07 {
        filename "grub2/shim.efi";
      } elsif option architecture = 00:09 {
        filename "grub2/shim.efi";
      } elsif exists user-class and option user-class = "iPXE" {
        filename "http://satellite.example.com/unattended/iPXE";
      } else {
        filename "pxelinux.0";
      }
      Note

      For http://satellite.example.com/unattended/iPXE, you can also use a Red Hat Satellite Capsule http://capsule.example.comf:8000/unattended/iPXE. You must update the /etc/dhcp/dhcpd.conf file after every upgrade. The content of the /etc/dhcp/dhcpd.conf file is case sensitive.

4.6. Chapter Summary

In this chapter, we examined how to configure certain network services in Satellite Server’s integrated Capsule and map the domain and subnet details of the network that Satellite Server controls. This provides a network for our new hosts and provides the hosts with key services, such as PXE booting and network configuration.

The next chapter looks at the basic provisioning workflow, which includes how to create new hosts and host groups.