Puppet Without a Puppet Server
One tool that is pretty neat for anyone who manages more than one machine is Puppet. In it’s simplest form, Puppet is designed to codify actions you may take on your server and run them automatically.
The typical deployment for Puppet relies on a central Puppet server (the “Puppetmaster”), and clients distributed around your network. What if, say, we wanted to run Puppet without this central server?
Puppet is great, and a centralized Puppet server is equally great. For my small home environment though, it just seemed like overkill. In all, I run less than 10 machines and don’t really have a ton of extra resources to spare.
Additionally, Puppet Clients rely on certificates and certificate authorities to authenticate to the central server. While very manageable and sensible, it can be somewhat daunting to a new user.
What Puppet Does
I use Puppet in my home lab to manage common settings that I want on every machine. These are things like ensuring SSH is blocking root logins, making sure programs like Sudo are installed, and making sure the machine is configured to use my Apt Mirror. All of these things are fairly trivial to set up on their own, but once you manage multiple machines and need to make a change across all machines, it can become quite a chore quickly.
Puppet allows me to write a series of manifest files that define how a system should look when it’s set up, ie which user accounts should exist, specific files I want defined, etc, and run those actions across all my machines. This way when I need to make a change to a common configuration component, I can make it in once place and push the changes out automatically.
Running Puppet without its central server doesn’t really introduce any major drawbacks. For simple provisioning I find it to be a quick and easy middle ground between manual setup tasks and the task of setting up a centralized server.
I put a demo of how all of this works on GitHub, so feel free to use it as a jumping off point for your setup.
This code is intended only to work with Debian based systems, so you will need to modify it if you are on another platform.
If you haven’t used puppet before, it’s a great idea to look at their documentation and specifically their resource types, which are the specific actions you can have puppet take.
The repository contains a
manifests and a
modules directory, both of which
are required. The
manifests directory is where you define puppet manifest
files that define what actions to take.
modules contains reference files for
As an example, I’ve included a simple manifest that creates a
Configuring the Demo
There’s a couple of things you’ll want to change if you fork the demo code.
Specifically, these are some URLs that should point to the repository you’re
setting up. References exist in
README.md (the example init invocation) and
update.sh (in the
Running the Demo
If you do want to run the vanilla demo, you can use this example:
curl -s https://raw.githubusercontent.com/grumpy-systems/puppet-without-a-server/master/init.sh | bash
Run that as root to download, initialize, and run the demo. Also feel free to
init.sh before running, as it’s always good practice.
How This Code Works
First, you’ll want to run
init.sh to kick things off. The example above
simply downloads the script and immediately runs it via
bash. This script
does a couple things to get ready:
- Install the Puppet apt repository and install the
git, as that’s how we download and update the various files for this system.
- Clone the code to
- Run puppet.
The real magic in running puppet is this line:
puppet apply --detailed-exitcodes --modulepath=$DIR/modules $DIR/manifests
That tells puppet to run and points it at our local modules and manifest directories, which it uses to configure the system.
There’s also an
update.sh file, which is designed to run periodically and keep
the system updated as needed. This step is completely optional, and you can use
this tool just for setting up machines if you want.
This system is a pretty quick-and-dirty way to provision new servers on your network and, to me at least, is a nice middle ground between automation and full-blown configuration management solutions. I’ve started to use this to make all my systems uniform and take care of common security and maintenance tasks that otherwise would require me to run things individually.
I hope you get some mileage from this!