DEV Community: Ben Ford

First release, hot off the presses!

Ben Ford — Wed, 22 Jan 2025 19:54:53 +0000

It’s been quite a journey, y’all. But we’re excited to announce the first release of OpenVox, the community-maintained open source implementation of Puppet. OpenVox 8.11 is functionally equivalent to Puppet and should be a drop-in replacement. Be aware, of course, that even though you can type the same commands, use all the same modules and extensions, and configure the same settings, OpenVox is not yet tested to the same standard that Puppet is.

Migrating is fairly simple, just replace the packages following instructions on the handy dandy new install page. You’ll notice that they’re still using the apt|yum.overlookinfratech.com repositories.
As we get our infrastructure built out, these will probably be moved to the voxpupuli.org namespace. Please don’t use these packages on critical production infrastructures yet, unless you’re comfortable with troubleshooting and reporting back on the silly errors we’ve made while rebranding and rebuilding.

If you’d like professional assistance in the migration, check out the support page for companies who provide migration services.

We consider OpenVox a soft-fork because we intend to maintain downstream compatibility for as long as we are able. As such, Vox Pupuli is working with Perforce to create a Puppet™️ Standards Steering Committee to set the direction of features and language evolutions.

The OpenVox project goals are pretty straightforward and aim to alleviate pain points observed by the community over the last few years:

Modernizing the OpenVox codebase and ecosystem, including supporting current operating systems.
Recentering and focusing on community requirements; user needs will drive development.
Democratizing platform support by allowing community members to contribute what they need instead of waiting for business requirements to align.
Maintaining an active and responsive open source community like the rest of Vox Pupuli's namespace.

Find out more or get involved at our GitHub namespace.

Security considerations of configuration management

Ben Ford — Wed, 29 May 2024 21:24:36 +0000

We often take for granted that the security implications of using configuration management tools like Puppet, Chef, or Ansible are obvious, but that’s far from the truth. I would be lying if I said that I’d never deployed dangerous configuration management code into production use that in retrospect should have been obvious from the start. Here’s a great example; the ability to destroy the online Puppet code validator was live for over a year!

So with that in mind, let’s take a wander through the Puppet ecosystem and talk about some things that might have security implications and might warrant a closer look in regard to access control. And let’s not bury the lede here; no matter what framework you’re running, configuration management is by definition root/Administrator level access to your entire infrastructure and access to its setup and codebase should be treated as such. The examples referenced in this guide are specific to Puppet, but the higher-level concepts are not. If you’re using a competing configuration management platform, you should evaluate your usage for similar patterns.

Taking a security mindset here means that this guide will refer to “attack vectors.” This does not mean that there is a vulnerability. It simply means that there might be potential for an attacker to exploit a misconfiguration. And to be clear, this is not intended to be an exhaustive checklist of the things you should avoid; instead, it’s a guide of how to think about code deployed into a configuration management infrastructure.

📝
The basic trust model of Puppet and other configuration management systems is that you are expected to maintain trusted control over your codebase.

In hindsight, that's kind of obvious -- configuration management works by distributing certain kinds of code and data across your infrastructure and executing it with admin privileges to ensure that your systems are configured in the state you want.

But there are a few places where this executable code isn't obvious. Less scrutiny means that these areas can be used as attack vectors. For example, during catalog compilation, functions are executed on the server. This means any custom functions included in modules, but it also means compiling Ruby code in ERB templates, and shell code run by the generate() function, and so on. The config_version script is executed prior to a catalog compilation; people usually use it to expose git revisions or the like, but it's just a shell script. It can run anything you want, and it's right in the control repository. And custom facts sync out and start running with root privileges across your whole infrastructure as soon as you install their modules.

Security recommendations:

