Configuring Puppet Files

Introduction

Puppet is a platform used to configure software settings. It has a language that makes the management of settings very convenient. There are files in Puppet that contains settings used by it during configuration. Puppet settings are configured in the main configuration file, which is known as puppet.conf. However, there exist some other files. To get started with Puppet, visit Installing and Configuring Puppet Enterprise.

In this article, we will grasp the process of configuring puppet files and their various aspects in detail.

Must Recommended Topic, Types of Agents in Artificial Intelligence.

Configuring Puppet Files

The Puppet Files cover a very important aspect of Puppet. These files contain settings, complex data structures, and information regarding Puppet's performance. So, regulating and managing these files become quite necessary. One needs to be very careful while Configuring Puppet Files.

Puppet's configuration files

We have already learned in Configuring Puppet Settings that the most important settings are framed in the main configuration file, which is puppet.conf. There are several additional files for new settings and the ones that must be kept separately. Here, we will learn about these files in detail.

❄️ puppet.conf

The main configuration file configures almost all Puppet commands and services. This includes Puppet agents, the Primary Puppet server, puppetserver ca, and Puppet apply. Nearly every setting mentioned in the configuration reference can be set via puppet.conf.

❄️ environment.conf

An isolated group of agent nodes is known as an environment. Any environment can contain an environment.conf file. When the primary server serves nodes assigned to that environment, this file overrides numerous settings to maintain its command.

❄️ fileserver.conf

We configure custom static mount points for Puppet’s file server via fileserver.conf. The file resources access custom mount points, if any, with their source attributes.

❄️ puppetdb.conf

This file contains server locations and configures how Puppet connects to several servers. The puppetdb.conf file is used only if you are using PuppetDB and have connected the primary server.

❄️ autosign.conf

The autosign.conf file permits certain certificates to be signed automatically. It is valid only for the CA primary Puppet server. Using this file, a primary server not serving as a CA becomes invalid.

❄️ csr_attributes.yaml

This file contains the certificate extensions. It validates custom data for new certificates that are signing requests.

❄️ custom_trusted_oid_mapping.yaml

This file allows users to customize short names for certificate extension object identifiers (OIDs). This makes the $trusted variable more useful.

❄️ device.conf

This subcommand of puppet-device retrieves catalogs from the Primary Puppet server. It then applies this catalog to remote devices. The devices to be managed by the puppet-device command are managed by the device.conf file.

❄️ routes.yaml

This file overrides those configuration settings that involve indirect termini. It permits termini to be framed in greater detail than the puppet.conf allows.

Adding File Server Mount Points

The Puppet Server consists of several servers that serve it in some or the other ways. A file server is one of them. It is used to transmit static file content to agents. In some cases, we need to serve large files. It is not advisable to store these files in source control or distribute them within a module. In such a scenario, you can generate a custom file server mount point. This mount point will allow Puppet to serve those files from another directory.

You can check whether a file server is involved or not; you can check the Puppet code and look for the source => puppet:///... attribute. Finding such a file resource can confirm that the file server is being used.

Setting Up a Mount point

Follow these steps to set up a mount point.

• Select a directory on the disk you want to create a mount point and add your files. Ensure that PuppetServer has access to it.
• Edit the code in fileserver.conf on your Puppet Server. This must be done so that Puppet knows which directory to be associated with the new mount point.
• You may or may not edit Puppet Server’s auth.conf. This will help you allow access to the new mount point.

Now, the Puppet code can refer to the files you have added to the directory at puppet:///<MOUNT POINT>/<PATH>.

Mount points in the Puppet URI

The syntax of Puppet URI looks like this: puppet://<SERVER>/<MOUNT POINT>/<PATH>. It contains three different tags, and every tag has its relevance.

• <SERVER>

This tag is optional so you can start Puppet URI as puppet:///. There is no particular reason to specify the server. For Puppet Agent, its value is taken from the server setting by default. We take a special mock server with a modules mount point for Puppet Apply by default.

• <MOUNT POINT>

It is a unique identifier for a collection of files. You can use the table below to learn about the different types of mount points.

Mount points	Description
custom	It corresponds to your specified directory.
modules	This type serves files from the file directories of every module. It collects copied file directories from every module into one large directory. To avoid confusion, it renames each of them with the name of their module.
task	It works in a similar way as the modules mount point. The only difference is that it covers the files under the tasks directory rather than the files directory.
plugins	This type serves files from the lib directory of every module. It is the collection of copied file directories from every module into one large directory with no additional namespacing. Puppet agent utilizes this mount point while syncing plugins before a run.
pluginfacts	This type serves files from the facts.d directory of every module. It supports external facts and behaves similarly to a plugins mount point with a different source directory.
locales	This type serves files from the locale directory of every module. It supports the automatic downloading of module translations to agents. It behaves similarly to plugins mount points with a different source directory.

