Over the years I’ve built up a small stack of removable drives, mostly for off site backup rotation, and when one of them (a decade old Maxtor) started to sound like two angle grinders ‘passionately embracing’ I thought it was time to do some data validation and re-planning. Although I’m fully aware that most technology trends towards getting smaller and cheaper it’s been a while since I’ve been drive shopping. My god, the difference a few years makes! Read on →

Naive First Steps with Terraform On one of the $WORK projects, we’ve recently had a chance to join seemingly the entire AWS using world and spend some time using Terraform to manage a few migration prototypes. I’ve had a few little plays with Terraform over the last few years but I’ve never tried to plan a large environment with it before and even though it’s -very- early days for me it’s been an interesting path of discovery. Read on →

While puppet-lint and rspec-puppet (thanks to Tim Sharpe) will help ensure your Puppet code is both clean and produces what you’d expect in the compiled catalog there are times when you’ll want to go further than unit testing with rspec-puppet and do some basic integration tests to ensure the system ends up in the desired state. In this post, with the assumption that you have Docker installed, I’ll show a simple way to run basic integration tests against a Puppet module. Read on →

On a *nix system a world writable file is one that anyone can write to. This is often undesirable, especially in production, where who can write to certain files should be limited and enabled with deliberation, not by accident. Ideally you should not be deploying files with those permissions, especially not across all your machines using puppet and so I wrote this plugin to provide a small safety net. class locked_down_file { file { '/tmp/open_octal': ensure => 'file', mode => '0666', } } files should not be created with world writable permissions The world_writable_files puppet-lint check is one possible solution to this. Read on →

The most recent in my recent series of puppet-lint plugins, the yumrepo gpgcheck enabled check, will mostly be of interest to security conscious Linux users who use a yum or dnf based package manager. In this case we’re checking the gpgcheck attribute, which indicates if yum should perform a GPG signature check on packages. Having this disabled means you’ll accept any packages from your configured repo, not just those signed by the packagers. Read on →

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 - 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. 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: Read on →