When installing new modules you should audit:
- Check for custom facts and functions and see what they do.
- Check for ERB templates and ensure that they contain only presentation or layout code, such as iterating over an array to build stanzas in a configuration file. Any other Ruby logic is suspect. Check manifests for use of the inline_template() function and validate them in the same way.
- Skim the manifests for use of the generate() function. There are extremely few valid use cases for this function, so any sight of it should be a red flag.
When reviewing pull/merge requests to your control repository:
- Pay very close attention to any changes to the config_version script.
- If new modules are added to the Puppetfile, then verify that they’ve been audited.

The Puppetfile is another surprise. It looks like a data file, and so many people doing code review treat it like data. But it's actually a custom DSL implemented as Ruby, meaning that it's possible (although highly discouraged) to include arbitrary code that will run during a codebase deploy. This is a sneaky attack vector because if someone can create a branch in your control repository, then it may be deployed and executed before anyone else can review it.

Security recommendations:

Do not allow untrusted users the ability to create branches in your control repository.
Consider using VCS checks to reject commits containing unexpected code in your Puppetfile. An unsupported and lightly tested example is available here.
When reviewing pull/merge requests to your control repository, pay very close attention to any changes to the Puppetfile and review it like code rather than treating it like simple data.

And of course, any modules you add to your control repo can run any custom extensions, or exec statements, or anything at all anywhere it's classified onto a node. Malicious modules can theoretically have a higher impact, because they're invoked as the root or admin user.

Security recommendations:

When installing new modules you should audit:
- Skim the manifests to get a general idea of how the module works and what it manages. Pay extra attention to anything that seems out of place.
- Look for resources that run shell code, such as exec, or cron jobs, the validate parameter of the file type, or the various command parameters of the service type. Besides looking for malicious code, also inspect for unsafe interpolation that can be used for shell injection attacks.
- Check for custom types and providers. These are not as simple to read but you should look for anything that looks out of place or unrelated to the thing it claims to manage.

If you identify any concerns, raise them as issues on the module’s repository or ask community peers about it in our Slack workspace.

Most of this shouldn't be terribly concerning. Again, automating the execution of code across your infrastructure is what infrastructure automation does. But it is important to remember that and treat your control repository and anything it might contain as privileged code. Audit modules before you use them, or only use modules from trusted authors. Be careful who has access to your control repo, or entries in your Puppetfile. And don't forget about the various unexpected code execution triggers. Classifying modules onto nodes isn't the only way to get their code to run.

Remember, this is not an exhaustive list of everything to look for. But I do hope that it gives you an idea of the types of vectors that could be abused by malicious actors and some good habits to get into. What other safeguards do you have protecting your codebase? Drop them in the comments!

May the Source Be With You, 2024!

Ben Ford — Fri, 03 May 2024 18:37:38 +0000

It's Star Wars Day again, and we usually do a hackathon to celebrate. This year it falls on a weekend though, and we're trying to get better at respecting everyone's work-life balance and personal time.

Luke Skywalker actually only said May the Force be with you! once and it was offscreen. We're going to channel a bit of that energy here and do a low-key "offscreen" self-paced hackathon. Any non-trivial pull request contributed to either the puppetlabs or voxpupuli GitHub namespaces on May 4 will earn you an iconic May the Source Be With You sticker.

So what's fair game? Anything, really. Write a blog post for Vox. Fix a bug for add a feature to a Puppet Supported module. Clean up documentation for r10k to make it more readable. Check out the issues list on the Vox Pupuli homepage and see if there's anything that you'd like to fix.

Just don't flood us with low effort spam. We all remember what happened with Hacktoberfest. If you contribute something, make it more than a whitespace or typo fix.

And a very important point to close on! If you want the sticker, you'll need to use this form to share your mailing address.

You can follow along and see what's been contributed with this dashboard. Who will be the first to contribute?

Happy weekend, happy hacking, and we're excited to see what you create. May the source be with you!

Announcing Puppet Enterprise 1401

Ben Ford — Mon, 01 Apr 2024 05:36:34 +0000

