Linux support

[GregPeden]

I am working on implementing Linux support for this package. The main point of interest in port mapping in Linux vs MacOS.

I am opening this as an issue mostly to comply with project instructions but I plan to submit a PR when I am ready.

I am developing in Ubuntu within WSL2 on Windows 11. I don't have macOS so I cannot test that environment for side-effects resulting from my changes for Linux.

Current state: coast runs and can start a worktreee environment, and I think the port mapping issue for checkout is actually solved except Linux/Ubuntu is strict about allowing free mapping of ports below 1024 so I am investigating best solutions for this. Probably will entail elevating coast with system permissions to do this.

[jamiesunderland]

@GregPeden sounds good! I would love the contribution and would rightfully attribute it. I have a system 76, but mostly work on my macbook. When you're ready just give me instructions and I'll test away. You'll need to give me instructions like I'm a 5-year-old, I'm a really bad linux user 🥲.

The big things I'm afraid of for linux are:

coast-cli/src/commands/dns.rs -DNS setup/status/remove is entirely macOS-only (/etc/resolver)

coast-daemon/src/api/query/docker.rs - Provider detection defaults to "docker-desktop", open_orbstack() has no platform guard, Linux branch assumes Docker Desktop URL scheme

Don't worry about any podman or sysbox runtimes yet.

Smaller things:

coast-cli/src/commands/ui.rs - Resolver path check references /etc/resolver/localcoast

coast-daemon/src/lib.rs -- ensure_host_tool_paths() is a no-op on Linux

There is a strategy in Coastfiles to extract info from the MacOS keys chain. See:
coast-secrets/src/extractors/keychain.rs

Right now it will fail I think if run on none-darwin. It would be ideal to be able to provide a linux alternative. We might have to introduce new syntax to the Coastfile toml to get this right. If you have an idea, I would love that. It's none-blocking and something we could do at a later date.

Tiny frontend things:

coast-guard/src/components/Layout.tsx - Renders provider name and "open settings" button based on the daemon's provider detection; will need UI handling for the "docker-engine" provider case

If you need any help, I'm around in the discord and happy to answer any questions.

Thank you so much for taking this on!

[GregPeden]

The changes needed to get it working in Linux are quite minimal.

I have extended my interest in smooth WSL support. This mostly affects how Windows exposes ports in Windows from Linux. The WSL environment gets its own internal IP address that can change every time WSL is restarted. A solution to this is to use another minimal docker container as a proxy, since the docker will expose the open ports to the local Windows machine.

I am also adding a solution to have the coast containers share one SSL certificate so that the developer only has to add one to the trusted registry for their browser. "coast" and "coast-dev" will keep separate certificates.

[jamiesunderland]

Awesome! Excited to have this be cross platform. Feel free to reach out to me here or on discord if you have any questions or need help.

[jamiesunderland]

@GregPeden I'm not sure if the SSL cert stuff overlaps with this #64 but just wanted to put that out there

[GregPeden]

That is fair, I will keep the SSL concern out of my scope and maybe address it later.

I'm hoping to submit a PR today after some practical testing. And it helps a lot that Codex released more formalized sub-agent support yesterday.

[jamiesunderland]

Taken care of in #86