Configuring Puppet Setting

Introduction

A Puppet is a software configuration management tool that manages many servers. It is quickly turning essential nowadays due to its high usability. It permits administrators to perform a particular activity on multiple servers simultaneously.

You can install several applications with a single click.

Thus, it makes configuring and maintaining thousands of servers convenient. Hence, also known as a remote execution tool. To get started with Puppet, visit Installing and Configuring Puppet Enterprise.

In this article, we will discuss the process of configuring puppet settings and its various aspects in detail.

Must Recommended Topic, Types of Agents in Artificial Intelligence.

When we say settings concerning Puppet documentation, it refers to the main settings. You can configure these settings in the main configuration file called puppet.conf. These are some settings that are listed in the configuration reference. They are supported only in puppet.conf and can be used to alter mostly all of Puppet’s core features.

There are a few additional configuration files, such as auth.conf and puppetdb.conf. The reasons for the existence of these files are mentioned below.

Some things cannot be configured using the main settings. These things need complex data structures and separate files to configure.
You cannot add new settings to a puppet.conf file by using extensions. Thus, a few other files exist.

Types of Settings

There are various types of configuration file settings that affect a command or service. Each of them is explained below in detail.

Puppet Server Configuration

The Puppet Server validates mostly all settings in puppet.conf file. So it picks them up automatically. But, for a few tasks, there are files and settings especially meant for Puppet Server, known as Puppet Server Configuration files. The tasks include WebServer Configuration or External Certificate Authority.

Settings loaded on startup

Some settings get loaded as soon as we start a Puppet command or service. You have to be careful with these settings because they influence the behavior of command or service. And a command or service reads the value of settings only once, making these settings sensitive. If you want to change the values, you must run the command again or restart the service after changing the settings.

Settings on the command line

Settings present on the command line are very high-priority settings. They always override every other setting from the configuration file. When you start any service or command, you can mark any setting from it as a command line option.

It requires only two hyphens and the name of the command line to make it a priority setting. An example of this is given below.

$ sudo puppet agent --test --noop --certname temporary-name.example.com

Basic Settings

You can specify the option and add value to common or basic settings.

An equals sign between the two or quotes around the values is optional. A complete configuration example with optional parameters is given below.

certname = temporary-name.example.com in puppet.conf

There are three other ways to configure the above example equivalent to it. All of these are mentioned below.

--certname=temporary-name.example.com
--certname temporary-name.example.com
--certname "temporary-name.example.com"

Boolean Settings

Settings that support only boolean values are known as boolean settings. They use a shorter format and validate only two values, true or false. Only mentioning the option alone sets the setting to true. If you want to set the setting to value, you must prefix it with no-.

An example of each of both cases is given below.

--noop is equivalent to setting noop = true in puppet.conf.
--no-noop is equivalent to setting noop = false in puppet.conf.

Default Values

A default value is assigned if a setting is not assigned on the command line or in puppet.conf. All settings do have a default value, and these values are listed in the configuration reference.

A few default values are dependent on other settings. If this is the case, the default is framed using the other setting as a variable.

Locale Settings

Puppet validates locale-specific strings in output. It looks for your locale in your system configuration. Hence, provides localized strings, log messages, and report messages for the locale’s language with its help when available.

Puppet detects a set of environment variables on *nix systems or the code page setting upon Windows start-up. As soon as a set is detected, Puppet uses that locale irrespective of where it is from, command line or puppet.conf file.

You can refer to Puppet documentation for adding new locales or providing help setting the Operating System locale.

Checking Locale Settings on *nix and macOS

To check the current locale settings, you must run the following command. This will output the settings of your current shell.

$ locale
LANG="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_CTYPE="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_ALL=

To know which locales are supported by the system, run the locale -a command. This will output a list of all available locales. Note that some available locale may exist for which localized strings are absent. You can use the set command to look for the current status of environment variables that may cause conflicts or override your locale settings. The following example command lists the environment variables containing LANG or LC_.

sudo set | egrep 'LANG|LC_'

Checking Locale Settings on Windows

To check current locale settings on Windows, run the Get-WinSystemLocale command. You can use the example below for your reference.

PS C:\> Get-WinSystemLocale

You will receive the output in the following format.

LCID            Name             DisplayName
----            ----             -----------
1033            en-US            English (United States)

To check the system’s current code page setting, use the chcp command.

Setting Locale on *nix with an environment variable

You can use the environment variables to set a locale for processes marked for the command line.