In the rapidly changing world we live in, it’s easy to overlook the quiet minority of the tech industry that doesn’t keep up with the breakneck pace of innovation. Rather than living on the bleeding edge, they value the fantastic stability that comes from running decades-old software which has withstood the test of time. To them, change is anathema--nothing but an opportunity for something to break.

Puppet's workflow is ideal for such use. Once you've defined your desired state, Puppet's consistency model will maintain that state indefinitely--years, if needed. It should come as no surprise that 100%^* of sites running IBM 1401 machines have requested a version of Puppet for their systems. We are happy to respond to this overwhelming demand and are announcing Puppet Enterprise 1401 ^tm today. This is the same Puppet Enterprise you know and love, tailored carefully to fit into the unique limitations of the IBM 1401.

Obviously, the runtime environment is significantly different from other systems that Puppet runs on and this necessitated some workflow changes. Instead of the server-client model traditionally used by Puppet infrastructures, Puppet Enterprise 1401 ^tm works with an existing Puppet Enterprise server and allows you to compile your configuration catalog onto a set of punchcards along with the 1401 Puppet Catalog Applicator.

This model is truly agentless, as the 1401 Puppet Catalog Applicator makes the catalog self-loading. This uses the GnuCobol backend to compile your Puppet code into Autocoder, and then uses 1401 Autocoder with COBOL subroutines to generate machine language that your IBM 1401 can process to manage its configuration.

To process the Puppet self-loading configuration catalog, the 1401 must have at least:

A minimum of 8,000 positions of core storage
Four IBM magnetic-tape units
IBM 1403 Printer, Model 2
IBM 1402 Card Read-Punch
Advanced Programming Feature
High-Low-Equal Compare Feature
Multiply-Divide Feature
Input and output units defined in the FILE-CONTROL paragraph.
Sense switches

Operator Instructions

Ready the tapes on tape units 2, 3, and 4. These tapes are used for runtime state management.
Load the card reader with the Puppet catalog set of cards.
- The catalog must be preceded by a COBOL RUN card and followed by an END OF SOURCE card.
Set sense switches as follows:
- Turn sense switch A on if you'd like to keep the main applicator program in core storage. This requires more positions free, but is much faster.
- Turn sense switch F on if you'd like to log output to the line printer.
- Turn sense switch G on to run in no-op mode.
Press the START button once to load the 1401 Puppet Catalog Applicator into core memory.
When card reading stops, press the START button once more to read and process the catalog.

Find out more about Puppet Enterprise 1401

Images from:

By stretching the rules of mathematics a bit, 0 out of 0 is 100%.

The internet is on fire again. This time it's XZ

Ben Ford — Sat, 30 Mar 2024 18:32:59 +0000

It appears that the internet is on fire again. This time in a story reminiscent of Cliff Stoll's hunt for a 75 cent accounting discrepancy, a software engineer doing some profiling noticed slightly elevated CPU usage where it shouldn't be. He tugged on that thread and discovered a cleverly obfuscated backdoor in the XZ compression utility that leads to unauthenticated SSH logins.

ℹ️ tldr; if you don't have time to read the full post, we have released a Puppet module that can help detect the current known xz backdoor.

What makes this compromise so concerning is that it was perpetuated by a long-term known contributor, with maintainer access to the XZ GitHub repository. This malicious actor has been working hard for at least two years to lay the foundation for this backdoor. They utilized sockpuppet accounts to pressure the original maintainer to accept help from a relatively unknown contributor and then later to weasel the compromised library into popular Linux distributions.

This attack was not only technical in nature, but also compromised the social network foundation of the open source community. We will be learning and evolving from this attack for years.

Our current understanding says that the XZ backdoor is the only active compromise, but due to the convoluted and long-term nature of the attack, everything they've touched for the last two years is suspect. And because the malicious actor had admin access to the XZ repository and could have easily spoofed commits, all activity in the repo is also suspect.

We'll be untangling this for a while. What we have today is a quick script to detect the known compromise.

