5 min to read

How to use puppet:/// URLs in Puppet profiles

A lot o' people don't realize what's really going on. They view life as a bunch o' unconnected files 'n things.

Featured image

Puppet allows you to do super convenient things inside modules like deploying static files which live in a modules files directory, but that doesn’t help when you’re using Puppet’s Roles and Profiles method.

Where do you put your static files then? You could just declare them as part of content if your resources support it, but that’s anywhere from a couple of lines of hardcoded data to a big great dirty file.

Instead, Puppet has a handy inbuilt fileserver that solves this problem. Let’s explore how it works.

Table of Contents

Our System

First up, this guide assumes you’re running Puppet 7. Both Community and Enterprise edition should be fine, but we’re only going to be testing with the Community edition which is free and open source.

Everything we’re doing here is running on Rocky Linux 8. This should run fine on your favorite flavor of Linuxy goodness though so long as it supports Puppet Server and Puppet Agent.

This article assumes you’re already used sudo or su to assume the correct user. If you’re not sure which user that is, ps -wweF f and double-check which user Puppet Server is running as. You’ll want to either be that user while following along (assumed), or chown everything we create to that user as you go.

The Process

1. Create a repository folder on your Puppet Server

First off, we need somewhere to put all our juicy static files for Puppet Server to serve. This will be referenced in the fileserver config file in just a moment.

mkdir /etc/puppetlabs/puppet/extra_files

2. Create a fileserver config and add the repo path to it

Using some BASH heredoc hotness, we create the config file for the Puppet Server’s fileserver. The config is in ini syntax which is kind of barf-worthy but hey, you can copy paste this into place and then leave it in a dark hole never to be seen again. Puppet Docs has a page explaining this file, but it doesn’t quite explain everything in context.

The section header, [extra_files] replaces the module name in your puppet:/// URLs, minus the square brackets. The location after path is the location on the Puppet Server that Puppet goes looking for files to serve when it’s asked to retrieve something from this repository.

cat <<'EOF' >/etc/puppetlabs/puppet/fileserver.conf
[extra_files]
  path /etc/puppetlabs/puppet/extra_files
EOF

3. Create or copy in the files you want in the repo

Now that config is in place for the fileserver, we’re going to create a static file for an MOTD message. This can be anything you want to create. Go nuts.

cat <<'EOF' >/etc/puppetlabs/puppet/extra_files/motd
This system is property of Kitsutron. Actual or attempted unauthorized access will result in an unpleasant visit from our resident large flying purple one eyed monster named Frank who is sick of reading incident reports for failed sudoers. Please be considerate of Frank, he only eats people sometimes.
EOF

4. Restart Puppet Server

With everything in place, kick the Puppet Server in the guts to make sure it refreshes its config and picks up on the new fileserver.conf. It shouldn’t need to be restarted next time you add static files and you can actually perform this task one step earlier if you prefer.

systemctl restart puppetserver

5. Use the new repo in your manifests

Apply your new static file in a resource somewhere as part of one of your profiles to see it get applied with the rest of your Puppet manifest.

class profile::linux_soe {
  file { '/etc/motd':
    ensure => present,
    owner  => root,
    group  => root,
    mode   => '0644',
    source => 'puppet:///extra_files/motd',
    }
}

6. Run Puppet Agent to confirm everything is working

If you’re using Puppet Enterprise, you can see from the GUI how this new Puppet code is being applied around your environment. On Open Source Puppet, I prefer to roll out new code to a test group first and apply it with Puppet Agent’s test mode. The command for this is puppet agent --test or puppet agent -t for short.

So long as your code is applied in the role assigned to the node you’re testing on (and you get in ahead of the agent’s periodic run), you should see something like this:

image

If not, jump on your Puppet Server and have a look through the logs for your node. These logs usually live under /opt/puppetlabs/server/data/puppetserver/reports/HOSTNAME, where HOSTNAME is the short name of your node.

TLDR

If you just want a one-stop shop to smash this in, here’s your copy pasta:

mkdir /etc/puppetlabs/puppet/extra_files
cat <<'EOF' >/etc/puppetlabs/puppet/fileserver.conf
[extra_files]
  path /etc/puppetlabs/puppet/extra_files
EOF
cat <<'EOF' >/etc/puppetlabs/puppet/extra_files/motd
This system is property of Kitsutron. Actual or attempted unauthorized access will result in an unpleasant visit from our resident large flying purple one eyed monster named Frank who is sick of reading incident reports for failed sudoers. Please be considerate of Frank, he only eats people sometimes.
EOF
systemctl restart puppetserver

You can access files dropped in the new extra_files directory like this:

class profile::linux_soe {
  file { '/etc/motd':
    ensure => present,
    owner  => root,
    group  => root,
    mode   => '0644',
    source => 'puppet:///extra_files/motd',
    }
}