DEV Community: puppet

RHEL 10 support now available in Puppet SCE for Linux

Jason St-Cyr — Thu, 18 Jun 2026 16:16:41 +0000

Version 2.7.0 of Security Compliance Enforcement (SCE) for Linux is now available for download from the Forge!

Support for the RHEL 10 family

This release adds Red Hat Enterprise Linux (RHEL) 10 CIS benchmarks (v1.0.1, Server Levels 1 and 2). Teams adopting RHEL 10 or a compatible platform can bring those systems into compliance using the same trusted standards already in place across earlier RHEL versions.

Other improvements

Some other issues were also addressed, including logging issues with the rsyslog configuration file and intrusion detection on RHEL 9.

For all the details, make sure to read the full release notes

SCE Module on Puppet Forge

Security Compliance Management 3.8.0 Is Now Available

Jason St-Cyr — Tue, 16 Jun 2026 13:31:38 +0000

Security Compliance Management (SCM) 3.8.0 is here, with updates focused on keeping compliance scans running reliably with less manual intervention and an important license update.

This release introduces automatic cleanup for stuck scans, improved control over scan behavior with configurable timeouts, extended CIS-CAT® Pro Assessor license support, and updated benchmark content. It also includes important security fixes across core components.

⚠️ We recommend upgrading to SCM 3.8.0 before June 21, 2026 to avoid disruption, as the CIS-CAT Pro Assessor license included in SCM 3.7.1 expires on that date.

What’s changing in SCM 3.8.0

CIS-CAT Pro Assessor licensing and version

SCM 3.8.0 now contains CIS-CAT Pro Assessor v4.63.0
The bundled CIS-CAT® Pro Assessor license is now valid for one year
- The license shipped with SCM 3.8.0 is valid until June 2027
- The license included in SCM 3.7.1 expires on June 21, 2026

You can now also update the license without upgrading SCM:

New license_path parameter
- Allows updating the CIS-CAT Pro Assessor license independently
- Documentation: https://help.puppet.com/scm/current/Content/UserGuide/SCM/update_assessor_license.htm

Scan management, configuration, and reliability