For Linux distributions, set the LANG variable to desired locale and the LANGUAGE variable to an empty string. On SLES, set the LC_ALL variable to an empty string. The example below shows how to set the locale to Japanese for any terminal session.

export LANG=ja_JP.UTF-8
export LANGUAGE=''
export LC_ALL=''

Add the export statements below to set the Locale for the Puppet Agent Service.

For RHEL and its derivatives

/etc/sysconfig/puppet

For Debian, Ubuntu, and its derivatives

/etc/default/puppet

After you have updated the file, restart the Puppet to apply the changes.

Setting Locale for the Puppet Agent Service on macOS

You must update the LANG setting in the /Library/LaunchDaemons/com.puppetlabs.puppet.plist file to set Locale for the Puppet Agent Service on macOS. An example code is given below.

<dict>
        <key>LANG</key>
        <string>ja_JP.UTF-8</string>
</dict>

After you have updated the file, restart Puppet to apply the changes.

Setting Locale on Windows

If the LANG environment variable is set, Puppet uses that to set Locale on Windows. If not set, it uses the configured region in the Administrator Tab of the Region Control Panel. Use the command below for the same.

Set-WinSystemLocale en-US

Disabling Internationalized Strings

To disable the use of internationalized strings, we use the boolean disable_i18n setting. This setting is optional and is used only when you have to disable internationalized strings. By default, it is set to false. If set to true, you will also be allowed to disable localized strings in reports, log messages, and sections of the command line interface. This improves performance, especially if environment caching is disabled.

Configure this setting in the server section of the puppet.conf file if you are facing any performance issues.

To mandate unlocalized messages, configure this setting in a node’s main or user sections of the puppet.conf file.

Key Configuration Settings

Puppet has near about 200 settings, each of which is listed in the configuration reference. A general user interacts with only a dozen of these settings. This module will help you understand the vital ones.

A few settings are used rarely but make sense, but at least a hundred are not used at all. The choice of which settings to use depends on Puppet’s design. It is because of the way Puppet code is arranged. The settings are the easiest way to introduce global constants irrespective of their initialization location.

Settings for Agents (Nodes)

The settings below are arranged according to their approximate order of importance. These settings are mostly framed in the main or agent sections or the command line.

🍃 Basics

These are common miscellaneous settings.

Settings	Description
server	It is the primary server from which we request configurations. It is set to the puppet by default. You can change it if that’s not your server name.
ca_server	Using multiple primary servers, you will have to centralize the CA. You can do this by configuring ca_server on all nodes.
report_server	It works similarly to other servers. But whether to use it or not depends on how you process reports.
certname	It is the node’s certificate name and the unique identifier. It is, by default, a fully qualified domain name and is used when requesting catalogs. Use only lowercase letters, numbers, underscores, dashes, and periods for the best compatibility. In special cases, ca is reserved and cannot be used as a certname for a normal node.
environment	This property shows the request's environment when connecting with the primary server. It is just a request, and the primary server’s ENC has the audacity to override it. This happens by default to production.
sourceaddress	This property contains the address of a multi-homed host. It is used for node communication with the primary server.

🍃 Run Behavior

These settings influence the way the Puppet catalog behaves.

Settings	Description
noop	It is set to disable by default. If enabled, the agent will not alter the node. Instead, it will detect the changes that can arise if we apply catalogs. Then, it reports to the primary server about what it can do. You can use the noop metaparameter setting to override this setting.
priority	It allows users to prioritize a few resources for sharing CPU resources. This way, the other resources will have access to processing power.
report	It is set to true by default. This setting decides whether to send reports or not.
tags	This setting limits the Puppet run to add only such resources that contain specified tags.
trace, profile, graph, show_diff	These are the tools for debugging and learning more about an agent run. It is quite useful when combined with –test and –debug commands.
usecacheonfailure	Suppose the primary server fails to return a valid catalog. In that case, this property indicates whether to fall back to the last known good catalog or not. This is the default behavior, but you can disable it anytime.
ignoreschedules	If you use schedules, this property can be useful. It is used to set up new nodes during an initial Puppet run.
prerun_command, postrun_command	It instructs commands to run on either side of a Puppet run.
ignore_plugin_errors	The default is set to true. If set to false, the node has to stop the run if pluginsync fails.

🍃 Service Behavior

These settings manipulate the way the Puppet node acts when it turns into a service.

Settings	Description
runinterval	This setting specifies how frequently a Puppet would run while working as a service.
waitforcert	The default value is set to true. This setting specifies whether to keep trying or not if the agent cannot generate a certificate initially.

