Red Hat Training

A Red Hat training course is available for Red Hat Satellite

Chapter 5. Understanding the Provisioning Workflow

This chapter explores the basic workflow for provisioning in Red Hat Satellite 6. The content in this chapter becomes the foundation for further chapters that use specific provisioning methods.

5.1. Defining the Provisioning Workflow

The provisioning process follows a basic workflow that is outlined as the following:

  1. You create a new host, either through the Create Host page at Hosts > Create host in the Web UI or through the Hammer CLI. The Satellite Server also requests an unused IP address from the DHCP Capsule Server associated with the subnet. The Create Host page uses this IP address for the IP address field. After completing all options for the new host, you submit the new host request.
  2. The DHCP Capsule Server associated with the subnet reserves an entry for the host.

  3. The Satellite Server configures DNS records:

    • A forward DNS record is created on the Capsule Server associated with the domain.
    • A reverse DNS record is created on the DNS Capsule Server associated with the subnet.
  4. A PXELinux menu is created for the host in the TFTP Capsule Server associated with the subnet.
  5. The new host requests a DHCP lease from the DHCP server.
  6. The DHCP server responds to the lease request and returns TFTP options (next-server, filename).
  7. The host requests the bootloader and menu from the TFTP server.
  8. The PXELinux menu and OS installer for the host is returned over TFTP.
  9. The installer requests the chosen provision template or script from the Satellite Server.
  10. The Satellite Server renders the template and returns the resulting kickstart to the host.
  11. The host enters a build process that installs the operating system, registers the host to the Satellite Server, and installs management tools (katello-agent, puppet).
  12. The installer notifies the Satellite of a successful build in the postinstall script.
  13. The PXELinux menu reverts to a local boot template.
  14. The host boots its operating system. If you configured the host to use any Puppet classes, the host configures itself using the modules stored on the Satellite Server.

This workflow differs depending on certain options, which are explored in detail in later chapters. For example:

  • Discovery — If using the Discovery service, the Satellite Server automatically detects the MAC address of the new host and reboots the host after you submit a request. Note that TCP port 8443 must be reachable by the Capsule to which the host is attached for the Satellite to be able to reboot the host.
  • PXE-less Provisioning — After you submit a new host request, you need to boot the specific host with a boot disk that you download from the Satellite Server.
  • Compute Resources — The compute resource creates the virtual machine for the new host and returns the MAC address to the Satellite Server. Also, if using image-based provisioning, the host does not follow the standard PXE boot and operating system installation. Instead, the compute resource creates a copy of the chosen image for the new host to use.
  • Containers — The container provisioning process does not follow the workflow process.

5.2. Creating a Host on Satellite Server

To configure host provisioning, start with creating a host entry on Satellite Server. You can use either the Web UI or the Hammer CLI. This provides the fundamentals for host provisioning including using Config Groups, which you can use as a reference for later chapters on specific provisioning methods. For more information on Config Groups, see Using Config Groups to Manage Puppet Classes in the Puppet Guide.

For Web UI Users

Navigate to Hosts > Create host. The UI provides a set of fields where you can input details for the host:

In the Host tab, you define the main details about the host and its placement. The Capsule Server can be the Satellite Server’s integrated Capsule or an external Capsule Server depending on your setup.

  • Name — The name of the host.
  • Organization — The organization that owns this host.
  • Location — The location of this host.
  • Host Group — The host group to use as a template for this host. For more information, see Host Grouping Concepts in the Architecture Guide.
  • Deploy on — The type of host deployment, either on a bare metal host or through a Compute resource.
  • Lifecycle Environment — The stage in the application life cycle of the host.
  • Content View — The Content View to use for repositories.
  • Content Source — The Capsule Server to use for providing content from the Content View. If using an external Capsule Server, make sure the content is synchronized to the Capsule Server already. For more information, see Adding Life Cycle Environments to Capsule Servers in the Installation Guide.
  • Puppet Environment — The Puppet environment containing the host. This is usually defined using the previously selected Content View and life cycle environment.
  • Puppet Master — The Capsule Server to use as the master server for agent communication.
  • Puppet CA — The Capsule Server to use for agent certification.
  • OpenSCAP Capsule — The Capsule Server to use as an OpenSCAP proxy.