Added a background scan sweeper to detect and cancel scans stuck in a "running" state
Fixed a race condition where timed-out Puppet Enterprise job status polls could leave scans permanently stuck
New assessor_scan_timeout option controls task timeout for Windows Server 2022 domain controllers (Note: this isn't set by default)
Increased default Max GraphQL requests limit to 300 requests

Benchmark coverage updates

New benchmarks added for Amazon Linux 2023 STIG, Microsoft Windows 11 STIG, Oracle Linux 9 STIG, RHEL 10 STIG, and SUSE 16
Updated benchmarks for: Amazon Linux 2, macOS, Debian, Windows, and Ubuntu (see the release notes for specific benchmark updates)
Removed benchmarks for:
- Azure Compute Windows Server 2019 v1.0.1
- Azure Compute Windows Server 2022 v1.0.0

Security fixes

This release includes updates to address 40 vulnerabilities across several components. The following components were updated to address the vulnerabilities:

Gorm.io
Keycloak
netty-codec
netty-codec-http
netty-codec-http2
netty-codec-haproxy
netty-handler
Protobuf
react-router

Refer to the full release notes for the complete list of CVEs.

Upgrade guidance

To avoid scan interruptions, upgrade to SCM 3.8.0 before June 21, 2026. This ensures continued use of the CIS-CAT Pro Assessor, access to updated benchmark content, improved security posture, and improvements in scan processing.

Learn more

Full release notes: https://help.puppet.com/scm/current/Content/UserGuide/SCM/Release_notes/release_notes.htm#SecurityComplianceManagement380

If you have questions or need assistance upgrading, reach out to Puppet Support.

🤖 AI Disclosure

This article was written and reviewed by the author, with the help of AI to assist in pulling together the details from multiple sources and general brand voice alignment.

How did I do that? For this particular article, I provided Microsoft 365 Copilot with the original release notes, my previous release announcement for 3.7.0, our company brand voice guidelines, and the official product release announcement that went out to customers. The LLM can then pull together the list of things that were updated and create a skeleton of an article. I then rewrite the content as needed to meet with my own tone of voice and get rid of the over-list-based approach that LLMs often take. It's also important to actually check back against the original release notes because sometimes the LLM will change certain words or remove words that change the meaning of what was in the release. I hope this helps if you are also writing with LLMs!

Selenium vs Puppeteer vs Playwright: Complete Guide for Web Scraping, Testing & AI Automation

IPFoxy — Tue, 16 Jun 2026 12:23:25 +0000

In 2026, browser automation has evolved far beyond traditional QA testing and web scraping. With the rise of LLM-powered AI Agents, automation frameworks have become the foundation for autonomous web browsing, task execution, and large-scale AI workflows.

This guide compares Selenium, Puppeteer, and Playwright across architecture, performance, scalability, AI automation compatibility, and proxy integration.

I. Introduction to the Three Automation Frameworks

**
1. Selenium: The Most Established Browser Automation Framework

Selenium was introduced in 2004 and remains the industry standard for browser automation. With Selenium 5.0, the framework has undergone a major architectural upgrade.

Key Features:
• Supports Chrome, Firefox, Edge, Safari, and other major browsers.
• Supports Java, Python, C#, JavaScript, and more.
• Large ecosystem and strong enterprise adoption.

Best For:
Automated testing, enterprise workflows, and projects requiring broad browser compatibility.

2. Playwright

Playwright was open-sourced by Microsoft in 2020 and has become the fastest-growing browser automation framework.

Key Features:
• Native support for Chromium, Firefox, and WebKit.
• Built-in Auto-Wait mechanism.
• Browser Context support for large-scale concurrency.

Best For:
Web scraping, AI Agent automation, eCommerce data collection, social media automation, and large-scale browser operations.

3. Puppeteer: Google's Native Chrome Automation Tool

Released by the Chrome team in 2017, Puppeteer popularized the Chrome DevTools Protocol (CDP).

Key Features:
• Simple and intuitive API.
• Fast execution speed.
• Popular in web scraping and browser automation.

Best For:
Chrome/Chromium automation, web scraping, screenshots, and PDF generation.

II. Real-World Performance Comparison

1. Startup Speed
In raw tests launching a headless browser, Puppeteer and Playwright achieve cold startup speeds of 100-300 milliseconds because they connect directly to the underlying binary protocols via WebSockets. Selenium, however, typically takes 1-2 seconds due to the need to initialize the corresponding Driver process and handle layered HTTP handshakes.

2. Concurrency

Selenium launches a new browser process for each isolated environment, resulting in significant memory usage.

Playwright uses BrowserContext, allowing dozens of fully isolated environments to run within a single browser process while reducing resource consumption by over 70%.

3. Stability

Modern React and Vue applications render content asynchronously. Selenium often requires manual waits, while Playwright automatically performs Actionability Checks before interacting with elements, improving reliability significantly.
**

Compatibility** If your enterprise requires testing specific rendering issues on Safari within a physical Mac environment, or if your development team relies strictly on Java/C#, Selenium’s multi-language support and deep-rooted history make it irreplaceable.

5. AI Agent Compatibility

In 2026, AI Agent + Browser Automation has become one of the hottest directions. Projects like Claude Code, OpenAI Agent, and OpenManus all prioritize Playwright by default for three key reasons:

Native MCP Protocol Support: Playwright can output the page’s Accessibility Tree directly to the LLM, eliminating the need to parse raw DOM text.
Highly Efficient Token Usage: Compared to traditional DOM serialization, Playwright's optimized approach reduces token consumption for long sessions by 3 to 4 times.
Execution Stability: Playwright’s auto-wait and auto-retry mechanisms drastically lower the failure rates of complex agent actions.

III. Proxy Integration and Anti-Detection Capabilities

For modern web scraping, accessing a page is only the beginning. Websites commonly evaluate:

• IP Reputation
• Request Frequency
• Browser Fingerprints
• Geographic Consistency

Residential Proxies provide a more authentic browsing environment than datacenter IPs and help reduce blocking risks.
IPFoxy offers residential proxies covering 200+ countries, static ISP proxies, mobile 4G/5G proxies, and supports both HTTP(S) and SOCKS5 protocols. It integrates seamlessly with Selenium, Puppeteer, and Playwright to significantly lower blocking risks for long-running scraper projects.

Here is how to configure an IPFoxy proxy across the three frameworks:
Selenium Proxy Configuration (Python)

from selenium import webdriver
from selenium.webdriver.chrome.options import Options

chrome_options = Options()
# Configure IPFoxy proxy address (with user/pass authentication)
# Static ISP or rotating residential proxies are recommended for the lowest fraud scores
proxy_server = "http://username:password@proxy.ipfoxy.com:port"
chrome_options.add_argument(f'--proxy-server={proxy_server}')

# Launch driver
driver = webdriver.Chrome(options=chrome_options)
driver.get("https://ipinfo.io")  # Verify the IP has switched to a clean residential IP from IPFoxy
print(driver.title)
driver.quit()

Puppeteer Proxy Configuration (JavaScript)

const puppeteer = require('puppeteer');
const proxy = 'http://user:pass@ipfoxy-proxy:port';

const browser = await puppeteer.launch({
  args: [`--proxy-server=${proxy}`]
});
const page = await browser.newPage();
await page.goto('https://example.com');

Playwright Proxy Configuration (Python)

from playwright.sync_api import sync_playwright

with sync_playwright() as p:
    browser = p.chromium.launch(
        proxy={
            "server": "http://ipfoxy-proxy:port",
            "username": "user",
            "password": "pass"
        }
    )
    page = browser.new_page()
page.goto("https://example.com")

IV. Which Framework Should You Choose in 2026?

Your technical choice should align directly with your business pain points and engineering stack:
Choose Playwright if:
• You are building a new web scraping, data collection, or AI Agent project.
• You need high concurrency and efficient resource usage.
• You work primarily with Python or TypeScript.

Choose Puppeteer if:
• You are a Node.js-focused developer.
• Your project only targets Chrome/Chromium.
• You require direct access to advanced CDP capabilities.

Choose Selenium if:
• Your organization relies heavily on Java or C#.
• You already have large-scale Selenium Grid infrastructure.
• Cross-browser testing is a top priority.

V. Conclusion

Selenium, Puppeteer, and Playwright are all excellent browser automation frameworks, but they serve different needs.

For web scraping, AI Agents, multi-account automation, and large-scale data collection, Playwright is often the most future-proof choice. Combined with high-quality residential proxies, it can significantly improve scraping success rates and long-term stability.

Remediating 18 OpenSSL CVEs at Scale with Puppet

Jason St-Cyr — Mon, 15 Jun 2026 14:10:21 +0000

Written by Paul Reed.

The June 2026 OpenSSL advisory is a big one. 18 vulnerabilities, one rated high severity with remote code execution potential, and a disclosure credited in part to Anthropic's Mythos model working alongside researcher Alex Gaynor. Six of those CVEs trace back to that collaboration.

When an advisory like the OpenSSL one lands, the first question is always the same: where are we exposed? If you run Puppet, you can answer that question across the entire fleet right now, patch it through one mechanism that handles every platform for you, and have it stay patched without anyone watching afterwards. The rest of this article is how.

The Vulnerability: What CVE-2026-45447 Actually Does

CVE-2026-45447 is a heap use-after-free in PKCS7_verify(). The bug fires when OpenSSL processes a PKCS#7 or S/MIME signed message where the SignedData.digestAlgorithms field is an empty ASN.1 SET.

When OpenSSL encounters this condition, OpenSSL frees a BIO object that was passed in by the calling application and is still expected to be valid. The calling application then uses the freed pointer. Depending on heap layout, that results in heap corruption, a process crash, or with a controlled heap grooming primitive, code execution.

Affected ranges:

OpenSSL 3.0.x through 3.3.x (patch to 3.5.1)
OpenSSL 1.1.1x (patch to corresponding 1.1.1 update)

The other 17 CVEs in the advisory cover authentication bypass via forged certificates (moderate, roughly a 1-in-256 success rate), ciphertext forgery, private key recovery, root CA replacement, and several DoS vectors. None are trivial in regulated environments.

Step 1: Query Your Actual Exposure

Knowing where you're exposed is where Puppet earns its keep on day zero. There's no scanner to stand up and no spreadsheet to chase round the teams. The data is already sitting in PuppetDB.

Package inventory is fed by Puppet's resource abstraction layer, the same machinery behind puppet resource package. It enumerates every package provider Puppet Enterprise supports. This means package inventory sees well beyond the system package manager: OS packages across apt, dnf/yum and zypper, and language managers like gem and pip alongside them. One query, every node:

puppet query 'package_inventory[certname, package_name, version, provider] {
  package_name ~ "(?i)openssl$|libssl$|libcrypto$"
  and
  version ~ "^(3\\.[0-3]\\.|1\\.[0-1]\\.)"
}'