• <PATH>

It is the remaining part of the path to the file. The path starts from the directory, followed by the mount point.

Create a new mount point in fileserver.conf

The fileserver.conf contains the following syntax in the code to define mount points.

[<NAME OF MOUNT POINT>]
    path <PATH TO DIRECTORY>

 

Refer to the example below for a better understanding. A file at /etc/puppetlabs/puppet/installer_files/oracle.pkg would be available in manifests as puppet:///installer_files/oracle.pkg.

[installer_files]
    path /etc/puppetlabs/puppet/installer_files

 

Ensure that the user has suitable permissions to access a particular directory and its contents. 

Control access to a custom mount point in auth.conf

Any node with an appropriate certificate can access the files in the new mount point by default. A node behaves the same as the special modules and plugins mount points. That means it will fetch files if it can fetch a catalog. And if a node cannot fetch a catalog, it will not fetch files. You can limit the access to a custom mount point by configuring auth.conf file.

You must meet the following requirements to add a new auth rule to Puppet Server’s HOCON-format auth.conf file. This file is framed at /etc/puppetlabs/puppetserver/conf.d/auth.conf.

1. It should match requests to all four of these prefixes.

/puppet/v3/file_metadata/<MOUNT POINT>

/puppet/v3/file_metadatas/<MOUNT POINT>

/puppet/v3/file_content/<MOUNT POINT>

/puppet/v3/file_contents/<MOUNT POINT>

 

2. This way, it can override the file server's default rule. You can use the example below for your reference.

{
    # Allow limited access to files in /etc/puppetlabs/puppet/installer_files:
    match-request:
    {
        path: "^/puppet/v3/file_(content|metadata)s?/installer_files"
        type: regex
    }
    allow: "*.dev.example.com"
    sort-order: 400
    name: "dev.example.com large installer files"
},

Checking the values of Settings

Puppet Settings are extensively vibrant. Their values keep changing as they come from several different sources. Run the following command to know the actual setting values used by a Puppet service.

puppet config print

 

This command loads and evaluates the settings. Also, it can imitate any other commands and settings while doing so. Ensure that Puppet uses the system config file to see the values Puppet uses when running as a service. Use the sudo keyword or run the command as root or Administrator.

Use the commands below for your reference.

• To see the value of a single setting.

sudo puppet config print <SETTING NAME> [--section <CONFIG SECTION>] [--environment <ENVIRONMENT>]

 

This will display only the value of ‘SETTING NAME’.

• To see the value of multiple settings.

sudo puppet config print <SETTING 1> <SETTING 2> [...] [--section <CONFIG SECTION>] [--environment <ENVIRONMENT>]

 

This will display the values of all requested settings.

• To see the value of all settings.

sudo puppet config print [--section <CONFIG SECTION>] [--environment <ENVIRONMENT>]

 

This will display the value of every setting.

Two setting options help you to control the way settings are loaded. These are --section and --environment options. We will discuss each section ahead.

Config Sections

This option mentions which section of a puppet.conf to use while finding settings. It is not compulsory and defaults to the value in the main section. If any other section contains the setting, it overrides the main section. Its various sections are listed below.

• main (default)

Every command and service uses it.

• server

The primary Puppet server service only uses it, and the puppetserver ca command.

• agent

The Puppet agent service uses this section.

• user

It is used by the Puppet apply command and most other commands.

Environments

This option mentions which environment to use while finding settings. It is not compulsory and defaults to the value in the user section. The usual value is production, as it is rare to mention an environment in the user. Note that you can specify only those environments which exist.

The primary server service mainly uses this option, which is very rare to find for Puppet apply and Puppet agents.

Imitating Puppet Server and puppetserver ca

Use the following commands as per your requirements to see the settings for Puppet Server Service and the puppetserver ca.

• For the effective modulepath in the dev environment.

sudo puppet config print modulepath --section server --environment dev

 

You will get an output like this.

/etc/puppetlabs/code/environments/dev/modules:/etc/puppetlabs/code/modules:/opt/puppetlabs/puppet/modules

 

• To check whether PuppetDB is configured for exported resources.

sudo puppet config print storeconfigs storeconfigs_backend --section server

 

You will get an output like this.

storeconfigs = true
storeconfigs_backend = puppetdb

While writing the codes, keep in mind the following points.

1. Always mention --section server.
2. Use the --environment option to mark the environment you need settings for, or leave it to use the usual production environment.
3. Remember to put the sudo keyword.

 

