firezone
Release binary naming
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:
- Docs need to be updated when these go live
- Windows updater checker needs to be updated for windows binary name changes
- Some users have already download the old binaries: https://tooomm.github.io/github-release-stats/?username=firezone&repository=firezone
### Tasks
- [ ] How does this affect the headless client standalone vs IPC behavior?
- [ ] https://github.com/firezone/firezone/issues/4770
@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.debfirezone-client-gui_1.0.0-pre.14_amd64.msifirezone-client-headless_1.0.0-pre.14_amd64.debfirezone-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/liband 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.
The one thing that would need to be addressed is auto upgrades for Gateways.
See:
- https://www.firezone.dev/kb/administer/upgrading
- https://github.com/firezone/firezone/blob/main/scripts/gateway-systemd-install.sh#L74
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.
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
latestto the version in manifest
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.