For the last few weeks I’ve been getting emails from AWS about Node 6.10 going end of life and saying I have deployed Lambda using this level.
The emails don’t list which Lambda or which region they think are at fault which makes tracking down the culprit difficult. I only really have 1 live instance deployed across multiple regions (and 1 test instance on a single region).
AWS Lambda region list
Clicking down the list of regions is time consuming and prone to mistakes.
In the email AWS do provide a command to list which Lambda are running with Node 6.10:
But what they fail to mention is that this only checks your current default region. I can’t find a way to get the aws command line tool to list the Lambda regions, the closest I’ve found is the list of ec2 regions which hopefully match up. Pairing this with the command line JSON search tool jq and a bit of Bash scripting I’ve come up with the following:
for r in `aws ec2 describe-regions --output text | cut -f3`;
do
echo $r;
aws --region $r lambda list-functions | jq '.[] | .FunctionName + " - " + .Runtime';
done
This walks over all the regions as prints out all the function names and the runtime they are using.
In my case it only lists NodeJS 8.10 so I have no idea why AWS keep sending me these emails. Also since I’m only on the basic level I can’t even raise a technical help desk query to find out.
Anyway I hope this might be useful to others with the same problem.
My post on DNS-over-HTTPS from last year is getting a fair bit more traffic after a few UK news paper articles (mainly crying that the new UK Government censoring won’t work if Google roll it out in Chrome… what a shame). The followning article has a good overview [nakedsecurity].
Seeing the scare stories in the news over the last few days, I offer this up again with no comment… https://t.co/KGlZ1l2O6s
Anyway I tweeted a link to the old post and it started a bit of a discussion and the question about the other side of system came up. Namely how to use a DNS resolver that pushed traffic over DNS-over-HTTPS rather than provide a HTTPS endpoint that supported queries. The idea being that at the moment only Firefox & Chrome can take advantage of the secure lookups.
I did a bit of poking around and found things like stubby which DNS-over-TLS (another approach to secure DNS lookups) and also Cloudflare have cloudflared which can proxy for DNS-over-HTTPS to Cloudflare’s DNS server (it also is used to set up the VPN tunnel to Cloudflare’s Argo service, which is also worth a good look at.)
Anyway, while there are existing solutions out there I thought I’d have a really quick go at writing my own, to go with the part I’d written last year, just to see how hard it could be.
It turned out a really basic first pass could be done in about 40 lines of Javascript:
It really could do with some caching and some more error handling and I’d like to add support for Google JSON based lookups as well as the binary DNS format, but I’m going to add it to the github project with the other half and people can help extend it if they want.
The hardest part was working out I needed the encoding: null in the request options to stop it trying to turn the binary response into a string but leaving it as a Buffer.
I’m in the process of migrating my DNS setup to a new machine, I’ll be adding a DNS-over-TLS (using stunnel) & a DNS-over-HTTPS listeners for the public facing sides.
Recently I’ve been playing with how to build a Bluetooth audio device using a Raspberry Pi Zero. The following are some notes on what I found.
First question is why build one when you can buy one for way less than the cost of the parts. There are a couple of reasons:
I build IoT prototypes for a living, and the best way to get a feel for the challenges is to actually face them.
Hacking on stuff is fun.
The Hardware
I’m starting out with a standard Raspberry Pi Zero W. This gets me a base high level platform that includes a WiFi and Bluetooth.
Raspberry Pi Zero W
The one thing that’s missing is an audio output (apart from the HDMI) but Raspberry Pi’s support audio using the I2S standard. There are several I2S pHATs available and I’m going to be using a pHAT DAC from Pimoroni. I’ve used these before for a project so I’m reasonably happy with how to set it up, but Pimoroni have detailed instructions.
I’m going to add a screen to show things like the current track title & artist along with the volume. I’m also going to need some buttons to send Play/Pause, Next & Previous commands to the connected device. I have a PaPiRus e-ink display that has 5 buttons built in which I was going to use but this clashes with the GPIO pins used for the DAC so instead I’ve opted for the Inky pHAT and the Button Shim.
The Software
I knew the core components of this had to be a problem others had solved and this proved to be the case. After a little bit of searching I found this project on github.
As part of the configuration we need to generate the Bluetooth Class bitmask. This can be done one this site.
Class options
This outputs a hex value of 0x24043C which is added to the /etc/bluetooth/main.conf
With this up and running I had a basic Bluetooth speaker that any phone can connect to without a pin and play music, but nothing else. The next step is to add some code to handle the button pushes and to update the display.
The Bluetooth stack on Linux is controlled and configured using DBus. Dbus is a messaging system supporting IPC and RPC
A bit of Googling round turned up this askubuntu question that got me started with the following command:
This sends a Play command to the connected phone with the Bluetooth mac address of 44:78:3E:85:9D:6F. The problem is knowing what the mac address is as the system allows multiple devices to pair with the speaker. Luckily you can use DBus to query the system for the connected device. DBus also has some really good Python bindings. So with a bit more poking around I ended up with this:
#!/usr/bin/env python
import signal
import buttonshim
import dbus
bus = dbus.SystemBus()
manager = dbus.Interface(
bus.get_object("org.bluez","/"),
"org.freedesktop.DBus.ObjectManager")
@buttonshim.on_press(buttonshim.BUTTON_A)
def playPause(button, pressed):
objects = manager.GetManagedObjects()
for path in objects.keys():
interfaces = objects[path]
for interface in interfaces.keys():
if interface in [
"orge.freedesktop.DBus.Introspectable",
"org.freedesktop.DBus.Properties"]:
continue
if interface == "org.bluez.Device1":
props = interfaces[interface]
if props["Connected"] == 1:
media = objects[path + "/player0"]["org.bluez.MediaPlayer1"]
mediaControlInterface = dbus.Interface(
bus.get_object("org.bluez",path + "/player0"),
"org.bluez.MediaPlayer1")
if media["Status"] == "paused":
mediaControlInterface.Play()
else:
mediaControlInterface.Pause()
signal.pause()
When button A is pressed this looks up the connected device, and also checks the current state of the player, is it playing or paused and toggles the state. This means that one button can be Play and Pause. It also uses the org.bluez.MediaPlay1 API rather than the org.bluez.MediaControl1 which is marked as deprecated in the doc.
The button shim also comes with Python bindings so putting it all together was pretty simple.
DBus also lets you register to be notified when a property changes, this paired with the Track property on the org.bluez.MediaPlay1 as this holds the Artist, Track Name, Album Name and Track length information supplied by the source. This can be combined with the Inky pHAT python library to show the information on the screen.
#!/usr/bin/env python
import dbus
from dbus.mainloop.glib import DBusGMainLoop
from gi.repository import GLib
def trackChanged(*args, **kw):
target = args[0]
if target == "org.bluez.MediaPlayer1":
data = args[1].get("Track",0)
if data != 0:
artist = data.get('Artist')
track = data.get('Title')
print(artist)
print(track)
DBusGMainLoop(set_as_default=True)
system_bus = dbus.SystemBus()
system_bus.add_signal_receiver(trackChanged,
dbus_interface="org.freedesktop.DBus.Properties",
signal_name="PropertiesChanged",
path='/org/bluez/hci0/dev_80_5A_04_12_03_0E/player0')
loop = GLib.MainLoop()
loop.run()
This code attaches a listener to the MediaPlayer object and when it spots that the Track has changed it prints out the new Artist and Title. The code matches all PropertiesChanged events which is a little messy but I’ve not found a way to use wildcards or partial matches for the DBus interface in python (since we don’t know the mac address of the connected device at the time we start listening for changes).
Converting the Artist/Title information into an image with the Pyton Image Library then getting the Inky pHAT to render that is not too tricky