• Edit Links in Hugo

    While going through some old posts, tidying things up a bit, I have missed the Wordpress Edit link on pages and posts. This got me to thinking, could I emulate this in Hugo?

    Turn out, yes you can and fairly easily.

    First off, I edited my themes’ layout for a single post, which for me was single-content.html, I then figured out where I’d like the edit link and added this bit of template code:

        {{ if .Site.IsServer }}
            {{ partial "edit" . }}
        {{ end }}

    The if around the partial means only include this if we are running hugo in development mode.

    The next task was to make the edit.html partial:

    {{ if .Site.Params.baseDir }}
    <a href="vscode://file{{ .Site.Params.baseDir }}/content/{{.File.Path}}">Edit</a>
    {{ end }}

    I defined Params.baseDir in my sites’ config.yaml, which means I won’t have to alter the theme if I alter where I’ve got the git repo checked out. This needs to be the full path to the root of your site (i.e. the path to the dir with config.yaml in it.).

    The vscode://file is specific to Microsoft Visual Studio Code, which is my preferred editor, that will likely need adjusting if you use something else.


    I tried to make the template read the editor specific bit of the url from the config.yaml, but whenever I did that the dev mode got in the way and mangled the url from:




    Which isn’t helpful. I’ve not figured out a way of fixing this as yet, so that portion of the edit link is hardcoded into the template.

  • Moved Away From Wordpress

    After many years of using Wordpress to host this site I have grown tired of its resource consumption and the constant need to keep it updated. When it came to put my CV online (here) I tried out Jekyll which worked out pretty well, I write a lot of Markdown for work, and while it has its faults I’m pretty happy with it over the alternatives.

    False Starts

    This lead to thoughts of moving this site to Jekyll. After a bit of faffing around I ended up with a fairly complete export from wordpress - although weirdly and for no reason I could find about 10 pages failed to export. I found a nice enough theme (Centrarium) which suited my needs and it all looked ok, sure there was plenty of tidying up to go, but on the whole it was ok.

    The biggest annoyance were the build times, on my 2015 MacBook Pro they ran to anywhere between 5 and 7 minutes! :(

    The other annoyance was I couldn’t find any nice photo gallery plugin, I’ve got a whole bunch of photos (mostly of models) on this site and I wanted to keep them. I toyed with the idea of moving them all to Flickr however with the recent SmugMug aquisition I didn’t want to sink a whole bunch of time into moving everything over, only for SmugMug to change the terms, or make it paid for only. I should point out I think SmugMug is a great home for Flickr, and I hope they reinvigorate it after many years of neglect under the hands of Yahoo. I’ll keep an eye on how things are panning out over there and maybe move my imagery over at some point in the future.

    While searching for a gallery plugin, I found this plugin for Hugo, it looked pretty good and did what I wanted really simply. The problem was I was using Jekyll and this was for the fairly new competitor on the static content scene, namely Hugo.

    Second attempt

    So, maybe I should look into Hugo. After a bit of fooling around I managed to get the Jekyll export from Wordpress up in Hugo. The first thing I noticed was rebuild times were quick, like really quick. It was down from the 5+ minutes with Jekyll, to between 5 and 10 seconds:

    % hugo
                       |  EN
      Pages            | 1347
      Paginator pages  |  277
      Non-page files   |    0
      Static files     | 1991
      Processed images |    0
      Aliases          |  346
      Sitemaps         |    1
      Cleaned          |    0
    Total in 5587 ms

    So that sort of made up my mind, it was far quicker, there was a nice gallery plugin and being in Go it made things easier from a dependancy point of view. The only problem was I liked Centrarium and couldn’t find a Hugo theme similar. Reading into theme development a bit I started to realise I could probably port the theme to Hugo in a couple of hours. Turns out that was about how long it took. I didn’t port 100% of the functionality in the original, just the bits I use. If anybody wants a copy I’d be more than happy to put it on Github and attempt to port the rest of the features.

    So this is the first post on the new blog, its all in git (apart from the photos) and I’m much happier with it.

    At the same time as migrating I also took the oportunity to move it all to an S3 bucket, fronted by CloudFront so I can have SSL and my own domain. I’m not sure how the cost of that will work out, but I’ll keep an eye on it. If it isn’t too much it’ll stay like that, otherwise it’ll be back to Nginx on my virtual server.


    The only thing feature wise, missing from my Hugo rig is comments, I never got many comments anyway so I’ve deprioritised them somewhat, maybe one day I’ll get round to plugging in Disqus or something.

    Until then, my email address is in the footer, please feel free to email me if you have any questions or want to chat about something.

    Work in Progress

    The biggest breaking change from the migration was the photos. I’m working my way through fixing them, starting with the top 50 posts, I’m about a quarter of the way through by now.

  • Custom LUA HAProxy HealthCheck

    I’ve recently been tasked with using HAProxy to front a LDAP server in AWS to allow SSL access to the LDAP backend. This was essentially following this guide from AWS. It is a great shame that AWS don’t offer SSL termination in the Directory Service itself, but the HAProxy/ELB solution isn’t too complex and does work well.

    While testing out some failure scenarios I did however spot an issue which I didn’t like.

    There exists a situation whereby if (for whatever unlikely reason) an HAProxy instance cannot reach any of its downstream LDAP backends the ELB health check of the HAProxy instance will still pass and thus the instance will still be considered healthy. The ELB will still send traffic to the instance, but then things go south because the instance cannot see any LDAP backends and the request fails.

    I spent a bit of time googling for a solution and didn’t find anything which solved this, what we really want is for HAProxy to stop listening on the TCP port of the front end when all the backends are unavailable, however that isn’t an option.

    The solution I came up with was to use a custom HTTP health check endpoint, which runs a simple LUA script inside HAProxy. This uses the new LUA support, added around to HAProxy around version 1.6.1. Not all the binaries I found had it compiled in as an option so we ended up using the official Docker container.

    The way this works is you define a custom HTTP front end in your haproxy.cfg like this:

        # Lots removed for brevity!
        lua-load /usr/local/etc/haproxy/haproxy-smart-tcp-healthcheck.lua
    # Custom HTTP Health check endpoint
    frontend status-lua
        bind  *:8000
        mode http
        http-request use-service lua.status_service
    # LDAP frontend
    frontend ldap_front
        bind  *:1389
        description LDAP Service
        option socket-stats
        option tcpka
        timeout client 5s
        default_backend aws-ldap
    # Downstream AWS LDAP backends
    backend aws-ldap
        balance roundrobin
        server directory1 check port 8081
        server directory2 check port 8081
        option tcp-check</code>

    This now runs the LUA service  tcp_healthcheck  defined in the file haproxy-smart-tcp-healthcheck.lua  whenever a request is made for / on port 8000 .

    The script itself turned out to be pretty simple, once I got my head around some LUA quirks!

    All it does, is query the HAProxy state for all the servers associated with a given backend (named aws-ldap on line 15). Then we loop that list of backends, and if any of them are UP  we return a 200 status with the message Found some servers up , if they are all down we return a 500 status with the message Found NO servers up . 

    -- This service checks all the servers in the named backend (see the 
    -- backend_name var). If _any_ of them are up, it returns 200 OK. If 
    -- they are all down it returns a 500 FAILED.
    -- This is intended to be used as a HTTP health check from an upstream
    -- load balancer, without this check the most intelligent health check 
    -- that could be performed is a simple TCP check on the HAProxy frontend.
    -- This would not fail in the event that HAProxy cannot see *any* of its
    -- downstream servers
    core.register_service("tcp_healthcheck", "http", function (applet)
        -- Harcoded backend here, if anybody knows how to pass vars into Lua
        -- from the haproxy.cfg please shout!
        local backend_name = "aws-ldap"
        local r = ""
        backend = core.proxies[backend_name]
        servers = backend["servers"]
        local any_up = false
        for k, v in pairs(servers) do
            status = v.get_stats(v)["status"]
            -- If _any_ of the servers are up, we will return OK
            if (status == "UP") then
                any_up = true
        if ( any_up ) then
            core.log(core.debug, "Found some servers up")
            r = "OK"
            core.log(core.debug, "Found NO servers up")
            r = "FAILED"

    With this all installed in the HAProxy instance it was a simple matter of configuring the ELB in AWS to use a HTTP health check for the path / on port 8000.

    The AWS Console config for the ELB Health check looks like this:

    alt text

    And you can see the Listeners configuration is still in TCP passthrough mode, with TLS termination performed at the ELB.

    alt text

    The one optimisation I’d like to make to this but have not yet found a solution for, is to pass the name of the backend to query through to the script as an argument. Currently it is hardcoded into the script which would mean duplicating the script if you need more than one of these custom health checks, that would be a pain. However in our use-case the HAProxy is only fronting a single LDAP directory so we can live with this single hardcoded piece fo configuration!

  • Importing non GoPro videos into GoPro Quik

    Update August 2019

    A reader dropped me a line to say this doesn’t to work for him, some time went by but I finally got round to looking into this, and surprise! I found it no longer worked for me either :(

    So I had a poke around and I’ve found a new ffmpeg command which seems to work for me. I’ve updated the command shown below.

    Original Post

    I’ve been using our GoPro quite a bit this summer which the kids have really enjoyed. I also recently got myself a DJI Spark, which is also great fun.

    However I really wanted to be able to import the Spark videos into the new GoPro Quik desktop app because it makes short work of turning a load of clips into short snappy videos.  Sadly it only offers to import videos originating from the GoPro.

    I figured there are only so many ways the software can check to determine if a given file was made by a GoPro or not, so I got to poking around and after about half an hour I found a solution which works on all my current DJI video files.

    If you run this ffmpeg command on any a DJI video (although it probably works for iPhone or other videos), it adds the magic field that Quik looks for, and then it happily imports the video.

    ffmpeg -i dji-video.mp4 \
           -map_metadata \
           -1 \
           -codec copy \
           -metadata:s handler="GoPro AVC encoder" \
           -metadata:s handler_name=" GoPro AVC" \

    I know almost nothing about the millions of options ffmpeg accepts, so this is mostly copy and paste from various google searches, but it works fine from what I can tell!

  • Still alive!

    I’m still here, and so is a very much neglected blog. I will try and make amends in the near future!