Technical infrastructure
14 September 2025Moving up to Manchester to take up my job was by any measure a rush and with train strikes limiting travel the apartment down south ended up being left in a semi-abandoned state, with things like pigeons on the balcony as well as general tidying-up being sorted out in a haphazard and piecemeal fashion. In the competition for time down south it had often lost out to either spending time in Berkhamsted or going to events in central London so most things were just left as they were. One icon of the state of the place was some old receipts found at the bottom of a bag grabbed for some last-minute shopping that were dated for almost exactly a year ago.
The big to-do for this weekend was fixing up some of my technology infrastructure which had been one of many things neglected over the last year. It had become well out of line with my evolving requirements and mitigations put in place proved to be insufficently robust in practice.
Remote access
The apartment's VPN server ran on a RaspberryPi using a developmental snapshot of Slackware from early-2021 and until some power failures this summer had been running continuously since late-2022. At this point had decided that the server needed a persistent clock rather than relying on polling of NTP so that IPSec would not complain about certificate validity dates and that installing it ought to coincide with a clean rebuild of the system. Although the version of strongSwan in use at had no security issues at least time of writing decided it was best not to let it soldier on until it fell over. Thankfully I had already done a move over to the new SwanCtrl configuration as the older deprecated interface had finally been removed.
Had been noticing connectivity issues with IPSec that were solved by reducing the Ethernet MTU from the default 1,500 bytes and I suspected that UDP-based IPSec also has robustness issues, so do wonder whether IPSec-based VPN is the right thing for me. Secure Shell's ProxyJump is perhaps better suited for my use-cases as practically everything I do is over SSH anyway and ideally want to move towards the apartment's LAN not being a de-facto trusted network. Manchester's internet connection being IPv4 only derailed a general movement towards using IPv6 for direct access.
Workstation upgrade
Having separate computer workstations for work and non-work purposes was an attempt to create a work-life separation while working fully remote but it was already looking like a failure by late-2022 and when the personal workstation was relocated to Manchester the display for the work system was taken with it, leaving the latter operating in a head-less state. With things becoming more settled the plan was to pair it up with a spare display so that the apartment had a usable workstation rather than relying on my laptop whenever staying there. I had been using the portable workstation with my personal workstation's former display but it felt a waste with a much better and stable computer in the next room.
Most of the stuff on the workstation had already been archived off to Blu-Ray discs and before it re-entered regular use it needed to follow the data management model used elsewhere: all user files synchronised with somewhere centrally, mainly through folders under control of Subversion. To aid this the best approach seemed to be to do a clean install and then if any archived content turns out to be of interest it can be pulled in on an as-needed basis. The system software was also a bit stale and in need of some upgrades so everything was pointing towards doing a complete reinstall.
Slackware current
Slackware 15.1 is still some time off but felt that the value of seeing what was up and coming in the Slackware-current developmental branch far outweighed any risk of ending up with a broken system. When this workstation was first built back in 2021 it used the release candidate beta of Slackware 15.0 since by this point Slackware 14.2 had become too stale due to bit-rot with system libraries and suspect it was already end-of-life in all but name, a decision that in hindsight was completely correct. Slackware is quite conservative in its nature so it os not known for earth-moving changes, and one that does springs to mind was to avoid any dependency on adopting SystemD. I am coming to the point where it almost makes sense to build a standard personal Slackware image and on the time-frame that I might actually need such an image Slackware 15.1 may well be out.Ditching NVidia
Ever since having trouble with Intel HD Graphics and since there was no need having anything remotely close to top-end GPU performance, I have normally gone for NVidia GeForce GT 700 series graphics cards which for me was perfect. Not being a purit the semi closed-source nature of the drivers has not been an issue but now the most recent package that supported the GT 710 in the system choked trying to build the kernel modules, presumably due to the use of a6.12.x series kernel.
For me this was something I had absolutely no patience to deal with and was not going to use NVidia's actual open-source offering because all information was that it sucked.
Decided best thing was to simply ditch the G710 in favour of the roughly-equivilent AMD Radeon R7 because AMD's own offering were properly maintained open-source drivers within the main Linux kernel sources rather than half-hearted out-of-kernel drivers. This is the only way hardware of this viltage has any hope of being supported, and this sort of vintage is all I actually need. These days the trend is for GPUs to often be included as part of the CPU package although the one installed in this workstation did not include this funtionality, and without this on-board graphics output does not work.