My services have been available via Tor .onion for around 7 years now, but my monitoring of their availability has always been relatively limited. I did previously have smokeping running reachability tests, but other than that there's been a reliance on me noticing that things weren't right (or perhaps receiving reports that an .onion was misbehaving).

Part of the reason for this is that there's never (to my knowledge) been a good centralised way to monitor the health of a Tor install. Nyx is a fantastic command line tool, but relies on the operator logging into their box: it's akin to relying on top to monitor CPU usage.

I've always figured that it should be possible to monitor the tor daemon more effectively, but never really quite got around to do anything about it.

This week, I decided to take a pop at it, and a quick scan over Tor's control port spec revealed how easy it should be to collect stats.

This documentation details how to use my new Tor Daemon Plugin for Telegraf to collect metrics from a Tor daemon.

The full list of statistics collected can be seen in the plugin's README, but they include

• bytes_rx: total bytes received by Tor
• bytes_tx: total bytes transmitted by Tor
• uptime: Tor daemon uptime
• version_status: Tor's assessment of whether the installed version is OK to use
• Accounting information: is a quota set? If so, how much is left?
• Reachability test statuses
• Guard node states

Although my main focus is on monitoring the availability of my onion services, the plugin can be used to monitor tor relays, bridges and exit nodes too.

Read more…

Earlier in the week, I saw an article about running Python in the browser via a port of the Python interpreter to WebAssembly.

I couldn't think of an immediate need for using it over Javascript, but often learn unexpected things when playing around with new technologies, so I wanted to have a play around with it.

An obvious start point for me seemed to be to see whether I could use the Python InfluxDB Client to connect to InfluxDB Cloud and query data out.

This proved to be more challenging than I expected, this post follows the process of tinkering around with Pyodide and Pyscript in order to get the client running and ultimately build a semi-interactive webpage that can query InfluxDB using Python in the browser.

Read more…

It's so easily done: you cook a nice roast dinner and someone "helps" by cleaning your roasting tray.

You find out, far too late, that they did this by putting it in the dishwasher, so the next time you see your trusty roasting pan all the seasoning's been stripped and it's a rusty mess

Unless you're partial to added rust in your food, this is an unmitigated disaster - anything cooked in the pan is going to stick and your roast spuds will pull apart when you try and take them out of the pan.

It is, however a recoverable disaster - the pan can be re-seasoned using much the same method as you'd use to Season cast-iron cookware.

Essentially, what it involves is coating the tray in (cooking) oil, and then holding that oil at it's smoke point for an extended period so that it leaves a protective residue on the base of the pan.

In this post, I'm going to re-season what was my best roasting tray. The same process can be used for cast-iron pans too.

Read more…

A few days ago, news broke that $34,000,000 had become forever irretrievable as the result of a bug in a smart contract created by AkuDreams.

It's a good example of an issue that's pervasive across multiple industries, rather than being something that's cryptocurrency specific (though I'm no fan of crytocurrencies)

The reason that $34m in ethereum has been lost isn't simply because someone made a mistake in a smart contract: that's just the inevitable result of an underlying naivety in the smart contract model itself. As we shall see, that same naivety is all too common in the wider technology industry too.

Read more…