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 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?

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.

In part 2, I reconfigured my WireGuard VPN to use an Unbound DNS server on the VPN server rather than rely on a third party server I had used for the original quick and dirty configuration. It was important for me to set up a validating DNS server, which I did in that part.

In this part, I’m extending the existing configuration to include some basic block lists for known ad and tracking servers. As I’m mainly trying to use the VPN while on the road, I want to ensure that anything I end up doing using the VPN is as secure as I can make it with reasonable effort. That makes tracking and preventing malicious ads the next step. That said, I’m not planning to go for a full Pi-Hole like setup. Initially, I am trying to do is integrate one known good blocklists into the Unbound configuration and automate the process. I can get fancy with a more Pi-Hole like setup later if I want to.

This blog is self-hosted, together with some other services on a FreeBSD virtual server over at RootBSD. Yes, I’m one of those weirdos who hosts their own servers - even if they’re virtual - instead of just using free or buying services.

I recently had to migrate from the old server instance I’ve been using since 2010 to a new, shiny FreeBSD 10 server. That prompted a review of various packages I use via the FreeBSD ports collection and most importantly, resulted in a decision to upgrade from PHP 5.6 to PHP 7.0 “while we’re in there”.

If you haven’t heard about the bash “shellshock” bug yet, it may be time to peek out from underneath the rock you’ve been under ;). While bash isn’t installed as standard on FreeBSD, there’s a very good chance that someone either installed it because it’s their preferred shell or because one of the ports lists it as a dependency. Either way, now would be a really good time to check if your machine has bash installed if you haven’t done so already. Go on, I’ll wait.

I was playing with the various shell options - sorry, trying to learn eshell - this evening. While playing with eshell I learned about the second, fully fledged terminal emulator ansi-term.

Most of my machines here run FreeBSD, as does the machine that hosts this blog. FreeBSD’s terminal emulators don’t recognise eterm-color as a valid terminal type, plus FreeBSD uses termcap and not terminfo, so the supplied terminfo file was of limited use.

Back in 2009 I built a “slightly more than NAS” home server and documented that build on my old blog. I’ve migrated the posts to this blog, you can find them here, here, here, here and the last one in the series here.

The server survived the move from the UK to the US, even though the courier service I used did a good job of throwing the box around, to the extent that a couple of disks had fallen out of their tool less bays. Nevertheless, it continued soldiering on after I put the drives back in and replaced a couple of broken SATA cables and a dead network card that hadn’t survived being hit by a disk drive multiple times.