software engineering

UFW, Ubuntu, OpenVPN, and Docker

By Adam K Dean on

Today I've been playing with UFW, Ubuntu, OpenVPN, and Docker. A few other things as well but this post relates to those technologies, mainly UFW, Ubuntu, and Docker.

In case you didn't know, like I didn't know, when you expose ports, Docker thinks a great idea would be to put some rules into iptables to allow the traffic to pass through. I'm sure there is a good reason for this, but you may find that when you enable UFW, traffic still gets through. Now that I understand what is going on, it all makes sense, but getting to that point has taken up my evening.

I followed this tutorial on how To Run OpenVPN in a Docker Container on Ubuntu 14.04 which was a breeze. Really highlighted the strengths of Docker. This setup assigns you an IP from

My next step, now that I had VPN access, was to shut down eth0 on the machine, allowing through only ports 22 & 1194/udp. What I didn't know was that Docker was going to be a royal pain in the arse during this time. It would continue to bypass my rules and make me wonder what the hell was wrong with UFW. Nothing was, it was Docker playing with iptables.

To stop Docker from doing this, you have to start the Docker daemon, or Docker engine I think it's now called, with the --iptables=false flag. To do this, on Ubuntu 14.04, open up /etc/default/docker in your favourite text editor and add the following line:


Save that, and then restart the Docker daemon/engine/server thing:

sudo restart docker

Now, I'm not sure what happens here with existing containers, but I went ahead and deleted them and started fresh. Now when you start new containers, there won't be crazy rules bypassing UFW.

For UFW, I had to add a few rules. I added in ports 22 (SSH) and 1194/udp (VPN). I also added a rule to allow all traffic from docker0:

sudo ufw allow 22
sudo ufw allow 1194/udp
sudo ufw allow in on docker0 to any
sudo ufw enable

Next, I started some containers, and tried to access them. No access... turned on the VPN, tried again, and bingo. I had access. It took a while to get there but I got there. Secured access to my containers.

Now I need a long, hot bath to relax. Thanks a lot Docker!

Shell settings for safer scripts

By Adam K Dean on

I was just reading through one of Progrium's scripts when I came across set -eo pipefail at the beginning of a script. Having not seen that before, I decided to Google. This is the result of that.

You can use set to manipulate shell variables and functions. Some of these can help you write safer scripts.

set -e

If any command fails, set -e will make the entire script fail, rather than just skipping onto the next line. If you want to allow a line to fail then you can pop || true onto the end of it.

set -u

This will treat unset variables as an error, and immediately exit the script.

set -o pipefail

By default only the last command in a list of piped commands returns a failure code if it fails. By using set -o pipefile, if any of the commands fail, the line will fail. Using this with set -e means that if any command in a piped command fails, the script will fail.

Now back to my reading...

Install Consul on Ubuntu 14.04

By Adam K Dean on

To install Consul on Ubuntu 14.04, first make sure you have unzip available:

$ apt-get install -y unzip

Now, grab the Consul archive, make sure to get the latest & the right architecture, at the time of writing it is 0.5.0, and for Ubuntu it's linux_amd64:

$ wget

Now unzip it.

$ unzip

Now move consul to somewhere in your PATH:

$ mv consul /usr/bin/local/consul

Finally, check it works:

$ consul --version

Consul v0.5.0
Consul Protocol: 2 (Understands back to: 1)

Good job!

Rename Ubuntu droplet

By Adam K Dean on

To rename a Digital Ocean Ubuntu droplet, update /etc/hostname and /etc/hosts, then run:

service restart hostname

You'll need either root access or sudo for this.

ES6 compatible sleep function

By Adam K Dean on

While debugging locally, it can be hard to see how an application runs in the wild as the network has no delay. Quite often, you get around this using a sleep function.

Pre-ES6 generators, you might do this with a callback, maybe using a setTimeout that calls the callback.

function sleep(ms, callback) {
    setTimeout(callback, ms);

With ES6 generators, where you want to yield sleep(1000) etc, you can't use callbacks. What you can do is return a function that takes a single parameter, done, which through closure has access to the parameter you want to pass in, ms. When the returned function is called by whatever cog under the hood calls the returned functions when yielding, your inner function will have access to the ms parameter you passed in, along with a callback that JS passes in, which when called, will continue on from where you yielded the sleep.

function sleep(ms) {
    return function(done) {
        setTimeout(done, ms);

yield sleep(1000);

This is now available on To install:

npm install es6-sleep

To use, let's say while inside some Koa middleware:

var sleep = require('es6-sleep');

app.use(function *() {
    // do something
    yield sleep(1000);
    // continue

Hopefully that makes sense. It does in my head.