Run the query against a live environment to review the results. On one fleet:

system libraries across multiple providers (libopenssl3/libopenssl1_1 via zypper, openssl and openssl-libs via dnf/yum, openssl via apt)
the Ruby openssl gem at several versions
openssl via puppet_gem on every agent node, because Puppet's own Ruby ships it
pyOpenSSL and python3-openssl via pip and the OS package manager

Most tools miss the bulk of that, because they only ever look at the system package manager. Here, anything a package manager put on the box is in scope, system libraries and language bindings together.

Scope the query to an environment by filtering against the inventory endpoint:

puppet query 'package_inventory[certname, package_name, version, provider] {
  package_name ~ "(?i)openssl$|libssl$|libcrypto$"
  and
  version ~ "^(3\\.[0-3]\\.|1\\.[0-1]\\.)"
  and
  certname in inventory[certname] { environment = "production" }
}'

Step 2: Patch It (recommended for the actual remediation)

You don't hand-write a package resource per platform, and you shouldn't. The package name varies (openssl-libs on RHEL, libssl3 on Debian, libopenssl3 on SUSE), the versions differ again, and the openssl CLI isn't even the vulnerable piece, the runtime library is. Let the tooling that already models your estate carry that.

Use the patching framework: pe_patch on Puppet Enterprise, os_patching for open source and Bolt. Classify the class and each node reports its pending updates, including which are security updates. You patch through the PE console or a task, scoped to security updates only if you want the change tight.

The OS package manager applies the vendor's security update, so the correct library package and version are chosen per platform without you encoding any of it. Reboots, update ordering, and patch and blackout windows are the framework's job. A box that can't be touched in business hours is a blackout window in config, not a workaround.

The exposure query doubles as your target list. The orchestrator takes PQL directly with -q, so there's no glue script to write. You hand the orchestrator the query and let it resolve the nodes:

puppet task run pe_patch::patch_server -q 'package_inventory[certname]{
  package_name ~ "(?i)openssl$|libssl$|libcrypto$"
  and version ~ "^(3\\.[0-3]\\.|1\\.[0-1]\\.)"
}'

That's pe_patch::patch_server on Puppet Enterprise, os_patching::patch_server for open source and Bolt. The orchestration runs the task against exactly the nodes the query returned and nothing else. Add security_only=true to keep the run tight, so a node that's already current is a no-op. If you'd rather not touch the command line, wire the same query into a node group in the PE console and drive it from there.

Step 3: Enforce It In Code

If you'd rather declare the state and have Puppet hold the state on every run, use the openssl module's class. The module knows the package names per platform:

class { 'openssl':
  package_ensure         => latest,
  ca_certificates_ensure => latest,
}

Using latest keeps the library current; set package_ensure to a specific version from Hiera if you want a pinned, auditable rollout.

This enforcement step is something a one-off script and a scanner both miss. A patch run fixes the issue once; declaring the state is what makes it stay fixed. The agent runs on a schedule, every 30 minutes by default, and enforces desired state each time. So when a node drifts back to a vulnerable version, a VM reprovisioned off a stale image, say, or a change someone made by hand and forgot, the next run quietly puts the desired state back. A scanner would notice that regression on its next sweep and open you a ticket. Enforcement just doesn't let the gap stay open that long.

The two paths aren't either/or. The patching framework is the quicker way to clear the initial backlog; enforcement is what keeps the backlog cleared. Run both and the framework does the first sweep while the module holds the line from then on.

Step 4: Restart Processes That Link the Library

Patching the package is only half the job. A running process keeps the old .so mapped until the process restarts, and a library swap under a live OpenSSL is exactly the case where that bites.

If you patched with the framework, it already tracks this for you. pe_patch reports the processes that require a restart in the node's fact, so you don't go hunting:

"reboots" : {
    "app_restart_required" : true,
    "apps_needing_restart" : {
        "1" : "/usr/lib/systemd/systemd --switched-root --system --deserialize 31",
        "586" : "/usr/lib/systemd/systemd-journald",
        "601" : "/usr/lib/systemd/systemd-udevd",
        "657" : "/sbin/auditd",
        "691" : "/usr/bin/python3 -s /usr/sbin/firewalld --nofork --nopid",
        "694" : "/usr/sbin/rngd -f --fill-watermark=0 -x pkcs11 -x nist -x qrypt -x namedpipe -x jitter -D daemon:daemon",
        "696" : "/usr/lib/systemd/systemd-logind",
        "766" : "/usr/sbin/NetworkManager --no-daemon",
        "863" : "sshd: /usr/sbin/sshd -D [listener] 0 of 10-60 startups"
    },
    "reboot_required" : true
},

apps_needing_restart is the list of processes still mapping a file that's been replaced underneath them, and reboot_required flags when a restart of individual services won't cut it. The patch run acts on these according to its reboot policy, so the same job that applies the update also clears the stale library, or tells you precisely which nodes still need a bounce. That's the manual lsof check in the next section, done for the whole fleet as a fact.

If you went the module route instead, chain the dependent services onto the class so they refresh when it changes the library:

Class['openssl'] ~> Service['nginx']

Chaining on the class rather than a Package['...'] title means you don't have to know the package name the module picks per platform. The refresh fires only when something actually changes, so steady-state runs leave your services alone.

A note on the language-level copies inventory turned up. Where a gem or pyOpenSSL links the system library, patching libssl/libcrypto fixes the underlying crypto and these processes will pick up the patch on restart. The few that statically bundle their own copy get updated through their own toolchain (gem update, pip). The OS-packaged bindings ride along with the patch run either way.

Step 5: Verify the Process Has Reloaded the Library

