Chris BerryI recently moved my "homelab" from my Raspberry Pi to an old laptop that I was no longer using, a late-2018 Huawei MateBook. It had been quite a while since I had originally set everything up on the Pi, and when I set out to rebuild it, I realized I remembered almost none of it.
I knew what was running. I didn't know how I'd gotten it there, which config files I'd touched, or which problems I'd already solved once and would now get to solve again.
This time around I used Claude to not only help troubleshoot, but also to write down how things were fixed while the details were fresh.
Fix it, then document the solution
The workflow is pretty straightforward. I troubleshoot with Claude the way most people do: paste the error, try a fix, paste the next error. When something does work, I ask Claude to write it up as a note in my "My Notes" folder, the same Obsidian vault I already use for everything else.
The important part is the timing. Claude has the whole conversation in front of it at that moment: every command I ran, every error message, everything that didn't work. Five minutes later I've closed the tab and that context is gone. Five months later I've forgotten I ever had the problem. And even if I remember, searching for conversations or trusting Claude's memory is neither ideal nor convenient.
Because the notes live in plain markdown in my own vault, they're mine. I can search them, edit them, and read them without Claude. These markdown notes could even be shared with another AI. The knowledge is portable.
What this looks like on the server
The new server runs Ubuntu, with AdGuard Home handling DNS for my Tailscale network, Caddy as a reverse proxy, and Jellyfin for media. Getting there produced three problems I could very reasonably run into again someday.
Remote desktop hung forever. The Windows App on my Mac would sit at "Securing connection" and never get further. Royal TSX connected fine, which was a clue. It turned out to be a known regression in FreeRDP 3.32 (issue #13583). The fix was a small registry-style file at /etc/FreeRDP/FreeRDP/HKLM.reg that turns off ExtSecurity, then restarting gnome-remote-desktop. One detail cost me a while: the value needed =dword: syntax, and the version with a colon silently did nothing.
Caddy not starting. systemctl just reported the service wasn't active. The journal held the answer: port 80 was already in use. ss -tlnp showed Apache using it, probably pulled in as a dependency of something else. Since I wasn't actively using it, disabling Apache fixed it. I also learned that systemctl reload does nothing useful until the service is actually running 😅, so enable --now needs to come first.
The cert that froze my Mac. Caddy issues its own local certificate authority for HTTPS on .lan names. That root cert doesn't exist until a site uses tls internal, and it's owned by the caddy user, so it has to be copied out with sudo first. Double-clicking it on the Mac threw Keychain error -25294 and locked up the whole system. The command-line route (security add-trusted-cert) worked on the first try. I still don't have my head wrapped around why it was causing the system to hang. But it is nice knowing that since the solution is documented I can easily jump back in later.
Each of these became a note, with the fluff stripped out and the dead ends called out. None of them took long to write, because I didn't write them!
What makes a note worth keeping
A note that just says "disabled Apache" doesn't tell me much. The ones that are likely to save me later share a few traits:
- The symptom, using the words I'd search for. "Stuck at Securing connection," not "RDP issue." Future me will search for what I see on the screen.
- The exact fix. File paths, commands, and syntax, since that's often where the time went.
- The dead ends. What I tried that didn't work, so I don't try it again.
- How to undo it. The FreeRDP fix is a workaround for a bug. My note says to delete that file once a patched FreeRDP reaches Ubuntu, and gives the command to do it. Otherwise it would sit there forever and I'd forget why. Not to mention I don't love band-aid fixes.
- A link to the source. The bug report, the docs page, whatever explained why.
I don't have to remember to include any of this. I just ask for it, and Claude pulls it out of the conversation we just had.
Writing for future me
When I set up the Pi, I was sure I'd remember how I did it. I didn't. The lesson isn't to try harder to remember. It's that the best time to document something is the moment you finish it, and that's exactly the moment you least want to.
This way it actually happens. The next time this server needs rebuilding I'll be ready.