Nick Burgan, a software engineer at Puppet whose name you might recognize from their community engagement, took the initiative to build a quick module which orchestrates that detection script across your infrastructure.

All the usual disclaimers apply. We currently have no way of knowing how complete that detection script is. The nature of the compromise means that our understanding of it will continue to evolve for weeks and new detection methods will be discovered. Your help in keeping the module current with the latest detection methods would be greatly appreciated!

This module provides both a task which you can run interactively across nodes in your infrastructure and can also set up a scheduled task to run the detection script daily. We encourage you use this scheduled task and to pin the module to the latest release in your Puppetfile to ensure that you get updates. This will ensure that when we add improved detection methods, your infrastructure will be running them shortly.

# `Puppetfile`

mod 'puppetlabs-xzscanner', 'latest'

Then classify all nodes with xzscanner. You might do that by putting it in a base profile class, or by adding it to the global site.pp.

Header photo from https://www.flickr.com/photos/jeremybrooks/2398999602/

Recovering archived Puppet blog posts

Ben Ford — Tue, 27 Feb 2024 00:00:00 +0000

The Puppet blog has long been a treasure trove of content. You never knew what you might find; a product announcement, an industry analysis, a user interview, a technical post. And it never deleted content, so people got into the habit of linking to blog posts to use as reference or documentation.

This was really great in a lot of ways, but it came with its downsides. Outdated content didn’t always get updated expediently and the amount of content just kept growing so there really wasn’t a good way to manage updates. Only the content that was actively noticed and complained about was updated. So links across the web often pointed to old and outdated content….

🔔 Unfortunately due to how Google indexing works, that really meant that the old, outdated, and often inaccurate content surfaced at the top of search results way too darn often!

During the acquisition, the new marketing team made the decision to declare bankruptcy and start over. They decided to refocus the blog on mostly industry news and product updates and asked the Community and Engineering teams to republish still-relevant content onto the engineering blog. They kept some of the old content that was performing well from an SEO standpoint and still relevant, but archived most of it.

Understandably, this was dismaying for those of us using these posts for documentation! But don’t fret, there is a blog archive located at https://prod-puppet-blog.netlify.app/blog/.

I’ve created a shortcut a method for retrieving pages from the archive if you have the URL.

First drag this link to your bookmarks folder and give it a reasonable name like “retrieve archived Puppet blog posts.”
Then when you see a link that leads to an archived post that you’d like to recover right click and copy it.
Click the bookmark and paste the URL into the dialog you see.

When you click OK, it will take you to directly the archived content. Save the page for your own reference or republish it as long as you respect copyright. _ 🚨 Please don’t link to the archive _, as there’s no guarantee how long it will stay running.

Happy excavating!

