With a real AD (and not Intune), it seems the `valueName` attribute is
required for text elements.
Supersedes: #9419
Co-authored-by: Antoine Labarussias <antoinelabarussias@gmail.com>
Introduces new structure in the `/kb/deploy/clients` docs for managed
configurations.
In draft until new Apple clients, Android, and Windows is ready.
---------
Signed-off-by: Jamil <jamilbk@users.noreply.github.com>
Co-authored-by: Thomas Eizinger <thomas@eizinger.io>
This PR adds the equivalent MDM configuration that we already have for
MacOS & iOS for the GUI client on Windows. These options are retrieved
from the Windows registry when the Client is started. Specifically, the
key for these is: `HKEY_CURRENT_USER\Software\Policies\Firezone`.
At moment, these cannot be configured or seen by the user. They are also
not "watched" for whilst the Client is running. If an admin pushes a new
MDM configuration, the Client will have to be restarted in order for
that new config to take effect.
Windows Policy templates are structured into two files:
- An `.admx` file that defines the structure of the policy, like the
kinds of values it has, where it is stored, which versions it is
supported on and which category it belongs to.
- An `.adml` file that defines defines all strings and presentation
logic, like the actual text of the policies and how the values are
presented in the GUI in e.g. Intune.
Internally, we differentiate between `MdmSettings` and
`AdvancedSettings`. The `MdmSettings` are cross-platform, however on
Linux, we always fallback to the defaults and therefore, they are always
"unset". Eventually, it might make sense to wrap both of these into a
more general `Settings` struct that acts as as a proxy for the two.
Related: #4505
Having defaults in here is confusing, because they are actually all
unset by default which means the user settings won't be overridden.
This is the final version submitted at
https://github.com/profilemanifests/profilemanifests
On macOS, we need to use `mobileconfig` files to configure the client.
These are cumbersome to generate by hand and so a number of popular
tools exist to aid in generating these.
One of the more popular options is [iMazing Profile
Editor](https://imazing.com/profile-editor), which maintains a
[repository](https://github.com/ProfileManifests/ProfileManifests) of
popular "Profile Manifests" for various enterprise-managed applications
on Apple.
In addition to opening the PR for the Firezone client in this repo,
we'll want to open one there too so we can be added to the in-app list
of support applications to generate `mobileconfig` files for.
Because `e2-micro` instances are cheap (our current 24 instances is only
costing $50/mo) it would make sense to deploy a single one in each GCP
region that supports them.
This will increase our global presence, reducing latency for users
around the world especially if they happen to need to go through a Relay
because of a badly behaved NAT. The number of instances in each region
is reduced from `2` to `1` based on the logic that more heavily
populated parts of the world _already_ have a higher density of GCP
regions in them, and we don't need inter-region redundancy.
Also, this ensures our staging Relay deployment matches our Production
relay deployment to reduce the chance that drift between the two will
cause unforeseen downtime.
This will be tested on staging first, and if all goes well, will go out
to production over the weekend.
The top graphic said `Signed in: Last week` while the card said `Last
signed in: 2 weeks ago`.
I did my best to recreate the original shadow and such. The graphic I
exported this PNG from is the one in the New Landing Page.
- Fix missing two-factor graphic
- Fix crash on mobile due to use of luminance in yc-logo-gray.svg,
replaced with PNG
- Fix layout issue on mobile for use case cards
- Consistent link/button font size on landing
- Use new elevator graphic and remove redundant HTML/CSS
- Removes underline on some ActionLinks because the color is not applied
correctly (Tailwind bug?)
- Adds the AWS equivalent of our GCP scalable NAT Gateway.
- Adds a new kb section `/kb/automate` that will contain various
automation / IaaC recipes going forward. It's better to have these
guides in the main docs with all the other info.
~~Will update the GCP example in another PR.~~
Portal helper docs in the gateway deploy page will come in another PR
after this is merged.
