Working with complicated template data UserData in Ansible

My new job means I’m currently building a lot of test boxes with Ansible, particularly OpenStack guests. This means I’m trying to script as much as possible without actually … getting my hands dirty with the actual “logging into it and running things” perspective.

This week, I hit a problem standing up a popular firewall vendor’s machine with Ansible, because I was trying to bypass the first-time-wizard… anyway, it wasn’t working, and I couldn’t figure out why. I talked to my colleague [mohclips] and he eventually told me that I needed to use a template, because what I was trying to do was too complicated.

But, damn him, I knew that wasn’t the answer :)

Anyway, I found this comment on a ticket, which lead me to the following… if you’re finding that your userdata: variable in the os_server module of Ansible isn’t working, you might need to wrap it up like this:

userdata: |
  {%- raw -%}#!/bin/bash
  # Kill script if the pipe fails
  set -euf -o pipefail
  # Write everything from this point on to Syslog
  echo " == Set admin credentials == "
  clish -c 'set user admin password-hash {% endraw -%}{{ default_password|password_hash('sha512') }}{%- raw -%}' -s
  {% endraw %}

Note that, if you have a space before your variable, use {% endraw -%} and if you’ve a space after it, use {%- raw %} as the hyphen means “ditch all the spaces before/after this command”.

One to read or watch: “Programming is Forgetting: Toward a New Hacker Ethic”

Here is a transcript of a talk by Allison Parrish at the Open Hardware Summit in Portland, OR. The talk “Programming is Forgetting: Toward a New Hacker Ethic” is a discussion about the failings of the book “Hackers” by Steven Levy. Essentially, that book proposed (in the 80’s) a set of ethics for Hackers (which is to say, creative programmers or engineers, not malicious operators). Allison suggests that many of the parables in the book do not truly reflect the “Hacker Ethic”, and revises them for today’s world.

Her new questions (not statements) are as follows:

  • Who gets to use what I make? Who am I leaving out? How does what I make facilitate or hinder access?
  • What data am I using? Whose labor produced it and what biases and assumptions are built into it? Why choose this particular phenomenon for digitization or transcription? And what do the data leave out?
  • What systems of authority am I enacting through what I make? What systems of support do I rely on? How does what I make support other people?
  • What kind of community am I assuming? What community do I invite through what I make? How are my own personal values reflected in what I make?

This is a significant re-work of the original “Hacker Ethic“, and you should really either watch or read the talk to see how she got to these from the original, especially as it’s not as punchy as the original.

I’d like to think I was thinking of things like these questions when I wrote CampFireManager and CCHits.

Use your Debian System with as an iBeacon for Home Automation

I have been using the Home-Assistant application at home to experiment with Home Automation.

One thing I’ve found is that the Raspberry Pi is perfect for a few of the monitoring things that I wanted it to do (see also https://github.com/JonTheNiceGuy/home-assistant-configs for more details of what I’m doing there!).

I’m using the OwnTracks application to talk to an MQTT server, but I could also do with it knowing where I am in the house, so I looked around for some details on iBeacons.

iBeacon is an Apple standard, but it’s very easy to configure on Linux systems. I took some pointers from this article and wrote up a script to turn on the iBeacon on my Raspbian Raspberry Pi 3.

Configuring the Script

When you first run it as root, it will pre-populate a config file in /etc/iBeacon.conf. Edit it and run the script again.

Running the script

This script needs to be run as root, so to test it, or to reconfigure the beacon, run sudo /root/iBeacon.sh (or wherever you put it!)

Making it persistent

To be honest, at this point, I’d probably just stick this into my root Crontab file by adding this line:

@reboot /root/iBeacon.sh | logger

Again, replace /root/iBeacon.sh with wherever you put it!

Please visit this link to see the script and make suggestions on improvements.

One to read: “You need to rethink that Jump Server”

One of my colleagues, Nick Cross, posts links to articles he thinks are worth reading. This is one of the ones I though was worth re-posting.
Essentially, the key suggestions I took from it is that the jump server should be application white-listed to the bare bones, and should be auto-rebuilt on a daily basis.
It suggests some other controls, but these are the two key ones which I think could be “easiest” to implement.

One to read: “Don’t build private clouds”

I’m catching up on the fabulous Devops Weekly mailing list, so some of these blog posts might be relatively old. The first post I’m picking out as interesting is Don’t build private clouds.

This post is interesting, because the role I’ve *literally* just accepted relates to building Private Cloud infrastructure, so… yehr. That was a great indicator :)

That said, the firm I work for falls solidly in the realms of “Actually, might be useful for you to build your own private cloud” so, not that bad really :D

And if you’re not in the range of people who the article claims should be building your own private cloud, give me a shout, and I’ll point you at some pre-sales people for building with *our* private cloud platform!

One to install: pipethis

Anyone who uses curl | bash needs to take a look at pipethis. A simple GoLang program to use instead of curl | bash, used like this: pipethis http://install.example.com

To install under Ubuntu, you need to do: sudo apt install -y golang-go && sudo GOPATH=/usr go get github.com/ellotheth/pipethis

Other Linux distributions will vary!

https://github.com/ellotheth/pipethis

One to listen to: “CodeNewbie Podcast Episode 116 – Diversity in Tech – Part I (Ashe Dryden)”

Today’s recommended podcast listening is from the CodeNewbie podcast, and this episode is about trying to level the playing field for any minority group looking to get into technology. It also discusses how focusing on the “next generation” of [Required Group Of People] is the wrong way to do it, and just pushes back the problem by 10+ years (until *they* get out of school and find there are no jobs for them either!)

The subject of the interview is Ashe Dryden, a woman who, among other things is a diversity consultant and organiser of AlterConf, a conference about Diversity.

As a conference organiser in tech, I’m keen to keep a close eye on how to do things better, and this interview really opened my eyes into how you *can* do better at organising conferences, and I’ll be taking as much of what I can from this interview to do my next conference better.

One to listen to: “Software Engineering Radio Episode 275: Josh Doody on Salary Negotiation for Software Engineers”

Today we have a podcast about negotiating salary from the IEEE Software Engineering Magazine. The episode is “Software Engineering Radio Episode 275: Josh Doody on Salary Negotiation for Software Engineers” and mentions that you don’t need to offer your current salary to prospective employers, nor do you need to tell them what salary you want – let them offer you a figure, which gives you the power to negotiate.

Clearly, these are some things I should have learned from when I was applying for my earlier jobs! If you’re looking for a new job, or just looking to maximise your next pay rise, take a listen to this show!

One to listen to: “Magic: The Gathering – Drive to Work Podcast #375 – 20 Lessons: Details Matter”

In something of a new concept for me, if I come across a link to a podcast episode that I think has useful content, I’ll link to it here.

In this case, this is the “Magic: The Gathering – Drive to Work podcast“, episode 375 (audio link).

Mark Rosewater, one of the designers of the popular game, explains a little something about the game, whether it’s the design of a card, or a set, or a mechanic, or …. well, any feature of the game really, and he does it twice a week, in the car, on his way to (or from) work.

In this episode, he details about why “Details Matter”, and basically it comes down to a sense of ownership that each little detail on a tiny piece of card, and how that can connect with a player and encourage them to keep playing.

Even if you don’t play Magic, this podcast (like many that I listen to) covers a facet of life that is generally under considered, and in this case, it has turned up something new to include in each design I bring forward from here on out.