(image from https://www.worldhistory.org/image/1353/archaeology/)

Vox Pupuli Elections, 2024 edition

Ben Ford — Mon, 12 Feb 2024 13:42:44 +0000

As announced at CfgMgmtCamp last week, we are kicking off the more-or-less annual PMC elections process. This is a yearly process to provide more people opportunities to get involved with our leadership and decision making. Would you like to help set roadmap or help architect our Puppet 8 support plans? Do you want to help organize events or run social media? Do you love spreadsheets and want to help with accounting and fundraising? Maybe you'd like to help curate our blog or source content from fresh writers.

Maybe you just want to get involved and help out with whatever is needed. Joining the PMC is your avenue to this involvement.

Starting today, you may nominate yourself or someone else for the elections. Nominations are open until March 22 2024 23:59 UTC and then we'll vote to select the 5 new members of the PMC.

See the elections page in our plumbing repository for nomination instructions.

I'll be your elections officer this year. I hope to see your PR soon, and I've got a Vox hoodie for the first person to submit a nomination.

Thanks!

CfgMgmtCamp talks I want to see

Ben Ford — Wed, 31 Jan 2024 00:33:21 +0000

CfgMgmtCamp is next week, and I hope you got all your travel booked already! This conference means a lot to us in the Puppet ecosystem; we've been coming back to Ghent and seeing familiar faces each year for over a decade now (with the obvious exceptions).

We've made a lot of great memories there, from sushi boats with Toshi to drinking too much jenever at 't Dreupelkot and sleeping through my first session. I'm looking forward to seeing the "troll bar" again, of course.

It's not all fun and games, of course. Every year we learn something new and exciting and spend time brainstorming and dreaming up new visionary ideas. Sometimes those ideas even get implemented and become the subject of next year's talks. Last year Adam told us that DevOps was invented to paper over the pain of traditional sysadmin tools and posits that we're now into second order tooling to paper over the pain of DevOps and I'm looking forward to hearing what's new this year.

I have a somewhat eclectic list of talks I am hoping to see. Some are because I want to learn, but some just sound fun or intriguing. This year we've even got a couple talks on how to improve the climate footprint of your infrastructure!

Michael Coté is talking about the fear of change at an organizational level. Whether it's moving to (or from) GitOps or deploying a new internal developer platform or building a new career mentoring program, we all combat organizational inertia and I'm interested in learning some new tactics for dealing with it.

In most programming languages and computing platforms these days we no longer have to think to hard about registers and L2 cache or endianness or interrupt handling and jump tables. We just write our application code and let the runtime figure out all the gory details. Winglang is a higher order programming language that promises to abstract away cloud resources in similar ways so that you can declare them and use them right alongside application code and Elad Ben-Israel is going to show how it works.

There are several others, from what to do when automation just amplifies technical debt, to a story of the kids taking up mainframe systems alongside the old fogeys 😜.

Florian Haas is going to talk about why he doesn't believe in simplification, and while I don't think I agree with him, I'm looking forward to learning and being proven wrong.

Of course, there's a 1-2-3 from Tim and Martin and Alessandro on some of the things you can do with Puppet, from troubleshooting to writing better code. There's even a talk on event driven Ansible, which I've been meaning to read more about.

Like always, the third day is Puppet's Community Day. We'll have a couple engineers from our DevX team if you have questions or ideas about any of our developer tooling. We'll be collaborating on modules and tools and processes and such. And we'll be kicking off Vox Pupuli's annual election process.

I'm really looking forward to seeing a lot of you next week. If you haven't registered yet then go do it! It's free and helps us with capacity planning. Don't forget to select the "Workshop / Fringe" option and sign up for Community Day so we know how many to expect.

Get your CfgMgmtCamp & Puppet Community Day tickets before they’re gone!

Ben Ford — Wed, 17 Jan 2024 20:08:26 +0000

It’s only a few short weeks until we meet up in Ghent again for Config Management Camp and Puppet Community Day. The conference is FREE but you must register for a spot and we sell out every year!

The schedule has been posted and it’s full of gems. Everything from how infrastructure choices affect climate change to how the Second Law of Thermodynamics applies to DevOps to the resurgence of mainframe computing and what’s it’s like to make that career choice today. To no surprise, compliance and AI are big this year and like always, there’s a strong showing on solving human organizational problems. Learn about building confidence in change and how to safely grow that silly little script or wiki page to a full internal developer platform.

The Puppet track includes talks about the whole lifecycle of Puppet infrastructures – writing and refactoring to get better Puppet code, understanding how classification gets that code to the nodes you want it on, performance tuning your infrastructure, and more.

Finish up the conference with Puppet Community Day. Meet Puppet DevX engineers and chat with Vox Pupuli about plans for the upcoming year. Share projects you’re working on and challenges you’re running into. Work together and collaborate with your peers to solve these problems. Share your ideas and maybe even influence our developer ecosystem roadmap.

Watch this space. In the upcoming days, I’ll be posting a quick writeup of some of the talks I’m most interested in attending.

I hope to see you in Ghent soon! And just a heads-up, this year is the tri-annual (is that even a word?) Light Festival, so if you’re intending to drive yourself, make sure to budget extra time for it.

Public issue reporting is back!

Ben Ford — Fri, 03 Nov 2023 19:02:03 +0000

I’m happy to share that public issue reporting is back!
You can now file issues directly in GitHub right on the project itself using the GitHub account you probably already have.

Issue creation is now enabled in the following repositories

puppet-agent,
puppet,
puppetdb,
puppetserver,
facter

We will be reviewing any new issues created using our normal triage process and update tickets accordingly. Since planning happens internally you may not see much activity on the issue until it’s being actively worked on.

We are working on a process to migrate existing tickets and we will provide an update on that soon. Until then you can still view existing tickets on https://puppet.atlassian.net.

Thank you for all the input you provide us and we hope that this makes it easier to contribute going forward.

Vox Pupuli election results

Ben Ford — Thu, 23 Mar 2023 02:32:02 +0000

Well, [[checks watch]] would ya look at that. It's March 23, UTC, and that means that it's time to close the Vox Pupuli elections. Not only that but as it turns out, we had precisely five nominations which is the number of open positions. Y'all are making my job as the elections officer way too easy this time around!

Martin was the first to submit a nomination, and as promised we'll be sending him a brand spankin' fresh hoodie as soon as we've got the new design finalized.

Let's get to it and meet your new PMC members!

No surprise to anyone, first up is Tim Muesel, known as bastelfreak to many. One of the most prolific contributors in the Puppet community, Tim's tireless energy is an inspiration to all of us. Read his nomination.

Next up is Romain Tartière, also known as smortex. Romain has been maintaining the FreeBSD Puppet port for so long that he's seen three major Puppet versions go EOL. Read his nomination.

Then we have Robert Waffen, also known as rwaffen. Robert came to the Puppet community and then to Vox Pupuli in the same way that many do--by exploration and debugging and little fixes and then realizing just how much of an impact all his little fixes cumulatively added up to. We're grateful to have Robert and people like him with us. Read his nomination.

Sebastian Rakel is active in both the Vox Pupuli and the Arch Linux communities. Not only is he a diligent pull request reviewer, but he also knows how to make communities valuable for all of us. Read his nomination.

Ewoud Kohl van Wijngaarden, also known as ekohl, is one of the most knowledgeable people in the Puppet community. Not only that, but he's very helpful and always ready to share that expertise. I always pay extra attention to his PR reviews. Read his nomination.

What's next?

Over the next few days, the new PMC officers will be onboarded and the website updated. They'll select also select members to fill a couple specialized roles.

The security officer is the point of contact for external or internal security issues. This person has a published gpg key, and will be the main point of contact for CVE numbers and such
The communications officer is the main point of contact for external and internal publicity and marketing efforts and requests.

Puppet’s Migration to Jira Cloud next Friday

Ben Ford — Wed, 01 Mar 2023 23:35:37 +0000

⚠️ Update:

⚠️ Update:
Some projects have been reverted. By this we mean that the Jira Cloud version has been marked as read-only and the canonical version has reverted again to the existing `tickets.puppetlabs.com` version. We took this step because we're migrating projects iteratively, meaning that internal projects are still running on our good old Jira Server instance. Unfortunately, linking between different instances is not possible, and this made work-in-progress epics that used these tickets un-closable. Unsurprisingly, engineers aren't super happy about not being able to mark their work as complete and the required projects were reverted in order to unblock their progress. The public projects are still viewable with all information up until the migration, but moving forward we are going to need to re-evaluate how to interact with the public. More on that to come, so watch this space! We have identified any ticket that was filed on the public JIRA instance while it was live and will be reconciling that with our internal instance. See the table below for the status of each project.

Some projects have been reverted. By this we mean that the Jira Cloud version has been marked as read-only and the canonical version has reverted again to the existing tickets.puppetlabs.com version.

We took this step because we're migrating projects iteratively, meaning that internal projects are still running on our good old Jira Server instance. Unfortunately, linking between different instances is not possible, and this made work-in-progress epics that used these tickets un-closable.

Unsurprisingly, engineers aren't super happy about not being able to mark their work as complete and the required projects were reverted in order to unblock their progress.

The public projects are still viewable with all information up until the migration, but moving forward we are going to need to re-evaluate how to interact with the public. More on that to come, so watch this space! We have identified any ticket that was filed on the public JIRA instance while it was live and will be reconciling that with our internal instance.

See the table below for the status of each project.

Puppet’s public facing Jira projects will be moving to a new Jira Cloud instance at https://puppet.atlassian.net starting on Friday 2023-03-10. See the attached list for all the projects being migrated.

If you have been identified as a user in the Puppet Jira instance at https://tickets.puppetlabs.com, then you should also have received an email with these instructions.

The migration will begin at 5:00 PM Pacific Standard Time Friday 2023-03-10. The migration is expected to be completed by 12:00 PM Pacific Standard Time Sunday 2023-03-12. Once the migration is complete, the listed projects will be accessible at https://puppet.atlassian.net, and archived in the Puppet Jira instance at https://tickets.puppetlabs.com.

Please do not make any changes to these projects after the beginning of the migration at 5:00 PM Pacific Standard Time Friday 2023-03-10, as the changes may not be migrated.

If you already have an Atlassian account registered with the email address you used at https://tickets.puppetlabs.com, that account will be granted access to Puppet’s Jira Cloud instance. If you did not already have an Atlassian account, you will first need to reset your password to use it with Puppet’s Jira Cloud instance. To do that, visit the Atlassian password reset page, enter your email address, and a password reset link will be emailed to you. If you would prefer not to keep your Atlassian account, you can delete it following Atlassian's instructions.

Got more questions? Stop by Office Hours next Thursday at 11am Pacific Standard Time.

Project	Key	Status
Beaker	BKR
Community Package Repository (Archived)	CPR
Contributor License Agreement	CLA
Documentation	DOCUMENT
Editor Services (Archived)	EDITSVCS
~~EZBake~~	EZ
~~Facter~~	~~FACT~~	reverted
Hiera	HI
HOCON (Archived)	HC
Impact Analysis Service (Archived)	IAS
Infrastructure Automation Content	IAC
Internationalization	INTL
Leatherman	LTH
MCollective	MCO
MCollective Plugins	MCOP
~~Modules~~	~~MODULES~~	reverted
Native Puppet	NPUP
Network Device Types	NETDEV
OS Images	IMAGES
~~Puppet~~	~~PUP~~	reverted
~~Puppet Agent~~	PA	reverted
Puppet Catalog Preview	PRE
Puppet Communications Protocol	РСР
Puppet Development Kit	PDK
Puppet Enterprise	ENTERPRISE
Puppet Forge	FORGE
Puppet Integrations Engineering	PIE
~~Puppet Server~~	~~SERVER~~	reverted
Puppet Strings	PDOC
~~PuppetDB~~	~~PDB~~	reverted
R10K	RK
Razor	RAZOR
Trapperkeeper	TK
~~Vanagon~~	~~VANAGON~~
VM Pooler	POOLER

DEV Community: Ben Ford

First release, hot off the presses!

Security considerations of configuration management

Security recommendations:

Security recommendations:

Security recommendations:

May the Source Be With You, 2024!

Announcing Puppet Enterprise 1401

Operator Instructions

The internet is on fire again. This time it's XZ

# Puppetfile

Recovering archived Puppet blog posts

Vox Pupuli Elections, 2024 edition

CfgMgmtCamp talks I want to see

Get your CfgMgmtCamp & Puppet Community Day tickets before they’re gone!

Public issue reporting is back!

Vox Pupuli election results

Let's get to it and meet your new PMC members!

What's next?

Puppet’s Migration to Jira Cloud next Friday

# `Puppetfile`