Building remote access against the clock

A slightly different sort of post — less "here's the fix", more "here's what an hour of pressure does to your decision-making", because I think the decisions were more interesting than any single command.

The situation: a Proxmox box on a desk at work, no remote management of any kind, and me standing next to it with maybe an hour before I had to leave — with the only laptop that was on the same network as the box. The job was to make it permanently reachable from home. So every choice was shaped by one looming fact: I was about to lose my only way in, and anything left half-finished would be left half-finished for good.

You'd think that means rush. It actually means the opposite — it means being ruthless about order.

Get the way back in working first, and test it, before anything else. The temptation is to do the satisfying engineering — the clean config, the tidy persistent setup — and leave "remote access" as the bow on top. Backwards. The remote path is the thing that lets you fix everything else later, so it's the thing that has to exist before you lose local access. I got a tunnel up and SSH'd into the box through it — from the public internet, not the local wire — while I still had the laptop as a safety net. Only once that worked did I relax. Everything after that, I could finish from my sofa.

Prefer the ugly-but-safe option when you won't be there to catch it. At one point the right-looking fix was to edit the box's network config file. The runtime-only version — a little watchdog that forced the correct route every 30 seconds — was uglier, and a purist would wince. But a typo in a network config file, on a host you're about to be unable to reach, is how you brick the whole exercise. The watchdog couldn't take the box off the network; a bad config edit could. Ugly and recoverable beats elegant and fragile, every time you won't be in the room.

"Good enough now, neat later" is a real plan, not an excuse. There was a heavier component (a headless browser, of all things) that really belonged in a container rather than on the hypervisor. Building the container properly would have eaten the rest of my window. So: on the host now, into a container later — over the remote path I'd just built. Writing down the "later" so it actually happens is the difference between pragmatism and a mess.

It didn't all end perfectly, by the way — the one piece I couldn't fully test before leaving (an automatic re-login for the captive portal the box sits behind) is exactly the piece that later went wrong, and took the box offline. Which is its own lesson, and an honest one: the thing you couldn't test under pressure is the thing that'll fail. If I'd had ten more minutes, I'd have spent them forcing that failure on purpose rather than hoping.

None of these are choices I'd make with unlimited time. They were the right ones for the time I had — and knowing the difference is most of the job.

Until next time, Matt.