I’ll leave any automatic power up scheduling and replication job configuration to the reader. You can fill your boots with Wake-on-LAN, iDRAC, iLO API prodding etc…

I approached the automatic power down problem as follows:

1. Write a bash script which will power the system down only when no-one is logged in, no replication tasks are running and not enough online time has passed for scheduled replications to start.
2. Add a matching CRON job.

Script

#!/bin/bash

echo "Checking if Admin session exists"
if who | grep '^truenas_admin' | grep -vq '192\.168\.0\.22[1-3]$'; then
    # truenas_admin is logged in, but not from 192.168.0.221–223 (aka my TrueCommand instance)
    echo "truenas_admin currently has a web or SSH session (not from 192.168.0.221–223 aka the TrueCommand instance). Skipping power off."
    exit 0
fi

echo "Checking if replications are active."

# Check if any replication task is running
if midclt call replication.query | jq -r '.[].state.state' | grep -q '^RUNNING$'; then
  # Replication running; don't power down
  echo "Replications currently active, not shutting down."
  exit 0
fi

# Check uptime in seconds
echo "No replications active, checking uptime."
uptime_seconds=$(cut -d' ' -f1 /proc/uptime | cut -d'.' -f1)

if [ "$uptime_seconds" -gt 600 ]; then
  logger "No replication running and uptime > 600s, powering off system."
  echo  "No replication running and uptime > 600s, powering off system."
  systemctl poweroff
else
  echo "Uptime lower than 600 seconds, skipping power off."
fi

Note: If you don’t have a TrueCommand instance you need to ignore, you should edit the logic in the first check block.

Setup

1. Add the script above to your local file system e.g. /root/check_replication_and_poweroff.sh
2. Add a CRON job.via the System --> Advanced Settings --> Cron Jobs which points at where you saved the script above. Choose to run as root, set your schedule (e.g. */1 * * * *), make sure to hide standard output and enable the job.
3. Do some testing to make sure this works how you need it to.

Script Functionality

The setup-bw-ssh-agent.sh script automates the necessary configurations:

• Installs npiperelay: A utility that exposes Windows named pipes as standard input/output streams, enabling WSL processes to interact with services (like the OpenSSH agent) running on the Windows host via named pipes.
• Installs socat: A powerful command-line utility that establishes two bidirectional byte streams and transfers data between them, crucial for bridging the Unix socket to the npiperelay process for SSH agent forwarding.
• Creates agent-bridge.sh: This script establishes and forwards a Unix socket to your Bitwarden SSH agent on Windows.
• Integrates with .bashrc: The bridge script is automatically sourced in your .bashrc, ensuring the SSH agent is available upon shell startup.

Usage

To set up the Bitwarden SSH agent in your WSL2 Ubuntu environment, execute the following in your terminal:

wget https://gist.githubusercontent.com/jkwmoore/ce9eab106fe378709f447c843b0090e4/raw/setup-bw-ssh-agent.sh && bash setup-bw-ssh-agent.sh

After script execution, restart your shell or run source ~/scripts/agent-bridge.sh to activate the changes.

Thanks go to Aaron and the original work discussed here: https://www.rebelpeon.com/bitwarden-ssh-agent-on-wsl2/

I want to see what my templates are rendering while doing local testing. This is pretty helpful especially if you’ve got some hiera data being used that you want to ensure is being rendered correctly.

How can we show the rendered templates during PDK testing?

Turns out this is pretty easy (so long as you like cheap and kind of nasty) and needs only the most basic changes to your class’s spec file.

e.g. to show a specific template’s content via the CLI output, add the following in your class spec file, spec/classes/myclass_spec.rb:

require 'spec_helper'

describe 'mymodule::myclass' do
  on_supported_os.each do |os, os_facts|
    context "on #{os}" do
      let(:facts) { os_facts }

      it { is_expected.to compile }

      # To visualise the output of the /the/path/to/your/defined/file/resource.txt template during a PDK run, 
      # set TEMPLATE_DEBUG=true in your shell environment before running ``pdk test unit``.
      # i.e. ``TEMPLATE_DEBUG=true pdk test unit``

      it 'echoes rendered template content with OS info and markers (if TEMPLATE_DEBUG is set true)' do
        if ENV['TEMPLATE_DEBUG'] == 'true'
          content = catalogue.resource('file', '/the/path/to/your/defined/file/resource.txt').send(:parameters)[:content]
          puts "################################ Generated /the/path/to/your/defined/file/resource.txt content on: #{os}"
          puts "#{content}"
          puts "################################"
        end
      end

    end
  end
end

This might be pretty noisy if you’re PDK testing against a lot of OSes with multiple templates though ¯\_(ツ)_/¯, so I figure why not be a bit more clever about it and simply render out all the template content to a subdirectory for inspection?

require 'spec_helper'

