When developing the macOS app, we always build the exact same version
and build code for each build. ~~This _may_ be one reason why we
constantly have to deactivate the extension before the new one will
launch.~~ Edit: Just tested, and I can verify that this does fix the
issue on dev builds, so no more having to uninstall the sysex between
builds.
Even if that's not the reason, this is a cleaner approach than building
it in our prod-only scripts.
---------
Signed-off-by: Jamil <jamilbk@users.noreply.github.com>
When updating the provisioning profiles (i.e. when changing anything the
Apple Developer Portal), we needed to manually update these build
scripts to point to the new UUIDs.
This can be made simpler to automatically pull it out of the profiles in
CI.
Somewhere between Xcode 16.0 and Xcode 16.3, the API for the libresolv
functions we call changed slightly, and we can now pass the return value
of `__res_9_state()` directly to the `res_9_ninit`, `res_9_ndestroy` and
`res_9_getservers` functions.
Microsoft Intune's DMG provisioner currently fails unexpectedly when
trying to provision our published DMG file with the error:
> The DMG file couldn't be mounted for installation. Check the DMG file
if the error persists. (0x87D30139)
I ran the following verification commands locally, which all passed:
```
hdiutil verify -verbose <dmg>
hdiutil imageinfo -verbose <dmg>
hdiutil hfsanalyze -verbose <dmg>
hdiutil checksum -type SHA256 -verbose <dmg>
hdiutil info -verbose
hdiutil pmap -verbose <dmg>
```
So the issue appears to be most likely that Intune doens't like the
`/Applications` shortcut in the DMG. This is a UX feature to make it
easy to drag the application the /Applications folder upon opening the
DMG.
So we're publishing an PKG in addition to the DMG, which should be a
more reliable artifact for MDMs to use.
---------
Signed-off-by: Jamil <jamilbk@users.noreply.github.com>
In #8480, we changed the location that `firezone-gateway` gets
downloaded to but forgot to update the knowledgebase with the new path.
---------
Signed-off-by: Thomas Eizinger <thomas@eizinger.io>
In order to get more recent tools like `cargo deny` that support Rust
2024, we need to bump the nixpkgs release we depend on to 24.11. As part
of doing so, we simplify the flake to not depend on `flake-utils` as we
only build for a single system anyway.
On some Linux distributions (Amazon Linux 2023), the default `iptables`
install includes a blanket deny rule in the `FORWARD` chain that
prevents packets from the tunnel interface from ever leaving the host.
To fix this, we ensure our `FORWARD` chain rules are inserted with
priority 1 which takes precedence over the blanket-deny rule.
We also update our MASQUERADE in the NAT table to apply only to the CIDR
range possible for Gateway tunnel IPs, as opposed to the default
`0.0.0.0/0`.
Fixes#8481
On older systemd versions (such as 219 bundled with Amazon Linux 2), the
`ExecStartPre` script isn't able to write to the `/usr/local/bin`
directory. This causes an error on unit startup.
To fix this, we update the `firezone-gateway-init` script to write to
`/opt/firezone` instead, which is `chown` `firezone:firezone`.
Tested to work on Amazon Linux 2.
Fixes#8471
When deploying a Gateway from the admin portal UI, we show various
environment variables required for setup. Until now, we've relied on the
`/var/lib/firezone` persistence method for identifying the Gateway.
However, this can cause issues on some systems that don't have writeable
access to /var/lib/firezone, or old versions of systemd that don't
support sandboxed access to this directory.
This PR updates each deployment method to use `FIREZONE_ID` instead
everywhere. Additionally, since the Docker upgrade script needs to
reinvoke the new container using the same arguments (more or less) as
the install, we need to extract the old `/var/lib/firezone/gateway_id`
file out of the existing container if it exists, and try to insert it
into the upgraded container.
Tested both scripts, including upgrades for the Docker script.
Fixes: #8471
A particular version of Xcode locks in particular versions of SDKs to
build against. If we hardcode this, the benefit is that we have a
predictable and repeatable build environment.
The downside is whenever GitHub updates its macOS runner images, we
could fail to build due to a version mismatch.
In general, drift between Xcode versions isn't a problem, and tracking
the latest will more closely track developer's machines.
Using `rustup` - even on NixOS - is easier to manage the Rust toolchain
as some tools rely on being able to use the `rustup` shims such as
`+nightly` to run a nightly toolchain.
