Online course for setting up your Manageable Puppet Infrastructure

Written by Ger Apeldoorn. Posted in Manageable Puppet Infrastructure

I’ve released a new course on Udemy, with this course you can set up your Manageable Puppet Infrastructure and learn how it works.

This is the first part of a series I will be developing over the next few months.

In this course we will build a fully functioning Manageable Puppet Infrastructure, fully deployed from puppet code.

This infrastructure has been deployed at many companies, and works very well in both very large and small environments.

It is updated with the latest best practices and works with Roles and Profiles, r10k deployments, Hiera eyaml et cetera. Puppetboard is used as the GUI.

With this coupon code, you will will get a nice discount.

Check usage of classes in your Puppet-infra

Written by Ger Apeldoorn. Posted in Manageable Puppet Infrastructure, Sysadmin

It’s always good to know what the impact is of your change. With these scripts, we can easily see which hosts use a specific class.

Example usage

$ Random
DTA Server
Count Modulename
4 Profile::Random
4 Profile::Random::Accounts
4 Profile::Random::Filesystems
4 Profile::Random::Initd
4 Profile::Random::Ulimit
2 Role::Random

Count Modulename
7 Profile::Random
7 Profile::Random::Accounts
7 Profile::Random::Filesystems
7 Profile::Random::Initd
7 Profile::Random::Ulimit
3 Role::Random

Continue reading for info on how to set this up!


Written by Ger Apeldoorn. Posted in Sysadmin

When upgrading the Puppet master (or messing things up) it can be useful to have a quick script that enables the firewall and stops incoming connections.

This is a simple script that enables that. Note that it assumes that the normal situation does not have any firewall-rules running.


# This script blocks all connections. Exceptions can be made in /etc/sysconfig/iptables-emergencystop
iptables-restore < /etc/sysconfig/iptables-emergencystop
mv /etc/sysconfig/iptables-emergencystop /etc/sysconfig/iptables


:OUTPUT ACCEPT [611449:52637218]
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -s [puppetmaster-IP] -m tcp -j ACCEPT
-A INPUT -p tcp -s [testmachine-ip] -m tcp -j ACCEPT
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -j REJECT --reject-with icmp-host-prohibited


iptables -F
mv /etc/sysconfig/iptables /etc/sysconfig/iptables-emergencystop


if [ $# -eq 0 ]
    echo "No arguments supplied"
iptables -I INPUT -p tcp -s $1 -m tcp -j ACCEPT

New developer environment (script)

Written by Ger Apeldoorn. Posted in Geen categorie

If you want to add a new developer-environment, it can be quite a hassle.

Here is a script to help you set it up, make sure that the user is known in Gerrit and that the SSH key is set up. Also, the repos must be present of course!

Make sure you understand what this script does BEFORE you run it!

MPI – Managing multiple customers within a single environment

Written by Ger Apeldoorn. Posted in Manageable Puppet Infrastructure


This is set in the Manageable Puppet Infrastructure, but should be quite useable if you’re not using it.

You want to manage multiple clients within a single environment. (You probably don’t want to create seperate environments or puppetmasters, because that creates quite a bit of overhead in the long run).

But how do we keep things flexible? It’s quite simple, use Hiera and classes in a smart way and you’re there!

One note; this simple setup only works if you do not have any naming conflicts in the modules. e.g. customer1 needs puppetlabs/apache and another needs another module named apache. In that case, you do need seperate environments.

Get that $customer variable filled

You’ll need a way to let Puppet know what customer a node belongs to. There are several ways:

Facter variables can be overridden quite easily. Use the ENC or Hiera!

  • Getting the info from Hiera, see below.
  • Set it from the ENC.

Adding a global $customer variable

In my site.pp:

$customer = hiera('customer')

node default {

Example: hieradata/hosts/

customer: mycustomer1

That’s an easy way to get the $customer (global) variable filled!

Putting it to use!


With the MPI, you’ve created a baserole that applies to all hosts.

We can still use that, just be aware that those resources/includes apply to ALL customers.

Also, we’d like a baseclass for each customer. Within the roles-module, that’s a piece of cake.

└── manifests
    ├── base.pp   # class role::base { (applies to all nodes)
    ├── mycustomer1
    │   ├── app.pp       # class role::mycustomer1::app {
    │   ├── base.pp      # class role::mycustomer1::base { (applies to all nodes of mycustomer1)
    │   ├── db.pp        # class role::mycustomer1::db {
    │   └── smarthost.pp # class role::mycustomer1::smarthost {
    └── mycustomer2
        ├── app.pp       # class role::mycustomer2::app {
        ├── base.pp      # class role::mycustomer2::base {
        ├── db.pp        # class role::mycustomer2::db {
        └── lamp.pp      # class role::mycustomer2::lamp {


You can add a level for customer-specific settings.

  - "hosts/%{clientcert}"        # Host-specific settings
  - "customer/%{customer}"       # Customer specific settings
  - "osfamily/%{osfamily}"       # Settings based on OS
  - "environment/%{environment}" # Environment specific settings
  - common                       # Common settings for all nodes.

Now, we can add a yaml file for each customer and assign the role::customer::base there.

Example: hieradata/customer/mycustomer1.yaml

  - role::mycustomer1::base

Of course, you can add other customer-specific settings as well here!

Feedback is welcome, leave a message!