🍃 Useful when running the agent from the cron

These settings are useful only when running the agent from the cron.

Settings	Description
splay and splay_limit	You are permitted to spread out agent runs by using these properties together. When running the agent as a daemon, we usually start the services far enough and out of sync. It is useful only with cron agents.
daemonize	It specifies whether or not to daemonize. Set this to false only when running the agent from the cron.
onetime	This property specifies whether or not to exit after completing the current Puppet run. Set this to true only when running the agent from the cron.

Settings for Primary Servers

These settings are mainly framed in the server section. But, if you are using Puppet apply in production, we put them in the main section. Many of these settings are used while applying nodes in standalone Puppet. This is because it acts as its primary server.

🥭 Basics

These are common miscellaneous settings.

Settings	Description
dns_alt_names	It is the list of hostnames that a server can use when acting as a primary server. The hostname an agent uses in its server setting should be added in this or the primary server’s certname setting. If you want to change the DNS names, follow these steps. Run the following code. `sudo puppetserver ca clean --certname <SERVER'S CERTNAME> sudo puppetserver ca generate --certname <SERVER'S CERTNAME> --subject-alt-names <ALT NAME 1>,<ALT NAME 2>,...` Now, turn off the Puppet Server Service. Run the following command. Restart the Puppet Server Service.
environment_timeout	It specifies the interval after which the primary server has to refresh. You can set this to unlimited for better results. In such a case, refreshing the primary server becomes a part of the deployment.
environmentpath	It specifies the location where Puppet will find a directory environment.
basemodulepath	It lists all directories containing Puppet modules we can use in every environment.
reports	It specifies which report handlers to use. To get a list of report handlers, use the report reference. You have an option to customize your report handler.
digest_algorithm	This property is specified when a user wants to accept requests from older agents while using a remote filebucket.

🥭 Puppet Server-Related Settings

Puppet Server has its puppet.conf file. As a result, there are several settings that Puppet Server neglects.

Settings	Description
puppet-admin	This setting controls the clients that can have access to the admin interface.
jruby-puppet	It provides information on syncing JRuby, leading to better performance.
JAVA_ARGS	It consists of information on syncing the Puppet Server memory allocation.

🥭 Extensions

These settings are mainly framed to configure add-ons and optional functionalities.

Settings	Description
node_terminus and external_nodes	These are ENC settings. If you are using ENC, set these settings to exec and locate them in your ENC script.
storeconfigs and storeconfigsbackend	These settings are solely used for setting up PuppetDB.
catalog_terminus	This setting is used to enable the optional static compiler. If you have a huge number of file resources, this compiler lets you reduce the workload of your CPU and transfer it to the primary server. This ensures faster configuration and reduces the HTTPS traffic on your agents.

🥭 CA Settings

Frequently Asked Questions

What do you understand by DevOps?

DevOps is the term used for a combination of advanced concepts, furious processes, and efficient tools. This combination enhances the capabilities of an organization by letting them provide products and services at a higher rate.

Explain the detailed architecture of Puppet.

Puppet uses Master-Slave architecture. The puppet slave requests the puppet master to form a secure connection by sending a slave certificate. The puppet master validates the certificate and forwards the configuration to the puppet slave upon successful receipt.

Describe the process of creating Puppet nodes.

We use the node statement or node definition to create a Puppet node. A node statement is a code section containing primary information about the node. This definition is present only in the inventories of the current node and matching nodes.

Point out the difference between agent nodes and agentless nodes.

Agent nodes are nodes with a Puppet agent installed in them. They can keep a network in the required state.

While Agentless nodes are those without a Puppet agent installed in them; hence, they are unable to keep a network stable.

Conclusion

Overall, we understood the process of Configuring Puppet Settings and its types in detail. We also discussed various key configuration settings that play a vital role in working service or command.

We hope the above discussion helped you understand the perks of Configuring Puppet Settings clearer and can be used for future reference whenever needed. To learn more about Puppet and its components, you can refer to blogs on the Overview of Puppet Server, Managing Access in Puppet, Puppet Query Language, Accessing Console in Puppet, and Token-based Authentication in Puppet.

Visit our website to read more such blogs. Make sure you enroll in our courses, take mock tests, solve problems, and interview puzzles. Also, you can pay attention to interview stuff- interview experiences and an interview bundle for placement preparations. Do upvote our blog to help fellow ninjas grow.

Happy Coding!