fix: separate the desktop user from the user running the install - #26
Merged
Merged
Conversation
The playbook assumed the two were the same. On a fleet machine they are not: hyperi-infra's inventory connects as `ubuntu` while the desktop belongs to `hyperi`, and everything user-scoped landed in the wrong home or failed outright. `-e hyperi_target_user=<name>` names the desktop user; `actual_user` and `user_home` derive from it. Molecule verify takes it as MOLECULE_TARGET_DESKTOP_USER, since `molecule verify` accepts no extra arguments, and now prints which user it checked -- a run against the wrong home was previously indistinguishable from a clean one. `become: false` means the CONNECTING user, so every user-scoped task carrying it was acting on the wrong account. An audit of tasks combining `become: false` with `user_home` found 19, of which 8 were wrong; the rest are macOS-only, where Homebrew refuses to run as root and the two users cannot differ. Two of the eight paired `become: false` with `become_user:`, which does nothing -- `become_user` is ignored while `become` is false. The worst of them made a tombstone lie. `ansible.builtin.file` cannot read a path it has no permission for and reports "Insufficient permissions ... Treating as absent", so the retired `~/.cargo/bin/uv` was reported removed while it sat there shadowing the real install on PATH. The molecule verify agreed, because it stat'ed the service account's empty home. Also removes the Docker Desktop context, which the package uninstall leaves behind: context state is a per-user file under ~/.docker/contexts, not package state. Where `desktop-linux` was also the selected context every docker command failed against a socket that no longer exists. Two hyperi-update fixes, both of which made it a no-op where it mattered most: - It gated on `sudo -v`, and Ubuntu 25.10+ ships sudo-rs, whose `-v` demands interactive authentication even where NOPASSWD grants the commands. It aborted before doing anything on every 26.04 box and under every unattended caller, which is what --yes exists for. Probes with `sudo -n true` now. - It did not wait for the dpkg lock, so an unattended-upgrades run in progress made the upgrade exit 100 while everything else reported success -- a box that looks updated and is not. Adds a watchdog to the rdp-server role for a fault that makes a remote-desktop host permanently unreachable. Force-stopping another session from the RDP login screen makes gdm tear down that session and the in-flight RDP login with it, and leaves the system daemon accepting TCP on 3389 while servicing nothing -- later connections get a blank screen and the daemon does not log so much as an incoming connection. Restarting gdm does not clear it; only restarting gnome-remote-desktop does, which on a headless host needs ssh that may not exist. The watchdog matches gdm's own failure line rather than probing the port: telling a wedged daemon from a healthy one over the wire needs a real RDP connection, and an aborted one exercises the same session teardown that wedges it, so a probe risks causing the fault it watches for. Gated on the presence of the GNOME handover unit, which is the mechanism the fault lives in, rather than on a version number.
Contributor
|
Released in v2.24.5 — https://github.com/hyperi-io/hyperi-developer/releases/tag/v2.24.5 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The playbook assumed the desktop user and the user running the install are the
same person. On the devex desktop VMs they are not - hyperi-infra connects as
ubuntuwhile the desktop belongs tohyperi- so everything user-scopedeither landed in the wrong home or failed outright. All of this came out of
running the remediation against dragonfly, kaz and kay for real.
The worst of it made a tombstone lie:
become: falsemeans the CONNECTING user, so asubuntuthe file module couldnot read
/home/hyperiand called the file absent. Green tombstone, and theretired uv still sitting there shadowing the real install on PATH. The molecule
verify agreed, because it stat'ed the service account's empty home. A host that
was never fixed looked clean twice over.
Rather than keep patching sites, we audited every task combining
become: falsewithuser_home- 19 of them, 8 genuinely wrong, the rest macOS-onlywhere Homebrew refuses to run as root and the two users cannot differ. Two of
the eight paired
become: falsewithbecome_user:, which does nothing:become_useris ignored whilebecomeis false, and it reads as correct inreview.
The knob is now
-e hyperi_target_user=<name>rather than overriding aninternal fact. Molecule verify takes
MOLECULE_TARGET_DESKTOP_USER(it acceptsno extra arguments) and prints which user it checked, so a run against the
wrong home is visible instead of quietly green.
Also in here:
Docker Desktop's context. The uninstall does not take it - context state
is a per-user file under
~/.docker/contexts. On kaydesktop-linuxwasalso the SELECTED context, so every docker command failed against a socket
that no longer exists. Docker was simply broken for her.
hyperi-update was dead on Ubuntu 26.04. It gated on
sudo -v, and 25.10+ships sudo-rs, whose
-vdemands interactive auth even where NOPASSWD grantsthe commands. It aborted before doing anything, on every 26.04 box and under
every unattended caller - which is what
--yesexists for. It also did notwait for the dpkg lock, so an unattended-upgrades run in progress made the
upgrade exit 100 while everything else reported success.
An RDP watchdog. Force-stopping another session from the RDP login screen
makes gdm tear down that session and the in-flight RDP login with it, and
leaves the system daemon accepting TCP on 3389 while servicing nothing. Every
later connection is a blank screen and the daemon does not log so much as an
incoming connection. Restarting gdm does NOT clear it; only restarting
gnome-remote-desktop does - which on a headless host needs ssh that may not
exist.
It matches gdm's failure line rather than probing the port. We built the
probe first and it worked, then noticed it makes the daemon build and tear
down a session - the same path that wedges it. A health check that can cause
the fault is not a health check. Gated on the presence of the GNOME handover
unit, which is the mechanism the fault lives in, rather than on a version
number.
Done when: the three real hosts converge clean, the removals actually land, and
they hold across a reboot.
Verified on dragonfly, desktop-kaz and desktop-kay, not just in check mode:
failed=0on each, then updated and rebootedmolecule verifygreen on all three against the RIGHT userdesktop-linuxgone anddocker psworks again;~/.cargo/bin/uvgonefor real this time
negotiated, clipboard and audio up
--tags handover-watchdogso it could not restart the RDP daemon under anyonemarker text, pointed at a throwaway target so it could not drop a live
session
Not covered: gdm killing the in-flight login in the first place is upstream,
and the watchdog only catches that one marker.