Skip to content

Blog

Cautious Unattended Upgrades

I’m very excited to have put the ideas mentioned in my previous blog post about Cautious Unattended Upgrades into practice!

To quickly recap, the idea is that, on a Debian-based test system (‘the canary’), this is a software package that runs the latest security updates, runs an automated browser-based test suite to make sure these new updates have not broken any critical functionality on our clients’ sites, then ‘pushes’ just these package updates to the production servers.

In keeping with my original plan, the software is written in Ruby and uses Watir/Selenium WebDriver to run a suite of tests that verify, just as a human being would in a live web browser, that client websites work correctly.

A canary — as in ‘the canary in the coal mine’

Cautious Unattended Upgrades — the canary in the coal mine. Image by stevep2008 on Flickr, licensed under CC-BY 2.0.

I was expecting the biggest challenge would be getting this browser automation side of things working, but actually that proved very easy, which is a testament to the design of those projects.

The software is still a little rough around the edges, as I explain in the README file on GitHub, but I’m very pleased with the project’s progress. We have put it into use on our live systems at Van Patten Media, so we can keep servers promptly up-to-date with security patches without our intervention, but retain a greater peace of mind that our clients’ sites are still working as they should post-upgrade. (This is of course dependent on the quality and breadth of the tests that we write!)

I am particularly excited that this marks the first ‘real’ project in Ruby that I have written. Ruby isn’t a platform I have worked with too extensively before, so I have enjoyed challenging myself to be exposed to a different environment and quickly pick up how to achieve what I want to do. There is definitely more work to do — it really should be organised in a slightly more ‘Ruby-like’ way, and perhaps become a proper Ruby Gem, listed on rubygems.org, so those are things I will be looking at over the longer term for this project.

If you are interested in using Cautious Unattended Upgrades, or contributing to making it better, the project is licensed under a BSD-style licence and the code is available on its GitHub project page.

Automating Security Updates… Cautiously

Broken padlock

Effraction by Sébastien Launay on Flickr. Licensed under CC-BY 2.0.

My attention has turned recently to how to automate the installation of security updates on various Linux distributions.

As Van Patten Media runs more servers, the effort and time needed to apply critical security updates promptly grows. Waiting several days to get security fixes just isn’t acceptable in a post-Shellshock era, yet there is always a risk of a completely automated update breaking important functionality.

One of the projects I will be investigating over these few weeks is how we might build an automated test environment that could apply the updates quickly to a test VM, run a test suite to verify none of our critical client functionality breaks, then push those updates to the live servers.

There are various solutions for truly automatic updates; I focus on Debian’s unattended-upgrades package here. What seems to be more difficult, however, is being able to push that list of ‘approved’ packages and just install those when we are ready.

My current train of thought on how to proceed on this is as follows:

  • Test box installs the day’s upgrades
  • Runs the test suite automatically
  • If the test suite passes, it determines which packages were most recently installed
  • Pushes that/those package names to the unattended-upgrades whitelist on the clients
  • Clients, on next unattended-upgrades run, will install those upgrades
  • Upon successful upgrade, we reset the whitelist

I am in the very early stages of looking at this, so that is a very rough sketch of where my thoughts are currently. There are missing pieces, but I was looking at Watir for the browser test suite component.

I would be interested to hear from anyone who has looked at this before, or if anyone knows of any interesting similar projects I haven’t found!

Adventures with WindowMaker and Debian

Back in my earlier Linux days, I would experiment and fiddle a lot with different setups for desktop environments and appearance, customising my Linux system to my heart’s content! An example: I loved the 3D desktop effects of Xgl/Compiz back in 2006.

Time moved on, and I ended up settling with the defaults that distributions provided. I liked Ubuntu’s direction with Unity, upon its release in 2011.

I have fallen out with Ubuntu and Unity more recently, however. The troubling privacy issues with the Amazon ‘lens’ and other changes to their corporate behaviour scared me off.

So, I moved over to Debian for my personal server and my Linux desktop systems, and I have been very happy with it. At the same time, though, I wanted to get back to my previous spirit of playing around with different bits of software instead of just going with the defaults and surrendering to a full-size desktop environment. Frankly, the way I use Linux means I don’t find an overwhelming need for a wide variety of graphical applications.

With that in mind, I have set up a very unusual, and minimalist, desktop experience, which I thought I would document a little here for those that might be interested.

WindowMaker screenshot, showing Iceweasel, Terminal and others

» Read the rest of this post…

Raspberry Pi

Raspberry Pi logo

In other 2012 gadget acquisition news, I got my hands on a Raspberry Pi this year, too.

Raspberry Pi in box

Ordered in the summer, and only delivered last month, due to the high demand, it is something I have not yet had an opportunity to play with as much as I would have liked. The advantage of having to wait that long, however, has been a beefier 512 MB version of the device!

In the spirit of my recent iPad mini post, here are some first thoughts on the device:

  • It is amazing how much you can do on such a tiny and inexpensive device. With the Debian wheezy build that is the Pi’s default operating system, you have access to almost the same rich range of software packages on any other Debian system. I was able to install Nginx to serve up web pages at rapid speed, and I am quite sure it would be possible to completely replicate Van Patten Media’s Managed Hosting platform that I have spent much of the year working on, even on such a device!
  • It is unashamedly geeky. This will probably be enough to put off some people who have received a Pi, but perhaps who don᾿t have the support in place to best use it. It isn’t that difficult to get started, but you do need to be able to get the OS onto an SD card. For me, though, I like that opportunity that it gives you.
  • It legitimises the hobbyist again. This pleases me a lot. Many great things were achieved by (originally) hobbyist hackers; re-igniting that spirit has huge potential.

There is some irony in that the Pi is, in a number of ways, the polar opposite of the iPad — it is hobbyist rather than consumerist. The Pi gives you complete control but requires some fiddling, the iPad gives you little control but is so intuitive.

I leave this year much more satisfied about the state of computing because of these two devices.

Why? There is now opportunity for both consumer hardware, and hobbyist hardware, to co-exist and complement each other.