DEV Community: puppet

Your AI makes decisions. We make sure every data move obeys the law. Try the demo at viradotech.com and give us your honest take.

virgiljunioradoleyine-stack — Sat, 22 Aug 2026 16:38:09 +0000

Puppet Core 9.0 and 8.21 Released: Ruby 4.0, OpenSSL 3.5, Platform Changes, and Security Hardening

Jason St-Cyr — Thu, 20 Aug 2026 15:26:21 +0000

Did you know there's a new major version in town for Puppet Core? You might have heard about it through the grapevine or in the Are You Ready for Puppet 9? webinar that @gpatton and I recently hosted. The wait is over and Puppet Core 9.0.0 is now available alongside Puppet Core 8.21.0.

Puppet Core 9 introduces significant runtime and platform changes, moving to Ruby 4.0, OpenSSL 3.5, and other changes, but the essential Puppet under the hood is largely unchanged from Puppet 8. The majority of upgrade effort will center on Ruby 4 compatibility and runtime dependency changes rather than Puppet language changes.

If you are staying on the Puppet Core 8.x release track, the latest Puppet Core 8.21 delivers the basic support fixes and security improvements you might need without the major dependency changes found in Puppet Core 9.

What matters most for the admins

Before upgrading to Puppet Core 9:

Test custom facts, functions, types, and providers against Ruby 4.0.
Validate any Forge modules you use for Ruby 4 compatibility.
Review integrations that depend on OpenSSL behavior.
Verify any workflows that still rely on SHA-1.
Confirm managed nodes are running supported operating systems.
Review any custom code that depends on PSON or multi_json.
Check deferred function behavior if you have custom types or providers.

Perforce will be rolling out updates to Puppetlabs modules on the Forge based on their priority tier and dependencies. The first batch of these should be rolling out soon.

Puppet Core 9.0 highlights

These are a few highlights I pulled from the release notes. Make sure to reference the full 9.0 release notes to get all the details about what has changed!

Ruby updated to 4.0.5: With a new Ruby baseline some deprecated syntax from older Ruby versions will no longer be compatible. This is the primary focus area for upgrades as you will want to validate your custom code and modules. The latest PDK 3.8.0 introduced some Ruby 4 validators to help you update your syntax while you are still on Puppet Core 8, before upgrading to Puppet Core 9.
OpenSSL updated to 3.5.7: This lays the groundwork for supporting post-quantum cryptography (PQC) and moves to TLS 1.3 as the default protocol version. This upgrade will resolve several OpenSSL-related CVEs.
Puppet Server has updated baseline components: As part of the move to JRuby 10.1, Puppet Server is now updated to require minimum JDK 21. The embedded web server is now using Jetty 12.
PSON support removed: You will need to migrate to a supported data format if your code has relied on PSON.
Deferred functions return to Puppet 7 behavior: While Puppet Core 9 largely keeps the same underlying behavior as Puppet Core 8.x, there is one change worth noting about deferred functions. In older versions (like Puppet 7), preprocess_deferred was enabled by default, but this was disabled by default in Puppet 8. In Puppet Core 9, preprocess_deferred is now enabled by default again.
UTF-8 encoding now used on Windows: Puppet Core now uses UTF-8 as the default external encoding on Windows. You will want to look for any configuration files encoded in non-UTF-8 before upgrading.

These are just some highlights I pulled from the full list, I really recommend taking a look at the release notes to get a full picture.

Security hardening

Both the 9.0 and 8.21 releases contain security-related fixes.

Stricter SSH key validation: Puppet now rejects malformed SSH keys that previously passed validation. This includes invalid inputs such as embedded newline characters. The goal is to prevent unsafe content from being written to managed files.
Improved autoloader validation: The puppet resource command now performs stricter validation of autoloader inputs. This change helps prevent unintended code loading through user-controlled values.
curl updated to 8.21.0: Both Puppet Core 9.0 and Puppet Core 8.21 update curl from 8.20.0 to 8.21.0. The update addresses numerous curl CVEs.

Admins who track dependency risk should review the release notes for the complete CVE list:

Platform updates

New agent platforms

The following agent platforms are now supported in both Puppet Core 9.0 and 8.21:

Rocky Linux 10 (x86_64)
Alma Linux 10 (x86_64)

Operating systems removed from support

Several end-of-life operating systems have been removed: Debian 10, macOS 13, RHEL 7, Ubuntu 18.04 and 20.04, and others.

The official full list is in the docs. The list in this article is not complete, so make sure to reference those notes to check your systems!

If you need to keep using a platform that has been removed you should know there is an extended support option. Migrating to a more modern OS is likely the best path, but if you can't migrate just yet, make sure to reach out to the team to get help with extended platform support

Upgrade resources

Before moving to Puppet Core 9, review the official upgrade documentation and release notes:

Make sure to start your Puppet Core 9 compatibility testing early and send over any questions as you encounter issues so that the team can help!

Why Healthcare Software Needs a Different QA Bar Than Everything Else You've Built

Ayushi Kumari — Tue, 18 Aug 2026 06:56:13 +0000

Most engineers carry an intuitive sense of "good enough" QA from whatever domain they cut their teeth in — e-commerce, SaaS dashboards, internal tools. That instinct is dangerous the moment it gets applied unchanged to healthcare software, where the cost of a subtle bug isn't a support ticket or a refund. It can be a missed medication interaction, a delayed diagnosis, or a compliance violation with real legal consequences.

Here's what actually has to change.

The Failure Modes Are Categorically Different

In a typical SaaS product, a bug that shows a stale number on a dashboard is annoying. In a system tracking medication dosages, a stale or incorrectly calculated number can directly affect patient safety. The same class of bug — a caching issue, a rounding error, a race condition in concurrent writes — carries a wildly different severity depending on what data it touches.

This means healthcare QA can't treat all features equally. A cosmetic UI bug on a marketing page and a calculation bug in a dosage calculator are not the same priority tier, even if they'd be treated similarly in a typical product backlog.

Edge Cases Aren't Edge Cases — They're Tuesday

Healthcare data is messier than most systems are designed to expect. Patient records have missing fields because the information genuinely wasn't available at intake. Names have characters that break naive string validation. A single patient might have multiple records that need to be reconciled, or duplicate entries that shouldn't be merged automatically. What would be a rare edge case in a typical CRUD app is routine, everyday data in a clinical system.

QA for healthcare software has to actively hunt for these patterns rather than treating them as improbable inputs unlikely to matter — because in this domain, they're the normal case, not the exception.

Compliance Isn't a Separate Checklist — It's a Testing Requirement

HIPAA (or equivalent regional regulations) isn't just a legal document to review once during planning. It has direct, testable implications: who can access which records, how access is logged, how long data is retained, what happens when a record needs to be permanently deleted versus archived. These aren't features to build and forget — they're behaviors that need explicit test coverage, the same way a payment flow needs test coverage for its critical paths.

A permissions bug that lets the wrong role view a patient record isn't a minor defect in this context. It's a reportable incident with real regulatory consequences, which changes how much test coverage that logic actually deserves relative to a typical feature.

Concurrency Bugs Have Higher Stakes

Multiple clinicians updating the same patient record simultaneously — a nurse logging vitals while a doctor updates a treatment plan — is a routine occurrence in clinical settings, not a rare race condition. Systems that haven't been explicitly tested for concurrent writes to the same record can silently lose or overwrite critical updates, and because the failure is silent, it might not surface until someone notices a treatment plan doesn't match what was actually decided.

This makes concurrency testing a first-class requirement rather than something addressed only if it happens to surface during normal testing.

Audit Trails Need Their Own Test Suite

Beyond the primary feature working correctly, healthcare systems typically need to prove who did what, when — an audit trail robust enough to hold up under regulatory review. It's not enough for the audit log to usually capture changes; gaps in the audit trail can themselves become a compliance finding, independent of whether the underlying feature worked correctly. This means the audit logging mechanism needs dedicated test coverage, not an assumption that it'll work because the primary code path was thoroughly tested.

A Practical Shift in QA Priorities

Compared to a typical SaaS QA process, healthcare software QA generally needs:

Explicit test coverage for permission boundaries, not just functional correctness
Deliberate testing of messy, incomplete, and duplicate data, treated as the expected case rather than an edge case
Concurrency testing on any record multiple roles can update simultaneously
Dedicated tests for audit trail completeness, separate from tests of the feature the audit trail is logging
A severity framework that weights patient-safety-adjacent bugs above cosmetic or convenience bugs, even when they'd rank similarly by engineering complexity alone

