Forem: Tony Green

Creating Successful Migration Workflows with Puppet

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

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

I've been doing this for over thirty years.

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

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

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

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

Why migrations go wrong

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

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

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

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

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

The four things you need to stay in control

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

Visibility

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

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

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

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

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

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

State

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

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

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

Execution

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

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

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

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

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

Control

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

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

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

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

A few things that come along for the ride

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

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

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

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

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

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

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

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

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

Final thought

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

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

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

Handling Dirty Frag and Copy Fail with Puppet

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

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

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

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

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

Add these to your Puppetfile. That is it.

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

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

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

See where you stand

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

dirty_frag

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

copy_fail

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

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

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

Query your entire fleet in one line

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

Show me every node vulnerable to Dirty Frag:

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

Show me every node vulnerable to Copy Fail:

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

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

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

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

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

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

What makes a system vulnerable?

Dirty Frag

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

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

Copy Fail

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

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

Why module presence, not kernel version?

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

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

When you want Puppet to enforce the block

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

Dirty Frag

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

Copy Fail

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

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

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

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

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

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

The built-in module problem (Copy Fail only)

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

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

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

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

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

Force-unload a module right now (with care)

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

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

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

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

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

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

The workflow

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

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

Get started

Both of these open source modules are available on GitHub:

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

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

Using Let's Encrypt with the Puppet Enterprise console

Tony Green — Thu, 30 Mar 2023 22:28:40 +0000

Had an itch I've been meaning to scratch for a while. I build my Puppet environment using Terraform, which makes it nice and easy to tear things down and rebuild them. That is great, but it does leave me with an issue when it comes to the console SSL certificates.

Puppet will generate self-signed certs for the console, which work fine, but it was always a niggle that the certs couldn't be automagically coaxed into being valid.

Since moving over to kubernetes for my home lab, I've come to expect managed SSL certificates for any public facing services, without me having to do anything.

Finally set some time aside to look at the options and thought I'd publish the details of the journey as well as where I ended up.

Step 1 - Let's Encrypt

Obviously I wasn't going to reinvent the wheel. If I wanted to manage and use Let's Encrypt on a Puppet Enterprise server, I'd be using the Let's Encrypt module. The module makes it very simple to get the relevant packages installed and configured.

class { 'letsencrypt':
  config     => {
    email  => 'certs@albatrossflavour.com',
  },
  config_dir => '/etc/letsencrypt',
}

One of the beauties of this module is that it also sets up a cron job to renew the generated certs, so you don't need to keep an eye on it.

Classify your server with that and you'll end up with certbot and it's dependencies. Great start and feeling confident about the future!

Then we need to generate a certificates:

