DEV Community: puppet

Handling Dirty Frag and Copy Fail with Puppet

Tony Green — Wed, 13 May 2026 21:00:55 +0000

Do you know which of your Linux servers are vulnerable right now?

Two critical Linux kernel vulnerabilities are being actively exploited. Dirty Frag targets the IP fragment reassembly modules that almost every Linux server has loaded by default. Copy Fail targets the AF_ALG cryptographic subsystem's AEAD interface. Both can allow an attacker to gain escalated local privileges, and both have interim mitigations you can deploy right now, before the kernel patches land.

The first question every team needs to answer is not "how do we fix it?" but "how many of our systems are actually exposed?" Not tomorrow, after someone runs a scanner. Not next week, when the security team finishes their audit. Right now.

If you are running Puppet, the answer is already within reach. You just need a fact.

Add these to your Puppetfile. That is it.

mod 'albatrossflavour-dirty_frag', '1.0.1'
mod 'albatrossflavour-copy_fail', '1.0.0'

Each of these open-source modules, that I have published to the Forge, ship a custom structured fact that reports vulnerability exposure on every node. No class to include. No Hiera changes. No manifest edits. Next Puppet run, the data is there.

dirty_frag reports exposure to Dirty Frag (CVE-2026-43284 and CVE-2026-43500)
copy_fail reports exposure to Copy Fail (CVE-2026-31431)

See where you stand

Once deployed, every node reports its exposure state as structured data. Here is what the output looks like.

dirty_frag

{
  "esp4": {
    "loaded": true,
    "blocked": true,
    "available": true
  },
  "esp6": {
    "loaded": false,
    "blocked": false,
    "available": true
  },
  "rxrpc": {
    "loaded": false,
    "blocked": false,
    "available": true
  },
  "vulnerable": true,
  "reboot_required": true
}

copy_fail

{
  "algif_aead": {
    "type": "builtin",
    "loaded": false,
    "active": true,
    "blocked": false,
    "available": true
  },
  "initcall_blacklisted": false,
  "vulnerable": true,
  "mitigated": false,
  "reboot_required": false
}

Both facts surface the same two summary keys that give you the answers you actually care about. vulnerable is true if the exploitable module is active. reboot_required is true if you have applied the mitigation but the module is still sitting in kernel memory.

That reboot_required flag is the one that catches people. You apply the mitigation, see the block in place, and assume you are safe. But the module is still loaded and exploitable until the machine restarts. The facts make this gap visible.

Query your entire fleet in one line

The facts land in PuppetDB like any other structured fact. No extra tooling, no scheduled scans, no agents phoning home to a separate platform. It is just data, maintained automatically every Puppet run.

Show me every node vulnerable to Dirty Frag:

puppet query 'facts[certname, value] { name = "dirty_frag" and value.vulnerable = true }'

Show me every node vulnerable to Copy Fail:

puppet query 'facts[certname, value] { name = "copy_fail" and value.vulnerable = true }'

Show me nodes where the Dirty Frag block is applied but a reboot is still needed:

puppet query 'facts[certname, value] { name = "dirty_frag" and value.reboot_required = true }'

Show me nodes where algif_aead is built into the kernel (the harder mitigation path):

puppet query 'facts[certname, value] { name = "copy_fail" and value.algif_aead.type = "builtin" }'

This is the bit that makes Puppet's model shine. You are not running a point-in-time scan. The data updates every run, automatically. As nodes get patched, rebooted, or have blocks applied, the numbers go down on their own. You can watch your exposure shrink in real time without maintaining anything.

What makes a system vulnerable?

Dirty Frag

The Dirty Frag vulnerability sits in three Linux kernel modules used for IP fragment reassembly: esp4, esp6, and rxrpc. If any of those modules is loaded, the system is exposed. The two CVEs chain together to allow privilege escalation and remote code execution through these modules.

These modules are almost universally loaded on production Linux servers. If you are running iptables, firewalld, Docker, Kubernetes, or any network policy enforcement, odds are at least esp4 is there. This one affects nearly everything.

Copy Fail

The vulnerability is a use-after-free in the AF_ALG subsystem's AEAD interface (algif_aead). An unprivileged user can trigger it by opening an AF_ALG socket and exercising the AEAD code path in a specific way.

algif_aead is present on most stock kernels but rarely used for legitimate work. The main consumers are some VPN implementations that offload crypto to the kernel, kcapi-tools, and certain FIPS-certified configurations. On systems where the module is loadable, an attacker can force-load it themselves just by opening the socket. On systems where it is built-in, it may already be active regardless of use.

Why module presence, not kernel version?

The real fix for both vulnerabilities is a kernel patch, but every distribution ships their own patched versions on their own schedules with their own version numbers. Tracking "which kernel version is safe" across Red Hat, Ubuntu, SUSE, Amazon Linux, and the rest is a moving target that goes stale the day you publish it. Module presence is the reliable signal: if the vulnerable module is active, you are exposed, regardless of kernel version.

This is also what the vendor advisories recommend. Red Hat's RHSB-2026-003 and the equivalent Ubuntu and SUSE bulletins all point to the same interim mitigation: prevent the modules from loading using install /bin/false.

When you want Puppet to enforce the block

The facts give you visibility. If you also want Puppet to actively prevent the modules from loading, include the classes.

Dirty Frag

class { 'dirty_frag':
  mitigate_esp4  => true,
  mitigate_esp6  => true,
  mitigate_rxrpc => true,
}

Copy Fail

class { 'copy_fail':
  mitigate_algif_aead => true,
}

Both classes write install <module> /bin/false directives to modprobe.d configuration files. From that point on, any attempt to load those modules (whether by autoloading, a dependency chain, or an explicit modprobe) will run /bin/false instead of loading the actual module code. The module simply cannot get into the kernel.

This is worth understanding because it is stronger than the kernel's blacklist directive. A blacklist entry only prevents autoloading, it does not stop explicit modprobe calls. install /bin/false intercepts the load at every entry point.

If the module was already loaded before the block was applied, it stays in memory until the next reboot. The reboot_required flag in both facts makes this gap visible.

This is declarative and safe. Puppet manages the config file, ensures the desired state on every run, and the classes are entirely opt-in. If your patching process handles the fix, or you are rolling out kernel updates, you might not need them at all. The facts alone give you the visibility to track progress.

Both modules ship with Hiera data defaults, so if you prefer to drive parameters through your hierarchy, see each module's README for examples.

The built-in module problem (Copy Fail only)