The Takeaway

The technical skills required for healthcare software aren't fundamentally different from any other domain — the discipline around testing priorities and failure-mode awareness is what actually shifts. Teams that bring a generic SaaS QA mindset into healthcare software tend to catch the bugs that would matter anywhere and miss the ones that matter specifically because of what's at stake here. Getting this right usually means building with a development partner that's specifically experienced in healthcare software, not just competent engineering applied without domain context.

Anchor text used above: "a development partner that's specifically experienced in healthcare software" → links to https://www.weboraz.com/industries/healthcare

PDK 3.8.0 now has Ruby validation to prepare for Puppet 9!

Jason St-Cyr — Tue, 11 Aug 2026 12:53:45 +0000

A new release is out for the Puppet Development Kit and it has some new additions like Debian 13 support, some security-related updates, and some new validation for Ruby syntax to help you get yourself ready for Puppet Core 9!

The next releases of Puppet Core 9 and Puppet Enterprise 2026, due out soon, will be moving to Ruby 4. To help you get ready, you can start using this new version of PDK on your Puppet 8 installation to look for areas that might need updates.

When you run pdk validate, it can now identify changes you can make that will be safe to run on Puppet 8, but also will prepare your codebase for Puppet Core 9:

Code that uses legacy Ruby Hash#inspect formatting, for example {:x=>1, "baz"=>3} . Legacy formatting can cause module code to fail after you upgrade to Puppet Core 9.
Ruby 4 syntax compatibility checks.
The Security/Open Rubocop flags Ruby patterns associated with Kernel#open and IO.open invocation that are no longer valid in Ruby 4.

Once Puppet Core 9 is out, you'll be able to do additional validation, but this should help you get started finding those places where the syntax might need some updates.

Full release notes: https://help.puppet.com/pdk/current/topics/release_notes_pdk.htm#PDK380

Download PDK: https://forge.puppet.com/resources/pdk

Vox Pupuli Container Statistics

Robert Waffen — Sat, 08 Aug 2026 11:13:05 +0000

Hello everyone!
I am excited to share some updates regarding container statistics.

We now have a page where we display the statistics for all our containers.
You can find it at https://voxpupuli.org/container_statistics/.

It is built from https://github.com/voxpupuli/container_statistics and is updated every 24 hours.

Getting the Downloads

For the download count, it scrapes the package HTML pages for the containers.
Sadly, this does not work with GraphQL or the API, so we have to use the HTML pages for now.
GraphQL and the API do expose a download count, but it is only for GitHub's legacy container system and not for ghcr.io ¯\_(ツ)_/¯.
If someone has an idea for a better way to get the download count from ghcr.io, please let me know.
The API is not very talkative about this :/

Getting the CVEs

For CVEs, we run two scanners: the wildly popular Trivy scanner and Grype from Anchore.
Both are run against the latest version of each container, and the results are displayed on the statistics page.
For Grype, we downplay the nvd/cpe entries, as they tend to be false positives.
They are still displayed, but specifically marked as nvd/cpe entries, so you can filter them out if you want to.

How the statistics are generated

The statistics can be generated by running the bin/container-statistics script in the container_statistics repository.
It needs a configuration file, which is located in the config directory.

---
containers:
  - name: openvoxproject/openbolt
    registry: ghcr.io
    tags:
      - latest
  - name: openvoxproject/openvoxagent
    registry: ghcr.io
    tags:
      - latest

We run it in GitHub Actions and push the results to the gh-pages branch, which is then displayed on the statistics page.
Scanning is also done in GitHub Actions.
The whole process is automated and runs every 24 hours, so the statistics are always up to date.
See the GitHub Actions workflow in the container_statistics repository (.github/workflows/container-statistics.yml) for more details.

You can run it locally and generate the statistics yourself.
You will need to have the scanners installed and available in your path.

CLI Commands

bin/container-statistics --download-report

This will display the downloads for all containers in a table format.
This will live-scrape the HTML pages for the containers, so it might take a while to run.

bin/container-statistics --download-report

CONTAINER                             TOTAL DOWNLOADS
------------------------------------  ---------------
ghcr.io/openvoxproject/openbolt                 1,504
ghcr.io/openvoxproject/openvoxagent            11,814
ghcr.io/openvoxproject/openvoxdb              157,774
ghcr.io/openvoxproject/openvoxserver          151,344
ghcr.io/voxpupuli/commitlint                      756
ghcr.io/voxpupuli/onceover                      4,248
ghcr.io/voxpupuli/r10k-webhook                  7,738
ghcr.io/voxpupuli/r10k                         22,548
ghcr.io/voxpupuli/renovate                      5,551
ghcr.io/voxpupuli/semantic-release              7,870
ghcr.io/voxpupuli/voxbox                      131,841

bin/container-statistics --cve-report

This will display the CVEs for all containers in a table format.
It depends on the scanners being installed and having been run at least once, so that the results are available in the cache.

bin/container-statistics --cve-report
CONTAINER                                           CRITICAL  HIGH  MEDIUM  LOW  UNKNOWN  TOTAL
--------------------------------------------------  --------  ----  ------  ---  -------  -----
ghcr.io/openvoxproject/openbolt:latest                     1     4       2    1        -      8
ghcr.io/openvoxproject/openvoxagent:latest                 -     7      58    7        2     74
ghcr.io/openvoxproject/openvoxdb:latest                    -     6      79    9        2     96
ghcr.io/openvoxproject/openvoxdb:latest-alpine             -     1       -    -        -      1
ghcr.io/openvoxproject/openvoxserver:latest                2    49     634  100        4    789
ghcr.io/openvoxproject/openvoxserver:latest-alpine         -     1       -    -        -      1
ghcr.io/voxpupuli/commitlint:latest                        1     6       5    2        -     14
ghcr.io/voxpupuli/onceover:latest                          1     4       2    1        -      8
ghcr.io/voxpupuli/r10k-webhook:latest                      3    41      35    2        7     88
ghcr.io/voxpupuli/r10k:latest                              -     8       5    -        1     14
ghcr.io/voxpupuli/renovate:latest                          -     1       -    -        -      1
ghcr.io/voxpupuli/semantic-release:latest                  1     6       8    2        -     17
ghcr.io/voxpupuli/voxbox:latest                            -     -       -    -        -      -

First published at: https://voxpupuli.org/blog/2026/08/07/container-statistics/

Puppetlabs Modules Roundup - July 2026

Jason St-Cyr — Thu, 06 Aug 2026 12:19:41 +0000

July 2026 brought 17 Puppetlabs module releases, headlined by a fairly large Continuous Delivery release. cd4peadm 5.16.0 added external PostgreSQL database support and a configurable image pull policy, and closes 11 CVEs, alongside a breaking change to commit status contexts. More modules dropped Puppet 7 support, some others picked up stdlib 10, and Windows Server 2025 support started rolling out into the modules. This roundup pulls the most important changes into one place.

Highlighted Updates

Continuous Delivery Adds External Databases, Configurable Image Pull Policies, and Closes 11 CVEs

cd4peadm 5.16.0 is the biggest release of the month. It adds support for pointing Continuous Delivery at an externally managed PostgreSQL database. That could be a self-managed instance, Amazon RDS for PostgreSQL, or Amazon Aurora. This externally managed db can be used instead of the database CD manages internally, giving operators control over durability, backups, and high availability. It also adds a configurable image_pull_policy option for job templates (Always/IfNotPresent/Never) and removes the docker.io fallback when using Podman; the matching cd4pe_jobs 1.7.4 release adds the same task parameter and fallback removal, so upgrade both together.

BREAKING: Commit status contexts now include the pipeline name (cd-pe/<pipelineName>/stage-<N> instead of cd-pe/stage-<N>). Review any branch protection rules or required status checks that reference the old format.
This release also closed 11 CVEs across opentelemetry, NGINX, jetty, jackson, log4j, postgresql, golang.org/x/sys, and react-router.

Puppet 7 Support Dropped

Five modules dropped Puppet 7 support in major version bumps:

haproxy, iis, mount_iso, scheduled_task, sslcertificate.

There were all released as major version bumps to ensure that users still working on upgrading from Puppet 7 can stay pinned on the previous major version releases.

In related news, postgresql 10.6.3 restored the Puppet 7 support that 10.6.2 broke in a previous release; see its entry below.

stdlib 10.x Rollout Continues

