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.

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.

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!

ConfDroid Puppet Modules - java

12ww1160 — Sat, 18 Apr 2026 16:24:20 +0000

Introducing confdroid_java: A Lightweight Helper for Reliable Java Installations

We’re continuing the ConfDroid Puppet modules series with a small but essential addition: confdroid_java.

This module does exactly one thing—and does it well. It installs and configures a specified Java version so that other Puppet modules can simply rely on it being there. No more guessing, no more manual setup, and no more version conflicts when you spin up Java-based services.

Think of it as the Java counterpart to our popular confdroid_php module. Just as confdroid_php prepares a clean PHP environment for applications like WordPress or Nagios, confdroid_java sets up the exact Java runtime that tools like confdroid_jenkins (and any future Java-dependent modules) expect. It keeps everything consistent, reproducible, and ready for automation.

What confdroid_java actually does

Installs the Java binaries you specify through parameters
Places all necessary configuration files in the correct locations
Automatically applies the right SELinux contexts (and gracefully ignores them on systems where SELinux is disabled)
Stays deliberately lightweight—no unnecessary features, no external module dependencies

It is designed to be a silent foundation. You include it once, and every Java-needing module that follows can simply assume a working Java environment is already in place. Confdroid modules which rely on it like confdroid_jenkins automatically add it, as long as it is in the Puppet catalogue.

Supported platforms

Fully tested and validated on Rocky Linux 9
Expected to work on all RHEL 9-based distributions
Requires Puppet 8

How to use it

The simplest way is just to include the class:

node 'example.example.net' {
  include confdroid_java
}

Or, if you manage your nodes with Foreman, simply set the desired parameters (Java version, installation source, etc.) directly in the host or host-group configuration. No extra code required.

Important note: This module is meant for fresh systems. If Java has already been installed or configured manually on a server, applying confdroid_java could overwrite those changes. Always test in a lab environment first.

Where to get it

The full module, complete documentation, and parameter reference are available right now in the Confdroid Forge:

You’ll also find the generated documentation in the doc/ folder inside the repository.

Why this module matters

In larger Puppet environments, helper modules like confdroid_java (and its PHP sibling) are the glue that makes everything else click. They remove duplication, enforce consistency, and let the bigger application modules focus on what they do best—managing Jenkins, application servers, or any other Java workload—without reinventing the Java installation wheel every time.
If you’re already running other ConfDroid modules on Rocky 9, adding confdroid_java is a quick win that will make your Java-based services even more reliable and easier to maintain.
Happy automating!
As always, feedback and pull requests are welcome in the repository.

Did you find this post helpful? You can support me.

ConfDroid Puppet Modules - SSH

12ww1160 — Sat, 18 Apr 2026 15:33:33 +0000

Introducing confdroid_ssh: Reliable and Hardened SSH Access for Your Rocky 9 Servers

SSH is the primary way we access and manage Linux servers. When SSH stops working, everything else grinds to a halt — troubleshooting becomes painful, and automation pipelines can fail.

To solve this, I created confdroid_ssh, a new Puppet 8 module that ensures the SSH daemon (sshd) is always installed, properly configured, running, and reachable.

The module provides a hardened, consistent SSH setup across your entire infrastructure while making it easy to apply custom security policies.

Why This Module Matters

Guarantees SSH access is always available.
Applies secure defaults for ciphers, MAC algorithms, and other important settings
Manages the main sshd_config safely through drop-in files in /etc/ssh/sshd_config.d/
Handles SELinux contexts automatically (works great together with confdroid_selinux)
Optionally manages firewall rules to keep the SSH port open
Prevents configuration drift and manual overrides that often cause problems

It fits perfectly into the Confdroid collection alongside confdroid_selinux (for global SELinux enforcement) and confdroid_fail2ban (for brute-force protection on SSH).

Key Features

Installs the SSH server packages and required binaries
Manages the sshd service (ensures it is enabled and running)
Supports custom configuration snippets via the confdroid_ssh::custom::custom_config define
Automatically applies correct SELinux contexts
Optionally opens the SSH port in the firewall (iptables/nftables)
Designed for Rocky 9 (and other RHEL 9-based systems)