In the Puppet Classes tab, you select which Puppet classes and Config Groups to apply to the host after provisioning. These classes are taken from the Content View and Puppet environment selected on the Hosts tab. The Included Classes section shows the classes to apply to the host and the Available Classes section shows what classes you can add to the host.

In the Interfaces tab, you define the network interface configuration for the host. Click Add Interface to create a new interface or Edit to edit a specific interface. New or modified interfaces use a form with the following fields:

  • Type — The type of interface to use, which not only includes basic Ethernet connections (Interface), but also baseboard management controller (BMC), bonds (Bond), and bridges (Bridge). This allows you to create complex networking configurations for a host.
  • MAC address — The interface’s MAC address, which allows you to map network details to a specific interface. In addition, the MAC address for a provisioning interface is used to identify bare metal hosts during PXE boot.
  • Device identifier — The interface ID, such as eth0, ens8, bond0, and br0.
  • DNS name — The domain name of the host. This is usually automatically populated with the host name from the Host tab.
  • Domain — The domain to provision the host. This combines with the DNS name to create a fully qualified domain name (FQDN) for the host.
  • Subnet — The network that connects this interface.
  • IP address — The IP address for this interface. Depending on the Subnet chosen and its options, this field might automatically populate.

  • A selection of interface types, including:

    • Managed — This interface provides DHCP, DNS, and TFTP services during provisioning. Additionally, the interface settings are used to generate an interface configuration file for the host. To disable an individual service, go to Infrastructure > Subnets and Infrastructure > Domains and set the corresponding Capsule setting to None.
    • Primary — The main interface and constructs the host’s FQDN from the interface details.
    • Provision — The interface for PXE boot services. In the case of image based provisioning, the IP address from this interface is used for the SSH connection to the client.
    • Remote execution — This interface is used for remote execution features.
Note

This form also displays additional fields relevant to the network interface Type chosen. For example, choosing Bond provides options for setting the bonding mode, bonding options, and choosing which devices to attach to the bond.

In the Operating System tab, define the operating system and related aspects to install on the host. Select the host’s Architecture and then select an Operating System related to that architecture. Depending on the operating system that you select, different options are available:

  • Build mode — To enable provisioning the host and installing the operating system. This option is required for all provisioning tasks. You only need to disable this option if creating an entry for an already existing and provisioned host.
  • Media Selection — To enable selection from synchronized kickstart repositories or from all repositories. Select the installation media type that will be used to provision this host. select Synced Content for synchronized kickstart repositories, or All Media to select from other installation media, typically those that have been added manually under Hosts > Installation media > New Medium.
  • Media — The operating system’s installation media. This is usually a kickstart tree, but it can also be a locally mounted ISO image.
  • Partition Table — The partition table template to use for the root disk layout. You can also define a Custom partition table directly on this form.
  • PXE loader - Red Hat Satellite 6.3 supports the booting of both BIOS and UEFI systems. If your host uses PXE provisioning, you must select the correct DHCP file to load. If your host uses PXE-less provisioning, for example iPXE, select None.
  • Root password — The password for the root user on the operating system.
  • Provisioning templates — This shows the templates chosen to provision the host. Click Resolve to see how the Satellite Server assigns templates to specific functions in the provisioning process (PXE, provisioning, user data, and others).
Note

Operating System tab provides additional options if you selected a Compute resource from Deploy on in the Host tab. These options are covered in a later chapter.

In the Parameters tab, you set variable data for both the provisioning process and Puppet configuration. The Puppet class parameters section allows you to modify data sent to Puppet’s parameters. The Global parameters and Host parameters define custom parameters that you can use within the Satellite Server, such as provisioning templates.

Note