Following June's stdlib 10.x rollout, four more modules now allow the puppetlabs-stdlib dependency to move to 10.x: haproxy, mount_iso, puppet_authorization, and sslcertificate. haproxy also widens its concat constraint to 10.x.

Affected modules: haproxy, mount_iso, puppet_authorization, sslcertificate.

Windows Server 2025 Support Added

Three Windows-focused modules added support for Windows Server 2025 this month: scheduled_task, windows_env, and windows_eventlog. These now all run acceptance testing against the 2025 version of the OS, in addition to other supported Windows versions.

What Updates Happened to Puppetlabs Modules in July 2026?

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

apache 13.3.0

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

Added OWASP CRS v4 support on modern Enterprise Linux (EL10) while preserving existing EL7/8/9 behaviour.

(MODULES-11857) Scaffold OWASP CRS v4 support on EL10 via crs_source enum #2637 (SugatD)

cd4pe_jobs 1.7.4

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

Adds the same configurable image_pull_policy task parameter and Podman fallback removal shipping in cd4peadm 5.16.0 — upgrade both together to get matching behavior.

A new optional image_pull_policy task parameter controls whether the container image is pulled before a job runs: Always (the default, and the previous behavior) pulls on every run; IfNotPresent pulls only when the image is absent from the local runtime; Never skips the pull entirely and relies on the locally present image. Presence is checked with docker image inspect / podman image exists. Omitting the parameter keeps the existing pull-every-run behavior.
The module no longer retries a failed image pull against docker.io. Image names are now pulled exactly as given. If you rely on unqualified image names (e.g. nginx, myuser/myimage) on a Podman host, add docker.io to unqualified-search-registries in registries.conf, or use a fully-qualified name.

cd4peadm 5.16.0

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

The changes this month added external PostgreSQL database support, a configurable image pull policy, source control token management improvements, and closed 11 CVEs. There is also a breaking change to commit status contexts — see below (and the linked release notes).

Added support for external databases. You can now point Continuous Delivery at a PostgreSQL instance you operate yourself, Amazon RDS for PostgreSQL, Amazon Aurora (PostgreSQL-compatible), or a self-managed PostgreSQL server, instead of the database CD manages for you. This gives you control over durability, backups, and high availability. You can configure external mode on a fresh install or migrate an existing managed install.
Added a feature to Continuous Delivery job templates so you can set an image pull policy per job (Always, IfNotPresent, or Never). In an air-gapped environment, for example, setting the policy to Never stops Continuous Delivery's attempts to reach out to the internet for the image.
Updated the Source Control settings page to show when a configured Personal Access Token (PAT) expires on each connected GitHub, GitHub Enterprise, and GitLab integration card. Tokens that have already expired or will expire within 30 days are clearly flagged so you can renew them before they cause failures.
BREAKING: Commit status contexts now include the pipeline name (cd-pe/<pipelineName>/stage-<N> instead of cd-pe/stage-<N>), which prevents collisions when multiple pipelines report status for the same commit. Review any branch protection rules or required status checks that reference the old format.
11 CVEs addressed, including opentelemetry, NGINX, jetty, jackson, log4j, postgresql, golang.org/x/sys, and react-router.

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

comply 3.8.1

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

A Security Compliance Management maintenance release that did not have any new CVE fixes this time and was mostly operational and licensing improvements.

Increased the CIS-CAT Pro Assessor license expiry time; licenses are now good for a full year.
Added a license_path parameter to update the CIS-CAT Pro Assessor license without upgrading SCM.
Added an assessor_scan_timeout option to control the task timeout for Windows 2022 domain controllers.
Added a background scan sweeper that detects and cancels scans stuck in a "running" state.
Increased the default Max graphql requests limit to 300 requests per window; use the complyadm::configure Bolt plan to customize.

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

haproxy 9.1.0

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

Two releases this month: 9.0.0 dropped Puppet 7 support (BREAKING) and added cache resource support, while 9.1.0 removed a sensitive-data workaround and allows both stdlib and concat to move to their 10.x releases.

Includes monthly releases: 9.1.0 (2026-07-28), 9.0.0 (2026-07-20).

Eliminate Workaround for Sensitive Data; raises minimum puppetlabs/concat requirement to 7.4.0 #607 (cocker-cc)
Add support for running programs #604 (deric)
Pass install_options to package installer #603 (deric)
examples: disable default stats listener #640 (bastelfreak)
make picking haproxy::globals::sort_options_alphabetic work #573 (trefzer)
Remove Puppet 7 support (BREAKING); the module now requires puppet >= 8.0.0 < 9.0.0 #631 (gavindidrichsen)
Add support for cache resource, extra backend options, and docs #626 (matejzero)
(MODULES-11840) Allow puppetlabs/stdlib 10.x #642 (imaqsood)
Allow puppetlabs/concat 10.x #641 (bastelfreak)
dependency: create mapfile before configfile #572 (trefzer)

iis 11.0.0

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

Dropped Puppet 7 support (BREAKING) as part of ongoing modernization efforts, and marked the iis_application_pool password parameter as sensitive so it no longer leaks into Puppet reports.

(CAT-2374) Puppet Core update (BREAKING) — drops Puppet 7 support #414 (LukasAud)
(MODULES-11595) Mark iis_application_pool password as sensitive to stop report leak #418 (imaqsood)

mount_iso 5.0.0

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

Dropped Puppet 7 support (BREAKING) and allowed the stdlib dependency to move to 10.x.

(CAT-2380) Update for Puppet Core / Drop Support for Puppet 7 (BREAKING) #58 (david22swan)
(MODULES-11840) Allow puppetlabs/stdlib 10.x #59 (imaqsood)

mysql 17.1.0

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

This month was a small update but important as RHEL 10 support was added.

(MODULES-11802) Add support for RHEL 10 #1712 (skyamgarp)

node_encrypt 3.2.0

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

Adds Ubuntu 24 and Debian 12 support, and upgrades rexml to address a CVE.

(CAT-2124) Add support for Ubuntu 24 #120 (skyamgarp)
(CAT-2100) Add Debian 12 support #119 (shubhamshinde360)
(CAT-2158) Upgrade rexml to address CVE-2024-49761 #121 (amitkarsale)

peadm 3.38.1

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

Restores public-schema privileges on PostgreSQL 15+ in restore.pp, fixing a bug that could affect PE restores on newer PostgreSQL versions.

(PE-44867) Restore public-schema privileges on PostgreSQL 15+ in restore.pp #676 (CharithaDunuwille)

postgresql 10.6.3

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

Restores Puppet 7 support that was unintentionally dropped in the 10.6.2 patch release last month.

NOTE: As flagged in June's roundup, the Puppet 7 removal in 10.6.2 shipped in a patch release rather than a major one. 10.6.3 restores Puppet 7 support; the removal will happen again, correctly, in a future major release.

(MODULES-11858) Restore Puppet 7 support broken by 10.6.2 #1686 (imaqsood)

puppet_authorization 1.0.1

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

A maintenance release: allows both the stdlib and concat dependencies to move to 10.x, tweaks a CI workflow flag, and adds a LICENSE file.

Change flag option in CI workflow #56 (zaben903)
(MODULES-11840) Allow puppetlabs/stdlib 10.x #57 (imaqsood)
puppetlabs/concat: Allow 10.x #55 (bastelfreak)
Create LICENSE #52 (binford2k)

sce_linux 2.8.0

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

Updates CIS Benchmarks from v3.0.0 to v4.0.0 for RHEL 8, AlmaLinux 8, and Oracle Linux 8, with matching control updates for each, and fixes three bugs affecting benchmark enforcement.

Updated CIS Benchmarks. RHEL 8, AlmaLinux 8, and Oracle Linux 8 move from CIS Benchmark v3.0.0 to v4.0.0, with matching control updates for each operating system.
Updated dependency. SCE for Linux now supports puppetlabs-stdlib >= 9.2.0 < 11.0.0; avoid using earlier stdlib versions.
Fixed: the user-specified default_zone setting was not enforced for CIS control 3.4.1.2; it is now enforced correctly.
Fixed: aide --init failed on RHEL/AlmaLinux/Oracle Linux/Rocky Linux 8 hosts shipping AIDE 0.17.x, which renamed the database= directive to database_in=.
Fixed: CIS control 6.2.2.2 (journald log-forwarding) did not work as designed on RHEL/AlmaLinux/Oracle Linux/Rocky Linux 9 and 10; control 6.2.3.3 was also added.

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

scheduled_task 5.0.0

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

