Simon Mott

Everyone’s probably sick of hearing about LLMs now, but I’ve been working with them a bit more recently and I decided it was probably time I used one to update my website.

Way back when, my website was originally some PHP I’d cobbled together. At the time it was… fine, I suppose. It had a basic admin section which allowed me to write posts, create custom pages etc. Referencing my recent OwnTracks post, this was the version of my site that had my current location for all to see - which, in hindsight, probably isn’t the smartest thing to publish on a public website… I was, and still am, terrible at creating good looking designs for things, so it was pretty basic, but it served my needs.

I had this version of my website from when I originally created it in 2009, through to sometime in late 2016.

A while back, a friend showed me an application they had started using called OwnTracks, which periodically sends location updates from your phone to your own server. I used to collect similar location data back in the day via Google Latitude, so the idea of self-hosting my own tracking history intrigued me. Fast forward a few months, and I finally got around to setting it up.

Shortly after, another friend decided to set it up as well and mentioned wanting to import their historical Google Timeline exports into it. I hadn’t even considered that, but I loved the idea of giving it a shot since I had years of location data sitting around. A day or two later, I had my data fully ingested and viewable in OwnTracks, dating all the way back to mid-2010.

The first hurdle I ran into was that iOS Google Maps exports use a different format than the Android versions, requiring me to patch the import script to handle the iOS payload. Using an LLM coding assistant, I threw some sample data at it, and it quickly generated everything OwnTracks needed to ingest the files.

However, I quickly discovered that Google Maps on iOS logs far less granular data than it does on Android. Thankfully, I still had my old Android phone from when Google originally moved Timeline data on-device. That phone contained my complete, detailed history from my Android years up until my switch to iPhone, so I dutifully ingested that data too.

As part of my last post, I was exploring video transcoding with an Intel Arc GPU and how different levels of ICQ affect video size and quality. During which, I noticed there’s a QSV compatible filter in ffmpeg called vpp_qsv which has a detail parameter. VPP stands for Video Post Processing and the filter help text simply says “enhancement level” for detail. The potential to do some automatic picture enhancements directly on the GPU piqued my interest so I decided to have a play with it.

I am a bit of an NVIDIA fanboy when it comes to GPUs. This is partly down to being a long time Linux Desktop user (until recently) and them having excellent drivers allowing me to pretty effortlessly get proper hardware acceleration working.

In my lab environment I have an old Nvidia Quadro P400 that’s set up for various transcoding workloads and its been working absolutely great for me despite being an older card. I have been primarily using the h264 codec but I recently moved over to h265 (hevc) mostly out of curiosity, and to see if I could get quality on-par with h264, whilst getting similar file sizes.

One of my friends recently installed a new storage server in our shared lab environment and graciously gave me some storage space on it via iSCSI. I use Proxmox for my personal lab, and I intended to store some non-critical VM disks on this new storage so I could play around with properly using HA (High Availability) with Proxmox. Additionally, I wanted to gain some experience using iSCSI at the same time. While I trust my friend, the storage itself is outside of my control, so I figured it would be good practice to encrypt my data. The general go-to solution for this would seem to be LUKS.

A while ago, I decided to play around with trying to create something cheap that would be able to synchronise its time by using GPS instead of over the internet - essentially building my own Stratum 1 time server. I intend this to be a series of articles about NTP and time servers, but let’s start with the basics…

What is a Stratum 1 Time Server?

The lower the “Stratum” number the more accurate the time it should be able to tell. Usually Stratum 1 time servers are directly connected to an accurate source of time such as (but not limited to) Atomic, GPS or even Radio clocks. The stratum of the machine which itself is directly interfacing with the accurate time source would be “Stratum 0”. For each additional layer of NTP servers added, the stratum increases by 1.

So if the server that’s connected directly to the time source is stratum 0, it would appear to any clients who want to synchronise with it as a stratum 1 source. If someone then tries to synchronise to one of those, they would see a stratum 2 source and so on. The image on the right illustrates the top-down increase in stratum and was taken from Wikipedia.

Generally the higher the stratum number, the less-accurate its view of time is. A stratum ranges from stratum 1 all the way to stratum 15 indicating the time is getting further away from a reference clock the higher you go. Stratum 16 indicates the clock is pretty far from the reference and should be considered un-synchronised and should not be used.

I’ve been working on setting up a lab environment for myself and decided to pick up a couple of Ubiquiti’s EdgeRouter 4 routers to act as my core routing devices, along with an EdgeRouter X to act as my out-of-band router. These new devices, along with an EdgeRouter Lite loaned to me for this article by Dom at LoveServers, puts me in a reasonably good position to do some performance testing between these different models of EdgeMAX routers. I thought a good place to start would be to compare how well these different models perform in terms of IPsec throughput and overall CPU usage at the same time.

Part of my lab setup will involve provisioning a couple of IPsec tunnels between the lab and my home network. So whilst this article will mainly focus on IPsec, I will be including some general observations/comparisons between the devices too which may be informative to some people.

As part of my recent (and ongoing) project to implement native IPv6 on my own infrastructure (except at home… I’m looking at you Hyperoptic), I decided to try to dual-stack as much as possible so that when I have IPv6 connectivity, services would prefer that over IPv4, without making things unavailable.

As it turns out, Proxmox’s Web interface (pveproxy) doesn’t listen on the IPv6 address family by default. This stumped me for a little while, but its pretty simple to fix when you know whats going on.

This post is going to spend most of its time explaining why this happens rather than the fix. If you’re just here to see how to do it, check below.

Bitcoin has been getting a lot of attention in the media lately; primarily due to its association with recent high profile ransomware incidents. Bitcoin was first introduced back in 2009 as a digital currency and has been steadily gaining traction since, increasing almost 140% in value so far this year!

Bitcoin however, is not the only player in the game; Ethereum is another popular digital currency, currently sitting at 2nd place in total market value and is getting a lot of activity on currency exchanges.

An incentive to help keep the underlying “network” up and running (for both Ethereum and Bitcoin, amongst others) is a piece of software which can be used to validate transactions on the network and issue rewards for doing so. This is otherwise known as Mining.

My current Gaming PC seems to grab me a reasonable amount of Ethereum Tokens on 2+ year old hardware. Certainly enough to make me want to play around with actually mining some.

My home server has always been somewhat of a Frankenstein’s Monster when it comes to hardware. Until about 2 years ago, it consisted of a large JBOD array of several different drive sizes with no kind of redundancy what-so-ever - for both OS and Data disks. That all changed though when I decided to invest in some 3TB disks and build a “proper” RAID array for my data; Which coincidentally was around the same time my data storage array lost a drive resulting in about 800GB of data-loss - I was unable to source a decent hardware RAID card at the time so I went with Software RAID (mdadm) instead.

The chassis which houses my home server happens to be an old X-Case model that has 10 internal bays, a couple of 5.25" for Optical drives and a 5.25" to 3.5" caddy that seems to be designed for a floppy drive (it has a cut-out at the front for access). I use the floppy slot to house my OS disk and the rest are for my data disks which are all in RAID6 for redundancy. This gives me a total of 11 hard drives in this chassis in its default configuration.

When I rebuilt my server to make use of Proxmox, I put in a known-working drive as the OS drive; It was an old drive at the time but didn’t have much in the way of power on hours so I figured it’d last me a while. Here I am a few years later and the drive is still going, but SMART data is showing some figures that’re making me worried it’s going to start having problems soon so I set about replacing it.