Homelab

Why Tailscale, not a real VPN server I looked at running my own WireGuard setup by hand … port forwarding, managing keys myself, keeping track of which peer is which. Tailscale does all of that for you, on top of WireGuard, and the actual setup on each machine ends up being a handful of lines. Every device I own is on the same tailnet now: the T620 server, my NixOS desktop, and … the one that surprised me … a MacBook Air 6,2 from 2014 that has no business running anything modern smoothly, and does it fine anyway. ...

Same symptom, completely different machine I already wrote about the remount script I built for my NixOS desktop … clearing stale network mount units through systemd when a share drops. This is the other half of that same story, except this one lives on JackSparrow2 itself (the T620 server) and fixes a genuinely different failure, even though the symptom looks identical from the client side: a share that used to work suddenly doesn’t. ...

The hardware I built this on an HP T620 … a thin client, not a real server. Dual-core AMD GX-217GA SoC, the kind of chip that used to sit in front of a cash register or a hospital terminal, not something anyone would call fast. No AES-NI either, which matters more than you’d think once you’re running encrypted traffic through it all day. If you’ve got something like this sitting in a drawer, it’s genuinely enough to run a small personal NAS. Don’t expect it to be quick. Expect it to just work, reliably, once it’s set up right. ...

The same sysctl file, three different machines I run the same core network tuning across the NAS (Fedora Server), the desktop (NixOS), and a laptop or two … not because every machine has the same workload, but because the underlying kernel-level wins are the same regardless of what’s actually running on top. The differences show up in what else gets layered on, not in the base config. BBR + CAKE, together The single biggest win of the lot. tcp_congestion_control defaults to cubic on most distros, which is fine but not great, especially over Tailscale/WireGuard tunnels where the effective path characteristics don’t always match what cubic assumes. bbr measures actual bandwidth and round-trip time instead of just reacting to packet loss, and pairs specifically well with cake as the queuing discipline … cake handles bufferbloat and fair queuing far better than the kernel’s default fq or pfifo_fast. ...

Why this even matters Every block device on Linux has an I/O scheduler sitting between your applications and the actual disk, deciding the order requests get sent in. Get the wrong one for your workload and you’re leaving real performance on the table, or worse, adding latency you didn’t need to. Check what’s currently active and what else is available: cat /sys/block/sda/queue/scheduler The one in brackets is active. On modern kernels you’ll usually see some combination of none, mq-deadline, kyber, and bfq listed. ...

The idea was simple All I wanted was for my T620 to mount the QNAP shares, retire the QNAP as the “brain,” and have the T620 do everything … Samba, SFTP, the lot … while the QNAP just sat there as dumb storage in the background. Simple networking. I have never been more wrong about something taking one evening. Boot failure #1: the NFS ordering cycle First attempt, I set up NFS mounts from the QNAP onto the T620, then re-exported those same paths back out via NFS so other machines could reach them through the T620. Seemed logical … one machine, one point of access. ...

This is my first post on JackSparrow2.