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 New Host page at Hosts > New 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 New Hosts 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 achieve this through either the Web UI or the Hammer CLI. This provides the fundamentals for host provisioning, which you can use as a reference for later chapters on specific provisioning methods.

For Web UI Users

Navigate to Hosts > New 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.

  • Name - The name of the host.
  • Organization - The organization that owns this host.
  • Location - The location of this host.
  • Host Group - Defines which host group to use as a template for this host.
  • Deploy on - Defines the type of host deployment, either on a bare metal host or through a Compute resource.
  • Lifecycle Environment - Defines the host’s stage in the application life cycle.
  • Content View - Defines the Content View to use for repositories.
  • Puppet Environment - Defines the Puppet environment containing the host. This is usually defined using the previously selected Content View and life cycle environment.
  • Content Source - The Capsule Server to use for providing content from the Content View.
  • Puppet CA - The Capsule Server to use for agent certification.
  • Puppet Master - The Capsule Server to use as the master server for agent communication.
  • Openscap Capsule - The Capsule Server to use as an OpenSCAP proxy.

In the Puppet Classes tab, you select which Puppet classes 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 - This defines the main interface and constructs the host’s FQDN from the interface details.
    • Provision - This interface is used 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, you define the operating system and related aspects to install on the host. You select the host’s Architecture and then choose an Operating System related to that architecture. The form provides further options based on the chosen operating system:

  • Build mode - Defines whether to provision the host and install 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 - Defines whether to select from only synchronized kickstart repositories or from all repositories. Select the installation media type that will be used to provision this host. Choose 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 - Defines the operating system’s installation media. This is usually a kickstart tree, but it can also be a locally mounted ISO image.
  • Partition Table - Defines the partition table template to use for the root disk layout. You can also define a Custom partition table directly on this form.
  • 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 choose 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

If provisioning many hosts, it is time consuming to enter all host details each time. However, Red Hat Satellite 6 uses the concept of host groups to help reduce the time to provision a host.

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 New 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 very parent group, so leave blank in this scenario.
    • Name - The name of the host group. For this scenario, enter Base.
    • Lifecycle Environment - Defines the hosts' stage in the application life cycle. Choose the Production environment created in the Red Hat Satellite 6 Content Management Guide.
    • Content View - Defines the Content View to use for repositories. Choose the Base view created in the Red Hat Satellite 6 Content Management Guide.
    • Puppet Environment - Defines the Puppet environment containing the hosts. This is usually defined using the previously selected Content View and life cycle environment. For this example, choose the production environment, which does not contain Puppet modules.
    • Content Source - The Capsule Server to use for providing content from the Content View. Choose the Satellite Server’s integrated Capsule.
    • Puppet CA - The Capsule Server to use for agent certification. Choose the Satellite Server’s integrated Capsule.
    • Puppet Master - The Capsule Server to use as the master server for agent communication. Choose the Satellite Server’s integrated Capsule.
    • Openscap Proxy - The server to use as an OpenSCAP proxy. 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.
    • Subnet - The network that connects this interface. Select ACME's Internal Network.
    • Realm - Defines 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 Red Hat Satellite 6 Content Management Guide. Select the entry. Media Selection - Defines whether to select from only 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 - Defines 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 Red Hat Satellite 6 Content Management Guide.
    • Partition Table - Defines 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. Leave this section empty.
  • 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.