Go to main content

Using Puppet to Perform Configuration Management in Oracle® Solaris 11.4

Exit Print View

Updated: October 2019

How Puppet Works

Puppet enables you to define the software and configuration that a system requires and then maintain that specified state. The Puppet master controls the configuration information; each managed agent node requests its own configuration from the master and configures itself.

image:Graphic describes the Puppet agent/master topology.

Puppet discovers information about a system by using the Facter utility, which is installed when you install the Puppet software package. See Gathering Information About a System by Using Facter.

The Puppet master uses manifests to declare the resources that are needed to configure each specific managed node. You can also create a site manifest to define global configuration that applies to all of the managed nodes.

Managed nodes run the Puppet agent application, typically as a background service. The Puppet agent collects configuration information about itself and sends that information to the Puppet master. The Puppet master compiles a catalog of how the agent node should be configured. Each managed agent node uses that catalog to apply any necessary configuration updates to itself.

Puppet works by using a pull mode: Agents poll the master at regular intervals to retrieve site-specific and node-specific configuration information. For more information, See Overview of Puppet’s Architecture.

Puppet Agent/Master Model

Puppet uses an agent/master (client/server) model, where the Puppet master manages important configuration information for all of the physical and virtual nodes on which the Puppet agent is running.

Nodes that are running the Puppet agent poll the Puppet master at regular intervals and make requests for updated configuration information, which the agent then applies to the node.

The Puppet Master

The Puppet master is the primary source of configuration data and authority for Puppet. The Puppet master is a daemon that runs on a designated system and provides instructions for all of the nodes that it manages. Because some component configuration depends on the configuration of other components, the Puppet master requires information about all components of each managed node.

    The following are some of the actions for which the master is responsible:

  • Compiling the catalog for each managed agent

  • Transferring files from a file server

  • Sending reports to a central server

    Through the puppet user, the Puppet master performs the following tasks:

  • Stores configuration manifests in the puppet manifests directory

  • Accepts SSL certificates from agents

  • Transfers files to agents

  • Creates catalogs

The master daemon runs as the puppet user. The puppet user is a member of the puppet group. Running the master daemon as the puppet user helps ensure that Puppet modules can access only the information that they require from the Puppet master and helps prevent Puppet modules from being exploited or compromised. The puppet user is automatically assigned to the master daemon when you enable the puppet:master SMF service instance during the setup process. See Getting Started With Puppet in Oracle Solaris.

Puppet Agents

The Puppet agent is a daemon that runs on a managed node. To apply the configuration that the Puppet agent pulls from the Puppet master, the Puppet agent must have the ability to modify most of the configuration on the system. For this reason, the Puppet agent runs as the root user or a user that is assigned the Puppet Management rights profile.

The time interval at which agents poll the master is configurable per agent as shown in Configuring the Puppet Master and Agents.

The Puppet agent gains communication privileges from the Puppet master system by requesting a Secure Socket Layer (SSL) certificate the first time the agent contacts the master system. Subsequently, the Puppet agent receives configuration updates from the master only if the certificate is still valid.

The master also authenticates to the agents so that the agents do not receive incorrect configuration information.

Puppet Encryption and Communication Methods

Puppet interfaces with the OpenSSL toolkit, which is based on SSL and the Transport Layer Security (TLS) cryptographic protocol. Puppet uses standard SSL/TLS encryption technology and standard SSL certificates for agent and master authentication and verification. Puppet also uses SSL/TLS to encrypt the traffic flow between server and agents. SHA-256 is the default hash that is used.

    The Puppet encryption method does the following:

  • Authenticates any agent to the master

  • Authenticates the master on any agent

  • Prevents communication eavesdropping between master and agents

Puppet uses a TLS client-side X.509 certificate to perform mutual host authentication. By default, this information is stored in the /etc/puppetlabs/puppet/ssl directory. This ssl directory contains separate directories for keys, certificates, and signed requests, as well as those requests that are awaiting a signature. These directories exist on both the master and the agent. For more information, see Directories: SSLdir.

The Puppet master generates its own CA certificate and private key, initializes the Certificate Revocation List (CRL), then generates another certificate, called the server certificate. This certificate is used for SSL and TLS communications and is sent to the agent. During the master and agent exchange, the CA is stored in the /etc/puppetlabs/puppet/ssl/ca/signed directory on the master and in the /etc/puppetlabs/puppet/ssl/certs directory on the agent.

Puppet Manifests

Puppet uses a Declarative Domain Specific Language (DSL) that is similar to Ruby to define states. Puppet configuration specifications are recorded in files called manifests. Manifests have a .pp file extension and are located on the Puppet master. Manifests declare resources that define various aspects of a system, such as files, software packages, and services. Resources are grouped into classes, which expose parameters that can affect their behavior. Classes and configuration files are organized into modules. See also the Puppet Glossary and the Puppet language Resources.

Use the Puppet site.pp manifest to define global configuration that applies to all of the managed agent nodes. A site manifest can also include node-specific code. A node definition (or node statement) is a block of Puppet code that is only included in the catalogs of the nodes named after the node keyword. This feature enables you to assign specific configurations to specific nodes. For more information, see the Puppet language Node definitions.

A manifest can group several resources together into a class. Then you can use the class to apply the resources to the specified nodes. A Puppet class can include resources, variables, and additional, advanced attributes. When you assign a class to a node, that node gets all of the configurations that are part of that class. Include class declarations in a manifest as described in Writing Puppet Classes and Writing Puppet Manifests, Classes, and Modules in Oracle Solaris.

Puppet modules are self-contained collections of files and directories that can contain Puppet manifests and other objects, including files and templates. Puppet uses modules to find the classes and types that can be used for configuration management within your IT infrastructure. Puppet loads classes and defined types that are stored in modules. Declare these classes and types by name in a manifest as described in Writing Puppet Modules.