Example: Adding Custom Configuration

You can easily add your own secure settings without touching the main config file:

confdroid_ssh::custom::custom_config { '30-my-hardening':
  config_name    => '30-my-hardening',
  config_content => [
    'PasswordAuthentication no',
    'PermitRootLogin no',
    'MaxAuthTries 3',
  ],
}

This creates a cleanly managed file /etc/ssh/sshd_config.d/30-my-hardening.conf, overriding default settings from the main configuration file.

How It Fits in the Confdroid Ecosystem

confdroid_ssh works hand-in-hand with the rest of the collection:

confdroid_selinux ensures the global SELinux mode is set correctly
confdroid_fail2ban protects SSH against brute-force attacks All other modules benefit from reliable SSH access for management and deployment.

Important Notes

Warning: This module overwrites SSH configuration. Do not use it right on systems that have heavy manual SSH customizations. Always test first in a non-production environment, and move your manual configuration into the module via the provided define see example. It is likely best practice to use small snippets depending on various conditions only when they apply. Not every Linux system follows the same pattern depending on the applications it hosts.
The module follows the Confdroid “ENC-first” philosophy — configure everything comfortably through Foreman smart class parameters.

You can find the full module, source code, parameter reference, and documentation here: https://sourcecode.confdroid.com/confdroid/confdroid_ssh

Final Thoughts

With confdroid_ssh, you no longer have to worry about SSH breaking after updates or configuration changes. It provides a solid, hardened, and fully automated foundation for secure remote access across your Rocky 9 fleet.

Combined with confdroid_selinux and confdroid_fail2ban, it forms a strong security layer that keeps your servers accessible to you — but not to attackers.
Have you ever lost SSH access due to a misconfiguration or update? How do you currently manage SSH hardening across your servers? Share your experiences or questions in the comments — I’d love to hear them!

Did you find this post helpful? You can support me.

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)

Installing PDK on a Linux Workstation (Manual Edition)

Matthew Stone — Sat, 11 Apr 2026 19:05:38 +0000

Getting PDK installed and updated can be a bit...weird these days, and after running into a few bumps I thought I'd share my compiled notes that streamlined a few different pages in the Puppet help documentation. Note: this is for manual setup. At some point I'll add the super fun Puppet version of this to make it simple and automated.

Prerequisites

One of the following: a Puppet Core license, a Puppet Enterprise License, a Puppet Core development license.
a Linux workstation. In this example I'm working with Fedora 33.

Steps

1. Gather Your Credentials

First things first, let's get our credentials in order.

For Puppet Enterprise users:

The username is license-id. The password can be found via the PE console. Log into the console, click on License in the left side menus and then click Copy license id.

For Puppet Core users:

The username is forge-key. The password can be found and/or created by logging into the Puppet Forge. Click on your account at the upper right corner and select View Profile. On the left side, select API Keys. Generate an API key and copy the key. That is your password. Make a note to save this for future use as once you leave that page you'll have to create a new one if you forget it.

2. Download and Setup the Repository File

First, let's grab the repository. You can find the relevant RPM or DEB from either yum-puppetcore.puppet.com/public or apt-puppetcore.puppet.com/public. Once you've found the right one, let's download and install!

wget https://yum-puppetcore.puppet.com/public/puppet8-release-el-9.noarch.rpm

sudo rpm -ivh puppet8-release-el-8-noarch.rpm

Once you've done the above, you'll be able to edit the repo file at /etc/yum.repos.d/puppet8-release.repo. Let's take a look at the contents:

[puppet8]
name=Puppet 8 Repository el 8 - $basearch
baseurl=https://yum-puppetcore.puppet.com/puppet8/el/8/$basearch
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-puppet8-release
enabled=1
gpgcheck=1

## Add authentication here by uncommenting and filling in values

#username=<api_user>
#password=<api_key>

It's pretty straightforward here. Remove the # from username and password, then copy your username and password from above into the <api_user> and <api_key> spaces, respectively. Save and quit editing the file.

3. Update and Install