There is a wrinkle with Copy Fail that Dirty Frag does not have. On most stock distribution kernels, algif_aead is compiled directly into the kernel image as a built-in module. It is not a loadable .ko file, so modprobe.d has no effect on it.

For built-in modules, the mitigation is initcall_blacklist=algif_aead_init on the kernel command line (via GRUB configuration). This prevents the module's init function from running on boot. It requires a reboot to take effect.

The copy_fail module does not automate GRUB changes. Getting boot configuration wrong can render a system unbootable. You can manage GRUB with Puppet (using file_line or augeas), but that is out of scope for this module. The fact will report initcall_blacklisted: true once the parameter is in place, and reboot_required: true until the reboot completes.

The type field in the fact output tells you which mitigation path applies to each node:

builtin: needs initcall_blacklist, modprobe.d has no effect
loadable: the class and modprobe.d approach works
absent: not vulnerable, nothing to do

Force-unload a module right now (with care)

Sometimes you cannot wait for a reboot. Both modules ship a Bolt task that removes the module from the running kernel immediately:

bolt task run dirty_frag::unload module=esp4 --targets servers
bolt task run copy_fail::unload module=algif_aead --targets servers

A word of caution. Unloading a kernel module is not the same as flipping a config switch. If the module is actively in use (for example, esp4 underpins IPsec tunnels, esp6 handles IPv6 ESP, and rxrpc is used by AFS), pulling it out from under a running service can drop connections, crash VPN tunnels, or cause dependent subsystems to fail. This is exactly why the Puppet classes do not do it automatically. The classes apply the block and wait for a reboot. The Bolt tasks give you the lever to pull when you have decided the tradeoff is worth it.

Each task validates the module name, checks it is actually loaded, and gives you structured output. If the module is in use by another kernel subsystem and cannot be unloaded, the task will tell you, and you are back to "apply the block and schedule a reboot".

Test on non-production nodes first. Know what the module is doing on that system before you yank it. If in doubt, the block-and-reboot path is always the safer option.

The unload task only works for loadable modules. Built-in modules cannot be unloaded.

The workflow

Add the modules to your Puppetfile. Deploy. Done. Every node now reports its exposure.
Query PuppetDB to see where you stand. One-liner, fleet-wide answer.
Decide on mitigation. Apply the classes via Hiera for persistent blocking.
Use Tasks to immediately unload modules on critical systems that cannot wait.
Watch the numbers drop. The facts update every run. No manual tracking, no spreadsheets, no scheduled scans.

The whole approach is declarative. You tell Puppet what state you want, and it converges towards it. The facts keep reporting reality. The gap between the two is your exposure, and it is always visible.

Get started

Both of these open source modules are available on GitHub:

albatrossflavour/dirty_frag (Puppet 7/8, no dependencies)
albatrossflavour/copy_fail (Puppet 7/8, no dependencies)

Both modules have been built for RedHat, CentOS, Ubuntu, Debian, Amazon Linux, and SLES.

Puppetlabs Modules Roundup – April 2026

Jason St-Cyr — Thu, 07 May 2026 16:31:43 +0000

In April 2026, the Puppetlabs module lineup saw 8 Puppetlabs module releases, with the most notable updates collected here for a quick review.

The overall pattern in these releases was event forwarding enhancements and security and compliance platform updates, which makes this month’s roundup a useful quick scan for teams planning upgrades or routine maintenance.

Highlighted Updates

Event Forwarding Enhancements

Coordinated updates to Splunk HEC and PE Event Forwarding modules add support for orchestrator_plan event type, improving visibility into Puppet orchestrator activities with enhanced filtering and integration capabilities.

Affected modules: splunk_hec, pe_event_forwarding.

Security and Compliance Platform Updates

Comply and Comply Admin modules received coordinated releases, advancing the Security Compliance Management platform capabilities.

Affected modules: comply, complyadm.

What Updates Happened to Puppetlabs Modules in April 2026?

The following is an alphabetical listing of modules which received updates in April 2026. If a module had multiple versions released, the updates are collected together, numbered with the "latest" version available.

cd4peadm 5.15.0

📅 Latest release: 2026-04-28 (🌐 View on the Forge)

A few highlights from this release:

Added a Hiera configuration option, external_webhook_url, that allows you to set the webhook URL that Continuous Delivery sends to your VCS provider. This is useful if you are using a proxy between your VCS and CD.
Added an idle timeout to the CD console that logs users out after 30 minutes. Configure this using the Hiera option, web_session_idle_timeout_mins.
Added CSRF protection to the DeleteUserAccount and SetSuperUser endpoints by restricting them to POST requests and validating CSRF tokens issued at login and expired on logout.
20 CVEs addressed.

Check the official release notes for cd4peadm 5.15.0 for the full details.

comply 3.7.1

📅 Latest release: 2026-04-28 (🌐 View on the Forge)

A few highlights from this release:

Fixed a stale image which resulted in checksum and benchmark issues upon install.
CVE-2026-33815, CVE-2026-33816. Updated gorm.io to v5.9.2 to address these vulnerabilities.

Check the official release notes for comply 3.7.1 for the full details.

complyadm 3.7.1

📅 Latest release: 2026-04-28 (🌐 View on the Forge)

A few highlights from this release:

Fixed a stale image which resulted in checksum and benchmark issues upon install.
CVE-2026-33815, CVE-2026-33816. Updated gorm.io to v5.9.2 to address these vulnerabilities.

Check the official release notes for complyadm 3.7.1 for the full details.

lvm 4.0.1

📅 Latest release: 2026-04-30 (🌐 View on the Forge)

This release addresses two bug fixes. A race condition where lvcreate returns before udev finishes processing device-add events could cause a subsequent filesystem resource targeting the same logical volume to fail with "device or resource busy" — the fix calls udevadm settle after a successful lvcreate. The release also corrects an AIX-specific issue where boolean filesystem parameters such as isnapshot were passed to crfs as true/false instead of the required yes/no, causing the command to reject them outright.

(MODULES-11756) Wait for udev to settle after lvcreate #380 (imaqsood)
(MODULES-11788) Pass converted boolean parameter #379 (joshcooper)

pe_event_forwarding 2.3.0

📅 Latest release: 2026-04-09 (🌐 View on the Forge)

This release adds orchestrator plan-job collection controls and fixes duplicate forwarding behavior in job collection.

