Tod's Homelab

Migrating Active Directory to Samba, One Domain Controller at a Time

Wed, 08 Jul 2026 23:35:00 -0400

The first post in the Downsizing series named Active Directory as one of the two reasons the old Windows dependency had to go: vader and maul, two Windows Server 2019 domain controllers, each a license to track and a machine that existed mainly to run one service. The PKI Detour covered the identity side of that problem going sideways for two weeks — a dead-end ACME proxy, three failed attempts at FreeIPA — before landing on Samba AD as the replacement. This is the second post in Off Windows, the thread that tracks removing every remaining Windows dependency from the lab; the first post covered getting the rest of the fleet ready the evening before. This one covers the part that actually moves the domain: the in-place replica join that swaps both Windows DCs for a Samba box named sidious, without a single workstation noticing.

Preparing the Windows Fleet for Samba

Sun, 05 Jul 2026 12:58:47 -0400

Off Windows tracks removing every remaining Windows dependency from the lab, starting with the two domain controllers that gave the series its name. The next post in the series covers the actual migration — an in-place replica join that swaps both Windows DCs for a Samba box named sidious without a single workstation noticing. This post covers the evening before that: getting the rest of the Windows fleet — the desktops, laptops, and piett, the Windows Server box running Veeam Backup & Replication and one of the two Windows-licensing reasons this whole series exists — under Ansible management and onto a trust chain that would survive the domain changing underneath them.

The Mastodon Migration

Sat, 04 Jul 2026 13:30:14 -0400

The previous post ended with two weeks of wrong turns and an honest need for something to just work. The same day FreeIPA got shelved — June 19 — I got it: Mastodon came off a dedicated Ubuntu VM running a source-checked-out install and onto official Docker images running in a Proxmox LXC, and every part of it went the way infrastructure work is supposed to.

What was there before

Mastodon had been running on a dedicated Ubuntu 24.04 VM (mastodon.tod.net) since long before this rebuild started — a source-checked-out Ruby/Node install managed by rbenv and nvm, the deployment model the Mastodon project’s own install guide walks you through. mastodon.tod.net reaches the public internet the same way every other externally reachable service here does: a cloudflared tunnel, so nothing about the host itself — old VM or new LXC — needs an inbound firewall rule. It worked, but every version bump meant babysitting Ruby and Node versions by hand, and the data volume was 71 of 95 GB used, with roughly 64 GB of that being nothing but a remote-media cache — other servers’ avatars and post images, fetched and stored locally the first time anyone here saw them, then never cleaned up automatically enough to keep pace.

The PKI Detour: A Week on the Wrong Cert Strategy, Three FreeIPA Failures

Mon, 29 Jun 2026 12:00:00 -0400

GitLab was up. The code had a home. The obvious next question was: how does every other internal service get a TLS certificate?

The answer I wanted: something clean, automated, and not requiring full Cloudflare DNS credentials on every host. The answer I got — eventually — was “Cloudflare DNS-01, one token per service, and accept the limitations.” Getting there took a week on the wrong approach, then six days and three attempts on a more ambitious one. This post is both of those failures, what they cost, and what survived them.

Infrastructure to Build Infrastructure

Sun, 28 Jun 2026 12:00:00 -0400

In the previous post I explained why the new cluster runs Proxmox instead of XCP-ng. This one is the migration itself — specifically, how it started: the Terraform and Ansible that stood up the first guest, what running them actually looked like, and the moment the code finally had a home somewhere other than my laptop.

Rebuild, don’t convert

The obvious-sounding plan is to export each VM from XCP-ng and import it into Proxmox. I didn’t do that. The two platforms use different disk formats and guest tooling, and — as the last post covered — Proxmox’s LXC model means many of these guests stop being full VMs at all. A cross-hypervisor disk conversion would have dragged years of per-VM cruft along with it.

Why I Left XCP-ng for Proxmox

Sun, 28 Jun 2026 09:00:00 -0400

The first post in this series covered why I’m retiring two 1U servers, and the second measured the power saving. This one backs up to a decision that came before any of the migration work — and didn’t go the way I planned.

proxmox-mini01 and proxmox-mini02 — the two Minisforum UM350s the rebuild runs on now, and the boxes that wouldn’t take XCP-ng with Secure Boot enabled.

I had already chosen XCP-ng, on purpose

When I built the old pool years ago, I ran it on XCP-ng, and I chose it largely on the strength of Lawrence Systems — Tom Lawrence’s channel, which I’ve followed for years. XCP-ng ran that pool faithfully the whole time. So when I started the rebuild my default was obvious: put the current XCP-ng release on the new mini PCs and carry on. I wanted to do this rebuild right and not cut corners.

Did the Rebuild Actually Save Power?

Sat, 27 Jun 2026 12:00:00 -0400

In the first post I listed power as one of four reasons for retiring two 1U Supermicro servers in favour of two small Proxmox mini PCs. It was honestly one of the main ones. The old pair ran around the clock to do work that fits comfortably on a single modern node, and Maine has some of the highest residential electricity prices in the country.

So: did it work? Did the rebuild actually save power?

Why I'm Replacing a Homelab That Still Works

Sat, 27 Jun 2026 09:00:00 -0400

For several years my homelab has run on two 1U Supermicro servers — chimaera and basilisk — paired together as an XCP-ng pool. Each has two Xeons, 128 GB of ECC RAM, dual 10-gigabit networking, and local disk. Between them they offer 24 cores, 48 threads, and 256 GB of RAM. They work. Nothing is failing. That is the part that makes a setup hard to walk away from.

Top to bottom: chimaera and basilisk (the 1U servers being retired), then proxmox-mini01 (left) and proxmox-mini02 (right), with the NAS underneath. The two small boxes in the middle are set to replace the two big ones above them.