I’ve been using Samba with the time machine setting for years to back up the couple of Macs I own. I’ve recently been running into issues with Time Machine backups erroring out with "The network backup disk does not support the required capabilities". Poking around the Internet didn’t really point at an obvious culprit until I found some mumblings about this potentially begin a disk space issue.

Bingo!

While the Samba server had more than enough disk space left, I had set the maximum Time Machine volume size to 3.5TB using the setting fruit:time machine max size = 3.5T. Bumping this up to 4.5T magically made Time Maching backups work immediatly.

I’m currently rebuilding my main Windows machine after it had become close to unusable. Given that I upgraded it multiple times from Windows 7 all the way to Windows 11 without ever reinstalling the OS, this shouldn’t have come as a major surprise. Either way, this is the reason for the sudden outburst of Windows related posts so I can go and refer to my blog as my Internet Notes repository.

On my Windows machine, I’ve mostly moved from using separate virtual machine products like Hyper-V or Virtualbox to have access to a Linux machine to using WSL. The PC is dual-boot with a separate Linux install anyway, but sometimes I just want to quickly fire up a Linux machine, take care of a couple of quick tasks and go back to Windows.

WSL installs Ubuntu by default, but I tend to want a different distribution like OpenSUSE, Fedora etc. To not end up with a “spare” Ubuntu install, you can eitehr install WSL on a fresh Windows install without specifying a distributuion using wsl --install --no-distribution or by installing a different distribution immediately using wsl --install -d <distro name>.

Version control system migrations are a fact of life for developers in any longer lived codebase. In fact, I’ve had a hand in quite a few migrations as newer, more workable version control systems became available. Also, like a lot of developers, I’ve got fragments of source code dating back quite some years floating around on various servers and development machines of mine. Not necessarily code that is still being used, but still code that I don’t want to just delete forever. Some of the oldest code I have uses RCS for source control and hasn’t been touched for a long, long time. As my machines generally don’t have anything as old as RCS installed for version control, I decided this might be a good time to migrate the code to my version control system of choice, Mercurial.

While I was implementing a few more changes on my web server - mostly adding the sorely needed blacklistd configuration for sshd - I noticed that NGINX’s log was showing occasional errors when trying to contact the Isso process. They all had one thing in common, namely that they were all trying to contact ISSO via IPV6 as the server has both stacks enabled. Turns out that isso only listens on an IPV4 socket and I could not find an obvious way to get it to listen on both.

I may have mentioned this before - I do run my own virtual servers for important services (basically email and my web presence). I do this mostly for historic reasons and also because I’m not a huge fan of using centralised services for all of the above. The downside is that you pretty much have to learn at least about basic security. Over the 20+ years I’ve been doing this, the Internet hasn’t exactly become a less hostile place. Anyway, Elliptic Curve Certificates, what about them?

First, I apologise for not noticing that the comments had been broken for a while. This was entirely my fault and not fault of ISSO, which I’m still super happy with as a self-hosted comments system. So in this post I’m going to describe what went wrong, and also how I made the system a little more resilient at the same time.

First, what did go wrong?

My web server is using FreeBSD as its OS, with a bunch of software installed via FreeBSD’s ports system. For those not that familiar with FreeBSD’s ports, the system essentially acts like a rolling distribution. As a result, you sometimes have to upgrade tools, especially languages like Perl, Ruby, and in this case, Python. A little while ago, the default Python version on FreeBSD was upgraded from Python 3.7 to Python 3.8, and I eventually followed along with that upgrade. ISSO is run out of a virtualenv as a regular user and the virtualenv was still using Python 3.7, but I decided I didn’t want to keep multiple Python versions on this machine. So, I upgraded the version in the virtualenv to 3.8 as well. So far, so good, especially as ISSO seemed to restart without issue.

I’ve blogged about putting together a WireGuard server using OpenBSD a couple of years back. The main purpose of the server was to ensure a slightly more secure connection when I was on hotel WiFi. Of course thanks to the pandemic, I have barely travelled in the past couple of years so the server was mostly dormant. In fact, I kept VM turned off for most of the time. The VPN server was set up on OpenBSD 6.6, which was the last release that supported user mode WireGuard and didn’t have an in-kernel implementation. It was finally time to change that as part of an upgrade to OpenBSD 7.0.

I’m in the middle of a server redo - right now, I’m setting up a replacement server for my trusty Dell T30, plus it was time to give this web server a new home. When I started the migration from my old WordPress site to the new static site, the static site was running on a small 1 core / 1GB RAM cloud server at Vultr. That had enough oomph for testing and for the last couple of months. That said, this machine is running FreeBSD with ZFS on root, and ZFS likes to have a lot of RAM. Why ZFS on root? Because it allows me to use boot environments. I’ve started using them on my other servers - especially the aforementioned home server - and decided that all my other servers also need them right now as it makes upgrading the OS a lot safer.

Update 2021-12-18: It looks like the rdiff-backup port has been removed from the FreeBSD ports tree, so installing it via the port is definitely not an option anymore. Also, the method described below works on FreeBSD 13.0 as well.

My main PC workstation (as opposed to my Mac Pro) is a dual-boot Windows and Linux machine. While backing up the Windows portion is relatively easy via some cheap-ish commercial backup software, I ended up backing up my Linux home directories only very occasionally. Clearly, Something Had To Be Done (tm).

I had a look around for Linux backup software. I was familiar with was Timeshift, but at least the Manjaro port can’t back up to a remote machine and was useless as a result. I eventually settled on rdiff-backup as it seemed to be simple, has been around for a while and also looks very cron-friendly. So far, so good.