#22437
There is a bug in Ubuntu 24.04's distribution of GDM that prevents it
from starting correctly and displaying a prompt to the user if
`/etc/nologin` is present. This issue is not present on the current
release of Fedora, meaning it is Ubuntu specific.
The way we lock users out is by manually creating the `nologin` file and
then masking the `systemd-user-sessions` systemd unit, which creates the
file on shutdown and deletes it on startup. This will cause a PAM policy
to fail and prevents anyone from logging in. When we unlock the system
we delete the `nologin` file, unmask the `systemd-user-sessions` unit,
and manually run the binary that it should start.
This process removes the cause of the GDM bug, but we need to reboot the
machine to get GDM working again.
While I have not yet been able to determine the exact cause of the bug,
this fix will prevent the user from being stuck with a black screen once
the machine is unlocked.
This fix will not remedy GDM showing a black screen upon being locked,
it only ensures that the user isn't stuck having to manually reboot the
machine once it's unlocked.
We should check back on this soon to see if the bug gets been fixed
upstream.
#20370
Part 2 to #20699. Apparently `systemd` now automatically deletes
`/etc/nologin` on startup. In the previous PR, rebooting the machine
would remove the nologin file and allow users to login. This PR masks
the service that performs the deletion, preventing it from running.
The message displayed to the user will be what is specified in [this
file](https://github.com/systemd/systemd/blob/7767896d127264f660e1e8a714e5cd760840921f/tmpfiles.d/systemd-nologin.conf#L10).
It's not the best, but I suspect messing with too many systemd files
could come back to bite us in the future if things change, so I'll leave
it as-is.
As part of this PR #20224, I added the new script to one location but
didn't notice that it wasn't included in the embedded scripts directory.
This also adds an unlock script that will reset the registry values to
their original settings
#18173
Creates a detached child shell process to wipe the host. This lets the
main shell script return and tells the server the command has completed,
clearing it from the run queue.
Now shuts the host down after being wiped instead of leaving it running
without files like a zombie
The Wine developer does have an Apple Develeoper certificate but the
"Wine Stable" app bundle is not code-signed or notarized post-install &
disables Gatekeeper for the install. This adds a warning to the script
user about the app not being signed. post-install
---------
Co-authored-by: Victor Lyuboslavsky <victor.lyuboslavsky@gmail.com>
New flow for `fleetctl --package --type=msi` on macOS using arm64
processor (M1, M2, etc.)
- wine must be installed locally. See
./orbit/tools/build/install-wine-macos.sh and
https://wiki.winehq.org/MacOS for reference.
- --local-wix-dir can be used to point to a local Wix3 installation
(using this switch requires a current Fleet EE subscription)
#15463
PR for docs: https://github.com/fleetdm/fleet/pull/16459
# Checklist for submitter
If some of the following don't apply, delete the relevant line.
<!-- Note that API documentation changes are now addressed by the
product design team. -->
- [x] Changes file added for user-visible changes in `changes/` or
`orbit/changes/`.
See [Changes
files](https://fleetdm.com/docs/contributing/committing-changes#changes-files)
for more information.
- [x] Manual QA for all new/changed functionality
---------
Co-authored-by: Noah Talerman <47070608+noahtalerman@users.noreply.github.com>
Dante Catalfamo