The next generation of Example42 Puppet Modules - Require Puppet > 2.6.x
Switch branches/tags
Nothing to show
Pull request Compare This branch is 233 commits behind example42:master.
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Failed to load latest commit information.
Example42-documentation @ 40644eb
Example42-tools @ 7485154
apache @ 0df4fa1
concat @ 753ba87
example42 @ 1b0d597
firewall @ 9a78b76
foo @ d4e6818
foreman @ 7fa5a3b
haproxy @ 367ded1
iptables @ 9ec756b
jboss @ c6aaebf
jenkins @ b599e1d
libvirt @ df0b4d0
maven @ ff8c8ca
monitor @ ebac0b5
munin @ 4645816
mysql @ 135449e
nginx @ 591d3aa
nrpe @ af334fa
ntp @ db293d1
openntpd @ 058d303
openssh @ b977ed6
openvpn @ 7054a87
orientdb @ f5ca2d1
php @ 1353832
postfix @ 0002ad9
postgresql @ 8148ac8
puppet @ 71f73bd
puppetdashboard @ 746f256
puppetdb @ b559c84
puppi @ 6715631
redis @ 319b2b7
resolver @ c0631f2
rvm @ 837c57e
solr @ 891f71c
splunk @ 27bacf4
stdlib42 @ f0bae5d
sudo @ 34b7672
tftp @ c98a5e4
tomcat @ 3331400
vsftpd @ 7d550d1
wget @ 1590ea7
wordpress @ 087d461
xinetd @ 7592b36
yum @ 4c908d9


Example42 Puppet Modules 2.0 : The Next Generation

This repository collects all the Next-gen Example42 Puppet modules ( ), included here as git submodules.

The offical repository of Example42 Puppet modules ( ) is going to contain both old and next-gen modules for a transition period that should last until all the modules are migrated. Old and new modules can cohexist on the same setup, but new modules have different usage patterns.


You can get the Next-gen only module set with:

git clone --recursive git://

To update your local copy with the upstream version:

cd /etc/puppet/modules # Or the directory where's you local copy
git pull origin master
git submodule init
git submodule update
git submodule foreach git pull origin master


The main features of Example42 Puppet modules (second generation):

  • Coherent and standardized structure, logic and usage based on best practices

  • Cross OS support (main targets are Redhat and Ubuntu derivatives)

  • Use of parametrized classes and fully qualified variables for Puppet Telly compliance

  • Full and coherent API exposure and classes introspection

  • Separation between core module and user's customizations, no arbitrary logic enforced.

  • Optional Puppi support for application deployments and “Puppet knowledge to the CLI”

  • Optional automatic Monitoring support based on an extensible set of tools

  • Optional automatic Firewalling support

  • Decommissiong support: you can remove (almost) whatever you've added

  • Complete documentation compliant with PuppetDoc

  • Integrated rspec-puppet tests. Code puppet-lint compliant (as much as possible)

  • Based on common “foo” templates for easy scaffolding on the modules.


Generally there's a module for each application and each module is a separated git submodule than can be indipendently retrived from GitHub. There are some special modules or directories with different functions:

  • Example42-tools/ is actually not a module. It contains scripts useful for maintenance of the modules. No Puppet code there.

  • Example42-documentation/ contains documentation about Example42 Puppet modules and their usage.

  • example42/ is a sample project/customer/site specific module. It contains files and subclasses specific to the Example42 test lab. Here are supposed to be placed all the customizations, and ideally this module (or the equivalent with your company name) is one of the few parts where to make changes.

  • foo/ and foo_whatever/ are sample template modules that are used for scaffolding new modules (that then are customized and enriched according to the specific application)

  • puppi/ is an Example42 Puppet module that can be used to automate and simplify the deployment of (web) applications and provides a CLI command that exposes most of the information that Puppet has (and defines) about the system. Puppi is a required dependency for all the Example42 modules because it contains some functions used by them, BUT you are not forced to use it. You just have it among your modules to retrieve (via pluginsync) the common functions.

  • monitor/ is an Example42 “meta-module” used for monitoring abstraction. It contains the definitions to use different monitor tools for a set of common resources

  • firewall/ is an Example42 “meta-module” used for firewalling abstraction.