The reboots fact above is your fleet-wide answer. When you want to confirm a single box by hand, or you're working somewhere the fact isn't available, lsof against the actual PID tells you what that process has mapped:

sudo lsof -p $(pgrep nginx | head -1) | grep libssl

If the lsof query still shows the old path after the run, the restart didn't fire. Check the agent log or the patch run's reboot status. The openssl CLI version won't help here, the version says nothing about what a long-running daemon has mapped.

Step 6: Confirm Convergence

Re-run the inventory query to verify closure. This query doubles as audit evidence:

puppet query 'package_inventory[certname, package_name, version, provider] {
  package_name ~ "(?i)openssl$|libssl$|libcrypto$"
}'

Anything still on an affected version, across any provider, is your remaining work. Puppet Enterprise users can pull the same data from the compliance dashboard for audit review.

The Point Isn't OpenSSL

OpenSSL is this month's fire drill. Next month it's something else, and the one after that hasn't been disclosed yet. None of the steps above were really about OpenSSL. They were about having a tool already in place that answers the questions every advisory asks, before the advisory lands.

Look back at what each step actually was:

The exposure query was inventory: what have I got, and where, as of the last check-in.
The patch task, scoped from that same query, was remediation. The reboots fact was reporting, telling you what's still exposed and what needs a bounce.
Enforcement was the bit that holds the line afterwards, so a reprovisioned box can't slip back in unnoticed.

That's the whole vulnerability-response loop, and the worst time to start building it is the morning a CVE lands with the clock already running.

That's the case for putting the capability in now, while nothing's on fire. The next disclosure becomes a query and a patch run instead of a fortnight of spreadsheets and change tickets. The same loop applies well beyond library upgrades, too. We recently showed how to deal with dirty frag and copy-fail with Puppet, which walks the same detect-mitigate-remediate pattern on a different class of problem.

Using Puppet provides a consistent way to address OpenSSL vulnerabilities across environments. It'll still be set up and ready when the next vulnerability lands.

🤖 AI Disclosure

This article has been reviewed by a human expert in the subject matter and all code samples have been reviewed by Puppet technical experts. Initial structural content has been generated by Claude AI tools to assist with editing for clarity, structure, grammar, and maintaining brand voice, and then passed through human review.

What You Need to Know About the New puppetlabs-stdlib 10 in June 2026

Jason St-Cyr — Thu, 11 Jun 2026 14:31:40 +0000

The TL;DR

We are releasing puppetlabs-stdlib 10.0.1 with a target date of June 30, 2026.
This is a major version bump because we are dropping support for Puppet 7 (which reached its end-of-life in February 2025) and requiring Ruby 3.1+.
If your modules pin stdlib to < 10.0.0, they will continue to work as-is on stdlib 9.x.
You do not need to take any immediate action, but we wanted to give the community advance notice so module owners have time to plan.

Why a Major Release?

The puppetlabs-stdlib module is one of the most widely depended-upon open source modules in the Puppet ecosystem. Because of that, we take major version bumps seriously and want to be transparent about what is changing and why.

The last release of stdlib (9.7.0) was published in December 2024. Since then, maintenance work has accumulated in the main branch, updates to Puppet Core tooling, CentOS 9 support, Rubocop alignment, CI and testing infrastructure updates, and various bug fixes and enhancements contributed by both Puppet engineers and community members.

Among those accumulated changes is the removal of Puppet 7 from the supported platforms in the module metadata. Since Puppet 7 reached end-of-life over a year ago, this is a natural and expected housekeeping step. However, because removing a previously supported Puppet version is a backwards-incompatible change under semver, it requires a major version bump. By making a major version release along with the removal of Puppet 7 support, this will make a clean delineation for any users still running Puppet 7.

Additionally, the Rubocop and tooling updates in the branch enforce Ruby 3.1+ syntax standards (such as the shorthand hash syntax). While these are primarily code-style changes, they mean the module codebase is no longer guaranteed to run on Ruby versions older than 3.1, which further supports the decision to move to a new major version.

What’s Included in stdlib 10

This release rolls up approximately 18 months of changes. The highlights include:

Puppet 7 support removed: The module metadata now requires Puppet 8.0.0 or later. Puppet 7 has been end-of-life since early 2025.
Ruby 3.1+ required: Rubocop and code style enforcement now targets Ruby 3.1 standards. Syntax that is incompatible with older Ruby versions has been adopted throughout the codebase.
CentOS 9 support: The module metadata now states support for CentOS 9.
Bug fixes and enhancements: Multiple community-contributed fixes and improvements that have been pending release.
CI and testing updates: Updated testing infrastructure using Puppet Core tooling, updated nightly test matrices, and improved CI workflows.

A full changelog will accompany the release on the Puppet Forge and on GitHub.

What This Means for Module Authors

If you maintain a Puppet module that depends on puppetlabs-stdlib, here is what you need to know.

If You Do Nothing

Your module will continue to work. Most modules pin their stdlib dependency with an upper bound like "puppetlabs/stdlib": ">= 4.0.0 < 10.0.0". The Puppet module resolver will keep you on the latest 9.x release. Nothing breaks, nothing changes.

If your module did not specify an upper bound, your module will be able to start using version 10 without any changes.

If You Want to Adopt stdlib 10

When you are ready, update the upper bound of your stdlib dependency in your metadata.json:

"puppetlabs/stdlib": ">= 4.0.0 < 11.0.0"

This will allow your module to resolve either stdlib 9.x or 10.x, giving your users flexibility. You should also confirm that your module no longer requires Puppet 7 support and that your testing and CI pipelines use Ruby 3.1 or later.

Timing Is Up to You

There is no urgency to adopt stdlib 10 on day one. The 9.x line will remain available on the Forge. We encourage module owners to update at their own pace, and we are providing this advance notice specifically so you can plan that work into your roadmap rather than being caught off-guard.

What Perforce Puppet Is Doing to Prepare

We recognize that stdlib touches a huge portion of the module ecosystem. There are approximately 34 puppetlabs modules that depend on stdlib. Between now and the release date, we will be updating all of those modules to expand their dependency bounds to accept stdlib 10.x. These updated modules will be released to the Forge ahead of or alongside the stdlib 10 release so that the transition is as smooth as possible.