Drops Puppet 7 support (BREAKING) and also adds Windows Server 2025 support.

(CAT-2391) Puppet Core upgrade (BREAKING) — drops Puppet 7 support #271 (LukasAud)
[MODULES-11616] Adding Windows 2025 support to module #275 (jst-cyr)
Update link to contributing documentation #273 (jst-cyr)

sslcertificate 6.0.0

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

Drops Puppet 7 support (BREAKING) and allows the stdlib dependency to move to 10.x.

(CAT-2394) Puppet Core update (BREAKING) — drops Puppet 7 support #142 (LukasAud)
(MODULES-11840) Allow puppetlabs/stdlib 10.x #143 (imaqsood)

windows_env 6.1.0

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

Adds Windows Server 2025 support.

(MODULES-11891) Add Windows Server 2025 support #115 (imaqsood)

windows_eventlog 5.1.0

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

Adds Windows Server 2025 support.

(MODULES-11892) Add Windows Server 2025 support #98 (imaqsood)

Until Next Time!

That wraps up the July 2026 roundup. If any of these modules intersect with your environment. especially the cd4peadm breaking change to commit status contexts and the Puppet 7 removals, the linked Forge pages and release notes are worth a closer look before upgrading.

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

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

🤖 AI Disclosure

This roundup is produced by a mostly-automated pipeline, with some AI sprinkled in for orchestration and enrichment (or 'Combobulating' and 'Finagling'), followed by a human review (that would be me) before publishing.

