Turning a Dead HP Laptop Into a Server

Not exactly server hardware

The HP Laptop 15-dw0037wm is not a machine anyone would spec out as a server. It's an i3-8145U, 8GB of RAM, a spinning 5400rpm hard drive. It was sitting around unused, and it became the answer to a problem I was actually having in the middle of building tcmvp and smokesignal: I was working off both my desktop and my laptop, sometimes with the laptop out at a client site or with my partner on smokesignal, and I needed code to stay in sync between them without relying on GitHub for every single commit. Step one was making Ubuntu Server treat this box like a server and not a laptop, which meant editing /etc/systemd/logind.conf to set HandleLidSwitch=ignore so I could close the lid without it going to sleep. Small thing, but without it the whole plan doesn't work.

Gitea first, everything else second

Gitea was the actual reason this box exists. It gave me a private git remote sitting on my own network, so I could push from the desktop after a work session, pull on the laptop before heading out, and not think about it. GitHub stayed the public, primary remote for these projects, but Gitea meant I always had a fast internal push/pull I controlled, and a second copy of the code that didn't depend on GitHub being reachable.

Stacking more on top

Once the box was up and doing that job well, it made sense to give it more work. Vaultwarden runs on it now for the household's passwords. TeamSpeak runs for voice chat. None of these need much horsepower, they need to just be there, and this box already was.

The Caddy problem that ate an evening

Getting HTTPS working for these services locally took longer than the rest of the setup combined. Caddy's tls internal directive generates its own local certificate authority and signs certs with it, which sounds like it should just work. It does, on the server. The part I missed is that every client machine also has to trust that local CA, not just accept the cert. Once I ran update-ca-certificates on my desktop and pointed it at Caddy's root cert, the browser warnings stopped and vault.lan started working like a real HTTPS site.

Pi-hole: on, then off

I also set up Pi-hole on this box for network-wide ad blocking, moving its web interface off ports 80/443 so it wouldn't collide with Caddy. It worked. It also worked too well, blocking things aggressively enough that it started breaking normal browsing for the household, so I turned it off. The container is still sitting there, just not doing anything right now. I haven't decided if I want to go back and tune the blocklists or just leave ad blocking off the table for this network.