If your primary server is being used as a Rack application, ensure that you check the config.ru file to check if it’s using the confdir and vardir directories. These are the standard directories. If it’s not using the standard ones, you must mention them in the command line with the --confdir and --vardir options. If you fail to do this, you may miss the correct values for settings.

Imitating puppet apply

Use the following command to see the settings for Puppet Apply. It will check whether the apply is framed to use reports or not.

sudo puppet config print report reports --section user

 

You will get an output like this.

report = true
reports = store,http

 

While writing the code, keep in mind the following points.

1. Always mention --section server.
2. Remember to put the sudo keyword.

 

Ensure that you check the agent’s init script or cron job to check if the confdir or vardir directory is running as root. These are the standard directories and must not override other settings with command line options. If it’s not behaving as you expected, there may be a need to set more options for the config print command.

Imitating Puppet Agents

Use the following command to see the settings for Puppet Agents. It will check whether the agent is framed to use manifest ordering while applying the catalog or not.

sudo puppet config print ordering --section agent

You will get an output like this.

manifest

 

While writing the code, keep in mind the following points.

1. Always mention --section server.
2. Remember to put the sudo keyword.

 

Ensure you look into the cron job or script responsible for configuring the machine with Puppet apply. It checks if the confdir or vardir directory is running as root. These are the standard directories and must not override other settings with command line options. If it’s not behaving as you expected, there may be a need to set more options for the config print command.

Editing Setting on the Command Line

Most Puppet settings are loaded in the puppet.conf file. You can edit this file or change an individual setting using the puppet config set command. You can use this command for fast one-off config changes and scriptable config changes in provisioning tools. If you find many changes, you better edit the puppet.conf file.

If you want to frame a new value to a setting, run the following command.

sudo puppet config set <SETTING NAME> <VALUE> --section <CONFIG SECTION>

 

This sets the value of <SETTING NAME> setting to <VALUE> in the mentioned config section. This is done regardless of whatever value the setting previously had.

Config Sections

This option mentions the section of a puppet.conf to be used for modification. It is not compulsory and defaults to the main section. The four allowed sections are listed below.

• main (default)

Every command and service uses it.

• server

The primary Puppet server service only uses it, and the puppetserver ca command.

• agent

The Puppet agent service uses this section.

• user

It is used by the Puppet apply command and most other commands.

Ensure that you use the sudo keyword or run the command as root or Administrator while editing the system config file.

Example

To understand how to edit the setting on the command line, we will refer to the puppet.conf example file below.

[main]
certname = agent01.example.com
server = server.example.com
vardir = /var/opt/lib/pe-puppet

[agent]
report = true
graph = true
pluginsync = true

[server]
dns_alt_names = server,server.example.com,puppet,puppet.example.com

 

Run the following commands to edit the setting.

sudo puppet config set reports puppetdb --section server
sudo puppet config set ordering manifest

 

You will get an output like this.

[main]
certname = agent01.example.com
server = server.example.com
vardir = /var/opt/lib/pe-puppet
ordering = manifest

[agent]
report = true
graph = true
pluginsync = true

[server]
dns_alt_names = server,server.example.com,server,server.example.com
reports = puppet.db

Configuration Settings

While using configuration settings, keep the following points in mind.

• The configuration settings are framed in the puppet.conf file or in the command line.
• Puppet Enterprise (PE) and open-source puppet share the same configuration settings. However, there are different default values for some settings of both versions. This includes node_terminus, storeconfigs, always_retry_plugins, disable18n, environment_timeout (when Code Manager is enabled), and the Puppet Server JRuby max-active-instances setting. You can check the puppet.conf or pe-puppet-server.conf file after installation to verify PE configuration defaults.
• If you use boolean settings on the command line, use --setting and --no-setting instead of --setting (true|false).
• You can interpolate settings as $variables in other settings. In the $environment, the puppet master will interpolate each agent node's environment instead of its own.
• Multiple settings should be framed as comma-separated lists. And multiple directories should be separated with the system path separator, usually a colon).
• Settings used to represent time intervals must be mentioned in duration format. That means an integer followed by any unit, such as years (y), days (d), hours (h), minutes (m), or seconds (s). If you forget to put the unit, it defaults to seconds (s).
• If you are using the splay setting, ensure that the period it waits changes every time the Puppet agent is restarted.
• Settings using a single file or set have the option to set the owner, group, and mode for their value in the following way.

rundir = $vardir/run { owner = puppet, group = puppet, mode = 644 }

  

• The Puppet executables ignore any setting that is irrelevant to their function.