Below are the five most recent posts in my weblog. You can also see a chronological list of all posts, dating back to 1999.
One morning last week I woke up to find the LED on my NAS a solid red. I've never been happier to have something fail.
I'd set up my backup jobs to fire off a systemd unit on failure
This is a generator-service, which is used to fire off an email to me when something goes wrong. I followed these instructions on the Arch wiki to set it up). Once I got the blinkstick, I added an additional command to that service to light up the LED:
ExecStart=-/usr/local/bin/blinkstick --index 1 --limit 50 --set-color red
The actual failure was a simple thing to fix. But I never did get the email.
On further investigation, there are problems with using
Debian at the moment: it's possible for the
exim4 daemon to exit and for
systemd not to know that this is a failure, thus, the mail spool never gets
processed. This should probably be fixed by the
exim4 package providing a
systemd service unit.
To start with configuring my NAS to use the new blinkenlights, I thought I'd start with a really easy job: I plug in my iPod, a script runs to back it up, then the iPod gets unmounted. It's one of the simpler jobs to start with because the iPod is a simple block device and there's no encryption in play. For now, I'm also going to assume the LED Is going to be used exclusively for this job. In the future I will want many independent jobs to perhaps use the LED to signal things and figuring out how that will work is going to be much harder.
I'll skip over the journey and go straight to the working solution. I have a systemd job that is used to invoke a sync from the iPod as follows:
[Service] Type=oneshot ExecStart=/bin/mount /media/ipod ExecStart=/usr/local/bin/blinkstick --index 1 --limit 10 --set-color 33c280 ExecStart=/usr/bin/rsync ... ExecStop=/bin/umount /media/ipod ExecStop=/usr/local/bin/blinkstick --index 1 --limit 10 --set-color green [Install] WantedBy=dev-disk-by\x2duuid-A2EA\x2d96ED.device [Unit] OnFailure=blinkstick-fail.service
/media/ipod is a classic mount configured in
/etc/fstab. I've done this
rather than use the newer systemd
.mount units which sadly don't give you
enough hooks for running things after unmount or in the failure case. This
feels quite unnatural, much more "systemdy" would be to
Requires= the mount
unit, but I couldn't figure out an easy way to set the LED to green after the unmount.
I'm sure it's possible, but convoluted.
blinkstick command sets the LED to a colour to indicate "in progress". I explored some of the
blinkstick tool's options for a fading or throbbing colour but they didn't work very well. I'll take another look in the future. After the LED is set, the
backup job itself runs. The last
blinkstick command, which is only run if the
umount has succeeded, sets the LED to indicate "safe to unplug".
WantedBy here instructs systemd that when the iPod device-unit is
activated, it should activate my backup service. I can refer to the iPod
device-unit using this name based on the partition's UUID; this is not the
canonical device name that you see if you run
systemctl but it's much shorter
and crucially its stable, the canonical name depends on exactly where you plugged
it in and what other devices might have been connected at the same time.
If something fails, a second unit
blinkstick-fail.service gets activated. This
is very short:
[Service] ExecStart=/usr/local/bin/blinkstick --index 1 --limit 50 --set-color red
This simply sets the LED to be red.
Again it's a bit awkward that in 2 cases I'm setting the LED with a simple
Exec but in the third I have to activate a separate systemd service: this seems to be the nature of the beast. At least when I come to look at concurrent jobs all interacting with the LED, the failure case should be simple: red trumps any other activity, user must go and check what's up.
Late last year, I was pondering how one might add a status indicator to a headless machine like my NAS to indicate things like failed jobs.
After a brief run through of some options (a USB-based custom device; a device pretending to be a keyboard attached to a PS/2 port; commandeering the HD activity LED; commandeering the PC speaker wire) I decided that I didn't have the time to learn the kind of skills needed to build something at that level and opted to buy a pre-assembled programmable USB thing instead, called the BlinkStick.
Little did I realise that my friend Jonathan McDowell thought that this was an interesting challenge and actually managed to design, code and build something! Here's his blog post outlining his solution and here's his code on github (or canonically)
Even thought I've bought the blinkstick, given Jonathan's efforts (and the bill of materials) I'm going to have to try and assemble this for myself and give it a go. I've also managed to borrow an Arduino book from a colleague at work.
Either way, I still have some work to do on the software/configuration side to light the LEDs up at the right time and colour based on the jobs running on the NAS and their state.
I wanted to write a more in-depth post about RetroPie the Retro Gaming Appliance OS for Raspberry Pis, either technically or more positively, but unfortunately I don't have much positive to write.
What I hoped for was a nice appliance that I could use to play old games from the comfort of my sofa. Unfortunately, nine times out of ten, I had a malfunctioning Linux machine and the time I'd set aside for jumping on goombas was being spent trying to figure out why bluetooth wasn't working. I have enough opportunities for that already, both at work and at home.
I feel a little bad complaining about an open source, volunteer project: in its defence I can say that it is iterating fast and the two versions I tried in a relatively short time span were rapidly different. So hopefully a lot of my woes will eventually be fixed. I've also read a lot of other people get on with it just fine.
Instead, I decided the Nintendo Classic NES Mini was the plug-and-play appliance for me. Alas, it became the "must have" Christmas toy for 2016 and impossible to obtain for the recommended retail price. I did succeed in finding one in stock at Toys R Us online at one point, only to have the checkout process break and my order not go through. Checking Stock Informer afterwards, that particular window of opportunity was only 5 minutes wide. So no NES classic for me!
My adventures in RetroPie weren't entirely fruitless, thankfully: I discovered two really nice pieces of hardware.
The first is Lenovo's ThinkPad Compact Bluetooth Keyboard with TrackPoint, a very compact but pleasant to use Bluetooth keyboard including a trackpoint. I miss the trackpoint from my days as a Thinkpad laptop user. Having a keyboard and mouse combo in such a small package is excellent. My only two complaints would be the price (I was lucky to get one cheaper on eBay) and the fact it's bluetooth only: there's a micro-USB port for charging, but it would be nice if it could be used as a USB keyboard too. There's a separate, cheaper USB model.
The second neat device is a clone of the SNES gamepad by HK company 8bitdo called the SFC30. This looks and feels very much like the classic Nintendo SNES controller, albeit slightly thicker from front to back. It can be used in a whole range of different modes, including attached USB; Bluetooth pretending to be a keyboard; Bluetooth pretending to be a controller; and a bunch of other special modes designed to work with iOS or Android devices in various configurations. The manufacturer seem to be actively working on firmware updates to further enhance the controller. The firmware is presently closed source, but it would not be impossible to write an open source firmware for it (some people have figured out the basis for the official firmware).
I like the SFC30 enough that I spent some time trying to get it working for various versions of Doom. There are just enough buttons to control a 2.5D game like Doom, whereas something like Quake or a more modern shooter would not work so well. I added support for several 8bitdo controllers directly into Chocolate Doom (available from 2.3.0 onwards) and into SDL2, a popular library for game development, which I think is used by Steam, so Steam games may all gain SFC30 support in the future too.
This morning I gave a guest lecture to students at the EPSRC Centre for Doctoral Training in Cloud Computing for Big Data. The subject was a gentle introduction to Docker.
This was the first guest lecture I've given for a couple of years so I thought I was a little rusty but I had a good time giving it and hopefully it went across OK.
I mentioned a couple of things worth linking to here
- I referenced the architecture diagrams at https://www.docker.com/what-docker
- the Docker Hub, https://hub.docker.com/
- most of my demos used the wildfly image https://hub.docker.com/r/jboss/wildfly/
- github issue describing the Steam "delete all your files" bug
- Research paper A Framework for Scientific Workflow Reproducibility in the Cloud (PDF available)
- my work-in-progress Ikiwiki-in-a-box Docker image
There was some discussion about alternatives to Docker, things which were briefly mentioned include
Older posts are available on the all posts page.