feat(share): serve on a custom Cloudflare-managed domain via --domain#1107
Conversation
Custom hostnames only exist for Cloudflare Tunnel, so requiring --cloudflare next to --domain was ceremony that told lerd something it could already work out. --domain now picks the tool itself and outranks a default set with share:tool, while combining it with a different tool flag stays an error rather than a silent override. A configured default whose binary has since gone missing used to fail with a bare "not found in PATH", which reads as lerd breaking rather than as a stale setting. The error now says the choice came from share:tool and how to undo it. Sharing a hostname whose tunnel was created on another machine died inside cloudflared with "tunnel credentials file not found", and by then lerd had already announced a public URL that was never going to work. The credentials are checked before anything is printed, and the error explains both ways out. A freshly routed hostname does not resolve straight away, and a resolver asked too early can hold on to the miss for half an hour while the tunnel sits there perfectly healthy. Routing a new record now warns about it. share:tool gained examples and an explicit list of what it accepts, and showing the current default now also says how to change it.
|
Pushed a commit to this branch, hope that is ok, it sits on top of what you had rather than rewriting any of it. The main thing is that --domain no longer needs --cloudflare next to it. Custom hostnames only exist for Cloudflare Tunnel, so lerd can work that out by itself, and --domain now also wins over a different default set with share:tool. Pairing it with another tool flag is still an error rather than a silent override. Three smaller things came out of running it against a real site on my own domain. If a tool pinned with share:tool later loses its binary, a bare lerd share used to fail with just cloudflared not found in PATH, which reads like lerd broke rather than like a stale setting, so the error now says where the choice came from and how to undo it. If the tunnel exists on the account but its credentials json is not on this machine, cloudflared died with tunnel credentials file not found after lerd had already printed a public URL, so the credentials are checked before anything gets announced. And a freshly routed hostname does not resolve straight away, I opened mine too early and my resolver held on to the miss for half an hour while the tunnel was sitting there perfectly healthy, so routing a new record now warns about that. Also gave share:tool some help, it had no examples and printing the current value did not tell you how to change it, plus a test file since the command shipped without one. One correction to the description, route dns is actually idempotent when the record already points at the same tunnel, it only refuses when the record aims somewhere else, so the docs say that now. The tolerance you wrote is still right, just a narrower case than either of us described. |
2 participants
lerd sharegets a--domainflag that serves the site on a hostname the user owns instead of a random trycloudflare.com URL. Passing--domain dev.example.comswitches from a quick tunnel to a named one: if cloudflared has never logged in, the interactive browser login runs first, then a tunnel namedlerd-<site>is created (or reused on later runs), the hostname is routed to it withcloudflared tunnel route dns, and the tunnel runs against the same host-rewriting loopback proxy the quick tunnel path already goes through, so Host, Location, and asset URL rewriting all behave identically.Route DNS is the one non-idempotent step, cloudflared refuses to touch an existing record, so a second run against the same hostname prints a note asking the user to check the CNAME instead of failing the share. Combining
--domainwith a non-Cloudflare tunnel flag is rejected up front, and without the flag the quick tunnel behaviour is byte-for-byte what it was.Following up on review,
--domainno longer implies--cloudflare. A newlerd share:toolcommand stores a default tunnel tool in the global config (share.default_tool), a barelerd shareuses it before falling back to auto-detection, and an explicit tool flag still wins per run.--domainnow only applies when the effective tool is Cloudflare Tunnel, either via--cloudflareor the configured default, and errors with a pointer to both otherwise.Refs #1106