The automation is an open-source project with deterministic python scripts to crawl the Forge and determine which puppetlabs modules were released during a specific month (and catching when a module gets more than one release in a month). By combining a template, automation scripts, and some AI orchestration the content all gets pulled together for a structured markdown document. I then jump in to double-check the content and update any wording that seems repetitive or irrelevant (and sometimes I need to add some extra context that isn't in the changelog notes).

The Decision Maker’s Guide to Puppet: What is Perforce Puppet? Which Edition of Puppet is Right for You?

Dragonsoft DevSecOps — Mon, 03 Aug 2026 09:13:31 +0000

As your infrastructure expands, you need a solution that securely scales as quickly as your organization grows. In this article, Dragonsoft, an authorized Perforce partner, will guide you through the modern automation landscape to help you make the right choice for your organization, including comparisons for each edition of Puppet, from open source to enterprise-ready options.

What is Perforce Puppet

Perforce Puppet empowers people to innovate through infrastructure automation. For more than a dozen years, Puppet has led the way in IT infrastructure automation to simplify complexity for the masses in order to strengthen customers’ security posture, compliance standards, and business resiliency beyond the data center to the cloud. More than 40,000 organizations — including more than 80 percent of the Global 5000 — have benefited from Puppet’s open source and commercial solutions.

What to Consider When Choosing Automation Solutions Like Puppet

What happens when your IT matures? IT maturity can mean a lot of things, but in a digital-first world, it almost always means new problems to solve.

As your business grows, your infrastructure must evolve to keep up. Your IT teams need to strengthen security, ensure compliance, enhance observability, and stay audit-ready without sacrificing performance or reliability. Even if your IT footprint isn’t expanding, it may shift laterally, introducing complexity without adding scale. Legacy tools and technical debt can still hold you back. Regardless of how it happens, your infrastructure will face growing pains.

One thing is certain: Your IT doesn't get easier to manage on its own.

So naturally, you turn to automation to handle the expanding workloads and increased expectations. All of a sudden, you’re writing scripts, automating tasks, and saving mountains of time by keeping everything in your desired state. Automation empowers infrastructure teams to be more focused and productive and break through the limits of human scale. Soon, you can’t imagine ever doing development, operations, or DevOps differently.

But before long, those growing pains start to show up again. You find that the tools, solutions, and processes that kept your IT afloat in the past don’t cut it anymore. The security, scale, and sophistication of your IT are essential to business success, but in a fast-paced, ever-changing digital landscape, new challenges and complexity are never far behind.

The IT Automation Landscape: A Brief Overview

Broadly, IT automation solutions fall into three categories: open source automation tools, open core solutions, and enterprise platforms. Each has distinct strengths and limitations, making them suitable for different use cases. Here’s a quick comparison of Puppet offerings to support informed decision-making.

OpenSource Puppet

Open Source Puppet is freely available for organizations looking to adopt automation. It appeals to businesses with limited budgets or that have an open source-first model and the resources to build and maintain it. But open source tools have underlying costs: They require significant in-house expertise and ongoing maintenance. They also often lack rigorous security testing, which can present issues for organizations with compliance and SLA requirements.

Puppet Core

Puppet Core is designed to balance cost efficiency with security. It delivers reliable, stable, and secure software builds that are consistently updated and rigorously tested. Hardened binaries, defect support, and guaranteed SLAs reduce the burden on internal teams, letting them focus on keeping their systems running smoothly with Puppet instead of worrying about the security of their infrastructure automation solution.

Puppet Enterprise Platform

For organizations prioritizing scalability and future growth, an enterprise infrastructure automation and management platform is the go-to choice. With advanced features, enhanced integrations and capabilities, and dedicated support, the Puppet Enterprise platform is designed to ensure long-term efficiency and resiliency in large, complex environments.

Enterprise organizations benefit from the advanced capabilities of an infrastructure operations platform that scales with their needs — particularly businesses with a strong focus on security and compliance and who are unwilling to sacrifice innovation.

Puppet Products Compared

Puppet is here to support your path to more resilient IT — especially when you need to handle greater complexity, support a growing userbase, and speed up evelopment.

All editions of Puppet are built on the same proven foundation, but there are key differences to consider.

In short:

• Open Source Puppet automates and enforces desired state without cost, although maintaining it requires trained resources and involves greater manual effort.

• Puppet Core is for those who want the same hands-on control of Open Source Puppet but require hardened, stable builds with vendor-backed SLAs.

• The Puppet Enterprise platform is built for enterprise teams who need their automation to work for them — not the other way around. The AI-powered user experience and intuitive GUI interface help users get started quickly, and advanced capabilities and exclusive third-party integrations increase productivity at every level.

“The more we use Puppet Enterprise, the more we find we can do with it. Puppet Enterprise comes with many modules to help us manage our Puppet setup more easily. The open source version does not come with these modules … Every new upgrade of Puppet proves to be more innovative, and brings exciting features that we want.”——Pope Davis, Senior Director of systems Engineering, NYSE/ICE

Why Organizations Choose Puppet Core

Puppet Core builds on the powerful automation capabilities of Open Source Puppet and adds additional peace of mind for security-conscious organizations. Backed by Perforce, a trusted DevOps partner with over 30 years experience supporting global enterprises, releases undergo rigorous testing and include signed, hardened binaries. Defects can be reported via a customer portal and guaranteed SLAs ensure quick remediation for high and critical CVEs on Puppet software. Puppet Core also incorporates built-in enforcement of popular security baselines to ensure your infrastructure is continuously verified as compliant.

Why Organizations Choose the Puppet Enterprise Platform

As infrastructure grows and compliance demands intensify, organizations often outgrow the limitations of their automation tools. Whether it’s the need to scale rapidly or respond swiftly to security vulnerabilities, teams require a platform that evolves with them.

That's why many who start with Open Source Puppet or Puppet Core later transition to Puppet Enterprise: to gain the advanced features, enterprise support, and integrated capabilities that modern environments demand.

Deciding Which Puppet Solution Your Organization Should Choose

l Choose OpenSource Puppet if:

• You have minimal security and compliance requirements

• You don’t need formal SLAs for your Puppet software

• Your infrastructure is relatively simple and not spread across hybrid/cloud environments

• You don’t require the latest OS support or access to enterprise-grade agent updates

l Choose Puppet Core if:

• You need releases with secure, signed binaries

• Your team has the in-house expertise to manage infrastructure automation software

• You prefer a hands-on, code-centric approach to infrastructure management

l Choose the Puppet Enterprise platform if:

• Your IT infrastructure is large, complex, or hybrid (e.g., thousands of servers, multi-cloud)

• You want intuitive, GUI-based tools to manage the full infrastructure lifecycle

• You want to empower more team members to access infrastructure insights and take action (without needing Puppet expertise) through AI-driven, natural language interaction

• You need a solution that scales without adding operational overhead or tool sprawl

• You want seamless integration with your existing security, observability, and self-service tools

• You require centralized control for compliance reporting, vulnerability remediation, and audit readiness

• You aim to build powerful automation workflows without reinventing your toolchain

• Your organization is growing — whether through scale, expansion, or complexity

• You’re ready to simplify infrastructure management and increase operational efficiency

The Puppet Enterprise platform is the only solution that combines both model-based (declarative) and task-based (imperative) capabilities in a way that enables you to scale

your hybrid infrastructure as your automation footprint grows. With both agent-based and agentless capabilities, the Puppet Enterprise platform gives your organization the flexibility to automate what you want, how you want, wherever you want.

Next Steps: Getting Started

Ready to take the next step with Puppet?

Whether you're just beginning or expanding your automation journey, our team at Dragonsoft, an authorized Perforce partner,is here to help. We'll work with you to assess your current environment, understand your goals, and chart a clear path to a more secure, efficient, and resilient infrastructure.

Schedule a demo or connect with our team to explore the best Puppet solution for your organization.

Website: www.hkdsdtech.com

Phone: +852-51679050

Email: marketing@hkdsdtech.com

New Benchmarks now Available for Puppet SCE for Linux

Jason St-Cyr — Thu, 30 Jul 2026 11:49:16 +0000

Security Compliance Enforcement (SCE) for Linux 2.8.0 is now available, delivering updated CIS Benchmark coverage along with improvements to policy enforcement, auditing, and logging reliability. These updates help organizations strengthen compliance programs, reduce operational risk, and maintain confidence that Linux systems remain aligned with security and governance requirements. SCE for Linux is available as part of Puppet Core and Puppet Enterprise Advanced.

Why Upgrade?

Stay aligned with current CIS guidance through updated benchmark coverage for major enterprise Linux distributions.
Improve audit readiness with expanded benchmark coverage and updated compliance checks.
Reduce operational risk through fixes that improve firewall, integrity monitoring, and logging behavior.
Increase confidence in enforcement by addressing issues that could prevent configurations from being applied as intended.

What's New?

Updated CIS Benchmark support for RHEL 8, AlmaLinux 8, Oracle Linux 8, and Rocky Linux 8.
Enhancements that improve alignment with current benchmark recommendations across system hardening, auditing, networking, and account management.
Reliability improvements for firewall zone enforcement, AIDE-based integrity monitoring, and log forwarding.
Updated platform dependencies to support ongoing compatibility and maintainability.

Security and Maintenance Updates

This release includes maintenance updates and issue resolutions that help improve platform stability, reduce security risk, and support more reliable compliance operations.

Next Steps

Review the release notes for complete details and upgrade guidance, then plan your upgrade to take advantage of the latest benchmark coverage and reliability improvements.

If you're new to SCE, visit the documentation page to learn how it helps automate compliance assessments, policy enforcement, and ongoing audit readiness across enterprise Linux environments.

Building with AI: Our Approach to Responsible Agentic Development in Open Source

Jason St-Cyr — Tue, 28 Jul 2026 12:36:14 +0000

The tech world has been building up towards the shift to a fully agentic development life cycle for a few years now. AI is changing how software gets built.

Across the Puppet ecosystem, we're seeing a shift toward more agentic engineering workflows. AI helps generate code, shape documentation, and accelerate how Puppet modules evolve. This brings real benefits in speed and consistency, but it also raises important questions from the community:

How are AI-generated changes validated?
How do you ensure consistency across modules?
What does this mean for contributors and maintainers?

These are exactly the kinds of questions we should be asking! This article will outline how Perforce and the Puppet team are approaching the use of AI in our open source modules and repositories.

How We Build Trust in AI-Assisted Contributions

At Perforce, AI is a core part of our process and our teams operate within a defined, governed framework for development. We don’t rely on trust in the tool itself. We rely on the processes around it.

Whether a change is written by a person, generated with AI, or some mix of both, they are held to the same standards before it’s accepted and released.

In practice, that means:

Human review is always the gate: Every change is reviewed by maintainers. AI can assist, but it doesn’t replace accountability.
AI works within established patterns: AI-generated code isn’t created in isolation. It’s guided by the same module structures, conventions, and expectations that already exist across the ecosystem.
Validation is continuous and enforced: AI doesn’t change our standards. It reinforces them. AI-generated changes go through the same checks as any other contribution:
- Test suites
- Integration validation
- Functional verification
AI output is a starting point, not a final artifact: Generated code is iterated on, refined, and aligned before acceptance. We treat AI as an accelerator, not an authority.
The community plays an important role Open source means visibility. The community can review changes, raise issues, and contribute ideas. That feedback loop adds another layer of resilience and helps shape how these workflows evolve.

At a high level, our approach is simple: the outcome matters more than how the code was created.

Community Contributions and AI

Community members are not required to use code assist tools when providing contributions to Puppet open source projects, even when those projects contain frameworks or files designed to support coding agents.

Contributions can be made using any tools or workflows that work best for you and there is no expectation to match the Perforce technology stack. While the Puppet team will be adding instructions, skills, and other artifacts to support agentic workflows, including tools like Claude Code, these are provided as optional enhancements, not requirements.

When contributions are reviewed, the same standards apply regardless of how they were created. This includes contributions that contain AI-generated code, are submitted by AI agents, or have been tested or reviewed using AI tools. We welcome contributions in any form, but all submissions go through the same review and approval process before they are accepted and released.

Maintaining Consistency Across the Ecosystem

Another important question we hear is how we avoid duplication or inconsistency as AI becomes part of the workflow. This is where ecosystem-level thinking and governance matter most and where we will be incrementally improving our engineering patterns.

Here’s how we approach that:

Changes are evaluated in context We don’t review contributions in isolation. We look at how they relate to existing modules and whether similar functionality already exists.
Reuse is prioritized over duplication When reviewing changes, we actively ask whether something can be reused instead of reimplemented. This helps maintain DRY principles across the ecosystem—not just within a single module.
Shared patterns guide development AI-assisted changes are aligned to standard module structures, established design patterns, and proven implementation approaches. This helps ensure consistency even as contribution velocity increases.
Documentation is treated as part of the system Generated documentation and supporting artifacts are treated as first-class components. This improves clarity, supports reuse, and helps maintain long-term consistency across modules.

Governance Is Built In, Not Bolted On

Building with AI tools is not left to individual discretion. AI usage at Perforce follows structured processes designed to ensure quality, security, and accountability across the lifecycle.

Here’s what that looks like for Puppet open source teams:

AI tools and workflows are intentionally reviewed We evaluate how AI tools are used within our development process, including how they interact with existing systems and patterns. Only tools approved for use by the Perforce AI governance team can be used for agentic development by Perforce employees.
Risks and dependencies are actively managed Using agentic development flows introduces new considerations from code duplication to unintended behaviors. These are identified, reviewed, and addressed as part of normal development workflows.
Security and compliance are built into the process AI-assisted development operates within the same security, permission, and compliance boundaries as any other contribution.

AI usage is part of a broader AI management system aligned with ISO 42001, ensuring responsible use across the lifecycle.

We also recognize the broader concerns around AI. We're deliberate about how and where AI is used. At its core, governance is about maintaining control while enabling progress. AI should operate within the systems teams already trust, not bypass them.

Our Commitment to the Open Source Community

This evolution isn’t happening in isolation. The Puppet modules team works within an open source ecosystem and it’s important that the community is informed about AI usage and included so that all members of the community are able to provide feedback as these processes evolve.

Our goal is to provide:

Clear communication about AI-assisted changes
Transparency in how contributions are reviewed
Ongoing dialogue as workflows evolve

This is a new world of software delivery that we all maintainers and contributors are collaborating in, and we'll need to work together to find the right process for everyone.

What This Means Going Forward

The agentic software development lifecycle is going to continue to shift and grow. AI will continue to play a growing role in how modules are developed and maintained.

In your favorite Puppetlabs modules, you are going to see:

Structural documentation, skills, instructions, and other frameworks to support agentic development
More AI-assisted contributions to open source repos
More structured documentation that aligns across the ecosystem
An increase in iteration cycles as agentic workflows grow and stabilize

There is one thing that won't change: Every contribution will be held to the same standards of quality, consistency, and trust.

In the end, trust in AI doesn’t come from the model. It comes from the systems, processes, and people behind it.

We want to hear from the community as we continue to evolve these practices and develop a solid agentic-supported workflow for our open source community. We’d love your feedback, so please share your thoughts here or in the Puppet Community Slack.

Additional Resources

These additional resources could be helpful if you are interested in this topic and want to learn more!

AI Governance at Perforce (trust.perforce.com)
Perforce AI Products and Features Achive ISO 42001 Certification (perforce.com)

🤖 AI Disclosure

You'll probably notice a few tell-tale structural suggestions from AI on this one. I experimented with drafting with AI on this one, using our AI Governance documentation and some context I provided about how we work on the Puppet team. From that draft, it has gone through multiple human reviews and a LOT of editing and rework, with a final review by an AI agent for brand voice alignment.

Integrar los datos de fichaje con el software de nóminas: el flujo real (export-validación-gestoría)

Nucleo360 — Mon, 27 Jul 2026 16:17:52 +0000

Desde el 12 de mayo de 2019, el Real Decreto-ley 8/2019 (BOE-A-2019-3481) obliga a todas las empresas en España a llevar un registro horario diario de su plantilla. Ese registro no vive aislado: cada mes, alguien tiene que convertir horas trabajadas, horas extra y ausencias en una nómina. Y ahí es donde muchas pymes pierden tiempo (y cometen errores).

En este artículo documentamos el flujo real para llevar los datos de fichaje de Nucleo360 hasta el software de nóminas o el gestor laboral, con un paso de validación intermedio que te puede ahorrar más de un disgusto.

Empecemos por la honestidad técnica

Nucleo360 no calcula nóminas. Es una decisión de producto deliberada: la plataforma cubre el registro horario, las vacaciones y ausencias, la gestión documental, el canal de denuncias y el resto de la gestión de RRHH de una pyme, y exporta la documentación y los datos al gestor laboral o al software de nóminas que ya usa la empresa. El cálculo de la nómina (convenios, cotizaciones, IRPF) lo hace quien mejor sabe hacerlo: tu asesoría o tu programa de nóminas.

Eso significa que la integración de la que hablamos aquí no es una sincronización mágica en tiempo real, sino un pipeline de datos clásico y robusto: exportar → validar → entregar. Es aburrido, y por eso funciona.

El flujo en tres pasos

Paso 1 · Exportar el periodo desde Nucleo360

Al cierre de cada mes (o del periodo que pacte tu gestoría), se exportan desde Nucleo360 los datos del registro horario del periodo: fichajes por empleado y día, con sus tramos de entrada y salida y los totales. El registro es inmutable y con trazabilidad (quién fichó, cuándo y desde dónde), así que lo que exportas refleja lo que realmente se registró, no una versión editada a posteriori.

Para nóminas, lo habitual es trabajar con el export en formato tabular (CSV) o con los informes del periodo, según lo que acepte tu gestor.

Paso 2 · Validar antes de enviar

Este es el paso que casi nadie hace y el que más errores evita. Antes de entregar los datos a quien hace la nómina, conviene comprobar tres cosas:

Totales por empleado: que las horas del mes cuadran con lo esperado (jornada pactada ± extras).
Huecos: días laborables sin ningún fichaje. Pueden ser vacaciones o ausencias legítimas (cotéjalo con el módulo de vacaciones), o pueden ser olvidos que hay que resolver antes de que lleguen a la nómina.
Solapes: tramos que se pisan entre sí (entrada a las 9:00 y a las 9:30 sin salida intermedia). Suelen indicar un fichaje duplicado o mal cerrado.

Aquí tienes un ejemplo genérico en Python (solo librería estándar) que hace exactamente eso sobre un CSV de fichajes. No depende de ningún proveedor: ajusta los nombres de columna a los de tu export real.

#!/usr/bin/env python3
"""
EJEMPLO GENÉRICO de validación de un CSV de fichajes antes de
entregarlo al gestor laboral. Ajusta columnas y delimitador a tu export.

Formato esperado (una fila por tramo de fichaje):
    empleado_id;nombre;fecha;hora_entrada;hora_salida
    E001;Ana;2026-07-01;08:00;15:00
"""
import csv
import sys
from collections import defaultdict
from datetime import datetime, timedelta

FORMATO_FECHA = "%Y-%m-%d"
FORMATO_HORA = "%H:%M"


def cargar(ruta):
    tramos = defaultdict(list)   # (empleado_id, fecha) -> [(inicio, fin), ...]
    nombres = {}
    with open(ruta, newline="", encoding="utf-8") as f:
        for n_linea, fila in enumerate(csv.DictReader(f, delimiter=";"), start=2):
            try:
                dia = datetime.strptime(fila["fecha"], FORMATO_FECHA).date()
                entrada = datetime.combine(
                    dia, datetime.strptime(fila["hora_entrada"], FORMATO_HORA).time())
                salida = datetime.combine(
                    dia, datetime.strptime(fila["hora_salida"], FORMATO_HORA).time())
            except (KeyError, ValueError) as e:
                print(f"[ERROR] Línea {n_linea}: fila ilegible ({e})")
                continue
            if salida <= entrada:
                # Turno nocturno: la salida cae en el día siguiente
                salida += timedelta(days=1)
            tramos[(fila["empleado_id"], dia)].append((entrada, salida))
            nombres[fila["empleado_id"]] = fila.get("nombre", "")
    return tramos, nombres


def validar(tramos, nombres):
    total = defaultdict(timedelta)
    dias = defaultdict(set)
    incidencias = 0

    for (emp, dia), lista in sorted(tramos.items()):
        lista.sort()
        # Solapes dentro del mismo día
        for (ini_a, fin_a), (ini_b, fin_b) in zip(lista, lista[1:]):
            if ini_b < fin_a:
                print(f"[SOLAPE] {emp} {dia}: "
                      f"{ini_a:%H:%M}-{fin_a:%H:%M} se pisa con {ini_b:%H:%M}-{fin_b:%H:%M}")
                incidencias += 1
        for ini, fin in lista:
            total[emp] += fin - ini
        dias[emp].add(dia)

    # Huecos: días laborables (L-V) sin fichajes dentro del rango del archivo.
    # OJO: pueden ser vacaciones o ausencias legítimas; esto solo los señala.
    for emp, fechas in dias.items():
        d, ultimo = min(fechas), max(fechas)
        while d <= ultimo:
            if d.weekday() < 5 and d not in fechas:
                print(f"[HUECO] {emp} ({nombres[emp]}): sin fichajes el {d} "
                      f"(¿vacaciones/ausencia sin cotejar?)")
                incidencias += 1
            d += timedelta(days=1)

    print("\n--- Totales por empleado ---")
    for emp, t in sorted(total.items()):
        horas = t.total_seconds() / 3600
        print(f"{emp} {nombres[emp]:<20} {horas:6.2f} h en {len(dias[emp])} días")
    return incidencias


if __name__ == "__main__":
    if len(sys.argv) != 2:
        sys.exit("Uso: python valida_fichajes.py fichajes.csv")
    tramos, nombres = cargar(sys.argv[1])
    n = validar(tramos, nombres)
    print(f"\n{n} incidencias detectadas.")
    sys.exit(1 if n else 0)

El script devuelve código de salida distinto de cero si hay incidencias, así que puedes encadenarlo en cualquier automatización: si algo no cuadra, el archivo no sigue viaje hacia la nómina.

Paso 3 · Entregar al gestor (bien empaquetado)

La entrega falla casi siempre por detalles tontos de formato, no por los datos. Pacta con tu gestoría o con quien opere el software de nóminas, una sola vez y por escrito:

Columnas y su orden (una tabla de mapeo de dos columnas es suficiente).
Codificación: UTF-8. Los nombres con tildes y eñes lo agradecerán.
Delimitador (; es lo habitual en España, porque la coma decimal rompe los CSV con ,).
Formato de fecha: ISO 8601 (2026-07-01) evita el clásico baile día/mes.
Fecha de corte: qué día del mes se exporta, para que la nómina no espere.

Y conserva una copia de lo entregado: el registro horario debe conservarse 4 años (art. 34.9 del Estatuto de los Trabajadores).

¿Y la integración directa por API?

Pregunta legítima de cualquier perfil técnico: «¿puedo saltarme el CSV y tirar de API?».

Respuesta honesta: a fecha de este artículo, la integración directa vía API con sistemas de nóminas está [PENDIENTE DE CONFIRMAR CON CLIENTE] — no hay una API pública documentada que podamos enseñarte aquí, y preferimos no inventárnosla. El flujo soportado y probado es el que acabas de leer: export, validación y entrega.

¿Se integra directamente con algún programa de nóminas concreto?

Misma honestidad: no hay integraciones directas confirmadas con programas concretos de nóminas ni con gestorías [PENDIENTE DE CONFIRMAR CON CLIENTE]. Lo que sí funciona hoy es el puente universal: la mayoría de software de nóminas y gestorías aceptan importación de datos tabulares (CSV) o trabajan directamente con los informes del periodo. Pregunta a tu gestor qué formato de importación acepta su herramienta y pacta el mapeo de columnas del Paso 3.

¿Menos glamuroso que un webhook? Sí. ¿Funciona con cualquier gestoría de España sin depender de que dos proveedores se pongan de acuerdo? También.

En resumen

Nucleo360 registra la jornada (registro inmutable, con trazabilidad) y exporta; la nómina la calcula tu gestor o tu software de nóminas.
Valida siempre antes de entregar: totales, huecos y solapes. El script de arriba es un punto de partida.
Pacta el formato con tu gestoría una vez y por escrito; UTF-8, ; e ISO 8601 te evitan el 90 % de los problemas.
API pública e integraciones directas con programas concretos: pendientes de confirmar; hoy el camino es el export.

Si quieres ver el módulo de registro horario en detalle (el plan Basic es gratuito y sin permanencia), tienes toda la información en nucleo360.com.

Última actualización: julio de 2026.

Nucleo360.com

Puppetlabs Modules Now Have Tiered Review Cycles

Jason St-Cyr — Tue, 14 Jul 2026 14:16:39 +0000

If you've been watching the Puppetlabs namespace on the Forge (or waiting on a pull request you opened) you've likely noticed that the pace of inclusion of community pull requests and fixes into the module releases has slowed over the last several cycles. That isn't how we want to serve the community that built these modules with us. The team has been reviewing how we can improve and this post is our commitment to do better. Here are the steps we're taking now:

Clear tiers with review cadences. Modules in the puppetlabs namespace will be grouped into three tiers, each with a defined review schedule (weekly, monthly, or quarterly).
Defining what “review cadence” means in practice. Every community PR gets engineering review in the next scheduled cycle for that module’s tier.
Showing progress monthly. We’ll continue to publish the monthly Modules Roundup covering what was released.

A Tiered Approach to Priorities

We've categorized supported modules in the puppetlabs namespace into three tiers, each with a defined community review cadence:

Tier	Count	Community review cadence
Tier 1: core, business-critical modules	25	Weekly
Tier 2: important, meaningfully used modules	19	Monthly
Tier 3: niche or low-usage modules	22	Quarterly

What a Review Cadence Means

Every community pull request (PR) on a module in the puppetlabs namespace gets engineering review during the next scheduled cycle for that module's tier. This doesn’t mean that every PR will be accepted. Sometimes a pull request needs feedback or changes, some pull requests won't fit a module's direction, but the cadence is intended to make sure that PRs will no longer sit quietly in a queue. That is the baseline we're holding ourselves to with these tiers and review cadences.

We do have a backlog of requests over the years and we will be working through that backlog as well, but priority will be given to active contributions for the purposes of our review cadence.

Tier 1: Our highest-priority modules

The following modules are our committed Tier 1 set. These modules will get a weekly review, with nightly CI coverage, and get priority on maintenance capacity:

puppetlabs-apache
puppetlabs-apt
puppetlabs-augeas_core
puppetlabs-concat
puppetlabs-cron_core
puppetlabs-docker
puppetlabs-firewall
puppetlabs-haproxy
puppetlabs-inifile
puppetlabs-java
puppetlabs-java_ks
puppetlabs-lvm
puppetlabs-mount_core
puppetlabs-mysql
puppetlabs-ntp
puppetlabs-package
puppetlabs-postgresql
puppetlabs-powershell
puppetlabs-reboot
puppetlabs-registry
puppetlabs-ruby_task_helper
puppetlabs-service
puppetlabs-sshkeys_core
puppetlabs-stdlib
puppetlabs-vcsrepo

Tier 2: Monthly reviews

The following modules have currently been assigned to our Tier 2 for prioritization. These modules will get a monthly review.

puppetlabs-accounts
puppetlabs-acl
puppetlabs-bolt_shim
puppetlabs-chocolatey
puppetlabs-facter_task
puppetlabs-iis
puppetlabs-kubernetes
puppetlabs-motd
puppetlabs-mount_iso
puppetlabs-node_encrypt
puppetlabs-puppet_conf
puppetlabs-satellite_pe_tools
puppetlabs-scheduled_task
puppetlabs-sqlserver
puppetlabs-sslcertificate
puppetlabs-tomcat
puppetlabs-windows_env
puppetlabs-windows_eventlog
puppetlabs-wsus_client

Tier 3: Quarterly reviews

The modules assigned to Tier 3 are still supported but will not generally be getting a high degree of priority. These modules will be reviewed quarterly and released as needed.

ca_extend
influxdb
puppet_operational_dashboards
puppetlabs-bash_task_helper
puppetlabs-dropsonde
puppetlabs-dsc_lite
puppetlabs-facts
puppetlabs-host_core
puppetlabs-node_manager
puppetlabs-pe_databases
puppetlabs-pe_event_forwarding
puppetlabs-pe_status_check
puppetlabs-puppet_bolt_server
puppetlabs-puppet_metrics_collector
puppetlabs-puppet_status_check
puppetlabs-selinux_core
puppetlabs-splunk_hec
puppetlabs-yumrepo_core
puppetlabs-zfs_core
puppetlabs-zone_core
ruby-pwsh
support-tasks

The Product and Engineering teams are still reviewing the puppetlabs modules for final placement in Tier 2 or Tier 3 and will follow the cadence associated with their tier once that placement is confirmed. Ultimately, the lists above might shift slightly as the team finds that some modules might need more attention than others.

What has already shipped?

It is one thing to say you will do better and quite another to follow through. We’re sharing this now because we have tangible changes already underway. In a focused sprint on Tier 1 modules, the team triaged and actioned several open community pull requests, some merged after review, some closed after discussion, others consolidated with newer work. You’ll see several modules released this month and next with these merged changes on the Forge. Keep an eye on the Forge modules list or check out the next Puppet Modules Roundup post for a summary!

On the Issues With CI for community PRs

We're aware that testing community contributions has been harder than it should be. The current pull request model makes it difficult to run the full acceptance test suite against a contributor's PR without manual effort by Perforce employees, which slows reviews and discourages contributions. Solving this is a priority for the team and we have been prototyping an improved approach that will meet both user expectations and maintaining a secure infrastructure. We’ll share specifics once it's working end-to-end. This is a known gap we're committed to closing.

How We'll Show Our Work

Monthly Modules Roundup. We publish a roundup each month covering what modules have been released, who contributed, and what’s next. You can follow the series here: Puppetlabs Modules Roundup on dev.to.
Contributor recognition. The release notes on the Forge and in the monthly roundup will call out merged community PRs by name.
Public GitHub transparency. We will be following up with contributors directly in pull requests and issues in our open source modules. In advance of a release, we will continue to merge and close PRs so that you can see what will be included in an upcoming release.

How can you help?

Keep contributing! Keep filing issues. Keep telling us when a module is in your way. If a PR of yours has stalled out, please rebase it or comment on the PR. And if the tiering above looks wrong for how you use Puppet day-to-day, let us know! The whole point of publishing this article is so that the community can understand what is changing and also to invite you to shape where the priority goes.

Tiering is not a one-way decision. 

The tiers outlined here have been based on the activity we have observed in our analytics and the importance identified by customers. If a module you depend on isn't in the tier you think it should be, or perhaps a long-waiting PR or issue is blocking you, reach out via the Puppet Community Slack or leave a comment on the monthly Puppet Modules Roundup posts. We want your input to make sure the tiering meet the needs of all our users.

Driving Value from Puppet Metrics: Puppet Observability Data Connector

klab-systems — Mon, 13 Jul 2026 16:28:45 +0000

What is the Puppet Observability Data Connector?

The Puppet Observability Data Connector is a premium Forge module included with Puppet Enterprise Advanced (PEA). This module provides a deeper dive into your Puppet agent reports. Visualizing these metrics gives you a great way to identify what is healthy and unhealthy in your environment.

Behind the scenes, this module provides 2 core functionalities.

It provides a report processor to convert Puppet reports into usable metrics.
It manages an exporter to serve these metrics for your time series database to scrape.

Example Metrics

Failed nodes
Changed nodes
Catalog cache failures
Stale nodes
Corrective changes
Out of sync resources
Average total run time
Max run time
Run time breakdowns
- Total run time
- Fact generation time
- Catalog application time
- Config retrieval time
- Plugin sync time
- Convert catalog time
Managed resource count by host
Managed resource count over time
Catalog application time trends

Using the metrics provided by Puppet Observability Data Connector, you can make impactful dashboards. Below are some examples that I have created.

Note: All dashboards can be filtered by the environment and/or host. All thresholds for color coding can be modified to fit your environment.

Fleet Status Dashboard Example

This example 'Fleet Status' dashboard provides an always-open first-look insight into whether anything in your fleet requires immediate attention. I will break this down by section.

When to Use a Fleet Status Dashboard?

After deploying Puppet code to confirm no regressions
During incidents to identify affected nodes
As part of a daily ops review to verify fleet-wide compliance

Fleet Health Summary (stat panels)

A top-level count of nodes in each state from the most recent run. Six stats that give you an instant fleet pulse without scrolling.

What this tells you:

Term	Description
Total Nodes Reporting	Quantity of nodes submitting reports; this number should be 1:1 with the amount of Puppet agent managed nodes in your environment
Failed Nodes	Nodes where `puppet_status{state="failed"} == 1;` any non-zero value requires immediate investigation
Changed Nodes	Nodes where Puppet applied changes in the last run; expected after a code push, unexpected otherwise
Unchanged Nodes	Nodes fully converged — your desired steady state
Catalog Cache Failures	Nodes that could not obtain a fresh catalog and fell back to a cached one. Triggers on server/network unreachable or any catalog compilation error (duplicate resource declaration, undefined variable, syntax error, missing module)
Stale Nodes (>2h)	Nodes that haven't reported in over two run intervals; the agent may be down, hung, or disconnected

Node Run Status (bar gauges)

Per-node breakdowns of the two most critical run-level signals.

What this tells you:

Term	Description
Time Since Last Puppet Run	Minutes since each node last phoned home. Green = within one run interval (~30 min), yellow = approaching stale, red = definitely stale. Use to find silent failures where the agent has stopped running entirely.
Transaction Completed by Host	Whether the last run completed (1) or was aborted mid-run (0). An aborted transaction means the node's actual state is unknown — treat it the same as a failure.

Compliance & Drift (stats + bar gauges + time series)

This section separates intentional changes (deployments) from unintentional drift (external actors modifying managed state).

What this tells you:

Term	Description
Total Corrective Changes (Fleet)	Aggregate count of corrective changes across all nodes. A corrective change means Puppet found a resource in the wrong state and fixed it — something external changed it. Persistent non-zero values are a compliance red flag.
Total Failed Resources (Fleet)	Resources that Puppet attempted to enforce but could not. Non-zero always warrants investigation.
Total Event Failures (Fleet)	Resource-level event failures, which can appear even on nodes not marked failed. Catches partial failures.
Total Out-of-Sync Resources (Fleet)	Resources declared in the catalog but not yet in the desired state. Elevated values indicate pending convergence or a broken dependency chain.
Corrective Changes by Host	Identifies which specific nodes are experiencing drift. Nodes with persistent corrective changes may have rogue processes or manual interventions overwriting Puppet-managed state.
Failed Resources by Host	Identifies which nodes have broken resources. Cross-reference with the node's Puppet report for the specific resource type and error message.
Corrective Changes Over Time	Trend view — spikes correlate with manual changes, automated tooling conflicts, or software self-repair mechanisms overwriting managed files.
Failed Resources Over Time	Trend view — a step-change increase after a code push indicates a bug in new Puppet code. A gradual increase may indicate environment drift.

Catalog Cache Status (stats + bar gauge)

Catalog cache usage is a leading indicator of Puppet infrastructure health, often surfacing issues before nodes start failing outright.

What this tells you:

Term	Description
Nodes: Cache Used on Failure	A fresh catalog could not be obtained. Common causes: Puppet server unreachable, network failure, or a catalog compilation error (duplicate resource declaration, undefined variable, syntax error, missing module). The node ran with a potentially stale catalog — investigate PE server logs and the agent's last run report.
Nodes: Cache Explicitly Requested	Nodes intentionally running offline (e.g., --use-cached-catalog). Expected during planned maintenance; unexpected otherwise.
Nodes: No Cache (Fresh Catalog)	Healthy nodes compiling a fresh catalog every run — your desired steady state.
Catalog Cache on Failure – by Host	Pinpoints which nodes are falling back to cache. Use to determine whether it's a widespread compiler/network issue or a node-specific catalog compilation error (check that node's agent log for the exact cause).