Added plan job data collection from the orchestrator/v1/plan_jobs API, with progress tracked in a dedicated pe_event_forwarding_plan_index.yaml state file.
Added the pe_event_forwarding::skip_plans parameter to disable plan job collection when needed.
Fixed get_jobs behavior where the first page could return more records than newly available jobs, which could cause duplicate forwarded data.
Source attribution: (PIE-1683) Add support for collecting plan data #137 (coreymbe).

peadm 3.37.0

📅 Latest release: 2026-04-01 (🌐 View on the Forge)

This release is a small change to add support for Puppet Enterprise 2025.10.0.

(PE-43654) Add support for PE 2025.10.0 #661 (davidmalloncares)

sce_linux 2.6.1

📅 Latest release: 2026-04-06 (🌐 View on the Forge)

A few highlights from this release:

Error message: comparison of NilClass with failed. Some users saw this error message and experienced catalog compilation failures when attempting to manage mounted file system options with SCE for Linux. The issue was caused by /etc/fstab files that did not have at least one comment line or blank line. The internal parser was updated to avoid the issue and help prevent compilation errors.
sce_mount_info fact does not resolve to a value. This issue is related to the Linux findmnt command, which is used to list all mounted file systems. The command, which supports different options depending on operating system, was failing on specific systems, resulting in a failure of the sce_mount_info fact. Now, if the findmnt command fails, warnings will be logged, and the /etc/fstab file will be parsed directly for mount information.
Error messages related to rsyslog. Because the version of the rsyslog logging service used on Red Hat Enterprise Linux (RHEL) 9 differs from earlier versions, users of RHEL 9 sometimes see error messages like this: imjournal: open() failed for path: '/var/lib/rsyslog/imjournal.state.tmp': Operation not permitted These messages indicate a failure to load the rsyslog imjournal module. To accommodate the changes in rsyslog and avoid this error, the module loading syntax was updated in SCE for Linux.

Check the official release notes for sce_linux 2.6.1 for the full details.

splunk_hec 2.2.0

📅 Latest release: 2026-04-09 (🌐 View on the Forge)

This release focuses on support for the orchestrator_plan event type from the puppetlabs-pe_event_forwarding module while also addressing orchestrator_plan to index mappings in util_splunk_hec template.

Added support for the orchestrator_plan event type from the puppetlabs-pe_event_forwarding module.
Added orchestrator_plan to index mappings in util_splunk_hec template.
New PE Event Forwarding filter orchestrator_plan_data_filter to allow filtering orchestrator plan event payloads.
Module dependency updated to ensure pe_event_forwarding v2.3.0+ is installed.
Removed support for Debian platform and EOL operating system versions.

Until Next Time!

That’s the full pass through the 8 Puppetlabs module releases from April 2026. The Forge links above are the quickest path to the underlying release details.

If there is a part of the Puppetlabs ecosystem that would benefit from more context in future roundups, that feedback is worth sending along.

Catch you in the next roundup for May 2026.

Puppet Continuous Delivery 5.15.0 is now available

Jason St-Cyr — Wed, 29 Apr 2026 16:20:25 +0000

Puppet Continuous Delivery (CD) version 5.15.0 is now available, with updates focused on stability, security, and day‑to‑day usability for teams running Puppet automation pipelines at scale.

If you’re already on CD 5.x, this is a straightforward upgrade that continues the work of refining the platform while keeping it aligned with current Puppet Enterprise releases and supported tooling.

The detailed release notes are linked below, but here’s a quick breakdown of what this release delivers and why you may want to upgrade.

What’s included in CD 5.15.0

CD 5.15.0 delivers targeted updates across webhook configuration, Pipelines as Code, Impact Analysis, VCS integrations, and platform security. The changes below focus on specific features and integrations rather than broad platform behavior.

Webhooks, sessions, and configuration

Added a new Hiera configuration option, external_webhook_url, which allows you to explicitly set the webhook URL that Continuous Delivery sends to your VCS provider. This is intended for deployments where CD is running behind a proxy.
Added an idle session timeout to the CD console. Users are logged out after 30 minutes of inactivity by default, configurable using the web_session_idle_timeout_mins Hiera option.

Pipelines as Code and Impact Analysis

Added the skip_empty_catalogs parameter to the Impact Analysis settings in the Pipelines as Code schema. When enabled, nodes with no catalog resources in PuppetDB are excluded from Impact Analysis results.
Fixed an issue where the browser would stop polling for Impact Analysis results when an IA run finished or when navigating away from the IA details view.

VCS integrations (Azure DevOps and GitLab)

Updated the Pipeline Summary view so the by field now displays the initiating user’s display name for Azure DevOps pipelines, instead of the user ID.
Changed how Continuous Delivery sends commit status updates to GitLab. When native GitLab pipelines are present, all CD commit status updates are now attached to the same branch pipeline, avoiding fragmented status reporting.

Data visibility and usability fixes

Fixed an issue where package_updates for pe_patch data did not appear in the fact picker. The query service was updated so this data now displays correctly.

Security and authorization hardening

Added CSRF protection to the DeleteUserAccount and SetSuperUser endpoints by restricting them to POST requests and validating CSRF tokens issued at login and expired on logout.
Fixed an issue where any authenticated user could enumerate user accounts and email addresses. Access to the GET /v1/users endpoint is now properly restricted to root and superusers.
Fixed an authorization bypass on the GraphQL /query endpoint where permission checks could be skipped when using workspace variables or omitting the id field. Authorization is now enforced consistently.

Platform and runtime updates

Added Amazon Linux 2023 as a supported platform for Docker‑based installs.
Updated the Postgres base image to postgres:17-trixie.

Security dependency updates

This release includes dependency updates to address reported vulnerabilities, including updates to:

lodash
diffjs
plexus-utils
glibc
undici
jackson
Jetty (updated to version 12)
golang.org/x/crypto
quartz
logrus
log4j2
bouncy-castle

Refer to the release notes for the full list of CVEs addressed in this release.

Why this release matters

For most users, CD sits in the middle of multiple systems: source control, CI tooling, Puppet Enterprise, and infrastructure targets. Small issues can quickly turn into pipeline friction.

CD 5.15.0 continues the effort to:

Reduce pipeline noise caused by edge‑case failures
Improve the quality of feedback when something goes wrong
Keep security posture current without forcing disruptive changes
Make upgrades between minor versions low‑risk

If you’re standardizing on CD 5.x, staying current helps ensure you’re getting fixes before they turn into operational problems.

Installation and upgrade notes

If you’re new to Puppet Continuous Delivery, start with the official install documentation:

Puppet CD installation docs

If you’re already running CD 5.x, upgrading to 5.15.0 should follow the standard upgrade path described in the documentation:

Puppet CD upgrade docs

As always, review the release notes before upgrading, especially if you rely on specific integrations or custom pipeline behavior.

Read the full details

For the complete list of fixes, security updates, and known issues, check the official release notes:

Continuous Delivery 5.15.0 release notes

If you have feedback or run into issues after upgrading, the Puppet community channels are always a good place to share what you’re seeing.

Happy automating!

Security Compliance Management 3.7.0 Is Now Available

Jason St-Cyr — Wed, 15 Apr 2026 14:56:44 +0000

Security Compliance Management (SCM) 3.7.0 helps teams assess systems against recognized security benchmarks. This release supports evolving baselines and improves audit readiness, operational reliability, and overall governance by giving administrators tighter control over platform performance, user access, and API security within the Puppet Enterprise platform.

What's new in this release

Expanded benchmark coverage for evolving environments

SCM 3.7.0 updates CIS-CAT Pro Assessor benchmark coverage to support newer operating systems and standards. This helps ensure compliance reporting remains current as teams adopt new platforms.

Highlights include:

New CIS benchmarks for numerous Linux distributions and macOS.
An updated benchmark for Microsoft Windows 11 Enterprise.

More predictable performance during compliance scans

Administrators can now control JVM memory allocation for the CIS Assessor, allowing performance tuning based on environment size and available resources. This results in more reliable scans and fewer disruptions during compliance assessments.

Greater control over user access and session behavior

New centralized session management options allow administrators to better align SCM authentication behavior with corporate security and identity policies. The outcome is reduced risk from long-lived sessions and improved governance.

Improved API governance and security posture

Additional GraphQL controls help limit exposure and enforce request limits in regulated or security-sensitive environments. The smaller API attack surface provides stronger API governance.

Security fixes and dependency updates

This release addresses multiple known vulnerabilities across core dependencies, helping reduce inherited risk and support ongoing vulnerability management.

For a complete list of addressed CVEs and detailed configuration guidance, see the release notes.

Why Upgrade to SCM 3.7.0

Organizations should consider upgrading to SCM 3.7.0 to reduce compliance gaps, stabilize large-scale assessments, and strengthen security controls as environments grow more complex.

With this release, teams can:

Maintain audit readiness as new operating systems and benchmarks are adopted.
Improve scan reliability and performance in large-scale environments managed through Puppet Enterprise.
Centralize and standardize user session and API behavior across the platform.
Reduce exposure to known vulnerabilities through updated dependencies and security fixes.

Next Steps

Review the release notes for technical details and configuration information.
Upgrade to SCM 3.7.0 to take advantage of expanded coverage and new governance controls.

Generate a Puppet Module Using GitHub Copilot and VS Code

Jason St-Cyr — Mon, 13 Apr 2026 13:23:29 +0000

This tutorial shows how to use GitHub Copilot with the Puppet Model Context Protocol (MCP) server to generate, validate, and refine a Puppet module—even if you’re new to Puppet development.

What You’ll Learn

How to configure GitHub Copilot with the Puppet MCP server
How AI agents can use the Puppet Development Kit (PDK) to generate Puppet modules
How AI agents can use the PDK to validate and iterate on generated Puppet code

The Challenge: Overcoming the Puppet Module Learning Curve

When you start automating infrastructure with Puppet, you might face an initial learning curve. You will begin to learn Puppet syntax, best practices around module structure and Puppet Domain-Specific Language (DSL), and even what tools are available to you.

To help DevOps practitioners get started, Puppet first released an MCP server to accelerate development when using the new Puppet EdgeOps module for working with network devices. Starting with Puppet Enterprise Advanced 2025.7, tools are available to provide even more guidance and information for working with agents on Puppet code in control repos, tasks, and modules. Traditional module development demanded deep domain expertise that teams often lack, but using modern AI-assisted development flows can help you bridge the knowledge gap.

Puppet's MCP server can be used with your favorite Integrated Development Environment (IDE) and code assist agent so that you can describe your requirements in natural language and work with your agent to get validated Puppet code and architecture. This tutorial demonstrates the use of Visual Studio (VS) Code and GitHub Copilot to generate a Puppet module with minimal Puppet expertise, helping you get started faster!

⚠️ Important: AI tools make mistakes, just like people. For this reason, your process should always involve review and testing as part of the end-to-end process. Use these tools to augment yourself and the team, but make those tools earn your trust.

Time to get started!

Tech Stack Overview: VS Code, GitHub Copilot, and Puppet MCP

For this tutorial, the Puppet development workflow will combine three key technologies:

Visual Studio Code: Serves as the IDE where all coding (and code generation) happens.
GitHub Copilot: Acts as the AI coding assistant that provides intelligent code suggestions and executes autonomous tasks.
Puppet MCP server: Exposes Puppet-specific intelligence through MCP, enabling GitHub Copilot to better generate Puppet solutions.

The MCP server provides several tools to provide Puppet language guides, information about Puppet environment entities, Puppet documentation, and networking info. This integration eliminates context switching between documentation, terminal windows, and code editors and provides the information required by AI agents to support smooth transitions from one step to the next.

Authentication to the Puppet MCP server happens via Puppet Enterprise (PE) API keys with secure token storage in VS Code. The MCP architecture follows a client-server model where VS Code instantiates client connections to the Puppet MCP server running in your Puppet Enterprise environment.

Prerequisites and Required Software Installation

This brief tutorial is based on the assumption that you have met several prerequisites. Plan time to go through this checklist before starting:

Obtain your authentication credentials to download Perforce Puppet applications. The credentials are either your Forge API key or your Puppet Enterprise license ID.
Install Puppet Enterprise Advanced 2025.7+.
Enable the Infra Assistant feature on your PE server. You do not have to configure the Infra Assistant OpenAI settings, but the Infra Assistant must be turned on in order for the MCP server to accept requests from your agent.
Generate a valid Puppet Enterprise API key from the console for a user with the infrastructure_assistant:use permission. (The API key is sometimes called a token.)
Install Visual Studio Code on your development machine and complete configuration tasks:
Configure the GitHub Copilot extension in Visual Studio Code.
Configure GitHub Copilot to use MCP servers in VS Code.
Ensure that your developer machine has network access to the PE console host.
Verify that your developer machine trusts the PE console CA certificate.

