13.4. Storing and Maintaining Host Information

Red Hat Satellite 6 uses a combination of applications to gather information about managed hosts and to ensure that those hosts are maintained in the desired state. These applications include:
  • Foreman: Provides for the provisioning and life cycle management of physical and virtual systems. Foreman automatically configures these systems using various methods, including kickstart and Puppet modules.
  • Puppet: A client/server architecture for configuring hosts, consisting of the Puppet Master (server) and the Puppet Agent (client).
  • Facter: Puppet's system inventory tool. Facter gathers basic information (facts) about hosts such as hardware details, network settings, OS type and version, IP addresses, MAC addresses, SSH keys, and more. These facts are then made available in Puppet manifests as variables.
The use of Puppet, Facter, and facts is discussed in more detail below.

13.4.1. The Puppet Architecture

Puppet usually runs in an agent/master (also known as a client/server) architecture, where a Puppet server controls important configuration information, and managed hosts (clients) request only their own configuration catalogs. Puppet configures hosts in two steps:
  • It compiles a catalog
  • It applies that catalog to the appropriate host
In the agent/master setup, the Puppet client sends facts gathered by Facter and other information to the Puppet Master. The Puppet Master compiles a catalog based on these facts, and then sends this catalog to the client. The client sends a report of all the changes it made, or would have made if the --noop parameter had been used, to the Puppet Master, which in turn sends the results to Foreman. This catalog describes the desired state for one specific host. It lists the resources to manage on that host, including any dependencies between those resources. The agent applies the catalog to the host.
This communication between master and agent occurs every 30 minutes by default. You can specify a different value in the /etc/puppet/puppet.conf file using the runinterval parameter. You can also run puppet agent apply to initiate communication manually.

13.4.2. Using Facter and Facts

Facter is Puppet's system inventory tool, and includes a large number of built-in facts. You can run Facter at the command line on a local host to display fact names and values. You can extend Facter with custom facts, and then use these to expose site-specific details of your hosts to your Puppet manifests. You can also use the facts provided by Facter to inform conditional expressions in Puppet.
Puppet determines a system state based on resources; for example, you can tell Puppet that the httpd service should always be running and Puppet knows how to handle that. If you are managing different operating systems, you can use the osfamily fact to create conditional expressions to tell Puppet which service to watch or which package to install. You can use the operatingsystemmajrelease and versioncmp parameters to create conditional expressions based on different versions of the same operating system. See Example 13.1, “Using Conditional Expressions with Facts” for an example of using conditional expressions.

Example 13.1. Using Conditional Expressions with Facts

if $:: osfamily == 'RedHat' {
  if $::operatingsystemmajrelease == '6' {
   $ntp_service_name = 'ntpd'
   }

  elseif versioncmp($::operatingsystemmajrelease, '7') >= 0 {
   $ntp_service_name = 'chrony'
   }
 }

Note

This example uses the expression "versioncmp($::operatingsystemmajrelease, '7') >= 0" to test for version 7 or later of Red Hat Enterprise Linux. Do not use the expression "$::operatingsystemmajrelease >= '7'" to perform this test. See https://docs.puppetlabs.com/references/latest/function.html#versioncmp for more information about this and other Puppet functions.
Puppet also sets other special variables that behave a lot like facts. See Special Variables Added by Puppet[3] and Core Facts[4] for more information.

13.4.2.1. Displaying Facts for a Particular Host

Puppet can access Facter's built-in core facts as well as any custom or external facts present in your Puppet modules. You can view available facts from the command line (facter -p) and also from the web UI (MonitorFacts). You can browse the list of facts or use the Search box to search for specific facts. For example, type "facts." to display a list of available facts.

Note

The list of available facts is very long. The UI only displays 20 facts at a time. The list of facts gradually filters as you enter more details. For example, type "facts.e" to display all facts that begin with the letter "e."