Our goal is that by the time stdlib 10 lands on the Forge, the puppetlabs module ecosystem will already be ready for it.

Timeline

Date	Milestone
Now	This announcement. Community has advance notice.
June 18–30	Perforce will release updated dependency bounds across puppetlabs modules.
June 30, 2026	Target release date for puppetlabs-stdlib 10 on the Puppet Forge.

A Note on Communication

We want to acknowledge that an earlier attempt to release stdlib 10.0.0 was made without sufficient advance communication to the community. We heard the feedback, rolled that release back, and are now doing this the right way: giving you notice, giving you time, and coordinating the broader module ecosystem before the release lands.

Major stdlib releases have historically been disruptive because of how deeply the module is embedded across the ecosystem. We are committed to making this transition as smooth as possible, and your feedback during this notice period is welcome and appreciated.

How to Prepare

Review your dependency bounds: Check your metadata.json for your stdlib version constraint.
Check your Puppet version support: If your module still claims Puppet 7 support, consider whether that is still necessary given Puppet 7 is end-of-life.
Check your Ruby version: Ensure your testing and CI environments use Ruby 3.1 or later.
Test against the main branch: If you want to verify compatibility ahead of the release, you can test your module against the main branch of puppetlabs-stdlib on GitHub.

Questions and Feedback

We want to hear from you. If you have questions, concerns, or feedback about this upcoming release, please reach out through any of the following channels:

Community Slack: The Puppet community Slack workspace, particularly the #forge-modules channel where we have already had some discussion on this upcoming change.
Comments on this post: We will be monitoring and responding to comments here on dev.to.
Perforce Forums: Join the discussion on the Perforce Puppet forums, part of the official Perforce Portal.

Thank you for being part of the Puppet community! We appreciate your collaboration and your contributions, and we are looking forward to getting this release into your hands.

stdlib Forge Module

Puppetlabs Modules Roundup – May 2026

Jason St-Cyr — Wed, 03 Jun 2026 21:48:48 +0000

This time around we look back at May 2026 and the 11 Puppetlabs module releases on the Forge, with an emphasis on the changes most likely to matter in active environments.

Highlighted Updates

New Windows audit policy module released!

The new audit_policy module has been released by Perforce as a Ruby replacement for the generated DSC community auditpolicydsc module.

This module uses Puppet Resources API for managing Windows audit policy using auditpol.exe

ruby_task_helper Dependency Bound Update

Five Bolt-adjacent modules all bumped the ruby_task_helper upper bound to < 2.0.0 in a coordinated maintenance pass, helping with dependency resolution failures when using Bolt 5.x.

Affected modules: vault, terraform, http_request, gcloud_inventory, azure_inventory.

CentOS 9 Support

Multiple modules added explicit CentOS 9 compatibility, expanding the Linux platform coverage in line with the broader Puppet ecosystem push.

Affected modules: concat, inifile.

What Updates Happened to Puppetlabs Modules in May 2026?

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

apt 11.3.1

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

This release introduced an explicit hash value syntax while also adding a param to support purging keyrings and other community contributions.

Includes monthly releases: 11.3.1 (2026-05-19), 11.3.0 (2026-05-18).

Use explicit hash value syntax instead of shorthand #1285 (SugatD)
Add param for purging keyrings #1266 (bwitt)
Include components when suite does not end with slash #1259 (bwitt)
Bugfix - sources format and ensure => absent fails #1243 (traylenator)
fix: allow plus signs in ppa #1222 (moritz-makandra)
Fix and improve DEB822-style template #1212 (smortex)

audit_policy 1.0.0

🌟 New Module: 2026-05-29 (🌐 View on the Forge)

This new module allows you to manage Windows audit policy with auditpol.exe as a replacement for the generated DSC community module. Initial release contains:

audit_policy_subcategory: manage Windows audit policy subcategories by display name using auditpol.exe
audit_policy_guid: manage Windows audit policy subcategories by GUID using auditpol.exe
audit_policy_option: manage global Windows audit policy options (CrashOnAuditFail, FullPrivilegeAuditing, AuditBaseObjects, AuditBaseDirectories)
audit_policy_csv: manage Windows audit policy by importing settings from an auditpol /backup CSV file
Support for Windows Server 2016, 2019, 2022, and 2025
Pure Ruby implementation — no PowerShell dependency; replaces the dsc-auditpolicydsc community module
Puppet requirement pinned to >= 8.0.0 < 9.0.0

azure_inventory 0.5.1

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

This release bumped the ruby_task_helper upper bound to < 2.0.0.