Full Dashboard Snapshot

Run Performance Example Dashboard

This example 'Run Performance' dashboard acts as your performance and capacity planning dashboard. It answers whether Puppet is running efficiently and helps you locate bottlenecks before they become outages. I will break this down by section.

When to use a Run Performance dashboard?

Run times are creeping up across the fleet
After adding new modules or resource types to identify compile/apply costs
To compare performance across environments (production vs. feature_demo)
When planning infrastructure scaling (for example, adding more compilers or faster agents)

Performance Summary (stat panels)

Fleet-wide performance KPIs. These numbers represent your overall SLA for Puppet run completion.

What this tells you:

Term	Description
Avg Total Run Time	The mean end-to-end run duration across all selected nodes. Green < 120s, yellow 120–300s, red > 300s.
Max Total Run Time	The slowest node in the fleet — identifies outliers dragging down SLA.
Avg Fact Generation Time	How long Facter is taking on average. This phase runs before catalog compilation so delays here block everything downstream.
Avg Catalog Application Time	How long Puppet spends enforcing resources. A reliable proxy for catalog complexity and system responsiveness.

Run Time Trends (time series)

Long-term trend views to distinguish persistent regressions from one-off anomalies.

What this tells you:

Term	Description
Total Run Time Over Time	The most important single trend. A sudden step-change after a deployment indicates new expensive resources. A gradual increase over weeks suggests catalog bloat or system degradation. A red threshold line at 300s provides a visual SLA boundary.
Fact Generation Time Over Time	Isolates Facter performance from the rest of the run. Upward trends often indicate new custom facts, growing hardware inventories, or external fact sources becoming slow.