Tutorial Walkthrough: From Empty Repository to Generated Module

These steps walk through how you can take a completely empty repository to a validated Puppet module by using an AI-assisted flow in Visual Studio with a code assistant. Remember to meet the previously listed prerequisites! The following steps use GitHub Copilot, but if you happen to use a different stack (like Claude Code or Cursor), the process is mostly the same.

Tip: In this tutorial, “agent chat” refers to the GitHub Copilot Agent chat window in Visual Studio Code.

Using your favorite source control tool, create a blank repository to begin working.
Clone the repository and open it in Visual Studio Code.
To support the use of Puppet tools, install GitHub Copilot instructions in your solution. Sample instructions are available on GitHub. Tip: Some models cannot easily find instructions in subfolders and search only in the root directory. Some models look only for the copilot-instructions.md file. The example provides a README.md and a copilot-instructions.md file that help lead the model toward the custom Puppet instructions file.
Add the Puppet MCP server to your mcp.json file.
Start the Puppet MCP server, either by clicking Start in your mcp.json file or through the MCP Servers – Installed list in the Extensions view.
Open an agent chat window for GitHub Copilot.
Run a prompt to generate a new module. For example: “I want to create a new Puppet module to automate the provisioning of new AWS VMs. Please follow best practices for Puppet module creation.”

Note that this is a simple prompt example. To follow context engineering best practices, you would provide much more detail to get your desired output. For tutorial purposes, the prompt is intentionally lightweight. By using a simple prompt, you can recognize the extra context and benefits provided by Puppet tools to accelerate your progress.

Installing Puppet Development Kit (PDK)

At this point, your agent should be running and attempting to solve the problem. The agent will quickly detect the need for additional information from the Puppet MCP server. In addition, the agent will determine that the Puppet Development Kit (PDK) must be used to create modules. In my model testing, the GitHub Copilot agent undertook the following tasks, which required minimal input from the user:

Processed the provided Puppet instructions and determined that the Puppet MCP server should be connected to retrieve guidelines.
Attempted to connect to the Puppet MCP server for the get_puppet_guide tool and augmented the context with information from the Puppet MCP server.
Recognized that the PDK is required and attempted to check whether PDK was installed (by running pdk --version).
If PDK was not detected, attempted to fetch the PDK installation instructions.

Tip: The agent may use different URLs to search for the PDK installation instructions. Eventually, the agent will find the correct installation instructions for the operating system.
After the agent discovered the installation instructions, the agent determined that authentication credentials are required to download the software. At this point, the user would be prompted for Forge credentials or Puppet Enterprise credentials. At the prompt, you will specify the type of credentials. For example: “Here is my license ID: abcdefghizjklmnopzrstuvwxyz1”. This sample prompt informs the agent to use a Puppet Enterprise license ID, instead of a Forge API key, as the authentication method.
Submit the prompt and the agent will begin to download and install the PDK.

The agent typically installs the PDK as part of its setup routine. In practice, the agent might run incorrect commands or fail to use elevated privileges on the first attempt. When that happens, allow the agent to iterate until the installation succeeds.

💡 Tip: This is a huge boost for new users because the agent can search for instructions and quickly iterate through installation failures, while you focus on reviewing the results.

After the agent successfully completes the PDK download and installation on your behalf, the agent continues with module generation.

Generating the Module

With the PDK installed, it’s time to create the first steps of a module that will accomplish your goals. Only minimal context is provided in the tutorial example for provisioning new AWS VMs. The models will attempt to create the functionality you require based on their training data, the context from the Puppet MCP server, and the context you provide. The better your prompting, the more accurate the output will be. For this tutorial, however, assume that you are not trying to generate the module in one step and will follow up with further prompting to refine the module. During this tutorial step, the agent will generate the basics of the module.

At this stage, GitHub Copilot typically performs the following actions without requiring additional prompts:

After completing installation, validates the installation by running pdk --version.
If successful, creates a module with a PDK command like pdk new module aws_provisioning --skip-interview.
After the PDK module creation logic completes processing, creates profile classes for AWS VM provisioning. This command might be pdk new class aws_provisioning or similar.
Creates additional supporting classes. In my testing, the agent ran these additional commands:
1. pdk new class aws_provisioning::config
2. pdk new class aws_provisioning::instance
After the basic structure of the classes is in place, begins implementing Puppet code for the classes. The actions resemble typical code generation steps, creating and editing a variety of files and patching them with new implementation logic.
When the initial code generation is completed on top of the PDK skeleton implementations, updates documentation such as the metadata.json file and the README file to match the needs of the generated code.

When documentation updates are completed, a typical agent might stop without validating further. However, by setting the context for the agent with knowledge of PDK and its capabilities as well as the best practices from the Puppet MCP server, the agent knows that validation of modules is an important next step.

Validating the Module

PDK supports validation of a module to ensure that it meets specific standards. Even with the best practices and instructions that were provided to the agent, along with its training, agents can make mistakes. With validation, you can catch some of these mistakes up front. Augmenting with tools is a key strategy for agentic workflows. Using the agent as an automation process to leverage the tools you have is a great way to take advantage of more deterministic capabilities along with the non-deterministic nature of the agentic automation.

For validation, the agent should attempt to use the PDK: pdk validate
PDK should find issues, even if they are only indentation issues in YAML files. The agent should then attempt to correct the issues with code assist using the output of the PDK validation.
When the patch edits are complete, the agent should run PDK validation again (pdk validate).

If more issues are found, the agent should circle back and try to resolve them, looping until no more issues are found, but typically the first run of validation should find all issues.

You can now continue your own testing and building out the module with a solid base that follows Puppet best practices! This workflow compresses the traditional learning curve and gets you to the interesting bits of your development much faster.

Key Benefits of Agent-Assisted Module Creation

This AI-assisted approach offers several key advantages over manual development:

Agent-led requirements detection and installation help you get started so that your system achieves a correct state.
Autonomous error detection and correction reduce debugging time significantly.
The agent's ability to reference the Puppet MCP server and official Puppet documentation helps to ensure that generated code follows best practices and coding standards.
Integration with PDK tooling provides deterministic automation and continuous quality checks throughout the development process.
Structured instruction files create a consistent and repeatable development experience across different projects and team members.

By building your AI-assisted flow on top of solid DevOps tools and practices, you’ll be equipped to avoid the typical challenges faced by generic coding models.

“DevOps is not dying. It is becoming the economic and operational foundation for AI at scale.