describe 'mymodule::myclass' do
  on_supported_os.each do |os, os_facts|
    context "on #{os}" do
      let(:facts) { os_facts }

      it { is_expected.to compile }

      # To render out all templated content during a PDK run to the ``rendered_templates`` subdirectory,
      # set TEMPLATE_DEBUG=true in your shell environment before running ``pdk test unit``.
      # i.e. ``TEMPLATE_DEBUG=true pdk test unit``

      it 'writes generated file content to rendered_templates directory per OS version' do
        # Check if TEMPLATE_DEBUG is set to 'true'
        if ENV['TEMPLATE_DEBUG'] == 'true'
          os_name = facts[:os]['name'].downcase
          os_version = facts[:os]['release']['full']
          # Write out the content per OS version
          base_path = File.join('rendered_templates', "#{os_name}-#{os_version}")
      
          catalogue.resources.each do |resource|
            # Only process 'File' resources with a valid path.
            # This way we don't try to dump directories.
            next unless resource.type == 'File'

            path = resource[:path] || resource.title
            content = resource[:content]
            
            if path && content
              output_path = File.join(base_path, path)
      
              # Create the directory if it doesn't exist
              FileUtils.mkdir_p(File.dirname(output_path))

              # Write the content to the file
              File.write(output_path, content)
              puts "✅ Wrote content to: #{output_path}"
            elsif path
              # Note - if the content is sourced from a file, the resource catalog does not have a content
              # element for us to render out.
              puts "⚠️ No content for: #{path} (likely sourced)"
            end
          end
        end
      end

    end
  end
end

I’ve found this to be a useful method during PDK testing for confirming correct template rendering while working with hiera data (structures).

This has also been particularly useful for visualising the created directories, files and content if the classes you are creating are calling other classes, as their outputs will also be rendered!

This is all very helpful for determining and implementing new spec tests for your classes, e.g. for adding tests to automatically validate template / file contents generated by the subordinate classes.

GLHF!

JKWM.

Warning: I cannot claim to be a Puppet backend expert but I managed to get past PDK testing issues as below.

What was the problem?

PDK tests are failing because I don’t have the keys necessary to decrypt the secrets while testing locally. I also do not want to keep the encryption keys locally, nor anywhere except the PuppetServer.

So what do these errors look like?

Well, I am trying to use the following from my hiera common.eyaml:

myclass::mysecretstring: ENC[PKCS7,MYENCRYPTEDSECRETSTRINGCONTENT]

And PDK gives me:

  1) myclass::mymanifest on redhat-8-x86_64 is expected to compile into a catalogue without dependency cycles
     Failure/Error: it { is_expected.to compile }
       error during compilation: Function lookup() did not find a value for the name 'myclass::mysecretstring' on node my_dev_machine.local
     # ./spec/classes/mymanifest_spec.rb:10:in `block (4 levels) in <top (required)>'

How did I sort this?

I added overrides to the spec test used for the class.

      before do
        allow(Puppet::Pops::Lookup).to receive(:lookup).and_call_original  # Allow normal lookups

        allow(Puppet::Pops::Lookup).to receive(:lookup)
          .with('myclass::mysecretstring', anything, anything, anything, anything, anything)
          .and_return('MOCKED_VALUE_STRING')
      end

Why do I think this works

Aside of the fact I tested it and it appears to do what I wanted, see below:

What is Puppet::Pops::Lookup?

• Puppet uses Hiera to retrieve values from a hierarchy of data sources.
• When a class requests a variable via lookup('some_variable'), Puppet internally calls Puppet::Pops::Lookup.lookup('some_variable', ...).
• This function searches for the requested key across the defined Hiera hierarchy.
• https://www.rubydoc.info/gems/puppet/Puppet%2FPops%2FLookup.lookup

For example, if the Puppet manifest has:

$mysecret = lookup('myclass::mysecretstring')

Puppet will call:

Puppet::Pops::Lookup.lookup('myclass::mysecretstring', ...)

and return the corresponding value from Hiera.

Stub Only the Problematic Lookup

allow(Puppet::Pops::Lookup).to receive(:lookup)
  .with('myclass::mysecretstring', anything, anything, anything, anything, anything)
  .and_return('MOCKED_VALUE_STRING')

• This overrides lookups only for myclass::mysecretstring.
• .with(...) ensures that this stub only activates when the exact expected arguments are passed.
• .and_return('MOCKED_VALUE_STRING') means that whenever Puppet tries to look up this variable, it will get 'MOCKED_VALUE_STRING' instead of failing.
• Depending on the expected data type for encrypted values, different mocking values may be required.

Effect:

• lookup('myclass::mysecretstring') returns 'MOCKED_VALUE_STRING' instead of failing.
• All other lookups still use Hiera data lookups as normal/expected.

Allow Normal Lookups

allow(Puppet::Pops::Lookup).to receive(:lookup).and_call_original

• allow(...).to receive(:lookup) tells RSpec to intercept calls to Puppet::Pops::Lookup.lookup.
• .and_call_original ensures that all other lookups (except the one we explicitly stub) continue to function normally.
• Without this, RSpec would try to stub all lookups, causing unexpected failures when other values like myclass::someotherstring' are requested from common.yaml.

Effect:

• Any lookup('some_variable') that is not explicitly stubbed will still perform its normal function.

tl;dr Why I think this works and warnings

1. Ensures normal lookups proceed without modification → The .and_call_original call ensures we do not break unrelated lookups.
2. Only stubs the problematic keys → This avoids unnecessary stubbing and allows normal Puppet behavior.
3. Prevents lookup errors in tests → PDK tests no longer fail due to “missing” Hiera data.
4. Depending on the expected data type for encrypted values, different mocking values may be required.
5. The Method: Puppet::Pops::Lookup.lookup method documentation explicitly says: This method is part of a private API. You should avoid using this method if possible, as it may be removed or be changed in the future.
6. I am not a Ruby expert nor Puppet/PDK backend expert - here be dragons!

GLHF!

JKWM.

GLHF!

JKWM.