At this point we have our repo file, we have our credentials configured and we just need to update the repos and install pdk. a simple yum update followed by yum install pdk should get us there.

root@choplifter:/home/matthew# yum update
Updating and loading repositories:
 Puppet 8 Repository el 8 - x86_64            100% |  14.2 KiB/s |  14.1 KiB |  00m01s
Repositories loaded.
Nothing to do.
root@choplifter:/home/matthew# yum install pdk
Updating and loading repositories:
Repositories loaded.
Package                   Arch     Version                    Repository          Size
Installing:
 pdk                      x86_64   3.6.1.1-1.el9              puppet8        223.8 MiB

Transaction Summary:
 Installing:         1 package

Total size of inbound packages is 57 MiB. Need to download 57 MiB.
After this operation, 224 MiB extra will be used (install 224 MiB, remove 0 B).
Is this ok [y/N]: Y
[1/1] pdk-0:3.6.1.1-1.el9.x86_64              100% |  15.8 MiB/s |  57.0 MiB |  00m04s
--------------------------------------------------------------------------------------
[1/1] Total                                   100% |  15.8 MiB/s |  57.0 MiB |  00m04s
Running transaction
Importing OpenPGP key 0x9E61EF26:
 UserID     : "Puppet, Inc. Release Key (Puppet, Inc. Release Key) <release@puppet.com>"
 Fingerprint: D6811ED3ADEEB8441AF5AA8F4528B6CD9E61EF26
 From       : file:///etc/pki/rpm-gpg/RPM-GPG-KEY-puppet8-release
Is this ok [y/N]: Y
The key was successfully imported.
[1/3] Verify package files                    100% |   5.0   B/s |   1.0   B |  00m00s
[2/3] Prepare transaction                     100% |   3.0   B/s |   1.0   B |  00m00s
[3/3] Installing pdk-0:3.6.1.1-1.el9.x86_64   100% |  72.0 MiB/s | 228.5 MiB |  00m03s
Complete!

root@choplifter:/home/matthew# pdk --version
3.6.1

That's all there is to it! As an added bonus, this is the same repo for Bolt and all the Puppet Core bits, so if you need the agent on your box it's as easy as another yum install.

Or dnf. Whatever.

ConfDroid Puppet Modules - Selinux

12ww1160 — Sat, 11 Apr 2026 10:04:51 +0000

Introducing confdroid_selinux: Declarative SELinux Management for Your Rocky 9 Servers

Security-Enhanced Linux (SELinux) is one of the most powerful built-in defenses on modern Linux systems. Unlike traditional permission-based security (user/group/other), SELinux adds mandatory access control (MAC) at the kernel level. It labels every process, file, directory, and network port with a security context and enforces strict policies that say exactly what each subject is allowed to do with each object — no matter what the file permissions say.

This means even if an attacker gains root or tricks a service into writing a malicious file, SELinux can still block the attack because the file simply doesn’t have the right context.
Many enterprise Linux distributions enable SELinux by default in enforcing mode on fresh installs:

Rocky Linux 9
AlmaLinux 9
Red Hat Enterprise Linux (RHEL) 9
Fedora

On these systems, SELinux is not an afterthought — it’s a core part of the security model.

How SELinux Stops Real-World Attacks

Imagine an attacker sends a phishing email with a malicious script disguised as a legitimate configuration file. The user (or a compromised service) downloads and places the file in /tmp or a web directory.

Without SELinux:

If the file has execute permissions, the attacker might be able to run it.

With SELinux (enforcing mode):

The file gets created with the wrong security context (for example, user_tmp_t instead of httpd_exec_t).
Even if the attacker somehow makes the file executable, SELinux denies execution or access because the policy doesn’t allow it.
The attack is stopped cold, and an audit log entry is generated.

SELinux turns potential disasters into harmless denied operations.

The Problem with Manual SELinux Management

While SELinux is powerful, managing it consistently across many servers is painful:

Forgetting to run restorecon after placing files
Accidentally setting the wrong mode (setenforce)
Configuration drift between hosts

That’s exactly why I built confdroid_selinux.

