4 Commits (v1.3.72)

Author	SHA1	Message	Date
nexxo	a21278eb52	Create the file the import needs, instead of writing that something else does ... The comment in Caddyfile.example said install-agent.sh creates /etc/caddy/clupilot-proxy-hosts.conf before anything imports it. It did not. I wrote the claim and never built the thing, and the release notes repeated it as an instruction. Following that instruction would have taken the site down. An import of a missing file makes the WHOLE Caddy configuration invalid — app.clupilot.com, the portal, everything — and the operator would have been holding a step I told them to take. So the installer now does both halves itself: it creates the file, and it adds the import line, then runs `caddy validate` and takes the line straight back out if Caddy rejects it. Doing it in a script rather than in a comment is the point — an instruction gets followed in the wrong order, a script does not. And a second trap alongside it: a hostname written by hand in the Caddyfile is now skipped when the generated file is rendered. Two site blocks for one name make Caddy reject the entire configuration, so an operator who managed an already-hand-written name in the console as well would have taken the public site off the air with no visible connection between the two actions. 2037 tests pass. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-30 23:35:13 +02:00
nexxo	006ce3568b	Manage hostnames and watch their certificates from the console ... files.clupilot.com is why this exists. DNS pointed at the right machine, the env var was set, the release was deployed — and there was still no certificate, because /etc/caddy/Caddyfile is maintained by hand and nobody thought of it as a second, separate step. Nothing in the console would have said so. Three settings looked correct and the address did not answer. So the page holds two things side by side. The WISH — which names should be served — and the REALITY: whether the name has a certificate and for how much longer. The second is measured by opening a TLS connection and reading the expiry, not by reading configuration, because the configuration is exactly what looked right while the address was dead. verify_peer stays on: a certificate that fails validation is not a certificate for this question, and a display that called it valid would be the fake R19 records. Applying goes through the existing agent, not a new channel. The console writes a request, the path unit wakes the agent within a second, and the agent calls one fixed command line of the root-owned helper. What that helper is allowed to do is the careful part. It fetches the list ITSELF rather than being handed one, and the list is HOSTNAMES, never Caddy blocks — `php artisan clupilot:proxy-hosts` prints `<name> <purpose>` and nothing else. Each name is matched against a strict pattern before it is used, and the template around it lives in the helper, which the service account cannot touch. install-agent.sh already states the principle for the sudoers grant: a grant is only worth anything if the holder cannot change what it grants. A service account that could write proxy configuration would have everything the proxy can do — redirects anywhere, files from any directory. Purpose is a column rather than a habit. A console name gets the network lock, a public one does not, and a console name published without it looks exactly like a working page. Removing takes the name out of the list and NOT out of the running proxy. Two decisions in one click, and the second one takes a site off the air. There is deliberately no "renew" button. Caddy renews on its own at two thirds of the lifetime; what an operator actually needs is a second attempt after an issuance has failed, and that is a reload — which is what Apply does. Thirty days is treated as a problem rather than a warning: at ninety days' lifetime, a renewal should long since have run, so anything under it is not a tight certificate but a renewal that is not happening. The ACME contact falls back to the owner's address, because a contact nobody reads is the step before expired customer certificates. CONTRACT and HOST_STEP_NEEDS both move to 2, which is what tells a server carrying the older helper to run the installer again — caught by the guard test that compares the two halves. 2035 tests pass, assets build. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-30 22:55:55 +02:00
nexxo	20d87c0474	Put the files hostname in the reference proxy configuration ... FILES_HOST tells Laravel which hostname to bind the routes to. It does not make the reverse proxy terminate TLS for that name or forward it anywhere, and the live server showed exactly that gap: DNS correct, the right machine, port 80 answering — and a TLS handshake that fails because no certificate exists for the name. The block carries two things the other public names do not have to think about. No console allowlist. The archive is fetched by a server in a RESCUE SYSTEM: a machine with no tunnel and a public address that is in nobody's allow list. The console's network lock here would be a lock against the only caller that needs it. The protection lives in the application instead — no valid one-time code, 404 — and the legal documents are public by intent. And no `http://… { abort }` either, unlike admin and ws below it. Those two hide that they exist; this one is meant to be known, and killing port 80 takes the path away from an ACME check on the day Caddy's own challenge handler is not the first thing to answer. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-30 22:34:15 +02:00
Claude	2bb1d7cc3b	Make the private hostnames look like nothing is there, and close the way past the proxy ... An empty 404 is itself information: it says something terminates TLS here and chose not to answer. The console and the websocket endpoint now close the connection instead, which is what a hostname that serves nothing looks like. The websocket endpoint answers a genuine upgrade — verified live, 101 — and nothing else; a browser opening it gets a closed connection. Reviewing that turned up two holes that mattered more than the thing being reviewed. The compose defaults published the application and Reverb on every interface. Docker publishes ports ahead of UFW, so those backends were reachable from the internet with the firewall closed — and reaching a backend directly skips the proxy, and with it every hostname and address rule keeping the console private. The defaults are loopback now, and an update rebinds an existing installation that is behind a proxy actually running and holding 443. A development box without one is left alone, because taking its port away would look like the machine had broken. And the console's own "open" switch was emitting 0.0.0.0/0 into the proxy's allowlist. One click would have put the console on the public internet, which is the exact state the owner's rule exists to prevent. Switching it off relaxes the application's check; the proxy keeps its list, always. The reference proxy config carries the arrangement: QUIC early data off, since an address-based decision taken on 0-RTT can answer 425 and some browsers do not retry — an intermittent lockout from the console is the worst kind — and explicit handling for plain HTTP, whose automatic redirect otherwise announces both hidden names to anyone who asks. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-27 11:26:48 +02:00