Here are the steps I used to install puppet-rspec on CentOS 6.

While I take the easy route and use RVM to install a newer Ruby, you can get rpec to work with the Ruby 1.8.7 that ships with CentOS 6, you just have to be careful which Gem versions you install.

1) Install RVM.  We’ll be using the multi-user install, but the single user install should work also.

sudo yum install gnupg2
sudo gpg --keyserver hkp:// --recv-keys 409B6B1796C275462A1703113804BB82D39DC0E3
curl -sSL | sudo bash -s stable

RVM installs a file in /etc/profile.d that allows it to take over ruby duties when anyone logs in. If you prefer to selectively enable RVM, move the /etc/profile.d/ file to another location and run the command
“source /path/to/” to enable it.

2) Add your user account to the rvm group to give yourself the ability to use rvm to manage ruby.  (You cannot use root or sudo to manage rvm.)

sudo usermod -a -G rvm myuser

Restart your session to pick up the change.

3) Install a newer Ruby.

rvm install 2.1

Run ruby –version to make sure you’re using the installed version. You should see something similar to:

ruby 2.1.5p273 (2014-11-13 revision 48405) [x86_64-linux]

4) Install the puppet-rspec gem along with some other requirements.

You’ll notice I have puppet in the list.  Now that we are using RVM,  the Puppet gem installed at the system level is no longer visible, so we need to reinstall it.   Make sure to specify the version if you don’t want to run the latest release.  Here I install version 3.8.1, the latest version 3 at this time.

gem update --system
gem install puppet -v 3.8.1
gem install -V rspec
gem install -V rspec-puppet
gem install -V puppet-lint
gem install -V puppet-syntax
# No need to install these two, they get pulled in by rspec.
#gem install -V rspec-core
#gem install -V rspec-expectations


5) Build and install the puppetlabs-rspec-helper gem.  We’ll use puppetlabs-rspec-helper in the next step to setup our directories.

git clone git://
cd puppetlabs_spec_helper
rake package:gem
gem install -V pkg/puppetlabs_spec_helper-*.gem


6) Run puppetlabs-rspec-helper to initialize the module’s spec directory layout.

cd path/to/your/module


7) Add the following line to your module’s spec/spec_helper.rb file.

require 'puppetlabs_spec_helper/module_spec_helper'


8) Add the following line to your module’s Rakefile:

require 'puppetlabs_spec_helper/rake_tasks'


9) Create a puppetlabs_spec_helper .fixtures.yml file in your module’s directory. Here is an example file:

      repo: 'git://'
      ref: '4.6.0'
      'atd': "#{source_dir}"


If you don’t create the .fixtures.yml you will receive trace backs.  In my case rake complained about missing constants.

So that that’s it.  Hopefully you found this useful and it got you up and running.


Useful Links: (explains .fixures.yml)

If you’re looking for information on rolling out a Graphite setup, I suggest you take a look at Jos Boumans How To Measure Everything video from Surge 2014.   Even if you’re not monitoring thousands of servers, it’s full of useful tips that will help you down the road.

I recently decided to start playing with smokeping, in particular a master/slave setup.

I started by keeping it simple, two Ubuntu 14.04 virtual machines on the same network. I decided to use Ubuntu because it already has smokeping packages and more importantly I had the ISO image handy.

I started by reading the documentation on the Smokeping home page and dove in.  Setting up the master went smoothly.   OK, technically there was nothing to do but install the smokeping package, but hey, baby steps.

Next came setting up the slave.

I installed smokeping on the second virtual machine that was to act as the slave.  I updated the slave’s default/smokeping file and created the secret file on the slave. I then updated the target entries on the master to expect the slave.

When I started the smokeping on the slave I was quickly presented with the following errors:

WARNING: Opening secrets file /etc/smokeping/smokeping_secrets: Permission denied

ERROR: we did not get config from the master. Maybe we are not configured as a slave for any of the targets on the master ?

I must have wasted two hours on this.   I kept looking at the configuration files on the slave for problems, after all it was reporting the error.

I ended up running tcpdump on the slave to see exactly what the master and slave were saying to each other.
Here is what I saw:


POST /smokeping/smokeping.cgi HTTP/1.1
TE: deflate,gzip;q=0.3
Connection: TE, close
User-Agent: smokeping-slave/1.0
Content-Length: 366
Content-Type: multipart/form-data; boundary=xYzZY

Content-Disposition: form-data; name=”slave”
Content-Disposition: form-data; name=”key”

Content-Disposition: form-data; name=”protocol”

Content-Disposition: form-data; name=”data”

Content-Disposition: form-data; name=”config_time”

HTTP/1.1 200 OK
Date: Tue, 14 Apr 2015 17:38:07 GMT
Server: Apache/2.4.7 (Ubuntu)
Vary: Accept-Encoding
Connection: close
Transfer-Encoding: chunked
Content-Type: text/plain

WARNING: Opening secrets file /etc/smokeping/smokeping_secrets: Permission denied


So, it wasn’t the slave that could not open file, it was apache on the master!  Why couldn’t the error message say that?!

A quick chgrp www-data /etc/smokeping/smokeping_secrets fixed the problem right away.

Now the slave reports “Sent data to Server and got new config in response.” when it starts.  Yea!