An upload endpoint with no password, on purpose

The machines that most need to send you a log file are exactly the ones that can't. A laptop that died halfway through an install has no agent, no credentials, and often no user account, because on our fleet the accounts get created when the machine first checks in, and checking in is the thing that failed. Every remote support tool assumes a working machine. That one isn't working, which is why you're looking at it.

So we built the opposite assumption into a small tool, and today it's on GitHub under MIT.

It does two things. A machine sends a diagnostic bundle up, and a machine fetches a fix script down. One Cloudflare Worker, one prefix in an R2 bucket, no database, no dashboard, no accounts. The whole product is a URL somebody types by hand:

wget -O- https://dbg.example.com/c | sudo bash

The part that sounds wrong

Uploads are unauthenticated. Anyone who finds the endpoint can POST to it.

That reads like a mistake, and it's the most deliberate decision in the thing. A laptop mid-failed-install has nothing to authenticate with. Requiring a credential doesn't make the system secure; it makes the system useless at the exact moment you need it, and what you get instead of a leaked bundle is no bundle at all.

What makes an open upload endpoint safe is the other half: nothing can be read back out over HTTP. There is no download route. Retrieving a bundle means wrangler r2 object get from a machine that's already authenticated to the account. The listing route returns object keys and never contents, and it wants a token. So the worst an anonymous POST achieves is putting bytes in a bucket that nothing serves.

One-way is the property that does the work. Once you have it, you can drop the password without dropping anything that mattered.

Redaction happens before the upload, never after

Here's the trap worth knowing about even if you never touch this tool. curtin, the thing that actually performs an Ubuntu autoinstall, echoes late-commands into its install log verbatim. So any secret your installer passes through a late-command is already sitting in a plaintext log file, on the machine, waiting for someone to helpfully collect it.

The collector reads that secret off the machine at runtime and strips it out of every file in the bundle before the bundle is ever built, along with Wi-Fi pre-shared keys and anything that looks like a key, token or password assignment. Device IDs stay: they identify the machine and they aren't credentials.

The secret is deliberately not written into the collector script, because the collector is served from that same public unauthenticated URL. A script that has to know a secret in order to hide it has been designed backwards.

If you only test one thing in a system like this, test that: plant a known string, run the collector, and assert it's absent from what came out.

The small things that cost real time

The fix scripts live in R2, not in the Worker bundle. That's not tidiness. It means publishing a correction is an upload, not a redeploy, which matters when the person who needs the corrected script is standing over the broken machine right now.

And never write wget -q into a command a human is going to type. On any failure, -q prints nothing, bash receives an empty script, and the whole thing exits 0. The terminal looks exactly like the service is down. You will debug the wrong end of the problem for an hour. wget -O- shows you the actual error.

What we didn't publish

No fix scripts ship with the repo.

The tooling to mint them is there, and so are the rules: every fix name carries eight random characters, because /f/ is public and unauthenticated and those scripts run as root, so the random suffix is the only access control a fix has. The 404 for an unknown name deliberately refuses to list what exists, since a listing would defeat the random names entirely.

But the fixes themselves are specific to the fleet they repair, and a published one describes both a failure and a way in. So the repo has the mechanism and none of ours. If you deploy it, write your own.

Two other things came out of that review worth passing on. A temporary rescue account should generate its password and print it once, never carry a fixed one. A constant is a standing credential on every machine that ever needed rescuing, identical across the fleet. And bash on macOS is 3.2, which mis-parses a case statement inside $( ), while the Ubuntu live session you're targeting runs 5.2. Lint on both or ship a script that only works where you wrote it.

Elsewhere

Rally, classroom quiz games with ten modes over the same question set, is live, and the import path takes the Blooket and Kahoot exports teachers already have rather than asking them to start over.

On the managed IT side the build status board is still the page we'd point at first. It says what's operational, what's in build, and what's merely planned, and rows move in both directions. One moved back to "planned" recently because calling it "in build" was generous when no code had been written.

Same instinct as the tool above, really. Publish the mechanism, be exact about what it does and doesn't do, and let people check.

If you'd rather someone else carried this kind of thing for you, that's the Managed IT beta, and the uptime monitor post covers the other half of how we watch machines that can still talk.