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.
This publishes the windows headless client using the same convention set
forth by the linux headless client.
Docs and website changes will come in a subsequent PR.
Related: #3782Resolves: #8046