Bump ruby_task_helper upper bound to < 2.0.0 (#16)

cd4peadm 5.15.1

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

A few highlights from this release:

Fixed an issue where SAML logins were failing.
Fixed an issue where CD would not use the configured HTTP timeouts when making calls to the Azure DevOps API, resulting in unexpected timeout failures.
Fixed an issue where GitLab merge request updates that do not involve code changes would trigger CD pipelines.
CVE-2026-42198. Updated to address this vulnerability.

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

concat 10.0.0

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

This release added support for CentOS 9 while also addressing runner images for Ubuntu 24.04.

Redact sensitive content #828 (smortex)
(CAT-2296) Update github runner image to ubuntu-24.04 #823 (shubhamshinde360)
(CAT-2152) Add support for CentOS 9 #818 (skyamgarp)
Allow user defined tag or list of tags #790 (Lightning-)
Use explicit hash value syntax instead of shorthand #835 (SugatD)

gcloud_inventory 0.3.1

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

This release bumped the ruby_task_helper upper bound to < 2.0.0.

Bump ruby_task_helper upper bound to < 2.0.0 (#14)

http_request 0.3.2

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

This release bumped the ruby_task_helper upper bound to < 2.0.0.

Bump ruby_task_helper upper bound to < 2.0.0 (#18)

inifile 6.4.0

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

The inifile module now supports multiple values per key while also adding support for CentOS 9.

Add support for multiple values per key #555 (bwitt)
(CAT-2152) Add support for CentOS 9 #549 (skyamgarp)

puppet_agent 4.28.0

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

Updates to new tooling (Bolt, PDK Templates) as well as support for MacOS 26 and some pre-work for the upcoming Puppet Core 9.

(PA-7824) Use newest Bolt #829 (mhashizume)
(PA-7897) Update to pdk-templates 3.6.1.1 #825 (joshcooper)
(PA-8250) Allow installation of puppetcore9-nightly packages #822 (joshcooper)
(PA-8238) Add support for MacOS 26 in install_shell.sh #821 (shubhamshinde360)
(PA-8250) Restore windows command to check puppet service #826 (joshcooper)
(PA-8041) Fix puppetcore8-nightly installs on rpm and mac #824 (joshcooper)
(PA-8247) Add guard against other ruby process when installing #823 (AriaXLi)

terraform 0.7.2

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

This release bumped the ruby_task_helper upper bound to < 2.0.0.

Bump ruby_task_helper upper bound to < 2.0.0 (#37)

vault 0.4.1

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

This release bumped the ruby_task_helper upper bound to < 2.0.0.

Bump ruby_task_helper upper bound to < 2.0.0 (#19)

Until Next Time!

That closes out the May 2026 update set. For deeper implementation detail, the linked module pages and release notes remain the best source of truth.

If you have feedback on the roundup format or want a deeper look at a specific module area, the Perforce Community Slack is still the best place to continue the conversation.

See you next month with a roundup for June releases!

Puppet Core 8.19 and PDK 3.7: Security Updates, Dependency Changes, and Windows Fixes

Jason St-Cyr — Thu, 21 May 2026 16:17:55 +0000

Puppet Core 8.19.0 focuses largely on security hardening, with some dependency cleanup and a small but important fix for Windows user management.

If you already run Puppet Core 8, this release is primarily about keeping your runtime secure and predictable, rather than introducing new workflows or configuration changes.

➡️ Full details: Puppet Core 8.19.0 release notes

PDK 3.7.0 was also released to improve performance on Windows, update dependencies, and provide other updates for security and known issues.

➡️ Full details: PDK 3.7.0 release notes

CSV gem dependency removed

Puppet Core no longer depends on the CSV Ruby gem.

Removes an external dependency from the Puppet runtime
Reduces overall dependency surface area
Simplifies installation and long-term maintenance

This change does not alter Puppet DSL behavior or require configuration changes.

Security updates

Puppet Core 8.19.0 updates several bundled runtime components to address recently disclosed security vulnerabilities. These updates apply automatically when you upgrade.

Ruby updated to 3.2.11 (CVE-2026-27820)
OpenSSL updated to 3.0.20 (CVE-2026-28387, CVE-2026-28388, CVE-2026-28389, CVE-2026-28390, CVE-2026-31789, CVE-2026-31790)
libxml2 updated to 2.15.3 (CVE-2026-6732)
curl updated to 8.20.0 (CVE-2026-6253, CVE-2026-6276, CVE-2026-6429, CVE-2026-7009, CVE-2026-7168)
net-imap updated to 0.4.24 (CVE-2026-42245, CVE-2026-42246, CVE-2026-42256, CVE-2026-42257, CVE-2026-42258)
erb updated to 6.0.4 (CVE-2026-41316)

ℹ️ Important note for net-imap users

If you use net-imap directly in custom Ruby code, the updated version enforces stricter argument validation. Check the release notes for some details on how to manage this gem if you cannot use the upgraded version of net-imap.

Windows user passwords now allow colons

When managing user resources on Windows, Puppet Core no longer rejects passwords containing colons (:).

Affects Windows platforms only
Behavior on other platforms is unchanged

This prevents unnecessary failures when managing Windows accounts with valid password formats.

Installation safeguards for Ruby versions

Puppet Core now prevents installation on unsupported Ruby versions.

Puppet Core 8 enforces a maximum supported Ruby version of 3.x
Prevents installation attempts using unsupported versions (such as Ruby 4)
Protects against installation failures like can't modify frozen Hash

This applies when installing Puppet Core via bundler or gem commands.

PDK 3.7.0 changes

This version of PDK was updated to help prevent security issues and reduce test failures, and made macOS 15 downloads available.

Rexml updated to version 3.4.4 to address CVE-2025-58767
macOS 15 downloads now available
Windows performance has been improved
YAML file validation issues should be resolved
Several puppet_forge gems and dependencies were updated

Should you upgrade?

Upgrading to Puppet Core 8.19.0 is recommended for Puppet Core 8.x users if:

You want current security fixes for bundled runtime dependencies
You manage Windows users with complex passwords
You want to avoid accidental installation on unsupported Ruby versions

Want to get started? Here are the install/upgrade guides:

For full details and CVE listings, see the release notes:

➡️ Puppet Core 8.19.0 release notes
➡️ PDK 3.7.0 release notes

Creating Successful Migration Workflows with Puppet

Tony Green — Mon, 18 May 2026 10:11:59 +0000

The goal isn't to move things. It's to only move them once.

I've been doing this for over thirty years.

Sysadmin, ops lead, global teams, and more data centre migrations than I'd like to admit. Site to site, P2V, V2V, cloud, hybrid, all of it.

Every migration gets sold as a clean, well-planned transition. None of them are.

They go wrong in very predictable ways. Not because moving infrastructure is especially difficult, but because nobody ever has a clear, current view of what's actually running, what's changed, and what still matters. So people fall back to spreadsheets, SSH sessions, scripts written at 2am, and a lot of "we think this is right".

That's where migrations fail. Not in the move itself, but in the loss of control around it.

Why migrations go wrong

After you've done a few of these, the pattern is obvious. Three things show up every time.

The first is drift. Most environments look well understood on paper. In reality, versions don't match, configurations have wandered off in their own directions, "identical" servers aren't, and there are systems no one owns but everyone is afraid to touch. I once worked on an estate where three "identical" app servers were running three different JVM versions, and nobody could tell me which one production traffic was actually landing on. You start the migration with an incomplete picture and everything after that is guesswork. It gets worse once the migration is underway, because people make manual fixes to keep things moving, and nothing lasts as long as a temporary solution.

The second is manual execution. No matter how good the plan looks in the slide deck, at some point it turns into a human running commands on a list of hosts they pasted out of a spreadsheet. Sequencing becomes tribal knowledge. Parallelisation becomes guesswork. The rollback plan, if anyone wrote one down, is usually a single line that says "restore from backup".

The third is lost accountability. During a migration more people have access, more changes are happening, and less of it gets tracked properly. So when something breaks at 3am, nobody is quite sure what changed, or who changed it, or how to undo it. By the time you've worked it out, the on-call engineer has lost an evening and the project has lost a week of trust.

None of this is new. What's interesting is that all three problems have the same root cause. There's no consistent way to know what your estate looks like and operate it predictably while it's moving.

The four things you need to stay in control

Fixing this comes down to four things. You need to know what's actually out there. You need a way to say what it should look like. You need to be able to operate it safely at scale. And you need to know who's allowed to do what. Most teams have bits of all four scattered across different tools, which is why nothing quite lines up when it matters. Puppet Enterprise gives you all four in one place. One model, one set of controls, one audit trail. Not four tools you have to glue together yourself and pray they agree with each other.

Visibility

Most migrations start with a discovery phase that's stale before the spreadsheet is finished.

What you actually want is continuous visibility, and that's what facter does. facter runs on every node, collects system information, and reports it back centrally dozens of times a day. Out of the box you get the obvious things (OS, kernel, memory, network) but the part that matters during a migration is custom facts. You can teach facter to collect anything you care about.

Here's a small one that reports the version of an in-house payments app by reading a file the deploy pipeline drops on disk:

Facter.add(:payments_version) do
  setcode do
    if File.exist?('/opt/payments/VERSION')
      File.read('/opt/payments/VERSION').strip
    end
  end
end

Once that fact exists, every node running the app reports its version on every Puppet run. Five minutes later you can ask Puppet Enterprise "show me every node where payments_version is older than 4.2" and get a real answer, not a guess. Multiply that across the dozen things you actually care about (JVM version, storage layout, mount points, whether a vendor agent is running, whether a system is genuinely in use) and you've replaced your discovery spreadsheet with something that updates itself.

That's the bit most teams never quite get to. Half the battle in a migration is just knowing what you've got.

State

Once you know what you've got, the next problem is making sure it behaves the way you expect.

This is the part Puppet has been doing for years. You define the desired state in code, and that code gets applied consistently across the old data centre, the new one, and any cloud environment you're bringing into the mix. No golden images quietly drifting. No "we rebuilt it by hand and it's nearly the same".

The reason this matters during a migration is that it lets you stand up the new environment alongside the old one and keep them honest. Same roles, same profiles, same definitions. The question stops being "did we build this correctly?" and becomes "does it match the defined state?". The second question has an answer. The first one rarely does.

Execution

At some point you actually have to do things. Stop services, drain load balancers, run pre-flight checks, kick off data sync, validate the result, move on. This is the bit that usually collapses into SSH and good intentions.

Puppet Tasks and Plans give you a way to do it properly. Tasks run actions across large numbers of nodes. Plans sequence those actions and react to what they return. You target nodes by what Puppet already knows about them, not by a hand-built host list, which means the targeting stays correct as the estate changes underneath you.

Here's roughly what a cutover step looks like as a Plan:

plan migration::drain_web (
  TargetSpec $nodes,
) {
  $targets = get_targets($nodes)
  run_command('systemctl stop nginx', $targets)
  run_task('healthcheck::wait_for_drain', $targets, timeout => 300)
  return "drained ${targets.size} nodes"
}

Nothing clever. The point is that it's the same plan whether you're draining four nodes or four hundred, it runs through the orchestrator with the same RBAC and the same logging as everything else, and you can call it from another plan that drains the web tier, then the app tier, then flips DNS. The chaos of cutover night turns into something you can rehearse.

Control

The last piece is the one most people only think about after something has already broken.

During a migration more people have access, more changes are happening, and the blast radius of a mistake is bigger. You need to know who can define behaviour, who can execute it, and who can see what's going on. Puppet Enterprise handles that through RBAC and its reporting layer. You can let a team run specific tasks against specific systems without handing them the keys to the kingdom, and you can give read-only visibility to the people who need to know what's happening without putting them in the room.

The same controls apply no matter how the work is triggered. A change ticket in ServiceNow, a step in a CI/CD pipeline, an approval workflow, or someone clicking a button in the console all run the same plans against the same nodes. Same RBAC checks, same audit trail. That matters during a migration because cutover work doesn't all come from one place. Some of it is planned change, some is automated, some is "the network team needs us to drain that rack in the next ten minutes", and you don't want each route to have its own access model and its own log.

If you're running PE Advanced, the same model extends into compliance. Continuous reporting, CIS benchmarks running on every node, and the ability to show an auditor that the new environment was in the expected state on the day you cut over. During a migration that evidence is the difference between "we think it went well" and "here's the report".

A few things that come along for the ride

If part of your migration is moving workloads into the cloud, PE Advanced ships with CloudOps and FinOps capabilities that are genuinely useful in flight, not just once you've landed.

Once your cloud accounts are connected, you get visibility of what's actually running, what it's costing, and what's been left switched on by mistake. Migrations are very good at producing all three: orphaned instances, oversized VMs that someone picked "to be safe", and test environments that nobody remembered to turn off.

The bit that makes this useful rather than just another dashboard is that it's tied to the same node inventory you're already managing with Puppet. So the cost story doesn't end up as a separate project six months after cutover, run by people who don't know which servers were meant to be there in the first place.

A couple of other things in PE Advanced are worth knowing about for the same reason. The data connector pushes Puppet's facts, reports, and events into whatever SIEM or observability platform you already run, so the migration shows up in the same dashboards your SOC and SREs are already watching, instead of being a parallel universe nobody looks at. And the ServiceNow integration syncs bi-directionally with your CMDB, which means the live view Puppet has of the estate stops drifting away from the system of record the rest of the business is using. Both of those matter more during a migration than at any other point in the life of an environment, because both are usually where the wheels come off after cutover.

You don't have to throw away what you've got

One thing worth saying clearly, because it comes up in every conversation I have about this. You don't need to rip out your existing tooling to do any of it.

Most environments I see are a mix of on-prem and cloud, multiple operating systems, and whatever automation has grown over the years. Usually that includes Ansible, a pile of homegrown scripts, and a fair bit of "don't touch that, it works". Trying to standardise all of that during a migration is a mistake. It adds risk at exactly the moment you want less of it.

A more practical approach is to orchestrate what you already have. Puppet Tasks can call existing scripts and Ansible playbooks, sequence them alongside Puppet-managed actions, and target the right systems based on facts and roles. Instead of maintaining multiple inventories and disconnected workflows, you get one control layer driving everything you already run.

Puppet isn't replacing those tools. It's coordinating them. That lets you keep what works, cut the duplication, and converge on a more consistent model over time, which is a much safer place to be in the middle of a migration than mid-rewrite.

Final thought

A data centre migration isn't really a logistics problem. It's a control problem.

If you know what's out there, what state it's in, and who's changing it, you can move systems safely, validate them properly, and recover when things don't go to plan. If you can't, it doesn't matter how good the plan looked at kickoff. You'll be discovering the gaps the hard way, one outage at a time.

The goal of a migration isn't to move things. It's to only have to move them once.

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.

Why GRC Should Matter to Every Developer, Not Just Compliance Teams

neviarrawlinson — Wed, 06 May 2026 13:53:13 +0000

Why GRC Should Matter to Every Developer, Not Just Compliance Teams

When most people hear "GRC" — governance, risk management, and compliance — they think of legal teams, auditors, or cybersecurity experts. Rarely do they think of developers.

But the truth is, GRC affects everyone who builds, ships, and maintains technology.

Whether you realize it or not, the choices you make in your code, architecture, or workflows impact your organization's ability to stay secure, compliant, and trusted.

What is GRC Anyway?

GRC stands for:

Governance: Making sure decisions align with company goals and policies.
Risk Management: Identifying and reducing potential threats to systems, data, and users.
Compliance: Following the laws, regulations, and industry standards that apply to your work.

At its core, GRC is about protecting the business and its customers while enabling growth.

And guess who sits at the heart of building that growth? Developers and tech teams.

Why Developers Should Care

Here’s why GRC should be part of every developer’s mindset:

Security starts in the code: Secure coding practices directly affect risk management.
Documentation matters: Process documentation makes audits and compliance checks smoother — and helps your team scale faster.
Tech debt can become risk debt: Skipping best practices today can create serious governance and compliance issues tomorrow.
Customers expect trust: Data breaches and compliance failures destroy trust. Good GRC practices protect it.

How Developers Can Contribute to GRC

You don't need to become a compliance officer overnight.

Simple steps make a big difference:

Follow secure coding guidelines (like OWASP Top 10).
Document your APIs, services, and system behaviors clearly.
Keep dependencies up-to-date and monitor for vulnerabilities.
Understand the compliance requirements that apply to your industry (HIPAA, GDPR, SOC 2, etc.).
Speak up if you see a potential risk or issue — risk management is everyone's job.

Final Thoughts

GRC is not just a checkbox for the legal team.

It’s a shared responsibility — and one that smart developers embrace.

When you understand governance, risk, and compliance, you become a more valuable teammate, a better builder, and a stronger protector of your organization’s future.

Tech doesn’t exist in a vacuum. Neither does trust.

Let’s build better, safer, more resilient systems — together.

Puppet for System Administrators: A Comprehensive Guide

Pranay Trivedi — Sat, 02 May 2026 06:30:14 +0000

Introduction

In the ever-evolving world of IT, effective configuration management is vital for maintaining system integrity and optimizing workflow. Puppet stands as a powerful automation tool designed specifically for system administrators. It empowers them to manage infrastructure as code, ensuring consistency, reliability, and reduced manual effort.

What is Puppet?

Puppet is an open-source software configuration management tool that allows you to define the state of your infrastructure. It enables automation of system administration tasks across a network of devices. Here are key features of Puppet:

Declarative Language: Puppet uses a simple, declarative language to define system states.
Resource Abstraction: You can manage multiple resources like files, packages, and services without worrying about underlying system specifics.
Idempotency: Puppet ensures that no matter how many times you apply a configuration, the final state remains unchanged.

Why Use Puppet?

For system administrators, Puppet offers several compelling benefits:

Efficiency: Automate repetitive tasks to save time.
Consistency: Ensure uniform configurations across different systems.
Scalability: Easily manage large numbers of servers across diverse environments.
Version Control: Puppet allows tracking of changes, akin to software development, facilitating better rollback capabilities.

Getting Started with Puppet

Before diving deeper into Puppet's capabilities, here are some practical tips for getting started:

Install Puppet: Start by installing Puppet on your primary server, known as the Puppet Master. Nodes that will be managed can connect to this Master.
- Use package managers like APT or YUM for Linux distributions.
- For Windows, enable using the MSI installer.
Create a Manifest: A manifest is a file where you define the resources. Begin with a simple one:

file { '/tmp/example.txt':
ensure => present,
content => 'Hello, Puppet!',
}

Test Your Configuration: Use the agent on the client machines to test your Manifest to ensure it works as expected.
Utilize the Puppet Forge: Access a repository of reusable modules and codes that can help you implement solutions faster.

Puppet Architecture

Understanding Puppet’s architecture is crucial for effective management:

Puppet Master: The central server that compiles configurations.
Puppet Agent: The client installed on nodes that communicates with the Puppet Master to fetch configurations.
Catalog: A document containing the desired state of a node, compiled by the Puppet Master.
Resource Types: Define various system elements such as packages, services, or files.

Essential Puppet Commands

Here are several commands every System Administrator should know:

puppet agent -t: To test the agent and apply configurations.
puppet status: To check the current status of agents.
puppet resource: To query the current state of a resource.

Advanced Puppet Features

Once you grasp the basics, consider exploring advanced features to enhance your Puppet skills:

Hiera Configuration: Use Hiera for data separation and to manage environment-specific variables effectively.
Puppet Modules: Organize shared code in modules to make your manifests cleaner and reusable.
Environment Management: Separate code into different environments to safely test changes before applying them in production.

Continuous Learning: Puppet Certifications

To deepen your Puppet knowledge, consider investing in training or certification. Platforms such as Puppet for System Administrators provide structured learning paths and official recognition of your skills. This can enhance your career prospects and solidify your expertise.

Conclusion

Puppet is an invaluable tool for system administrators looking to streamline their workflows and improve system management. By harnessing Puppet’s capabilities, you can automate tasks, enforce configurations, and ultimately provide a more reliable IT service. Start small, practice regularly, and continuously seek to learn more as technology evolves.