The data shows the same pattern across every domain: AI succeeds when delivery systems are standardized, centralized, automated, and measurable. Where those foundations are weak, AI magnifies existing gaps in coordination, governance, auditability, cost, and outcomes.”

- State of DevOps Report 2026

Challenges and Solutions in AI-Assisted Puppet Development

You might encounter a few common challenges when using AI agents for Puppet module generation:

According to a recent evaluation by Vercel, coding agents ignore available skills in 56% of cases, choosing not to invoke skills even when relevant documentation exists. The solution involves using instruction files that force context loading rather than relying on agent decisions. In the evaluation, Vercel found that directly embedding a compressed 8 KB docs index into an AGENTS.md file helped coding agents achieve 100% pass rates compared to 79% with skills combined with explicit instructions. In my own tests with GitHub Copilot, references from the README.md file to other instruction files helped the agent, with less sophisticated models, to find the correct instructions and load them.
Agents sometimes refuse to use PDK or read proper installation instructions, requiring iterative prompt refinement. The solution involves adding explicit installation commands, troubleshooting steps, and URL references to your copilot-instructions.md file. Ensure that you follow best practices for instructions files to keep them lean. Getting GitHub Copilot to consistently read instruction files requires understanding that passive context (always-loaded files) outperforms active retrieval (on-demand skills). Instruction files should be concise (fewer than 1,000 lines), structured with headings and bullet points, and use imperative rules rather than long paragraphs.
AI agents can get stuck in validation and fixing loops. For linting and validation errors that agents struggle to fix, adding error-specific guidance to instruction files helps GitHub Copilot learn from mistakes. The goal is to eliminate decision points by providing persistent context rather than making agents decide when to look up information.

Table 1: Common challenges in AI-assisted Puppet module development and recommended solutions

Challenge	Impact	Solution
Agents ignore MCP tools (56% of cases)	Skills documentation not invoked when needed	Use .github/copilot-instructions.md for passive context loading (achieves 100% pass rate versus 79% with on-demand skills).
PDK installation issues	Agents fail to use PDK or read installation instructions	Add explicit installation commands and troubleshooting steps to copilot-instructions.md.
Inconsistent reading of instruction files	Agent decisions create unpredictable behavior	Provide persistent context (always-loaded files) rather than relying on agent retrieval decisions.
Incorrect Puppet code or missing namespaces or invalid spacing	Generated configurations fail validation	Include specific vendor configuration examples in instruction files and use PDK validation for testing modules.
Validation errors agents can't fix	Repeated mistakes across generations	Document error-specific guidance in instruction files so agents learn from past failures.
File structure guidelines	Keep instruction files concise (fewer than 1,000 lines) with clear structure	Use headings, bullet points, and imperative rules instead of long paragraphs.

Should You Use Agent Skills or Instructions?

Vercel's research on AI agent instruction approaches provides compelling evidence to show why instruction files are essential for effective AI-assisted development. Their evaluation tested Next.js 16 API generation using four configurations:

No documentation: 53% pass rate
Skills with default behavior: 53% pass rate, same as no documentation
Skills with explicit trigger instructions: 79% pass rate
A compressed 8 KB docs index in AGENTS.md: 100% pass rate

The static markdown file outperformed sophisticated retrieval systems because the file eliminated decision points where agents must choose whether to invoke tools. In 56% of eval cases, skills were never invoked despite being available, producing no improvement over the baseline.

Although these findings were focused on web development frameworks like Next.js, similar issues occur with agents across language frameworks and IDEs. For Puppet development, my testing found that combining instructions, PDK tooling, and the Puppet MCP server gave agents the best chance to have the correct context information.

AI-assisted development is still evolving but is expected to become an important part of many DevOps team processes. The Model Context Protocol is establishing itself as an enterprise-wide standard enabling vendor interoperability, with companies like Figma, Notion, Linear, Atlassian, and MongoDB building MCP servers that work seamlessly together.

For infrastructure-as-code specifically, the shift toward “vibe coding” is opening up the opportunity for developers to express intentions in natural language rather than memorizing command-line syntax or the specifics of the Puppet Desired State Language (DSL). Given a solid base of DevOps tools across the lifecycle, from development to testing to operations, coding assistants are well positioned to take advantage of these tools, thus unlocking opportunities for more practitioners to achieve greater efficiency across the entire workflow.

References

Check out the following sources, some of which were referenced in the document, and some of which provide a deeper dive if this topic is of interest to you!

Sample instructions for GitHub Copilot and Puppet MCP server (github.com/jst-cyr)
Installing Puppet Enterprise (PE) (help.puppet.com)
Infra Assistant: code assist (help.puppet.com)
Infra Assistant: Enable the Infra Assistant (help.puppet.com)
Infra Assistant - code assist: Available MCP tools (help.puppet.com)
Infra Assistant - code assist: Configuring your client to use the MCP server (help.puppet.com)
Infra Assistant - code assist: Add the Puppet MCP server (help.puppet.com)
SAML authentication: Generate a token in the console (help.puppet.com)
View your license details | Puppet Enterprise (help.puppet.com)
Get the Puppet CA certificate chain in Puppet Enterprise (portal.perforce.com)
Build Tasks for Network Devices Faster with Code Assistance and Puppet Edge (puppet.com)
The State of DevOps Report 2026 (perforce.com)
AGENTS.md outperforms skills in our agent evals (vercel.com)
GitHub Copilot: Use MCP servers in VS Code (code.visualstudio.com)
GitHub Copilot in VS Code (code.visualstudio.com)
Using custom instructions to unlock the power of Copilot code review (docs.github.com)
Bridging the Gap: A Deep Dive into the Model Context Protocol (MCP) (dev.to)

Puppet Core 8.18.0 is out: macOS 15 support and key security updates

Jason St-Cyr — Thu, 09 Apr 2026 12:06:38 +0000

You can now download Puppet Core 8.18.0! This update adds support for macOS 15 and includes several important security updates to help keep your infrastructure protected.

As always, Puppet Core releases focus on stability, platform support, and staying ahead of reported vulnerabilities.

👉 Official Puppet Core 8.18 release notes

What’s new in Puppet Core 8.18.0

Support for macOS 15: Puppet Core now supports macOS 15 on both x86_64 and ARM architectures. This enables continued management of macOS systems using the same automation controls and policies you already rely on.

Security focused dependency updates

Security remains a top priority in every Puppet Core release. This release includes updates to several bundled components to address recently disclosed security vulnerabilities. By delivering these updates as part of hardened Puppet Core builds, you reduce dependency risk without tracking, validating, or rebuilding components independently.