Run Time Breakdown – Latest Run (by Host) (bar gauges)

Per-node, per-phase timing from the most recent run. Use this to pinpoint which phase is slow on which node rather than just knowing the total is high.

What this tells you:

Panel	Phase	Optimization Lever
Total Run Time	End-to-end wall clock	—
Fact Generation Time	Running Facter	Audit custom facts; disable unused external facts
Catalog Application Time	Enforcing all resources	Reduce catalog size; identify slow resource types (Package, Exec)
Config Retrieval Time	Fetching compiled catalog from PE server	Scale compilers; check network latency between agent and server
Plugin Sync Time	Downloading Puppet functions/types/providers	Audit and prune modules; check if all plugins are necessary
Convert Catalog Time	Transforming compiled catalog into apply-ready format	Indicates catalog structural complexity

Resource Catalog (bar gauge + time series)

Catalog size is the root cause of many performance problems. These panels correlate resource count with run time.

What this tells you:

Term	Description
Total Managed Resources by Host	Nodes with significantly more resources than peers warrant investigation — are all those resources intentional? `pe.klab.internal` managing 2,419 resources vs 61 for simpler nodes is expected for a PE server; unexpected divergence between similar nodes is not.
Total Managed Resources Over Time	A sudden jump indicates a code change added many new resources. Gradual growth over months indicates catalog bloat — exported resources collecting without cleanup, or defined resource types generating more instances than expected.

Catalog Application Time Trends (time series)

Deeper trend analysis for the two phases most sensitive to infrastructure and code changes.

What this tells you:

Term	Description
Catalog Application Time Over Time	Correlate spikes with git commit timestamps. A spike immediately following a deployment confirms the new code introduced expensive resources. Persistent elevation after the spike stabilizes means the cost is structural, not transient.
Config Retrieval Time Over Time	Sustained increases across all nodes simultaneously point to a PE server bottleneck (JVM heap, database pressure, or compiler overload). Increases on a single node suggest agent-side network issues.

Full Dashboard Snapshot

Download the Puppet Data Connector Forge Module

Want to try it in your environment? Download the premium Forge module now.

Get the Module

Wrap-up

The Puppet Observability Data Connector provides valuable information about the Puppet agent nodes across your environment. Visualizing these metrics gives organizations key insights, allowing team members to identify problems, measure performance, and track changes. The dashboards shown here are just one of the many ways to drive value from your Puppet metrics.

For assistance driving value from your Puppet metrics please ask your account team about how Professional Services could help you with dashboards that match your environment and operational priorities.