I’ve been writing a few Terraform modules recently with the aim of sharing them among a few different teams and there are a couple of things missing that I think would make reusable modules much more powerful. The first and more generic issue is using the inability to use more complex data structures. After you’ve spent a while using Terraform with AWS resources you’ll develop the urge to just create a hash of tags and use it nearly everywhere. Read on →

While Terraform is remarkably good at its job there are going to be some occasions when you want to test what you wanted actually happened. In the unixdaemon_terraform_experiments repository I’m handling this with awspec and a little custom rspec directory modification. First we pull in the awspec gem. bundle install We also need to add the necessary scaffolding files: echo "gem 'awspec', '~> 0.37'" >> Gemfile mkdir spec echo "require 'awspec'" >> spec/spec_helper.rb Now we’ll add a test to our simple-sg project to confirm that the security group was created. Read on →

Introduction While it’s possible to experiment and learn parts of Terraform in isolation sometimes it’s handy to have a larger, more complete, environment to run your tests in. For me unixdaemon_terraform_experiments this is that repo. It will contain a number of different terraform based projects that can be consistently deployed together. You can see some of my thinking behind this in the Naive first steps with Terraform post. Terraform is a very powerful, but quite young, piece of software so I’m making this repo open to encourage sharing and invite feedback on better way to do things. Read on →

One of the principles of running large numbers of instances is that consistency is key. Config deviations cause oddities that’ll drain your time with investigations and nothing causes entropy on your hosts like an admin investigating an issue. In this post we’ll configure our instances to mark themselves as contaminated when someone logs in. We can then use other tooling to query, collate and probably reap, machines corrupted by the keystrokes of humans. Read on →

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 - # 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 →