🔐 libxml2 updated

libxml2 has been updated to version 2.15.2
Addresses the following CVEs:
- CVE-2026-0989
- CVE-2026-0990
- CVE-2026-0992
- CVE-2026-1757

🔐 zlib gem updated

zlib gem updated to version 3.0.1
Addresses:
- CVE-2026-27820

🔐 curl updated

curl updated to version 8.19.0
Addresses:
- CVE-2026-1965
- CVE-2026-3783
- CVE-2026-3784
- CVE-2026-3805

If you rely on Puppet Core in security‑sensitive or regulated environments, this release is strongly recommended.

Getting Puppet Core 8.18.0

You can upgrade to Puppet Core 8.18.0 using your existing Puppet Core repositories and standard upgrade workflows. Upgrading to Puppet Core 8.18.0 helps you take advantage of the latest platform support, reduce exposure to dependency related security risk, and rely on vendor-tested packages instead of managing updates yourself.

As always:

Test upgrades in a staging environment first
Review the full release notes for platform‑specific details
Roll out broadly once validated

📄 Puppet Core Installation Docs:

Let us know how it goes

If you’re upgrading to 8.18.0, running Puppet Core on macOS 15, or have feedback on this release, let us know in the comments. Your input helps shape future updates.

Happy puppeting!

Puppetlabs Modules Roundup – March 2026

Jason St-Cyr — Mon, 06 Apr 2026 14:24:03 +0000

March 2026 brought 4 Puppetlabs module releases in the Puppetlabs Forge catalog. Read along to see what changed this month!

Across the month, the clearest themes were compatibility updates across Puppet Enterprise (PE), supported platforms, and operational hardening and troubleshooting improvements.

Highlighted Updates

Compatibility updates across PE and supported platforms

March releases leaned toward version-alignment work, with updates for newer Puppet Enterprise releases, Ubuntu 24.04 benchmark coverage, and dependency ranges that allow newer supporting modules.

Added support for PE 2023.8.9 and 2025.9.0.
Added CIS Benchmark support for Ubuntu 24.04 Server Levels 1 and 2.

Operational hardening and troubleshooting improvements

Several releases focused on making "Day Two" operations safer and easier to debug through better validation, more useful logging, and targeted runtime fixes.

Added installer untar checks and deduplicated hosts in the legacy compiler group.
Moved most SCE-specific logging into the Puppet agent run log for easier debugging.

What Updates Happened to Puppetlabs Modules in March 2026?

The following is an alphabetical listing of modules which received updates in March 2026. If a module had multiple versions released, the updates are collected together, numbered with the "latest" version available.

cd4pe 3.4.0

📅 Latest release: 2026-03-04 (🌐 View on the Forge)

This release focuses on updated puppetlabs-docker and puppetlabs-hocon dependencies to allow usage of newer versions while also addressing updated module with PDK 3.6.1.

Updated puppetlabs-docker and puppetlabs-hocon dependencies to allow usage of newer versions
Updated module with PDK 3.6.1

peadm 3.36.0

📅 Latest release: 2026-03-25 (🌐 View on the Forge)

This release focuses on adding support for PE 2023.8.9 and 2025.9.0 while also addressing deduplicate hosts in legacy compiler group.

Adding support for PE 2023.8.9 and 2025.9.0 #657 (Jade2153)
(PE-43572) deduplicate hosts in legacy compiler group #658 (davidmalloncares)
(PE-42686) Add checks to installer untar command #654 (davidmalloncares)

sce_linux 2.6.0

📅 Latest release: 2026-03-17 (🌐 View on the Forge)

This release focuses on support for Ubuntu 24.04. You can use Security Compliance Enforcement (SCE) to enforce the Center for Internet Security (CIS) Benchmark for Ubuntu Linux 24.04, v1.0.0, Server Levels 1 and 2 while also addressing support for Puppet module dependencies.

Check the official release notes for sce_linux 2.6.0

sqlserver 5.1.1

📅 Latest release: 2026-03-04 (🌐 View on the Forge)

Small change this month to ensure permission the variable is set.

(MODULES-11613) Set permission variable in permission sql EPP #500 (shubhamshinde360)

Until Next Time!

That wraps up the March 2026 roundup. If any of the modules overlap with your environment, the linked Forge pages and release notes are worth a closer look.

Feedback on the series is always useful, especially if there are module families or release-note patterns that deserve more attention in future editions.

More updates coming next month when the April 2026 releases land.

Puppet Enterprise 2025.10 Resolves Malformed Task and Plan Metadata Failures

Jason St-Cyr — Tue, 31 Mar 2026 18:28:46 +0000

We’ve released a patch in Puppet Enterprise 2025.10 to resolve an issue affecting task and plan metadata handling.

Prior to PE 2025.9: Malformed task or plan metadata was logged in the bolt-server log, and the affected task or plan was ignored. Other tasks and plans continued to work as expected.

In PE 2025.9: Malformed metadata caused the task and plan listing to fail to load entirely and prevented affected tasks or plans from running. Errors were written to the bolt-server log.

With PE 2025.10: Task and plans retain the improvements from 2025.9 but will now also load correctly even when malformed metadata is present.

More: 👉 Official 2025.10 Release Notes

Puppet Enterprise 2025.9 and 2023.8.9 are available!

Jason St-Cyr — Wed, 25 Mar 2026 13:24:08 +0000

Puppet Enterprise 2025.9 and 2023.8.9 are now available, delivering improved operational visibility, expanded agent platform support, and important security fixes for both the latest and 2023.8 LTS streams.

What's new in PE 2025.9?

In Puppet Enterprise 2025.9, this release improves day-to-day operations with:

Real-time visibility into Advanced Patching runs directly in the PE console
Clearer error and warning messages when patch group creation fails, plus retry support from the console or API
The ability to edit workflows and stop running workflows from the PE console or via API
Agent support for Debian 13 on amd64 and aarch64
Multiple CVEs addressed, along with fixes to Advanced Patching behavior and Infra Assistant reliability

What's new in PE 2025.8.9?

Puppet Enterprise 2023.8.9 adds:

Agent support for Debian 13 on amd64 and aarch64
Multiple security fixes for customers on the 2023.8 LTS stream

Release notes

🔔Lifecycle Reminder

Starting with Puppet Enterprise 2026.0 (expected August 2026), Puppet Enterprise will move from the STS/LTS model to a Latest / Latest-1 support lifecycle.