Procedure 13.16. To View Facts for a Particular Host:

  1. On the main menu, click HostsAll Hosts and then click the name of the host that you want to inspect.
  2. In the Details pane, click Facts to display all known facts about the host.

Note

  • For any fact listed on this page, you can click Chart to display a chart of the distribution of this fact name over all managed hosts.
  • You can bookmark a search to make it easier to use in the future. When you have refined your search, click the drop-down arrow next to the Search button, and click Bookmark this search. Bookmarked searches appear in the Search drop-down list, and also under AdministerBookmarks on the main menu.

13.4.2.2. Searching for Hosts based on Facts

You can use Facter information to search for specific hosts. This means that you can search for all hosts that match specific fact criteria, such as facts.architecture = x86_64.

Procedure 13.17. To Search for Hosts Based on Facts:

  1. On the main menu, click MonitorFacts to display the Fact Values page.
  2. In the Search field, start typing the name of the fact that you want to filter by. You can search by specific name, name/value pairs, and so on.
  3. Click Search to retrieve the list of matching hosts.

13.4.2.3. Custom Fact Reporting

Obtaining custom information from managed hosts is fully supported with Red Hat Satellite 6. This section illustrates using a Puppet module obtained from Puppet forge, but the principle applies equally for other sources of Puppet modules.
The number of facts reported via the standard Facter interface can be extended. For example, to gather a fact for use as a variable in modules. If a fact that describes the packages installed was available, you could search this data and make informed configuration management decisions based on the information.
To obtain a report on the packages installed on a host the process is as follows:
  • The manifest pkginventory is obtained from Puppet Forge and saved to the base system.
  • The Puppet module is added to a content view and then this is promoted to a system and deployed to that system.
  • The facts for the system are then queried using a package name. In this example, for a host called hostname and using a Satellite user with credentials username and password, the following API query would return the facts that matched the search string "bash":
    curl -u username:password -X GET http://localhost/api/hosts/:hostname/facts?search=bash
    {"hostname":{"pkg_bash":"4.2.45-5.el7_0.4"}}
    
    The search returns the package version. This could then be used to populate an external database.

Adding the pkginventory Puppet Module

To add the pkginventory Puppet module to the Red Hat Satellite Server application, download the module from https://forge.puppetlabs.com/ody/pkginventory to the base system where the Satellite Server application is installed and then follow the procedures below.

Procedure 13.18. Uploading a Puppet Module to a Repository

Puppet modules are usually stored in a custom repository named Puppet Modules. This procedure assumes you have made a custom repository with that name. If you have not yet made a custom repository for Puppet Modules, see Creating Custom Products and Repositories in the Red Hat Satellite 6.1 Provisioning Guide.
  1. Download the Puppet module to the base system. Modules that are downloaded will have a .tar.gz extension.
  2. Click ContentProducts and then click the product name in the Name field associated with the Puppet module repository. For example, Custom Products.
  3. On the Repositories tab, select the Puppet Modules repository you want to modify. For example, Puppet Modules.
  4. In the Upload Puppet Module section, click Browse, and navigate to the module that you downloaded.
  5. Click Upload.

Procedure 13.19. Adding a Module to a Content View

To distribute a Puppet module to clients, content hosts, the module must be applied to a Content View and published. Follow this procedure to add a module to a Content View.
  1. Click ContentContent Views and then select a content view from the Name menu.
  2. On the Puppet Modules tab, click Add New Module. A list of installed modules appears.
  3. From the Actions column, click Select a Version to select the module you want to add. A table of available versions appears.
  4. Click Select Version next to the version of the module that you want to add.
  5. Click Publish New Version to create the new Content View.
  6. Optionally add a description and click Save.


[3] https://docs.puppetlabs.com/puppet/3.7/reference/lang_facts_and_builtin_vars.html#special-variables-added-by-puppet
[4] https://docs.puppetlabs.com/facter/latest/core_facts.html