If you aim to attach your activation key to the host, add a new host parameter with the Name set to kt_activation_keys and the Value set to the name of your activation key.

In the Additional Information tab, you define miscellaneous data about the host including it’s owner, whether to include it in reporting, the hardware model, and any additional comments.

To save the host entry, click Submit.

For CLI Users

Create the host with the hammer host create command. For example: 

# hammer host create --name "testhost" --organization "ACME" \
--location "New York" --environment "Test" --architecture "x86_64" \
--build true --domain "example.com" --enabled true \
--mac "aa:aa:aa:aa:aa:aa" --subnet "ACME's Internal Network" \
--managed true --medium "Red Hat Kickstart Tree" \
--operatingsystem "RedHat 7.2" --owner admin \
--partition-table "Kickstart Default" \
--puppet-proxy "satellite.example.com" \
--puppet-ca-proxy "satellite.example.com" --root-password "p@55w0rd!"

Use the --interface option to configure specific interface settings. See Appendix B, Additional Host Parameters for Hammer CLI for more information. You can also define specific network interface configurations with the hammer host interface create command. Use the --host or --host-id options to identify the host that receives the interface. For example: 

# hammer host interface create --host "testhost" --type interface \
--mac "aa:aa:aa:aa:aa:aa" --identifier "eth0" --name "testhost" \
--domain "example.com" --subnet "ACME's Internal Network" \
--managed true --primary true --provision true

This procedure acts as foundation for most provisioning methods. However, the process of defining all this information for each host is time consuming. Therefore, it is recommended to create a host group to define common settings among all hosts.

5.3. Creating a Host Group on Satellite Server

Red Hat Satellite 6 uses the concept of host groups to help reduce the time to provision many hosts.

A host group acts as a template for common host settings. It contains a lot of the same details that you provide to hosts. When you provision a new host with a host group, the host inherits the defined settings from the host group. You can then provide additional details where necessary to individualize the host.

In addition, you can create a hierarchy of host groups. Typically, you will aim to have one base level host group that will represent all hosts in your organization and provide general settings, and then nested groups to provide specific settings. For example, you can have a base host level (parent) group that defines the operating system, and two nested (child) host groups that inherit the base level host group:

  • Hostgroup: Base (Red Hat Enterprise Linux 7.2)

    • Hostgroup: Webserver (applies the httpd Puppet class)

      • Host: webserver1.example.com (web server)
      • Host: webserver2.example.com (web server)

    • Hostgroup: Storage (applies the nfs Puppet class)

      • Host: storage1.example.com (storage server)
      • Host: storage2.example.com (storage server)
    • Host: custom.example.com (custom host)

In this example, all provisioned hosts use Red Hat Enterprise Linux 7.2 as their operating system due to their inheritance of the Base host group. The two web server hosts inherit the settings from the Webserver host group, which includes the httpd Puppet class and the settings from the Base host group. Likewise, the two storage servers inherit the settings from the Storage host group, which includes the nfs Puppet class and the settings from the Base host group. The custom host only inherits the settings from the Base host group.

This scenario shows how to create a host group for ACME. Later chapters in this guide use this host group to help with the provisioning process.

For Web UI Users

Navigate to Configure > Host groups and click Create Host Group. The UI provides a form with fields similar to the host creation form. Enter the following details:

  • In the Host Group tab:

    • Parent — The parent host group to inherit basic settings from. Not applicable when creating the first group, so leave blank in this scenario.
    • Name — The name of the host group. For this scenario, enter Base.
    • Lifecycle Environment — The hosts' stage in the application life cycle. Select the Production environment created in Creating An Application Life Cycle in the Content Management Guide.
    • Content View — The Content View to use for repositories. Select the Base view created in Managing Content Views in the Content Management Guide.
    • Content Source — The Capsule Server to use for providing content from the Content View. Select the Satellite Server’s integrated Capsule.

    • Puppet Environment — The Puppet environment containing the hosts. This is usually defined using the previously selected Content View and life cycle environment. For this example, select the Production environment, which does not contain Puppet modules.

      Note

      Puppet fails to retrieve the Puppet CA certificate while registering a host with a host group associated with a Puppet environment created inside a Production environment. To create a suitable Puppet environment to be associated with a host group, follow these steps:

      1. Manually create a directory and change the owner: 

        # mkdir /etc/puppet/environments/example_environment