letsencrypt::certonly { 'puppet.gcp.albatrossflavour.com':
  domains       => ['puppet.gcp.albatrossflavour.com'],
  manage_cron   => true,
  plugin        => 'webroot',
  webroot_paths => ['/var/www],
}

Annnnnnnd that's where things start to go south.

When you request a cert, the most simple method of validating you are who you say you are is to have a web server on the host respond to a query sent to port 80. Sure we say, easy, couldn't take much to do!

By default, the Puppet Enterprise nginx config does a 301 redirect for http requests to https. This means any queries from Let's Encrypt to validate the requests will end up as https requests and the cert request will fail.

Step 2 - `nginx`

Let me introduce you to puppet_enterprise::profile::console::proxy::http_redirect::enable_http_redirect. This parameter controls if that redirect is in place. So step .... 6(?) was to use hiera to disable the http redirect:

❯ cat data/role/role::pe::master.yaml
puppet_enterprise::profile::console::proxy::http_redirect::enable_http_redirect: false

Once we run this through a puppet run, the redirect gets removed! Score!

Only problem is, without the redirect, the nginx server doesn't listen on port 80. OK, we can fix that easily. We could use the pe_nginx::directive type, but I found it to be a bit of an overkill for what I needed. Instead I opted for a simple template:

  file { '/etc/puppetlabs/nginx/conf.d/certs.conf':
    ensure  => file,
    owner   => 'root',
    group   => 'root',
    mode    => '0644',
    content => template("${module_name}/cert_vhost.conf.erb"),
    notify  => Exec['pe_nginx'],
  }

and the template is just:

server {
  listen       80;
  server_name  <%= @fqdn %>;
  index        index.html;
  location /.well-known {
    root /var/www;
  }
  location / {
    return 301 https://$server_name$request_uri;
  }
}

(Sorry, still using erb, I will at some point rewrite everthing in epp)

The template keeps the 301 redirect in place for anything other than a request to /.well-known, which is where Let's Encrypt looks for the validation info.

Run this through and the nginx vhost gets created. However the letsencrypt::certonly call still fails on the first run. The notify to the pe_nginx service, which is done when we create the cert_vhost.conf, doesn't happen in the order we need. The Let's Encrypt module is trying to get a response before we've setup the vhost. Now this would work on subsequent runs, but Golden Rule #1 is to make sure, whenever possible, that you get a clean puppet run in one pass. Plus this was a challenge.

Before I worked on fixing that, I wanted to make sure I could make the rest of it work. Let's sum up where we are:

I've got the Let's Encrypt client installed and configured
I've got a new nginx vhost running that allows the Let's Encrypt web validation queries through and redirects any other http traffic.
After a couple of puppet runs, I've got valid SSL certs in /etc/letsencrypt

Step 3 - The console certs

It'd been a while since I played with the Puppet console SSL certs, so I checked in with the source of truth, which outlines the steps we need to go through to use custom SSL certs with the console:

Retrieve the custom certificate and private key.
Move the certificate to /etc/puppetlabs/puppet/ssl/certs/console-cert.pem, replacing any existing file named console-cert.pem.
Move the private key to /etc/puppetlabs/puppet/ssl/private_keys/console-cert.pem, replacing any existing file named console-cert.pem.

So we can just create a file resource that takes the Let's Encrypt cert/key and places them into the console SSL directory structure.

  file { '/etc/puppetlabs/puppet/ssl/certs/console-cert.pem':
    ensure    => file,
    owner     => 'pe-puppet',
    group     => 'pe-puppet',
    links     => 'follow',
    mode      => '0640',
    source    => "/etc/letsencrypt/live/${facts['puppet_server']}/cert.pem",
    backup    => '.puppet_bak',
    notify    => Service['pe-nginx'],
    subscribe => Letsencrypt::Certonly[$facts['puppet_server']],
  }

  file { '/etc/puppetlabs/puppet/ssl/private_keys/console-cert.pem':
    ensure    => file,
    owner     => 'pe-puppet',
    group     => 'pe-puppet',
    links     => 'follow',
    mode      => '0644',
    source    => "/etc/letsencrypt/live/${facts['puppet_server']}/privkey.pem",
    backup    => '.puppet_bak',
    notify    => Service['pe-nginx'],
    subscribe => Letsencrypt::Certonly[$facts['puppet_server']],
  }

Sure enough, when I try this on the Puppet server, life is good and we have a console with valid SSL certs.

Time to crack open a bottle of red and tick an item off my to do list.

Damn it, Golden Rule #2 raises it's head. It's not finished until you know it works fine from scratch... WITHOUT breaking Golden Rule #1.

Step 4 - Rebuild

Nuked the Puppet server and rebuilt it. Lots of failures on the first run (we kinda expected that), however they didn't go away. The nginx service never gets restarted as the various dependencies can be resolved, but not in the way we need.

This is the fun (?) of declarative configuration management. I can only manage things once, which includes only being able to notify the pe-nginx service once. Then the compiler will figure out when the service is restarted, based on all of the dependencies in the catalog.

I played around with a lot of options, some waaaaay hackier than I wanted to go with. Plus this was becoming a fun exercise.

All I needed to be able to do was to inject a restart of the pe-nginx service twice in a single run.

To get there, I bent a few of the future Golden Rules and came up with:

exec { 'restart_nginx':
  command     => '/bin/systemctl restart pe-nginx',
  refreshonly => true,
}

This exec resource will allow me to do a restart of pe-nginx outside of, and before, the notify => Service['pe-nginx'] parameters.

Yes, it's a hack, but it's a hack on the side of the angels. Not only will it solve the issue of the process not working at all, but it will also allow the certs to be generated, and installed, in a single run.

Step 5 - Quick Robin, to the `pdk` mobile

I did a fair bit of testing and found the end result to be far more reliable and useful than I thought it would be.

I first created a fully parameterised profile to manage the certs. Once I got that working, it was a no-brainer to create a module to share the love.

That's how I ended up with the pe_console_letsencrypt module. You can also just check out the code.

I've done a fair bit of testing, but I'm certainly not saying it's bulletproof.

Step 6 - Profit?

I'm still scratching my head to think of another way I could get the certs generated and in place in a single run without the exec hack. That being said, I've had hacks a lot worse go live in the past!

Note

While researching the links for this post, I came across a blog less frequently updated than mine which has a post from 2017 showing a similar way of achieving the same thing, but without the hack to make it work in a single run.

Forem: Tony Green

Creating Successful Migration Workflows with Puppet

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

Why migrations go wrong

The four things you need to stay in control

Visibility

State

Execution

Control

A few things that come along for the ride

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

Final thought

Handling Dirty Frag and Copy Fail with Puppet

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

Add these to your Puppetfile. That is it.

See where you stand

dirty_frag

copy_fail

Query your entire fleet in one line

What makes a system vulnerable?

Dirty Frag

Copy Fail

Why module presence, not kernel version?

When you want Puppet to enforce the block

Dirty Frag

Copy Fail

The built-in module problem (Copy Fail only)

Force-unload a module right now (with care)

The workflow

Get started

Using Let's Encrypt with the Puppet Enterprise console

Step 1 - Let's Encrypt

Step 2 - nginx

Step 3 - The console certs

Step 4 - Rebuild

Step 5 - Quick Robin, to the pdk mobile

Step 6 - Profit?

Note

Step 2 - `nginx`

Step 5 - Quick Robin, to the `pdk` mobile