What confdroid_selinux Does

This new Puppet 8 module (tested on Rocky 9) gives you full declarative control over SELinux:

Installs all required SELinux tools and binaries
Manages the main configuration file /etc/sysconfig/selinux with correct permissions and SELinux contexts
Controls the global SELinux mode (enforcing or permissive) — the Puppet equivalent of setenforce
Ensures every file and directory managed by other Confdroid modules receives the proper SELinux context
Works cleanly on enforcing-mode systems

All other Confdroid modules (see the full collection overview) already include proper SELinux context handling:

and many more.

They work even better when **confdroid_selinux** is present, because the global policy and mode are managed in one place.

SELinux Management Flow with the Module

Here’s how the module turns your Puppet run into reliable SELinux enforcement:

Easy Deployment

Simple inclusion: in your site.pp or nodes.pp:

include confdroid_selinux

with Foreman (recommended):

Add the confdroid_selinux::params class to the host or host group and override parameters (mode, etc.) as smart class parameters.

Important notes:
Test in a non-production environment first.
If you are switching from disabled to enforcing mode, a reboot is required (the module does not reboot automatically to avoid surprises).

You can find the full module, source code, and parameter reference here:
→

Final Thoughts

SELinux is no longer optional on modern enterprise Linux. With confdroid_selinux, you get consistent, version-controlled, and fully automated SELinux management that works hand-in-hand with the rest of the Confdroid collection.
Your servers stay secure by default — even when things go wrong elsewhere.
Have you been running SELinux in enforcing mode across your fleet, or are you still in permissive because of management headaches? Would you like to see more advanced features (custom Booleans, custom modules, etc.) in a future version? Let me know in the comments!

Did you find this post helpful? You can support me.

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!

DEV Community: puppet

Handling Dirty Frag and Copy Fail with Puppet

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

Add these to your Puppetfile. That is it.

See where you stand

dirty_frag

copy_fail

Query your entire fleet in one line

What makes a system vulnerable?

Dirty Frag

Copy Fail

Why module presence, not kernel version?

When you want Puppet to enforce the block

Dirty Frag

Copy Fail

The built-in module problem (Copy Fail only)

Force-unload a module right now (with care)

The workflow

Get started

Puppetlabs Modules Roundup – April 2026

Highlighted Updates

Event Forwarding Enhancements

Security and Compliance Platform Updates

What Updates Happened to Puppetlabs Modules in April 2026?

cd4peadm 5.15.0

comply 3.7.1

complyadm 3.7.1

lvm 4.0.1

pe_event_forwarding 2.3.0

peadm 3.37.0

sce_linux 2.6.1

splunk_hec 2.2.0

Until Next Time!

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

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

What is GRC Anyway?

Why Developers Should Care

How Developers Can Contribute to GRC

Final Thoughts

Puppet for System Administrators: A Comprehensive Guide

Introduction

What is Puppet?

Why Use Puppet?

Getting Started with Puppet

Puppet Architecture

Essential Puppet Commands

Advanced Puppet Features

Continuous Learning: Puppet Certifications

Conclusion

Puppet Continuous Delivery 5.15.0 is now available

What’s included in CD 5.15.0

Webhooks, sessions, and configuration

Pipelines as Code and Impact Analysis

VCS integrations (Azure DevOps and GitLab)

Data visibility and usability fixes

Security and authorization hardening

Platform and runtime updates

Security dependency updates

Why this release matters

Installation and upgrade notes

Read the full details

ConfDroid Puppet Modules - java

Introducing confdroid_java: A Lightweight Helper for Reliable Java Installations

What confdroid_java actually does

Supported platforms

How to use it

Where to get it

Why this module matters

Related posts

ConfDroid Puppet Modules - SSH

Introducing confdroid_ssh: Reliable and Hardened SSH Access for Your Rocky 9 Servers

Why This Module Matters

Key Features

Example: Adding Custom Configuration

How It Fits in the Confdroid Ecosystem

Important Notes

Final Thoughts

Related posts

Security Compliance Management 3.7.0 Is Now Available

What's new in this release