The following Puppet features and functionality are supported in Oracle Solaris:
Puppet installation
The Puppet software package (system/management/puppet) is not installed by default on your Oracle Solaris system. You must individually install the same Puppet Image Packaging System (IPS) package on the Puppet master and all of the nodes that will run the Puppet agent.
Puppet modules and utilities
When you install the Puppet IPS package, you get all of the core Puppet modules, as well as other modules that are specific to the Oracle Solaris release.
To display a complete list of all of the installed and available modules that are included in a Puppet installation, run the following command:
% pkg list -a *puppet*
For detailed information about a specific Puppet module, refer to the README file that is included with that module. You can also go to the Puppet web site to search for more information about a given module.
When you install Puppet, you also get the following utilities, which are designed to work in concert with Puppet:
Facter – Is a utility that Puppet uses to discover facts about a particular system, for example, OS type, CPUs, memory size, and so on. The information that Facter gathers about a system is sent to the Puppet master, which the Puppet master then uses to compile catalogs that describe a desired system state for a specific set of resources. The catalog lists all of the resources that must be managed and any dependencies between those resources. See Gathering Information About a System by Using Facter.
Hiera – Is a cross-platform, key/value lookup tool that you use to manage configuration data. You use Hiera along with Puppet to maintain site-specific data that would normally be included in a Puppet manifest. Storing site-specific data in a Hiera configuration file rather than a manifest avoids repetition, which enables you to write more generic manifests that you can reuse for multiple systems.
Puppet classes can request the data that is needed and Hiera acts as a site-wide configuration file. When Puppet loads Hiera, it uses this configuration file instead of the global file that is located in /etc/hiera.yaml. For more information, go to https://docs.puppet.com/hiera/3.1/.
Puppet agent/master model
Puppet uses an agent/master model, where the Puppet master manages important configuration information for all of the nodes (physical or virtual) 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. See How Puppet Works.
Puppet SMF service
When you install the Puppet software package, you get a single Puppet SMF service (svc:/application/puppet) with the following two instances: svc:/application/puppet:master, for the Puppet master, and svc:/application/puppet:agent, for the Puppet agent. By default, these service instances are disabled after a Puppet installation. When you enable these service instances, the daemons for these services are started. When these services are disabled, the daemons are halted. See Configuring the Puppet Master and Agent.
Puppet configuration file
Puppet provides a configuration file (/etc/puppet/puppet.conf) for both the master and the agents. This configuration is stored in the SMF repository. Many system resources are defined in the puppet.conf file. The file lists the default values that are used by the Puppet master and all of the nodes that are managed by the master.
The Puppet configuration file is generated through the svcio utility by using an SMF stencil. See Chapter 6, Using a Stencil to Create a Configuration File in Developing System Services in Oracle Solaris 11.3.
To ensure that the configuration within the puppet.conf file always matches what is in the SMF repository, never edit this file directly. Instead, use SMF commands to set the appropriate properties in the file. See svccfg(1M). Because stenciling is used to generate the Puppet configuration file, any persistent changes that you make by setting SMF properties are automatically applied to the puppet.conf file.
Puppet resources and resource types
Puppet uses resources to represent various aspects of a system, such as when and how services are run, software package management, and certain components of networking and naming service configuration. A resource can also reflect the state in which a certain aspect of a system should be.
Each resource has a resource type, which is defined by a title and a series of attributes and values that you can specify within a Puppet manifest. The values that you can declare depend on the type of configuration that you are managing. See Working With Puppet Resources and Resource Types in Oracle Solaris.
Puppet providers
Puppet providers translate the general definitions for a resource into the actions that are required to implement that resource on a specific platform. These cross-platform capabilities are enabled by the Puppet Resource Abstraction Layer (RAL), which translates configuration settings into the platform-specific commands that are required to apply the specified configuration.
For example, if you are installing a software package on an Oracle Solaris system, Puppet uses IPS, while on a Red Hat Enterprise Linux system, Puppet uses RPM (Red Hat Package Manager) to install the package.
The following are some of the key providers that are supported in Oracle Solaris:
IPS package installation, commands, publishers, facets, and mediators
SVR4 package installation
Boot environments
Datalink properties
Aggregations
Etherstubs
IP network interfaces
Naming services
Oracle Solaris Zones, Oracle Solaris Kernel Zones, and Zones on Shared Storage (ZOSS) backing stores
SMF administrative commands
SMF properties
TCP/IP tunables
Virtual area networks (VLANs)
Virtual network interface cards (VNICs)
ZFS dataset creation and property manipulation (including zpool creation and deletion for most vdev types)
Puppet command-line interface (CLI)
You use the Puppet command-line interface (CLI) to perform several actions, for example, the initial handshake between the master and agent nodes. You might also use the CLI to perform a dry run for testing purposes. You can also use the CLI to troubleshoot and debug issues with Puppet.
Other tasks that you might perform with the Puppet CLI include the following:
Managing certificates
Generating and managing reports
Accessing plug-ins
Managing resources
Displaying status
You use the following syntax to perform actions with the Puppet CLI:
# puppet subcommand [options] action [options]
Display all of the available Puppet subcommands and their usage as follows:
# puppet help
Display help for a specific subcommand as follows:
# puppet help subcommand
The following partial example shows how you would display information about the agent subcommand:
# puppet help agent puppet-agent(8) -- The puppet agent daemon ======== SYNOPSIS -------- Retrieves the client configuration from the puppet master and applies it to the local host. This service may be run as a daemon, run periodically using cron (or something similar), or run interactively for testing purposes. USAGE ----- puppet agent [--certname <name>] [-D|--daemonize|--no-daemonize] [-d|--debug] [--detailed-exitcodes] [--digest <digest>] [--disable [message]] [--enable] [--fingerprint] [-h|--help] [-l|--logdest syslog|<file>|console] [--no-client] [--noop] [-o|--onetime] [-t|--test] [-v|--verbose] [-V|--version] [-w|--waitforcert <seconds>] DESCRIPTION ----------- This is the main puppet client. Its job is to retrieve the local machine's configuration from a remote server and apply it. In order to successfully communicate with the remote server, the client must have a certificate signed by a certificate authority that the server trusts; the recommended method for this, at the moment, is to run a certificate authority as part of the puppet server (which is the default). The client will connect and request a signed certificate, and will continue connecting until it receives one. . . .
Display help for a specific subcommand's action as follows:
# puppet help subcommand action
Puppet privileges and authorizations
To configure and administer Puppet, you must be assigned the Puppet Management rights profile, or you must assume the root role. The Puppet Management rights profile includes the solaris.smf.manage.puppet and solaris.smf.value.puppet privileges. See User Rights Management in Securing Users and Processes in Oracle Solaris 11.3 for details about how user rights and privileges work.