Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Release binary naming #4531

Closed
1 of 2 tasks
jamilbk opened this issue Apr 6, 2024 · 7 comments
Closed
1 of 2 tasks

Release binary naming #4531

jamilbk opened this issue Apr 6, 2024 · 7 comments
Assignees
@ReactorScram
Labels
kind/refactor Code refactoring

Comments

@jamilbk
Copy link
Member

jamilbk commented Apr 6, 2024 •
edited by ReactorScram
Loading

We need to settle on binary names for the following things we publish:

artifact
linux headless client
linux gui client (deb)
windows headless client
windows gui client (msi)
gateway

Note:

Tasks
Beta Give feedback
  2. bug(scripts): Update gateway upgrade script to handle new permalinks #4770
    0 of 2
    area/gateway kind/bug
    ReactorScram
@jamilbk
Copy link
Member Author

jamilbk commented Apr 6, 2024

refs #4397

@jamilbk jamilbk added the kind/refactor Code refactoring label Apr 6, 2024
@jamilbk jamilbk mentioned this issue Apr 6, 2024
Merged
This was referenced Apr 16, 2024
Merged
Closed
@ReactorScram ReactorScram self-assigned this Apr 19, 2024
@ReactorScram
Copy link
Collaborator

@jamilbk Without thinking of compatibility or how to make Tauri fit this, this would work for me:

For package filenames, brand-product_version_arch.extension

  • firezone-client-gui_1.0.0-pre.14_amd64.deb
  • firezone-client-gui_1.0.0-pre.14_amd64.msi
  • firezone-client-headless_1.0.0-pre.14_amd64.deb
  • firezone-client-headless_1.0.0-pre.14_amd64.msi

firezone-client-gui_1.0.0-pre.14_amd64.deb installs:

  • /usr/bin/firezone-client-gui
  • /usr/lib/firezone-client-ipc
  • /usr/lib/systemd/systemd/firezone-client-ipc.service

firezone-client-gui_1.0.0-pre.14_amd64.msi installs the equivalent for Windows

firezone-client-headless_1.0.0-pre.14_amd64.deb installs:

  • /usr/bin/firezone-client-headless
  • /usr/lib/systemd/systemd/firezone-client-headless.service

firezone-client-headless_1.0.0-pre.14_amd64.msi installs the equivalent for Windows

If the Gateway ever needs deb / MSI it would be similar to the headless client. i.e. firezone-gateway_1.0.0-pre.14_amd64.deb installs:

  • /usr/bin/firezone-gateway
  • /usr/lib/systemd/systemd/firezone-gateway.service

Checklist:

  • exe paths don't need OS, arch, or version
  • exes not meant for the user to launch are in /usr/lib, outside of $PATH
  • Token, device ID, etc. are configured separately from the systemd service, which is stored in /usr/lib and so gets wiped whenever the package upgrades
  • All files start with the firezone- prefix since they'll end up places where files from other organizations live
  • The headless Client and GUI Client don't conflict, as long as only one of them is configured to auto-start with systemd
  • package filenames include the full version tag
- [ ] FIREZONE_ID should be in `/etc`, not in the systemd service file in `/usr/lib`. The tests currently set a bad example for this.
- [ ] FIREZONE_DNS_CONTROL can be in the systemd service file, but it should be overrideable somewhere.

@ReactorScram ReactorScram mentioned this issue Apr 19, 2024
Merged
@jamilbk
Copy link
Member Author

jamilbk commented Apr 20, 2024

The one thing that would need to be addressed is auto upgrades for Gateways.

See:

@jamilbk
Copy link
Member Author

jamilbk commented Apr 20, 2024

I supposed auto upgrades for Clients would need to have a solution as well. We would need some kind of version manifest, like scripts/manifest with key=value pairs declaring the latest version of binaries we can use to build download URLs from.

We could get this from the GitHub unauthenticated API like we currently do for the Windows client.

But while that works as a stop-gap measure today, it won't scale very well because it's IP-based rate limited with very low limits.

Imagine lots of in-office employees not receiving auto-updates, or gateways behind a load-balancer not being auto-updated.

The standard HTTP API with the /releases/download/latest shortcut doesn't appear to be rate-limited.

@jamilbk
Copy link
Member Author

jamilbk commented Apr 22, 2024 •
edited
Loading

This could work:

  • website/manifest contains versions of components
  • scripts/Makefile update to version components from the website/manifest file
  • Add a route handler to website to redirect latest to the version in manifest

@ReactorScram
Copy link
Collaborator

Yeah adding a manifest to the website and keeping the binaries themselves on Github for now sounds good

I might use the Windows Client as a guinea pig today to see what breaks if I add the version number to the name. Last time I considered it I thought it wouldn't work, but actually it might.

@ReactorScram ReactorScram mentioned this issue Apr 22, 2024
Merged
ReactorScram added a commit that referenced this issue Apr 23, 2024
@ReactorScram
refactor(linux-client): add a systemd service to run the IPC service
9721c05 
Also fix the names of the executables. I couldn't get the IPC service
exe into `/usr/lib` unfortunately. We'd have to work around Tauri's deb
bundling to do that, and that can wait.

Refs #4531
jamilbk added a commit that referenced this issue Apr 24, 2024
@ReactorScram @jamilbk
refactor: Make published artifact names consistent and use permalinks (…
e1eda79 
…#4746)

```[tasklist]
- [x] Update website
- [x] Update blog entry with old link
- [ ] ~~Replace Github URL in GUI Client updater with our own links~~
- [ ] Wait for CI to go green
```

Refs #4531 

This proposes a unified scheme for deb and MSI packages, and moves
Windows to that scheme.

This breaks compatibility. Existing Clients won't recognize the new
asset names once this is merged, so they won't show the "Firezone 1.0.0
is available" pop-up.

---------

Co-authored-by: Jamil Bou Kheir <jamilbk@users.noreply.github.com>
This was referenced Apr 24, 2024
Closed
Merged
github-merge-queue bot pushed a commit that referenced this issue Apr 25, 2024
@ReactorScram
refactor(linux-client): remove FIREZONE_ID from example systemd file (#…
bc94078 
…4714)

For tests it doesn't hurt, but this will be used as a template for the
systemd service we ship to production, and that can't have the ID there.

So I'm also cleaning up a few other problems I noticed:
- I wanted to split the service files as part of #4531, so that the GUI
Client and headless Client can have separate sandbox rules. e.g, the
headless Client won't be allowed to create Unix domain sockets
- I'm punting more things to systemd, which allows us to tighten down
the sandbox further, e.g. creating `/var/lib/dev.firezone.client` and
`/run/dev.firezone.client` for us
- Closes #4461

---------

Signed-off-by: Reactor Scram <ReactorScram@users.noreply.github.com>
github-merge-queue bot pushed a commit that referenced this issue Apr 26, 2024
@ReactorScram
refactor(linux-client): package systemd unit for IPC service (#4752)
b93e887 
This aligns some of the internal names with #4531, but it shouldn't
break the externally-visible things like package names or permalinks.

---------

Signed-off-by: Reactor Scram <ReactorScram@users.noreply.github.com>
@jamilbk
Copy link
Member Author

jamilbk commented May 26, 2024

I think this has been resolved

@jamilbk jamilbk closed this as completed May 26, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@ReactorScram ReactorScram

Labels
kind/refactor Code refactoring
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@jamilbk @ReactorScram