What follows are the steps I had to follow to get puppet-rspec working on a CentOS 6 server so I could run tests on the modules I’m working on.


1) Install RVM (we’ll ne using the multi-user install).

sudo yum install gnupg2
sudo gpg --keyserver hkp://keys.gnupg.net --recv-keys 409B6B1796C275462A1703113804BB82D39DC0E3
curl -sSL https://get.rvm.io | 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/rvm.sh to another location and run the command source rvm.sh
to enable it.
2) Add your account to the rvm group so you can manage it.  (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.  Because we are now using RVM,  the Puppet gem installed at the system level is no longer accessible so we 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.

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


6) Initialize the module’s spec layout

cd path/to/your/module


7) Add this to your module’s spec/spec_helper.rb:

require 'puppetlabs_spec_helper/module_spec_helper'

8) Add this to your module’s Rakefile:

require 'puppetlabs_spec_helper/rake_tasks'

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

      repo: 'git://github.com/puppetlabs/puppetlabs-stdlib'
      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:
https://github.com/puppetlabs/puppetlabs_spec_helper (explains .fixures.yml)

If you’re looking to roll out a scalable 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 create a lot of CentOS virtual machines for testing purposes. I have one master template VM that I clone instead of reinstalling from scratch all the time.   Generally the VMs are configured to use dhcp.  Not a big deal, except that it means logging in to them using the VirtualBox or Vmware console to get the IP address.    To get a round this, I added this to my template VM’s /etc/rc.local file.

/bin/cat /etc/centos-release > /etc/issue
/bin/echo 'Kernel \r on an \m' >> /etc/issue
/bin/echo -n 'IP: ' >> /etc/issue
/sbin/ip addr show dev eth0 | awk '/inet / { print $2 }' >> /etc/issue

This code creates a new /etc/issue file every time the VM boots that includes some basic information, including the VM’s IP address.

For the record, I haven’t tried this in Debian/Ubuntu.

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 vm 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!