stdenvNoCC + p7zip extraction; strips installer scripts and README,
keeps Licenses/. dontFixup since the artifacts are Windows DLLs.
meta.license is unfreeRedistributable to reflect the bundled XeSS
(Intel SLA) alongside the GPL-3.0 source.
Wires lib/overlays.nix into mkDesktopHost (was muffin-only) and adds
"optiscaler" to the unfree allowlist on jovian hosts so yarn can
consume it without flipping the global allowUnfree flag.
Three additions on top of the file-replacement scaffolding:
- mode = "init": create-on-first-apply, leave-alone-otherwise. For
files the application writes back to (configs edited in-game, save
files). Operator pushes a new template by deleting the target.
- chmod 644 after every copy. shutil.copy2 preserved the source's
/nix/store mode (0o444), which made dropped DLL configs read-only.
Apps that wrote back (OptiScaler "Save INI") got EACCES, which in
OptiScaler's case cascaded into CreateSwapChainForHwnd returning
E_FAIL and crashed FH5 on launch.
- launchOptions = listOf str. Multiple mods targeting the same
steamAppId have their lists concatenated (mod-name alphabetical),
joined with spaces, %command% appended once. Written into Steam's
per-app block in userdata/<id>/config/localconfig.vdf via vdf
parse + atomic os.replace. Idempotent.
- X-ConfigHash on the systemd unit so switch-to-configuration switch
re-runs apply when the manifest changes.
BIOS 2423→4101 update on yarn required an fTPM reset, which broke the
sealed age identity at /var/lib/agenix/tpm-identity. Bootstrapped a new
identity against the new SRK and rotated yarn's recipient.
age-plugin-tpm 1.0+ emits age1tag1… (p256tag) recipients by default and
refuses to encrypt to legacy age1tpm1… ones, so rotated mreow's recipient
to the same encoding (same key, new bech32 HRP) and added an
age-plugin-tag→age-plugin-tpm symlink in the rage wrapper so rage's
plugin dispatch finds the binary under the new prefix. Stripped the
trailing host labels from the tpm recipient strings — rage's stricter
bech32 parser now rejects the trailing whitespace; labels live in
adjacent Nix comments instead.
oo7-server 0.6.0 only feeds the systemd / PAM secret to existing
keyrings discovered on disk. On first run no keyring exists yet, the
daemon creates an empty 'Login' collection via LockedKeyring::open,
the credential is silently ignored, and any client Unlock() routes to
a prompt that nothing on a niri desktop can satisfy.
Patches/oo7-server/0001-... is upstream commit cf7b9a9 (PR #443)
regenerated relative to the package's sourceRoot ('server/'). It
switches the auto-created default-keyring path to UnlockedKeyring::open
when a secret is available.
The override threads the patch through pkgs.oo7-server.overrideAttrs
in modules/desktop-oo7-daemon.nix and uses the patched derivation for
both services.dbus.packages and systemd.packages so the user unit and
D-Bus activation file land from the same store path. Cargo.lock is
untouched, so the existing cargoDeps hash stays valid.
Drop the override once nixpkgs ships an oo7-server release that
includes the fix (anything past 0.6.0).
oo7-daemon was running but its 'Login' keyring stayed locked because
nothing supplied a master password, so libsecret clients (flare in
particular) blocked indefinitely on keyring.unlock().
The upstream user unit declares
ImportCredential=oo7.keyring-encryption-password
which picks up matching credentials from systemd's per-service
credential machinery. Wire LoadCredential=oo7.keyring-encryption-password
to the agenix-decrypted secret so the daemon unlocks at session start
without any prompt.
The password itself is a fresh 64-byte urandom value encrypted to all
desktop recipients (admin SSH key + mreow + yarn TPM identities); it's
opaque to the user and never typed manually. Owner is primary so the
user-scope unit's LoadCredential read works without elevating.
Verified the activation script chowns the decrypted file primary:users
mode 0400, the user unit override carries the LoadCredential line, and
the resulting drv builds clean.
Without a secret-service implementation on the bus, libsecret clients
like flare fail at startup with 'The communication with libsecret
failed'. None of the desktop hosts had one wired up.
oo7-daemon is the matching pure-Rust implementation (same project as
the oo7 crate flare uses internally), without the GNOME plumbing that
gnome-keyring would drag in. Register the package's D-Bus service
file and systemd user unit, start the daemon at user login, and alias
the unit as dbus-org.freedesktop.secrets.service so D-Bus
auto-activation also resolves cleanly when the wantedBy start hasn't
fired yet.
Verified the toplevel build and that the resulting system carries the
oo7-daemon user unit, the dbus alias symlink, and the
default.target.wants entry.
new site-config.nix holds values previously duplicated across hosts:
domain, old_domain, contact_email, timezone, binary_cache (url + pubkey),
dns_servers, lan (cidr + gateway), hosts.{muffin,yarn} (ip/alias/ssh_host_key),
ssh_keys.{laptop,desktop,ci_deploy}.
threaded through specialArgs on all three hosts + home-manager extraSpecialArgs +
homeConfigurations.primary + serverLib. service-configs.nix now takes
{ site_config } as a function arg and drops its https namespace; per-service
domains (gitea/matrix/ntfy/mollysocket/livekit/firefox-sync/grafana) are
derived from site_config.domain. ~15 service files and 6 vm tests migrated.
breakage fixes rolled in:
- home/progs/zen/dark-reader.nix: 5 stale *.gardling.com entries in
disabledFor rewritten to *.sigkill.computer (caddy 301s the old names so
these never fired and the new sigkill urls were getting dark-reader applied)
- modules/desktop-common.nix: drop unused hugepagesz=1G/hugepages=3
kernelParams (no consumer on mreow or yarn; xmrig on muffin still reserves
its own via services/monero/xmrig.nix)
verification: muffin toplevel is bit-identical to pre-refactor baseline.
mreow/yarn toplevels differ only in boot.json kernelParams + darkreader
storage.js (nix-diff verified). deployGuardTest and fail2banVaultwardenTest
(latter exercises site_config.domain via bitwarden.nix) pass.
Unified CI on nixos repo is proven end-to-end (CI run on 836f80a deployed to
muffin successfully and yarn's pull URL now serves from the new build). The
two per-repo git-crypt keys are no longer in use by any active pipeline.
Old dotfiles and server-config repos had Gitea Actions disabled before this
commit, so no CI race possible.
The two legacy entries git-crypt-key-{dotfiles,server-config} stay until
muffin has deployed this config at least once and the new CI pipeline is
green. Phase 6 removes them after cutover.