Ubuntu 24.04 support comes to Puppet SCE for Linux

Jason St-Cyr — Wed, 18 Mar 2026 17:52:28 +0000

The latest 2.6.0 version of Puppet Security Compliance Enforcement (SCE) for Linux is now available. This release adds support for Ubuntu 24.04 LTS and includes a few operational improvements aimed at making SCE easier to run and troubleshoot in day‑to‑day Puppet environments.

Below is a quick overview of what’s new.

Ubuntu 24.04 LTS support

One of the main additions in this release is support for Ubuntu 24.04 LTS. SCE for Linux now allows you to enforce the CIS benchmarks v1.0.0 on Ubuntu 24.04 systems. Both Level 1 and Level 2 CIS profiles are supported.

Operational improvements

This release also includes some changes intended to improve visibility and troubleshooting.

Logging changes

Most SCE logs are now written to the Puppet agent run log. This means you can get more insight into SCE behavior by running the Puppet agent in debug mode, rather than checking separate log locations.

Updated mount information fact

The custom fact sce_mount_info has been updated to report information about all mounted file systems, providing a more complete view of the system during enforcement.

Updated Puppet module dependencies

SCE for Linux now supports the latest versions of puppet/systemd, puppet/logrotate, and puppetlabs/augeas_core.

Resolved issues

Puppet runs no longer fail on systems where the rsyslog package is not installed. This helps avoid unnecessary failures on minimal or customized Linux images.
Unnecessary PAM_POSITION_ALIASES warning messages related to the augeasproviders_pam module should no longer display.

More details

For the full list of changes and additional details, see the official release notes:

https://help.puppet.com/sce/current/linux/scel_relnotes_260.htm

Puppet Agent OS Support EOL: 90 Day Notice

Jason St-Cyr — Fri, 13 Mar 2026 13:13:55 +0000

ℹ️ NOTE: This notice was originally posted by the Product Team on 2026-03-12

This is a 90-day notice that Puppet Agent support for the following operating system platforms is reaching End of Life (EOL). Support for these platforms will be discontinued in upcoming Puppet releases:

Amazon Linux 2
Debian 10
Fedora 40
Red Hat Enterprise Linux 7
Ubuntu 18.04
Ubuntu 20.04
Windows 10

After this period, these platforms will no longer receive updates or be included in future puppet-agent releases.

If you have any questions or concerns regarding this change, please don’t hesitate to reach out.

Puppetlabs Modules Roundup – February 2026

Jason St-Cyr — Thu, 05 Mar 2026 16:51:13 +0000

Welcome back to the Puppetlabs Modules Roundup! This series is all about keeping you in the loop on what’s new and updated in the Perforce Puppet puppetlabs modules on the Forge. This month we look back at the latest updates from February 2026.

If you want a quick look at the latest developments across the Puppet module ecosystem, this is the place to catch up!

Highlighted Updates

SQL Server 2025 and DSC Reporting Fixes

The latest sqlserver module release now supports SQL Server 2025
The latest sce_windows module corrects DSC reporting issues.

Continued Deprecation of Puppet 7 in New Releases

A few more modules received updates to have better alignment with Puppet Core and have stopped supporting Puppet 7 in the new releases, in line with changes to other modules from previous months.

Docker
firewall
inifile
sqlserver

What Updates Happened to Puppetlabs Modules in February 2026?

The following is an alphabetical listing of modules which received updates in February 2026. If a module had multiple versions released the updates are collected together, numbered with the "latest" version available.

docker 10.4.0

📅 Latest release: 2026-02-10 (🌐 View on the Forge)

Several updates to support Puppet Core better and updates for APT keyrings:

Now uses puppetlabs-apt for modern APT keyrings on Debian family (by kenyon)
APT keyring used to manage GPG key (by techsk8)
Dependency on cgroupfs-mount for Debian Trixie has been removed (by zen-fu)
Services with restart no are now ignored in the exists? method
Puppet 7 support removed
Target ruby version updated to 3.1 (2.7 removed)
Changes to better support PDK latest releases
CI tests now run against Ubuntu 24.04 (replacing Ubuntu 20.04)

firewall 8.3.0

📅 Latest release: 2026-02-09 (🌐 View on the Forge)

Several updates to support Puppet Core better and updates for SUSE IPv6:

IPv6 rule saving command added for SUSE in utility
Puppet 7 support removed
Target ruby version updated to 3.1 (2.7 removed)
Changes to better support PDK latest releases
CI tests now run against Debian 12 instead of Debian 10 for primary testing

influxdb 3.0.1

📅 Latest release: 2026-02-05 (🌐 View on the Forge)

Small release here to provide an updated GPG key.

inifile 6.3.1

📅 Latest release: 2026-02-17 (🌐 View on the Forge)

Several updates to support Puppet Core better and updates for handling empty sections:

Removing the last setting of a section will no longer remove the “empty” section (by smortex)
Puppet 7 support removed
Target ruby version updated to 3.1 (2.7 removed)
Changes to better support PDK latest releases

puppet_agent 4.27.0

📅 Latest release: 2026-02-24 (🌐 View on the Forge)

Debian 13 (Trixie) acceptance tests added for ARM and x86_64

pwshlib 2.0.1

📅 Latest release: 2026-02-24 (🌐 View on the Forge)

This release fixes per-property change event reporting in PE when using DSC resources with custom_insync.

sce_windows 2.2.1

📅 Latest release: 2026-02-24 (🌐 View on the Forge)

SCE for Windows now supports the latest versions of the puppetlabs‑pwshlib dependency, including a fix for DSC reporting issues. In addition, resource names are updated to correctly reference SCE instead of the legacy CEM name.

Check the official release notes for Security Compliance Enforcement 2.2.1

sqlserver 5.1.0

📅 Latest release: 2026-02-26 (🌐 View on the Forge)

Support was added for SQL Server 2025 along with changes to better support Puppet Core.

Support added for SQL Server 2025
Several changes to match with requirements for Puppet Core
Puppet 7 support removed
Target ruby version updated to 3.1 (2.6 removed)
Changes to better support PDK latest releases

Until Next Time!

That’s a wrap for this roundup! If you want to dive deeper into any of these modules, check out the module documentation on the Forge or explore the individual module repos on GitHub for more details.

Got feedback or ideas for future updates? We’d love to hear from you! Add a comment here or join the conversation in the Perforce Community Slack.

Catch you at the next roundup!