Sometimes there are certain puppet resource types that you don’t want to include in your code base. In my case it was cron but in yours it could be the more line originated augeas or the horribly named computer. The no cron resources check puppet-lint check will display a warning each time it finds a resource of that type in your manifests. class cron_resource { cron { 'logrotate': command => '/usr/sbin/logrotate', user => root, hour => 2, minute => 0, } } # and the lint check will show: # 'cron resources should not be used' While installing the plugin is done in the usual way - # add this line to your `Gemfile` gem 'puppet-lint-no_cron_resources-check' # install the gem bundle install It’s trivial to make a custom copy that detects which ever resource you don’t want to have in your code base. Read on →

In versions of Puppet under 3.8.5 it’s been possible to have the same parameter name specified multiple times in a class definition without error. Although allowed it was a little misleading as only the last value assigned to that parameter was taken and so in the name of simplicity it was decided in the No error on duplicate parameters ticket that this behaviour should change and now return an error. Puppet itself will start to throw an error in 3.8.5 and above and now with this puppet-lint plugin you can hopefully catch those issues before you upgrade. Read on →

Modern versions of Puppet allow you to specify the mode of a file resource in one of two ways, either as a traditional octal value or the (newer addition) symbolic file modes. Although these may seem equivalent there is a minor difference that recently caused an issue on a project I do a little bit of puppet work for. Below are two example resources that each set the files permissions so the user can read and write it. Read on →

As part of operation ‘make my infrastructure look like an adult operates it’ I needed to add some basic uptime/availability checks to a few simple sites. After some investigation I came up with three options, Pingdom, which I’d used before in production and was comfortable with, and two I’d not used in the past Uptime Robot and Status Cake. By coincidence I was also doing my quarterly check of which AWS resources Terraform supported and I noticed that a StatusCake Provider had recently been added so I decided to experiment with the two of them together. Read on →

Once you’ve been using *nix for a while it’s easy to become complacent with the dozen or so tools you reach for most often. As part of starting a new job, and having a Mac ‘bestowed’ on me, I’ve decided to make a conscious effort to choose my tools, rather than reach for the familiar. The first batch that have managed to survive January and still be mostly helpful are: alias '..'='cd ..' We’ll start with the simplest, a basic alias. Read on →

2015 is long over and it’s time for a little belated reflection over its last three months. Firstly we’ll cover reading. In general I try and read one tech book each month. In Q4 I totalled 5 - Violent Python TMUX (PragProg) Exceptional Ruby (PragProg) Rails, Angular, Postgres, and Bootstrap (PragProg) The REST API Design Handbook Of those I enjoyed (the beta version of) Rails, Angular, Postgres, and Bootstrap the most. Read on →

A fair while ago I wrote a Deprecation Warnings From Puppet Resources blog post and metaparameter for adding expiry information to your manifests - file { '/ec/cron.d/remove_foos': ensure => 'file', source => 'puppet:///modules/foo/foo.cron', # our custom metaparameter deprecation => '20130425:Release 6 removes the need for the foo cronjob', } We were happy users of this for a while but it had a high cost, we had to maintain our own puppet fork due to puppet being unable to load metaparams from modules. Read on →

A few projects ago we had a JSON app with quite a fiddly config file that was undergoing rapid iteration. Although we never deployed an invalid JSON config we hit a couple of snags with config files that didn’t quite match up to the applications expectations. A proposed solution was to produce a JSON Schema document we could use in both integration tests and to ensure the JSON we generated in Puppet was both well formed and, more importantly, valid for that version of the application. Read on →

As you add more jobs to Jenkins you’ll often want to start breaking them out in to smaller, more logically grouped, views. While the UI itself makes this simple it’s a manual task, and as automation loving admins we can do better than clicking around. In this post we’ll take a brief look at the jenkins-view-builder and see if it can make our lives any easier. My test case will be a simple Jenkins view that should include any jobs whose names match the test-puppet-.*-function pattern. Read on →

While there are many ways to test your code under Docker, for example puppet modules with dockunit, discussions about how to run acceptance checks against docker image and container creation are less common. In this post we’ll present one approach using the docker api and serverspec to test the creation and execution of a dockerised Redis. As our first step we’ll create the directory we’ll be testing under and a basic Dockerfile. Read on →