# chown apache /etc/puppet/environments/example_environment
      2. Navigate to Configure → Environments and click Import environment from. The button name will include the FQDN of the internal or external Capsule.
      3. Choose the created directory and click Update.
    • Puppet Master — The Capsule Server to use as the master server for agent communication. Select the Satellite Server’s integrated Capsule.
    • Puppet CA — The Capsule Server to use for agent certification. Select the Satellite Server’s integrated Capsule.
    • OpenSCAP Capsule — The OpenSCAP Capsule to use for fetching SCAP content and uploading ARF reports. In this example, leave this blank.
  • In the Puppet Classes tab, you select which Puppet classes to apply to the host after provisioning. This scenario does not use Puppet classes, so skip this tab for the moment.

  • In the Network tab:

    • Domain — The domain to provision the host. This combines with the DNS name to create a fully qualified domain name (FQDN) for the host. Select ACME’s example.com domain.
    • IPv4 Subnet — The network that connects this interface. Select ACME's Internal Network.
    • IPv6 Subnet — The network that connects this interface. In this example, leave this blank.
    • Realm — The authentication realm for the host. This scenario does not use realms so leave this field blank.

  • In the Operating System tab:

    • Architecture — The hosts' architecture. Select x86_64.
    • Operating System — The base operating system to install. An entry for Red Hat Enterprise Linux 7.2 should appear after performing the synchronization steps, which are described in Synchronizing Red Hat Repositories in the Content Management Guide. Select the entry.
    • Media Selection — To enable selection from synchronized kickstart repositories or from all repositories. Select the installation media type that will be used to provision this host group: Synced Content for synchronized kickstart repositories, or All Media for other installation media, typically those that have been added manually under Hosts > Installation media > New Medium.
    • Media — The operating system’s installation media. Select the kickstart tree from Red Hat Enterprise Linux 7.2, which should be present after performing the synchronization steps, which are described in Synchronizing Red Hat Repositories in the Content Management Guide.
    • Partition Table — The partition table template to use for the root disk layout. Select Default Kickstart.
    • Root password — The password for the root user on the operating system. Enter a root password.
  • In the Parameters tab, you set variable data for both the provisioning process and Puppet configuration. For example, to enforce Puppet 4 for hosts, add the enable-Puppet4 parameter in the Global parameters area and set it to true.
  • In the Locations tab, set the location for the host group. For this example, select New York.
  • In the Organizations tab, set the organizations that are allowed to use the host group. For this example, select ACME.
  • In the Activation Keys tab, select the example activation key. This adds a new parameter (kt_activation_keys) to each host that defines the activation key to use for registration.

Click Submit to save the host group.

For CLI Users

Create the host group with the hammer hostgroup create command. For example: 

# hammer hostgroup create --name "Base" \
--lifecycle-environment "Production" --content-view "Base" \
--environment "production" --content-source-id 1 \
--puppet-ca-proxy-id 1 --puppet-proxy-id 1 --domain "example.com" \
--subnet `ACME's Internal Network` --architecture "x86_64" \
--operatingsystem "RedHat 7.2" --medium-id 9 \
--partition-table "Kickstart default" --root-pass "p@55w0rd!" \
--locations "New York" --organizations "ACME"

The server creates the host group entry. This scenario uses this host group for provisioning examples.

5.4. Chapter Summary

This chapter showed the basic workflow for creating new hosts entries in Red Hat Satellite 6. This chapter also demonstrated how to create a host group to predefine certain parameters when creating new hosts.

The next chapter explores how to provision bare metal hosts. We use the Base host group to predefine settings for hosts in the next chapter.