darman/homelab
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs: condense comments across the repo

Browse Source 
Comments had drifted into multi-paragraph narrative (git commit
lineage, debugging stories, restated code) in several hot spots
(scripts/deploy, hermes-agent.nix, flake.nix, gitea.nix, headscale.nix).
Trim every comment to its load-bearing "why" — gotchas, safety
warnings, and non-obvious rationale survive verbatim in substance,
just tightened to 1-2 sentences; historical narrative and anything
already covered in CLAUDE.md is cut. No code/logic changed.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UJqEmY1y3AYX3JoX4Y6b21
This commit is contained in:
darman
2026-09-18 21:36:30 +02:00
co-authored by Claude Sonnet 5
parent 3899290c5b
commit 6f24ab69ad
47 changed files with 1051 additions and 1965 deletions
Download Patch File Download Diff File Expand all files Collapse all files
hosts/jupiter/configuration.nix
+37 -85
View File
@@ -40,16 +40,11 @@
# systemd-boot for UEFI. If ZimaBlade boots legacy/BIOS, switch to grub.
boot.loader.systemd-boot.enable = true;
boot.loader.efi.canTouchEfiVariables = true;
# common.nix's cap of 5 comes from this box's own 34-generation incident,
# but at ~5G free on a 29G eMMC even 5 is too many — override down to 2.
# common.nix's default of 5 is still too many boot entries for a 29G eMMC — override down to 2.
boot.loader.systemd-boot.configurationLimit = lib.mkForce 2;
# A `switch` pins the old generation as a GC root until the box reboots onto
# the new one (booted-system vs current-system) — common.nix's nix.gc is
# weekly, far too slow to catch that on a 29G eMMC. 2026-08-19: one switch
# alone took 14G -> 19G used; only reboot (releases the old root) + this GC
# brought it back to 14G. Run a full collect right after every boot instead
# of waiting on the weekly timer.
# A `switch` pins the old generation as a GC root until reboot; common.nix's weekly
# nix.gc is too slow for a 29G eMMC, so collect garbage on every boot instead.
systemd.services.gc-on-boot = {
description = "Full nix-collect-garbage on every boot";
wantedBy = [ "multi-user.target" ];
@@ -70,46 +65,24 @@
boot.kernelParams = [ "reboot=pci" ];
# ---- GPU (jellyfin hardware transcoding) ----
# Apollo Lake N3450 / HD Graphics 500 (Gen9, pci 8086:5A85). The i915 KERNEL
# driver binds on its own — /dev/dri/{card1,renderD128} exist without this —
# but the libva USERSPACE driver only ships when hardware.graphics is on, and
# nothing else here pulled it in. Without it VAAPI init fails with "unknown
# libva error" and jellyfin-ffmpeg exits 251 on EVERY transcode, which the
# client shows as generic playback failure: the server log only says "FFmpeg
# exited with code 251", never that a driver is missing. Verified on the box:
# the same h264_vaapi encode goes 251 -> 0 once iHD is on LIBVA_DRIVERS_PATH.
#
# iHD (intel-media-driver) is the right one for Gen9; i965 is for Gen8 and
# older. Note the render node is 0666 but card1 is 0660 root:video, so the
# group membership in services/media/jellyfin.nix matters for the card node.
# Apollo Lake N3450 / HD Graphics 500 (Gen9). i915 binds on its own, but VAAPI needs
# the iHD userspace driver (Gen9; i965 is Gen8-only) or jellyfin-ffmpeg exits 251 on
# every transcode with no clearer error than "FFmpeg exited with code 251" in the log.
hardware.graphics = {
enable = true;
extraPackages = [ pkgs.intel-media-driver ];
};
# ⚠️ This buys VAAPI only — jellyfin must be set to VAAPI, NOT QSV, in its
# web UI (Dashboard -> Playback -> Transcoding). QSV needs an MFX runtime on
# top of the libva driver: ffmpeg's `-init_hw_device qsv=qs@va` dies with
# "Error creating a MFX session: -9" -> exit 171, the SECOND failure hiding
# behind the first (fixing the missing driver only moved 251 -> 171).
# There is no good way to provide it here: vpl-gpu-rt is Gen12+, and the
# Gen9 runtime `intel-media-sdk` is marked INSECURE in nixpkgs (EOL, 5 CVEs
# incl. local privilege escalation) — not worth it when VAAPI does the same
# job on this chip at ~3.5x realtime for 1080p->720p.
#
# Also: 4K HDR (the 2160p HEVC/DV remuxes) can NOT be tone-mapped here.
# tonemap_opencl needs OpenCL, which has no platform on this box, and
# tonemap_vaapi is Gen11+ — both fail. Only a plain scale_vaapi=format=nv12
# succeeds, which drops HDR without tone-mapping (washed-out picture).
# Those files need to direct-play, or be kept as 1080p SDR versions.
# ⚠️ Use VAAPI, not QSV, in jellyfin's UI — QSV needs an MFX runtime not safely
# available for this Gen9 chip (only insecure/EOL options) and fails with exit 171.
# 4K HDR remuxes also can't be tone-mapped here (needs OpenCL or Gen11+); keep those
# as 1080p SDR or let them direct-play.
# ---- NAS data array ----
# Existing ext4 on the mdadm RAID0 over sda+sdb (md0, 29.1T).
# Mounted, NOT formatted; kept out of disko so it is never wiped.
# ⚠️ RAID0 = no redundancy: either 16TB disk failing loses ALL data.
boot.swraid.enable = true; # assemble the mdadm array at boot
# Silences "mdmon service will crash" eval warning. RAID0 here uses native
# superblocks so mdmon (external-metadata arrays only) never actually runs,
# but the module warns unconditionally without SOME MAILADDR/PROGRAM set.
# Existing ext4 on mdadm RAID0 (sda+sdb, md0, 29.1T) — mounted, not formatted, kept
# out of disko. ⚠️ RAID0 has no redundancy: either disk failing loses ALL data.
boot.swraid.enable = true;
# Silences the "mdmon service will crash" eval warning — mdmon never actually runs
# here (native superblocks, not external-metadata) but the module warns regardless.
boot.swraid.mdadmConf = "MAILADDR root";
fileSystems."/mnt/data" = {
# fs UUID (stable) — the array may enumerate as /dev/md127, so avoid /dev/md0.
@@ -118,69 +91,48 @@
options = [ "nofail" ]; # don't block boot if the array is degraded/absent
};
# `nofail` above is necessary but NOT sufficient — any mount layered on the
# array (prowlarr/seerr binds) is RequiredBy local-fs.target and will fail it
# regardless, and emergency mode on this box is a dead end: root is locked, so
# sulogin drops you at a prompt you cannot answer, with no ssh. 2026-08-06: a
# drive that failed to enumerate after the rack move did exactly this —
# "Timed out waiting for device /dev/disk/by-uuid/dadbff6f-…" -> Dependency
# failed for Local File Systems -> Reached target Emergency Mode, twice.
# Boot as far as possible instead and leave the failed units to be read over
# ssh. The array-backed services carry RequiresMountsFor=/mnt/data so they
# still refuse to start rather than writing to the eMMC.
# `nofail` alone isn't enough — mounts layered on the array (prowlarr/seerr binds)
# are RequiredBy local-fs.target and can still trip Emergency Mode, which is a dead
# end here (root locked, no ssh). Boot as far as possible instead; the array-backed
# services carry RequiresMountsFor=/mnt/data so they still won't write to the eMMC.
systemd.enableEmergencyMode = false;
# ---- Heavy state moved off the eMMC ----
# A deploy holds TWO full closures (~9G each) on a 29G disk at once, so the
# OS disk has no room for state that grows on its own. 2026-08-09: it hit 0
# bytes free with both gen 39 and gen 40 resident, and postgres died on
# "No space left on device" — note ext4 reserves 5% for root, so non-root
# services see zero while df still shows ~300M free.
#
# Paths live under /mnt/data/AppData like every other service's state. Both
# settings below are jupiter-only on purpose: services/containers.nix stays
# engine- and host-agnostic (mercury runs pihole on podman with no array).
# A deploy holds two full closures (~9G each) on this 29G disk at once, so state
# that grows on its own can't live there — moved under /mnt/data/AppData like every
# other service's state. Settings below are jupiter-only; services/containers.nix
# stays engine/host-agnostic (mercury runs podman with no array).
# podman: CI images dominate and keep growing — the gitea runner's
# act-latest is 1.7G, and the act-22.04 label in services/dev/gitea.nix
# pulls another ~1.7G the first time a job requests it.
# runroot stays on /run: it is per-boot tmpfs state, not a growing store.
# runroot stays on /run (per-boot tmpfs, doesn't grow); graphroot moves to the array
# since the gitea runner's CI images alone run several GB.
virtualisation.containers.storage.settings.storage = {
driver = "overlay";
graphroot = "/mnt/data/AppData/containers/storage";
runroot = "/run/containers/storage";
};
# immich's postgres cluster. Version component mirrors the upstream default
# (`/var/lib/postgresql/${psqlSchema}`) so a major bump gets its own dir
# instead of silently reusing the old cluster's files.
# ⚠️ This puts the DB in the SAME failure domain as the photos it indexes:
# /mnt/data is RAID0, so either 16TB disk now loses both, where before an
# eMMC failure and an array failure each took only one. Chosen deliberately
# — the two are useless apart — but neither is backed up.
# immich's postgres cluster. Version-qualified path (matches upstream default) so a
# major bump gets a fresh dir instead of reusing the old cluster's files.
# ⚠️ Puts the DB in the same RAID0 failure domain as the photos it indexes —
# deliberate (the two are useless apart) but neither is backed up.
services.postgresql.dataDir =
"/mnt/data/AppData/postgresql/${config.services.postgresql.package.psqlSchema}";
# /mnt/data/AppData is drwx--x--- darman:users, so postgres needs group
# "users" just to TRAVERSE into its own dataDir — exactly the reason immich
# has the same line. The cluster dir itself keeps the mode it was initdb'd
# with (0750 postgres:postgres) — postgres only accepts 0700, or 0750 when
# the cluster was created with group access, and refuses to start otherwise.
# /mnt/data/AppData is drwx--x--- darman:users, so postgres needs the "users" group
# just to traverse into its dataDir (same reason immich needs it) — postgres itself
# refuses to start unless the cluster dir is 0700 or 0750.
users.users.postgres.extraGroups = [ "users" ];
# Neither path is under /var/lib, so no module creates it: the postgresql
# module's own tmpfiles entry only adjusts a dataDir that already exists,
# the same way immich's mediaLocation rule does.
# Neither path is under /var/lib, so no module creates it automatically — same
# reason immich needs its own mediaLocation tmpfiles rule.
systemd.tmpfiles.rules = [
"d /mnt/data/AppData/postgresql 0750 postgres postgres -"
"d /mnt/data/AppData/containers 0700 root root -"
];
# graphroot is not a systemd path dependency the way dataDir is, so nothing
# derives a mount ordering from it. Without these, podman would recreate an
# empty store on the eMMC under the mountpoint when the array is late or
# absent, and the runner would re-pull every image into it.
# (podman-clonarr already carries this from services/media/clonarr.nix.)
# Without this, podman would recreate an empty store on the eMMC if the array mounts
# late or is absent, and the runner would re-pull every image.
# (podman-clonarr already sets this in services/media/clonarr.nix.)
systemd.services.podman.unitConfig.RequiresMountsFor = [ "/mnt/data" ];
systemd.services.gitea-runner-jupiter.unitConfig.RequiresMountsFor = [ "/mnt/data" ];
hosts/jupiter/secrets.nix
+20 -37
View File
@@ -1,14 +1,8 @@
{ config, ... }:
# sops-nix secret wiring (real host only; not imported by vm.nix).
# Encrypted values live in ../../secrets/jupiter.yaml, decrypted at activation to
# /run/secrets/<name>.
#
# The host decrypts with its OWN SSH host key (age identity derived via
# ssh-to-age, recipient listed in ../../.sops.yaml). The key is pre-generated on
# the laptop and shipped once at install as /etc/ssh/ssh_host_ed25519_key
# (nixos-anywhere --extra-files) — so decryption works on boot #1 and there is
# no separate sops-only key to manage.
# sops-nix secret wiring (real host only; not imported by vm.nix). Decrypts with the
# host's own SSH host key (ssh-to-age), shipped once at install via nixos-anywhere
# --extra-files, so there's no separate sops-only key to manage.
{
sops.defaultSopsFile = ../../secrets/jupiter.yaml;
sops.age.sshKeyPaths = [ "/etc/ssh/ssh_host_ed25519_key" ];
@@ -26,18 +20,14 @@
# Headscale pre-auth key for tailscale auto-registration (see configuration.nix).
sops.secrets.tailscale_authkey = { };
# Immich's OIDC client secret, from its Authentik application (a SEPARATE
# app from headscale's and headplane's — see hosts/neptun/secrets.nix).
# Referenced as settings.oauth.clientSecret._secret in
# services/media/immich.nix; the module resolves it through systemd
# LoadCredential, which reads as root before dropping privileges, so the
# sops default of root:root 0400 is correct — do NOT set `owner`.
# Immich's OIDC client secret (separate Authentik app from headscale/headplane, see
# hosts/neptun/secrets.nix). Resolved via systemd LoadCredential as root before
# privilege drop, so sops's default root:root 0400 is correct — do NOT set `owner`.
sops.secrets.immich_oauth_client_secret = { };
# Gitea Actions runner registration token (services/dev/gitea.nix). Gitea
# generates this itself once Actions is enabled — it is not a password
# chosen up front. Rendered into a `TOKEN=...` env file because
# gitea-actions-runner takes an EnvironmentFile, not a raw secret path.
# Gitea Actions runner registration token — gitea generates this itself once Actions
# is enabled. Rendered into an env file since gitea-actions-runner takes an
# EnvironmentFile, not a raw secret path.
sops.secrets.gitea_runner_token = { };
sops.templates."gitea-runner.env".content =
"TOKEN=${config.sops.placeholder.gitea_runner_token}";
@@ -53,15 +43,11 @@
owner = "gitea";
};
# SABnzbd credentials (web UI login, API keys, eweka.nl usenet server) —
# migrated off the reused ini in services/media/sabnzbd.nix into
# services.sabnzbd.settings + secretValues. sabnzbd_api_key predates this
# migration (provisioned for mediamanager's future use, services/experimental/
# mediamanager.nix — not currently imported by any host); reused here as the
# same single source of truth rather than duplicating it.
# owner = sabnzbd: the module's preStart (replace-secret) runs as the
# service's own User=/Group=, and sops secrets default to root:root 0400 —
# without this, replace-secret gets Permission denied reading /run/secrets.
# SABnzbd credentials (web UI login, API keys, eweka.nl usenet server) for
# services/media/sabnzbd.nix; sabnzbd_api_key is shared with
# services/experimental/mediamanager.nix rather than duplicated.
# owner = sabnzbd because the module's preStart runs as that user, and sops secrets
# default to root:root 0400.
sops.secrets.sabnzbd_web_username.owner = "sabnzbd";
sops.secrets.sabnzbd_web_password.owner = "sabnzbd";
sops.secrets.sabnzbd_api_key.owner = "sabnzbd";
@@ -69,15 +55,12 @@
sops.secrets.sabnzbd_eweka_username.owner = "sabnzbd";
sops.secrets.sabnzbd_eweka_password.owner = "sabnzbd";
# CouchDB admin account for Obsidian LiveSync
# (services/dev/obsidian-livesync.nix). Rendered into an [admins] ini
# fragment rather than passed as services.couchdb.adminPass, which would put
# the plaintext in the world-readable store.
#
# owner = couchdb on BOTH: couchdb re-reads its ini chain as its own
# User=/Group= after systemd drops privileges, and sops defaults to
# root:root 0400 — without this it comes up with no admin configured, which
# under require_valid_user means every request 401s.
# CouchDB admin account for Obsidian LiveSync — rendered into an [admins] ini
# fragment instead of services.couchdb.adminPass, which would put the plaintext in
# the world-readable store.
# owner = couchdb on both: couchdb re-reads the ini as its own user after privilege
# drop, and without this sops's default root:root 0400 leaves it with no admin
# configured (every request 401s).
sops.secrets.couchdb_admin_password.owner = "couchdb";
sops.templates."couchdb-admins.ini" = {
owner = "couchdb";
hosts/mars/configuration.nix
+9 -12
View File
@@ -25,13 +25,12 @@
boot.loader.systemd-boot.enable = true;
boot.loader.efi.canTouchEfiVariables = true;
# jupiter's samba share (services/network/samba.nix) — mounted on demand so
# mars doesn't stall boot/login when jupiter is off or unreachable. This is
# also where Hermes's shared dropbox lives now (hermes-agent.nix). Modes are
# tighter than terra's equivalent mount (0770 not 0755, gid=hermes not
# gid=users) since the hermes-agent container (uid 986, gid 983 — no podman
# userns remapping, see services/network/pihole.nix) needs group write into
# it, not just darman.
# jupiter's samba share (services/network/samba.nix), mounted on demand so
# mars doesn't stall when jupiter is off — also where Hermes's shared
# dropbox lives (hermes-agent.nix). Tighter modes than terra's equivalent
# mount (0770/gid=hermes, not 0755/gid=users) since the hermes-agent
# container (uid 986/gid 983, no podman userns remapping) needs group
# write here, not just darman.
fileSystems."/mnt/jupiter" = {
device = "//jupiter/data";
fsType = "cifs";
@@ -43,11 +42,9 @@
"dir_mode=0770"
"nofail"
"x-systemd.automount" # lazy-mount so boot doesn't stall if jupiter's down
# NO idle-timeout here (unlike terra's equivalent mount): hermes-agent's
# podman-hermes-agent.service RequiresMountsFor this path, so an idle
# auto-unmount tears the container down with it — confirmed the hard
# way, it killed the service ~60-70s after every start with no crash
# or error, just "Unmounting /mnt/jupiter" right before the stop.
# NO idle-timeout here (unlike terra's): podman-hermes-agent.service
# RequiresMountsFor this path, so an idle auto-unmount silently kills
# the container with it — confirmed the hard way (~60-70s per start).
"x-systemd.mount-timeout=10s"
"_netdev"
];
hosts/mars/hermes-agent.nix
+159 -317
View File
@@ -1,83 +1,45 @@
{ config, pkgs, ... }:
# Hermes Agent — moved here from jupiter (hosts/jupiter/hermes-agent.nix,
# see its git history / b5fa599 / 713d91d for the terra->jupiter->mars
# lineage). mars is dedicated to this one service, on-site, with no big
# data array of its own — unlike jupiter it has nothing under /mnt/data, so
# state lives on the local OS disk and the shared dropbox rides jupiter's
# samba share as a CIFS client instead of being served locally.
# Hermes Agent runs on mars, which has no big data array — state lives on the
# local OS disk, and the shared dropbox reaches jupiter's array as a CIFS
# client instead of being served locally.
#
# Runs the OFFICIAL published image (docker.io/nousresearch/hermes-agent —
# real and actively maintained, contrary to what the checked-out repo's own
# README/docker-compose.yml suggested; verified directly on Docker Hub) as a
# plain podman container. It never sets HERMES_MANAGED or writes .managed, so
# Hermes fully self-manages config.yaml, profiles, memories and skills at
# runtime — no redeploy needed except to bump the pinned digest below.
# Runs the official docker.io/nousresearch/hermes-agent image (verified on
# Docker Hub) as a plain podman container. It never sets HERMES_MANAGED, so
# Hermes fully self-manages config.yaml, profiles, memories and skills.
#
# Security posture:
# - Reachable paths: its own local state dir, the small shared "dropbox"
# (via the jupiter samba mount) for darman to hand files to Hermes, and
# `git`/`tea`, logged in as the `luna` gitea account (PR-tier only —
# see services/dev/gitea.nix). No working copy of this repo is
# provisioned for her: an earlier version cloned one into
# ${hermesHome}/workspace/homelab, dropped again because nothing ever
# told her at runtime where it was (she self-manages config/profiles/
# memories, so a host-side path in this file never reached her) — she
# searched /opt/data/homelab and /workspace, found neither, and
# concluded she had no repo at all. She can clone one herself if she
# wants; the credentials below are what actually grants the access.
# Nothing else on jupiter's array or the host is reachable if a
# command goes wrong or gets injected via Telegram/tool output.
# - Its own Telegram bot (own token, in secrets.nix) with an EXPLICIT
# TELEGRAM_ALLOWED_USERS.
# - Runs as a rootful podman container (services/containers.nix) with its
# OWN numeric uid/gid — not darman, who is in the "hermes" group for
# host-level debugging only (`hermes ...` alias below, needs sudo since
# the container itself runs under root's podman, not darman's rootless
# one).
# - git/tea access is direct CLI, not a narrow wrapper: darman explicitly
# chose this over a purpose-built MCP server (tried first, scrapped —
# see git history) in favor of simplicity. The backstop is entirely
# server-side: gitea's branch protection on `master` (only darman can
# push/merge/approve there) is what actually keeps a bad or injected
# command from reaching the base branch, not anything client-side here.
# Security posture: reachable paths are only Hermes's own state dir, the
# shared dropbox, and git/tea as the PR-tier `luna` gitea account (see
# services/dev/gitea.nix) — no working copy of this repo is provisioned, and
# nothing else on jupiter's array or host is reachable if a command goes
# wrong or gets injected via Telegram/tool output. It runs its own Telegram
# bot with an explicit TELEGRAM_ALLOWED_USERS, and as a rootful podman
# container under its own uid/gid (not darman's). git/tea access is direct
# CLI rather than a wrapper; the real backstop is server-side gitea branch
# protection on `master` (only darman can push/merge/approve), not anything
# client-side here.
#
# Dashboard (HERMES_DASHBOARD=1) is gated behind Authentik, same setup as on
# jupiter. Its default bind (0.0.0.0:9119) fails closed without an auth
# provider registered, and 0.0.0.0 (not loopback) is required so neptun's
# Caddy can reach it over tailscale0 — reachability itself stays LAN-closed
# (no networking.firewall.allowedTCPPorts entry; tailscale0 is already a
# trustedInterface, services/vpn/tailscale.nix). Public route: neptun's
# hermes.mgaction.town vhost (hosts/neptun/configuration.nix) proxies to this
# over the tailnet. mars's own Caddy (luna-sites.nix) only serves luna's apps
# and has no vhost for this — reach the dashboard directly via mars's tailnet
# name (mars.orbit.sol:9119) or LAN IP:9119 for local debugging.
# Dashboard (HERMES_DASHBOARD=1) is gated behind Authentik like jupiter's; it
# fails closed without a registered auth provider. Binds 0.0.0.0:9119 (not
# loopback) so neptun's Caddy can reach it over tailscale0, but stays
# LAN-closed since there's no firewall rule opening it — reach it directly at
# mars.orbit.sol:9119 or via the public hermes.mgaction.town vhost on neptun.
# Uses upstream's generic self-hosted OIDC plugin against the same Authentik
# application (slug `hermes`) as before.
#
# Uses upstream's generic self-hosted OIDC plugin, same Authentik
# application as before (slug `hermes`) — the client ID/secret didn't need
# to change since the public redirect URI (hermes.mgaction.town) didn't.
#
# Data migration: this starts with a FRESH state dir. jupiter's instance was
# itself reset to fresh on 2026-08-21 (see its old hermes-agent.nix), so
# there was nothing irreplaceable to carry forward; if that turns out to be
# wrong, jupiter's old data is backed up at
# /mnt/data/AppData/hermes.bak-2026-08-21 and can be rsynced into
# ${hermesHome} below before the first switch on mars.
# Starts with a fresh state dir — jupiter's instance was already reset to
# fresh on 2026-08-21, so nothing needed carrying forward. Its old data is
# backed up at /mnt/data/AppData/hermes.bak-2026-08-21 if that's ever wrong.
let
stateDir = "/var/lib/hermes";
hermesHome = "${stateDir}/.hermes";
# Shared drop-in folder: darman can put files here from any host. Lives on
# jupiter's array (reachable at /mnt/jupiter, the samba mount below) rather
# than locally, so it's the same physical location it always was — only
# the container reading it moved. Mounted under /opt/data so it falls
# inside Hermes's own sealed write-safe root (HERMES_WRITE_SAFE_ROOT=
# /opt/data) rather than a path its own tooling would treat as untrusted.
# Shared drop-in folder for darman to hand files to Hermes, on jupiter's
# array (CIFS mount below) rather than locally. Mounted under /opt/data so
# it's inside Hermes's own write-safe root (HERMES_WRITE_SAFE_ROOT).
dropboxDir = "/mnt/jupiter/AppData/hermes-dropbox";
# Pinned by digest (captured 2026-08-21 via `podman image inspect
# docker.io/nousresearch/hermes-agent:latest --format '{{.Digest}}'` on
# jupiter) rather than floating `:latest`, so a redeploy is reproducible —
# bumping Hermes is an explicit edit here, not silent drift on next pull.
# Pinned by digest (captured 2026-08-21 from jupiter) rather than floating
# :latest, so bumping Hermes is an explicit edit here, not silent drift.
hermesImage = "docker.io/nousresearch/hermes-agent@sha256:5342e518734a08f6c66b89b4262434813c28a77abbc59c230c8f1637df71a259";
# Kept identical to jupiter's instance purely so nothing else needs to
@@ -90,15 +52,10 @@ let
# is hers to make, anywhere inside HERMES_WRITE_SAFE_ROOT=/opt/data.
giteaHost = "git.mgaction.town";
# luna's webhook filters, mounted READ-ONLY below. They live in the nix store
# rather than being written into hermesHome because hermesHome IS
# HERMES_WRITE_SAFE_ROOT: a filter dropped there is a loop guard sitting
# inside the writable root of the agent it constrains, and she could edit
# it back out. Deleting it would fail closed (Hermes treats a missing
# script as "ignore"), but rewriting it to always-allow would silently
# restore the reply loop. Read-only from the store makes that impossible
# and keeps the guard versioned in git — same reasoning as the git/tea
# binaries mounted below.
# luna's webhook filters, mounted READ-ONLY from the nix store rather than
# written into hermesHome: that IS her write-safe root, so a writable copy
# would let her edit her own loop guard back out. A missing script fails
# closed (Hermes ignores it); read-only from the store rules out a rewrite.
prCommentFilter = pkgs.writeText "gitea-pr-comment-filter.py" (
builtins.readFile ./gitea-pr-comment-filter.py
);
@@ -106,13 +63,10 @@ let
builtins.readFile ./gitea-pr-review-filter.py
);
# The route prompts. These are NOT mounted into the container: the route
# config below embeds them as strings, and jq reads them from these store
# paths host-side with --rawfile. Keeping them in files rather than inline
# nix strings is still what makes that work — they are ~60 lines of markdown
# full of apostrophes and {placeholders} that would otherwise have to
# survive nix string escaping on the way into a shell command. --rawfile
# crosses all of that untouched, and they stay diffable in git.
# Route prompts: not mounted into the container, but embedded as strings by
# the route config below via jq --rawfile, which lets ~60 lines of markdown
# full of apostrophes/{placeholders} skip nix string escaping and stay
# diffable in git.
prCommentPrompt = pkgs.writeText "gitea-pr-comment-prompt.md" (
builtins.readFile ./gitea-pr-comment-prompt.md
);
@@ -126,88 +80,55 @@ let
prCommentEvents = [ "issue_comment" ];
prReviewEvents = [ "pull_request_comment" "pull_request_rejected" ];
# Toolsets granted to both routes' agent runs.
#
# Hermes defaults webhook runs to a deliberately narrow set (web_search,
# web_extract, vision_analyze, clarify) because a webhook payload is
# third-party content. That default cannot clone, edit or push, so neither
# prompt was executable under it: the run would be woken, read the comment,
# and have no way to act on it.
#
# This list REPLACES the platform default for these routes rather than
# merging with it, so anything the default provided has to be re-listed —
# "web" is here for that reason, not because the prompts ask for research.
#
# Upstream's stated boundary is that `hermes webhook subscribe` has no
# --toolsets flag, so "an agent creating its own subscription at runtime
# cannot self-grant terminal". That boundary does NOT hold here and must not
# be relied on: webhook_subscriptions.json lives under /opt/data, which is
# HERMES_WRITE_SAFE_ROOT, so luna can edit her own grant — she already did
# once, which is why this moved into nix. What this buys is that the grant
# is deliberate, reviewable and re-asserted on every restart, not that it is
# unforgeable. The real backstop stays server-side: gitea's branch
# protection on master.
# Toolsets granted to both routes' agent runs. Hermes's webhook default
# (web_search, web_extract, vision_analyze, clarify) has no shell/file/edit
# access, so neither prompt could act without this — and it REPLACES the
# default rather than merging, hence "web" being re-listed. luna could in
# principle self-grant via webhook_subscriptions.json (it's under her own
# HERMES_WRITE_SAFE_ROOT, and she has edited it before), so this only makes
# the grant reviewable and reasserted on restart, not unforgeable — the
# real backstop stays gitea's branch protection on master.
routeToolsets = [ "terminal" "file" "web" ];
# hermesHome as the CONTAINER sees it (the bind mount below). Anything
# written host-side that gets READ back inside the container must use this
# prefix, not hermesHome — see the credential.helper below, which was
# broken exactly that way from 3c1f3e5 until 2026-08-23.
# hermesHome as the CONTAINER sees it. Anything written host-side that gets
# READ back inside the container must use this prefix, not hermesHome.
containerHome = "/opt/data";
in
{
# Browsing convenience (ssh access to the bind-mounted local state) — does
# NOT touch the container, which keeps using HERMES_UID/GID above
# regardless of what's declared here.
# ssh browsing convenience only — the container still uses HERMES_UID/GID
# above regardless of this.
users.groups.hermes.gid = 983;
users.users.darman.extraGroups = [ "hermes" ];
# `hermes <args>` on mars == `sudo podman exec -it hermes-agent hermes <args>`.
# sudo is required: virtualisation.oci-containers runs rootful (system)
# podman, a separate namespace from darman's own rootless `podman`/`docker`
# — darman's "hermes"/"docker" group membership only grants filesystem
# access to the bind-mounted state dir, not to root's container socket.
# `hermes <args>` == `sudo podman exec -it hermes-agent hermes <args>`. sudo
# is needed because oci-containers runs rootful podman, a separate
# namespace from darman's own rootless one.
programs.zsh.shellAliases.hermes = "sudo podman exec -it hermes-agent hermes";
systemd.tmpfiles.rules = [
"d ${stateDir} 0750 root hermes -"
];
# podman requires the bind-mount source to already exist (no auto-create),
# and the dropbox lives on the CIFS mount below — mkdir there works fine
# over cifs, no server-side (jupiter) config needed.
# podman needs the bind-mount sources to exist first; the dropbox lives on
# the CIFS mount below, which is fine to mkdir into directly.
#
# Also provisions luna's git/tea access: writes a git credential-store file
# and runs `tea logins add` INTO hermesHome (i.e. paths that appear at
# /opt/data/... once the container is up). Both run on the HOST as root,
# before the container starts, and both therefore have to chown what they
# write themselves — see the chown at the end of the script. Do NOT assume
# the image's cont-init fixes ownership under hermesHome: it does not
# recurse into what this oneshot drops there, even though it runs after it.
# Also provisions luna's git/tea access as root, before the container
# starts, and chowns what it writes itself — the image's cont-init only
# fixes ownership of hermesHome's top level, not what this oneshot drops
# into it. No longer clones the repo for her (see the header); the version
# that did left a stale ${hermesHome}/workspace/homelab that this does not
# clean up.
#
# It deliberately does NOT clone the repo for her any more (see the
# header). The stale ${hermesHome}/workspace/homelab left behind by the
# version that did is not cleaned up here either — it just stops being
# managed, and stops being updated. Remove it by hand if you want it gone.
#
# Delete-then-add for the tea login (not a "does it exist" check): tea can
# leave a login entry behind even when `add` reports failure (e.g. a token
# missing a scope errors out AFTER the entry is written — observed
# directly against the real instance during the first version of this
# setup). Delete-then-add is idempotent either way and picks up a rotated
# Delete-then-add for the tea login, not an existence check: tea can leave
# a login entry behind even when `add` itself reports failure, so
# delete-then-add is the only idempotent option and picks up a rotated
# token for free.
#
# `tea logins add` is the ONLY step in here that touches the network, and
# ordering is what makes it survivable. switch-to-configuration restarts
# NetworkManager and starts this unit in the SAME pass: on 2026-09-11 the
# two landed in the same second, tea's connect went out over an interface
# that was still coming back, and the kernel spent 2m48s on SYN retries
# before reporting "connection timed out". That failed this unit, which
# podman-hermes-agent Requires=, so a five-second network blip took the
# whole container down and returned 4 from the deploy. Hence
# network-online.target below, the bounded reachability probe in the script,
# and TimeoutStartSec as the backstop — no single blocking call in here may
# outlive the deploy that started it.
# `tea logins add` is the only network call here, and ordering matters:
# switch-to-configuration restarts NetworkManager in the same pass as this
# unit, and on 2026-09-11 that raced badly enough to hang the unit for
# minutes and take the whole container down. Hence network-online.target,
# the bounded probe below, and TimeoutStartSec as a backstop.
systemd.services.hermes-agent-prepare-dirs = {
description = "Create Hermes state dirs + luna's git/tea access before the container starts";
before = [ "podman-hermes-agent.service" ];
@@ -218,16 +139,13 @@ in
path = [ pkgs.git pkgs.tea pkgs.curl pkgs.coreutils ];
serviceConfig.Type = "oneshot";
# Everything here is either local or bounded to ~30s by the probe loop, so
# anything past two minutes is a hang, not slowness. Failing at that point
# is strictly better than holding the deploy open.
# anything past two minutes is a hang, not slowness.
serviceConfig.TimeoutStartSec = "120";
script = ''
mkdir -p ${hermesHome}
mkdir -p ${dropboxDir}
# Parent for the read-only filters bind-mounted at
# /opt/data/scripts/gitea-pr-*-filter.py. /opt/data is itself a bind
# mount of hermesHome, so this directory has to exist HOST-side before
# podman can mount a file inside it.
# Parent dir for the read-only filters bind-mounted below; must exist
# host-side first since /opt/data is itself a bind mount of hermesHome.
mkdir -p ${hermesHome}/scripts
export HOME=${hermesHome}
@@ -241,25 +159,18 @@ in
install -m 0600 /dev/null ${hermesHome}/.git-credentials
printf 'https://luna:%s@${giteaHost}\n' "$(cat "$token_file")" \
> ${hermesHome}/.git-credentials
# containerHome, NOT hermesHome: git reads this .gitconfig from INSIDE
# the container, where the host path does not exist. Nothing host-side
# consumes these credentials any more (the clone that used to is gone),
# so the container's view is the only one that has to be right.
# containerHome, not hermesHome: git reads this .gitconfig from inside
# the container, and nothing host-side needs it any more.
git config --global credential.helper "store --file=${containerHome}/.git-credentials"
git config --global user.name "luna"
git config --global user.email "luna@${giteaHost}"
# Probe before touching the login, with a hard per-attempt timeout: a
# bare TCP connect to an interface that is still coming up hangs for
# ~3 minutes on kernel SYN retries, and tea has no timeout flag of its
# own. /api/v1/version is unauthenticated, so this says "is gitea
# reachable", never "is the token good" — the token is the add's job.
#
# Probing FIRST (rather than retrying the add) is what protects the
# login that is already there. delete-then-add is not atomic: an add
# that fails because the network is down leaves luna with no login at
# all, strictly worse than the stale-but-working one we started with.
# Unreachable therefore means skip the refresh entirely and warn.
# A bare TCP connect to an interface still coming up can hang ~3min on
# kernel SYN retries, and tea has no timeout flag, so probe first with a
# hard per-attempt timeout. /api/v1/version is unauthenticated (tests
# reachability only). Probing before touching the login (rather than
# retrying the add) protects it: delete-then-add isn't atomic, so an add
# that fails on a down network would leave luna with no login at all.
gitea_up=0
for attempt in 1 2 3; do
if curl -fsS --max-time 5 -o /dev/null "https://${giteaHost}/api/v1/version"; then
@@ -271,42 +182,29 @@ in
done
if [ "$gitea_up" = 1 ]; then
# Reachable but the add still fails == a real problem (revoked or
# under-scoped token, gitea rejecting the login), and that stays
# fatal: it is a config error, it will not fix itself on the next
# boot, and it should be loud.
# Reachable but still failing means a real problem (revoked/under-
# scoped token) — stays fatal since it won't fix itself on reboot.
tea logins delete luna 2>/dev/null || true
GITEA_SERVER_TOKEN="$(cat "$token_file")" timeout 60 tea logins add \
--name luna --url "https://${giteaHost}" --no-version-check
else
# Deliberately not fatal. Every other thing this unit does is local,
# and podman-hermes-agent Requires= it — failing here would take
# Telegram and the dashboard down over a transient blip. luna keeps
# git (the credential helper above needs no network to be written)
# and loses only the tea CLI until the next start re-runs this.
# Not fatal: everything else here is local, and podman-hermes-agent
# Requires= this unit — failing here would take Telegram/dashboard
# down over a transient blip instead of just the tea CLI.
echo "WARNING: ${giteaHost} unreachable; left luna's tea login untouched." >&2
fi
# Hand everything written above to the container's uid/gid. This does
# NOT happen by itself: the image's cont-init only chowns hermesHome's
# top level and its own state, so root-owned 0600 files dropped here by
# this oneshot (.git-credentials, and tea's config.yml — tea writes it
# 0600 too) are simply unreadable to uid ${hermesUid}. Symptom is not an
# error but an absence: git reports no credential helper and tea reports
# no login, i.e. "they're missing". Confirmed on the real instance
# 2026-08-23 — cont-init ran AFTER these files were written and left
# them root-owned regardless.
# Hand written files to the container's uid/gid: the image's cont-init
# only chowns hermesHome's top level, so root-owned files dropped here
# (confirmed on 2026-08-23) are otherwise unreadable to Hermes.
#
# `if`, not `[ -d x ] && chown`: this script runs under `set -e`, where
# a false test as the left side of an && list takes the whole list's
# non-zero status and aborts the unit.
# `if`, not `[ -d x ] && chown`: this script runs under `set -e`, and a
# false test on the left of && would abort the whole unit.
chown ${hermesUid}:${hermesGid} \
${hermesHome}/.gitconfig \
${hermesHome}/.git-credentials
# Same cont-init caveat as the files above: the directory is created
# here as root, and Hermes reads its scripts as uid ${hermesUid}. The
# mounted filters themselves are world-readable 0444 from the store, so
# only the directory needs handing over.
# Same cont-init caveat: this dir is created as root, and Hermes reads
# scripts as uid ${hermesUid}.
chown ${hermesUid}:${hermesGid} ${hermesHome}/scripts
if [ -d ${hermesHome}/.config ]; then
@@ -330,25 +228,18 @@ in
"${hermesHome}:/opt/data"
"${dropboxDir}:/opt/data/dropbox"
# luna's Obsidian vault, kept in sync with CouchDB on jupiter by
# livesync-bridge.nix. Under /opt/data so it lands inside
# HERMES_WRITE_SAFE_ROOT and she can write notes, not just read them —
# same reasoning as the dropbox above. The bridge runs as this very
# uid/gid, so no ownership fixup is needed on either side.
# luna's Obsidian vault, synced with CouchDB on jupiter by
# livesync-bridge.nix. Under /opt/data so she can write notes, not just
# read them; the bridge runs as this same uid/gid so no chown is needed.
"/var/lib/livesync-bridge/vault:/opt/data/vault"
# git/tea for luna: the image doesn't ship `tea` (and shouldn't be
# trusted to have a known-good `git` either), so both come from this
# host's Nix store instead — mounted read-only at fixed PATH-visible
# locations. /nix/store itself has to come along too since both
# binaries are dynamically linked against paths inside it; the store
# is read-only content-addressed build output, not a source of
# secrets, so mounting the whole thing read-only costs nothing beyond
# the two specific binaries actually being reachable.
# Read-only: see prCommentFilter above. Hermes resolves route scripts
# under ~/.hermes/scripts, which is /opt/data/scripts in here. The route
# prompts are NOT mounted — they are embedded in the route config the
# unit below writes, so nothing inside the container reads them.
# git/tea for luna: the image ships neither (and its own git shouldn't
# be trusted), so both come from this host's Nix store, read-only.
# /nix/store must come along too since both binaries are dynamically
# linked against it.
# Filters mounted read-only (see prCommentFilter above), where Hermes
# resolves route scripts (~/.hermes/scripts). Prompts are NOT mounted —
# they're embedded directly in the route config the unit below writes.
"${prCommentFilter}:/opt/data/scripts/gitea-pr-comment-filter.py:ro"
"${prReviewFilter}:/opt/data/scripts/gitea-pr-review-filter.py:ro"
@@ -361,16 +252,12 @@ in
HERMES_GID = hermesGid;
TZ = "Europe/Berlin";
# Point git/tea at the config the prepare-dirs oneshot wrote into
# hermesHome (visible here as /opt/data/...) — the credential-store
# helper, the luna gitea login, and (implicitly, via HOME not being
# overridden) darman's Hermes state stays wherever it already was.
# Points git/tea at the config prepare-dirs wrote into hermesHome
# (visible here as /opt/data/...).
GIT_CONFIG_GLOBAL = "/opt/data/.gitconfig";
XDG_CONFIG_HOME = "/opt/data/.config";
# HERMES_TIMEZONE is the highest-priority source hermes_time.py checks
# (ahead of config.yaml's `timezone` key) — the container has no host
# /etc/localtime bind-mount, so it defaults to UTC otherwise (fixed in
# 9403122 on jupiter; carried forward here).
# Highest-priority source hermes_time.py checks; without it the
# container defaults to UTC (no /etc/localtime bind-mount).
HERMES_TIMEZONE = "Europe/Berlin";
# Dashboard + Authentik OIDC gate — see the file-level comment above.
@@ -378,14 +265,11 @@ in
HERMES_DASHBOARD_HOST = "0.0.0.0"; # must be tailscale0-reachable, not just loopback
HERMES_DASHBOARD_OIDC_ISSUER = "https://auth.mgaction.town/application/o/hermes/";
HERMES_DASHBOARD_OIDC_CLIENT_ID = "4BqdJu3htnMtSZnyEu5zHnsSOvlEbw3Ie3mYVlh6";
# uvicorn's proxy_headers=True (web_server.py) only trusts
# X-Forwarded-Proto from forwarded_allow_ips, which defaults to
# 127.0.0.1 — neptun's Caddy reaches this over the tailnet (a real
# routed IP), so without this the dashboard sees the raw scheme (http)
# and builds an http:// redirect_uri that Authentik rejects against its
# registered https:// one. Safe to trust any peer here: 9119 is already
# scoped to loopback + tailscale0 only (no LAN firewall rule), so
# nothing untrusted can reach this process to begin with.
# uvicorn only trusts X-Forwarded-Proto from forwarded_allow_ips
# (default 127.0.0.1); neptun's Caddy reaches this over a real routed
# tailnet IP, so without this it builds an http:// redirect_uri that
# Authentik rejects. Safe to trust any peer: 9119 is already scoped to
# loopback + tailscale0 only.
FORWARDED_ALLOW_IPS = "*";
};
environmentFiles = [ config.sops.templates."hermes-agent.env".path ];
@@ -401,35 +285,19 @@ in
unitConfig.RequiresMountsFor = [ "/mnt/jupiter" ];
};
# The two Gitea webhook routes, written as config rather than created with
# `hermes webhook subscribe`.
# The two Gitea webhook routes, written as config (not via `hermes webhook
# subscribe`, which has no --toolsets flag — see routeToolsets above).
# Gitea posts directly to Hermes with X-Hub-Signature-256 and
# X-GitHub-Event, which is what Hermes validates against and reads the
# event name from.
#
# Gitea posts straight at Hermes (jupiter's gitea-hermes-webhook-provision
# registers one hook per route at http://mars.orbit.sol:8644/webhooks/<name>)
# — there is no relay in between. Gitea's addDefaultHeaders sends
# X-Hub-Signature-256 in GitHub's exact format AND X-GitHub-Event,
# unconditionally, for every webhook type, which is precisely what Hermes
# validates and reads the event name from.
# Written host-side into hermesHome (bind-mounted at /opt/data), so the
# webhook adapter hot-reloads it on the next delivery — no container
# restart needed.
#
# WHY NOT `hermes webhook subscribe`: it has no --toolsets flag, and without
# a toolset override a webhook run gets Hermes's constrained default
# (web_search, web_extract, vision_analyze, clarify) — no shell, no file
# access, so neither prompt below can actually be carried out. Upstream's
# documented answer is to write the `toolsets` key into
# webhook_subscriptions.json by hand. Doing that by hand does not survive
# this unit, which re-provisions on every start, so the whole route
# definition moves here instead and the CLI is not used at all. See
# routeToolsets above for what that costs.
#
# This writes the file HOST-side. hermesHome is bind-mounted at /opt/data,
# so the container sees the same inode, and the webhook adapter hot-reloads
# the file (mtime-gated) on the next delivery — no container restart, and no
# `podman exec` quoting chain between nix and the prompt text.
#
# Events are WIRE names (X-GitHub-Event). Gitea spells the same events three
# different ways and two of the spellings collide — from
# HookEventType.Event() in modules/webhook/type.go, and updateHookEvents in
# routers/api/v1/utils/hook.go for the api column:
# Events below are WIRE names (X-GitHub-Event), not the api names
# gitea.nix's hooks use — gitea spells the same events three ways and two
# spellings collide:
#
# HookEventType wire name (here) api name (gitea.nix)
# --------------------------- ---------------------- --------------------
@@ -439,46 +307,31 @@ in
# pull_request_review_rejected pull_request_rejected pull_request_review
# pull_request_review_approved pull_request_approved pull_request_review
#
# Hermes matches these against X-GitHub-Event, i.e. the WIRE name. So
# "pull_request_comment" HERE means a review and "issue_comment" HERE means
# a comment — the exact inversion of how they read. X-GitHub-Event-Type
# carries the HookEventType, but Hermes does not look at it. This file and
# services/dev/gitea.nix therefore name the same event differently on
# purpose; neither is a typo.
# So "pull_request_comment" HERE means a review and "issue_comment" HERE
# means a comment — neither this file nor gitea.nix has a typo.
#
# The api column is not a third alias but a coarser set: HasEvent
# (models/webhook/webhook.go) collapses all three review types onto
# pull_request_review, so the gitea hook cannot subscribe them separately.
# Approvals arrive here as a result and are dropped by NOT being in
# prReviewEvents — Hermes answers {"status": "ignored"} on the event match,
# before the filter script and before any LLM call. Widening to approvals is
# a mars-side change only: add "pull_request_approved" to prReviewEvents and
# "pull_request_review_approved" to the filter's ALLOWED_REVIEW_TYPES.
# api names collapse all three review types onto pull_request_review, so
# approvals can't be subscribed separately — they arrive here and are
# dropped by omission from prReviewEvents. Widen by adding
# "pull_request_approved" here and to the filter's ALLOWED_REVIEW_TYPES.
#
# issue_comment on the wire covers comments on plain issues too; the hook
# does not subscribe those, and the comment filter's is_pull check drops
# them anyway if the hook is ever widened.
# issue_comment on the wire also covers plain-issue comments; the comment
# filter's is_pull check drops those if the hook is ever widened.
#
# deliver is "log", not a chat target: both prompts tell her to answer in
# the pull request, so the PR comment IS the delivery.
# deliver is "log", not a chat target — both prompts answer directly in the
# pull request.
#
# `script` is the selection that MUST NOT be retunable at runtime.
# gitea-pr-comment-filter.py drops luna's own comments before any LLM call,
# which is what stops the reply loop: the prompt tells her to answer on the
# PR, and her answer is itself a pull_request_comment. Both filters are
# bind-mounted read-only from the store above so the agent cannot edit her
# own guard out. Hermes resolves the name relative to ~/.hermes/scripts,
# hence the bare filename.
# `script` must not be retunable at runtime: the filter drops luna's own
# comments before any LLM call (what stops the reply loop, since her PR
# answer is itself a pull_request_comment), and is mounted read-only so she
# can't edit her own guard out.
#
# What read-only does NOT buy: it protects the sources, and this unit
# re-asserts prompt, filter, events and toolsets from them on every start,
# so a restart restores the intended config. The live file is inside the
# agent's own write-safe root, so a self-modification sticks until this unit
# next runs.
# Read-only protects the source only — this unit re-asserts prompt, filter,
# events and toolsets on every start, so a live self-modification only
# sticks until the next restart.
#
# Routes this unit does not name are left alone (the merge below is
# per-key), so retiring an old one stays a deliberate one-off:
# sudo podman exec hermes-agent hermes webhook remove <name>
# Routes not named here are left alone (the merge below is per-key);
# retire one with `sudo podman exec hermes-agent hermes webhook remove <name>`.
systemd.services.hermes-agent-webhook-routes = {
description = "Write Hermes's Gitea webhook route config";
wantedBy = [ "multi-user.target" ];
@@ -504,26 +357,19 @@ in
tmp="$conf.new"
trap 'rm -f "$tmp"' EXIT
# --slurpfile below cannot read a file that does not exist. Creating it
# empty is safe: this only ever happens before the first run, when there
# are no routes to lose. If it exists but is not valid JSON, slurpfile
# fails the unit loudly and leaves it untouched, which is the right
# direction — better a failed unit than silently discarded routes.
# --slurpfile needs the file to exist; empty is safe pre-first-run.
# Invalid JSON fails the unit loudly and leaves it untouched — better a
# failed unit than silently discarded routes.
[ -e "$conf" ] || printf '%s\n' '{}' > "$conf"
# The secret reaches jq via --rawfile, never argv: /proc/<pid>/cmdline
# is world-readable, so `--arg secret "$(cat ...)"` would publish it to
# every user on the box for the lifetime of the process. Same reason the
# prompts come in by path rather than by value.
#
# sops stores this one without a trailing newline (see secrets.nix), but
# rtrimstr is kept anyway: a stray newline would silently change the key
# the HMAC is computed with and fail every delivery afterwards.
#
# The emptiness guards are load-bearing. Without them a truncated secret
# file or an unreadable prompt yields "", and the route is written with
# an empty secret — which fails EVERY signature check while the unit
# still reports success.
# Secret goes to jq via --rawfile, never argv (cmdline is world
# readable) — same reason the prompts come in by path, not value.
# sops stores this without a trailing newline, but rtrimstr guards
# against one anyway: it would silently change the HMAC key.
# The emptiness guards are load-bearing: without them a truncated
# secret or unreadable prompt yields "", and the route is written with
# an empty secret that fails every signature check while reporting
# success.
jq -n \
--slurpfile existing "$conf" \
--rawfile rawSecret "$SECRET_FILE" \
@@ -547,12 +393,9 @@ in
deliver: "log",
toolsets: $toolsets };
# created_at is cosmetic (hermes webhook list prints it) and is the
# one key carried over from whatever is already there, so it keeps
# reading as when the route first appeared rather than as the last
# deploy. Everything else is replaced outright: a leftover key from
# an earlier definition — or from a hand edit — would otherwise
# survive here forever.
# created_at is cosmetic and the only key carried over from any
# existing route; everything else is replaced outright so a
# leftover key from an earlier definition can't survive here.
def upsert($name; $r):
.[$name] = ($r + { created_at: (.[$name].created_at // (now | todate)) });
@@ -566,10 +409,9 @@ in
$reviewEvents; $reviewPrompt; "gitea-pr-review-filter.py"))
' > "$tmp"
# 0600 because the file holds the HMAC secret in cleartext, and owned by
# the container's uid because Hermes rewrites it itself whenever anything
# calls `hermes webhook subscribe`. mv is an atomic rename within the
# same directory, so a delivery landing mid-write never reads a half
# 0600: holds the HMAC secret in cleartext. Owned by the container's
# uid since Hermes rewrites this file itself on `webhook subscribe`.
# mv is an atomic rename, so a delivery mid-write never sees a half
# written config.
chmod 0600 "$tmp"
chown ${hermesUid}:${hermesGid} "$tmp"
hosts/mars/livesync-bridge.nix
+49 -71
View File
@@ -1,59 +1,47 @@
{ config, pkgs, inputs, ... }:
# livesync-bridge (vrtmrz) — mirrors an Obsidian LiveSync vault out of CouchDB
# on jupiter (services/dev/obsidian-livesync.nix) into a real directory of
# markdown here, so luna can read and write the vault as files. Obsidian itself
# is an Electron GUI with no headless mode, and an agent wants files anyway.
#
# ⚠️ THE WRITE-BACK PATH IS THE RISKY ONE. Upstream has three open, unanswered
# issues on storage->couchdb — #50 (Jun 2026, writes detected and logged as
# uploaded, database never updated), #23 (only lowercase filenames transmitted
# from storage), #46 (silent stall on files over ~30KB). All fail QUIETLY: the
# log says success and the note never arrives. So do not treat this directory
# as durable storage for anything luna cannot regenerate, and check that her
# edits actually reach your devices before trusting it. (E2EE itself is fine —
# PeerCouchDB.ts hard-errors if a passphrase is missing for an encrypted
# remote, so it is a deliberate code path. The one issue claiming E2EE breaks
# bridging, #12, is a single unreproduced report with no maintainer reply.)
# on jupiter (services/dev/obsidian-livesync.nix) into real markdown files
# here, since Obsidian itself is a GUI-only Electron app and luna needs files.
#
# ⚠️ THE WRITE-BACK PATH IS THE RISKY ONE: upstream has open bugs where a
# write is logged as uploaded but the database is never updated (#50), only
# lowercase filenames sync from storage (#23), and files over ~30KB silently
# stall (#46) — all fail quietly with no error in the log. Don't treat this
# directory as durable for anything luna can't regenerate, and verify her
# edits actually reach your devices. (E2EE itself is fine — it hard-errors on
# a missing passphrase rather than failing silently.)
#
# EXPECTED NOISE ON FIRST SYNC: a stack trace per historically-deleted file —
# NotFound: ... remove '<vault>/Welcome.md' at PeerStorage.delete
# CouchDB keeps deletion tombstones, and the bridge replays them against a
# directory where the file never existed. PeerStorage.ts:33-40 catches it,
# logs, and returns false, so nothing is wrong; it only LOOKS fatal because
# main.ts pins the logger to LOG_LEVEL_DEBUG, which prints exception dumps
# that are otherwise verbose-level. It stops once the initial catch-up ends.
# Talks to CouchDB over the TAILNET (jupiter.orbit.sol:5984), not through
# neptun: mars is a tailnet node, so the public vhost, its TLS and its path
# allowlist are all irrelevant here.
# CouchDB replays deletion tombstones against a directory where the file
# never existed. Harmless, caught and logged, and stops once the initial
# catch-up ends.
#
# Talks to CouchDB over the tailnet (jupiter.orbit.sol:5984) directly — mars
# is a tailnet node, so neptun's public vhost/TLS/allowlist don't apply here.
let
stateDir = "/var/lib/livesync-bridge";
appDir = "${stateDir}/app";
vaultDir = "${stateDir}/vault";
# The same uid/gid the hermes-agent container runs as (hermes-agent.nix).
# Deliberate: the bridge and luna both read and write these files, and
# sharing one uid removes any dependence on the container's umask. Two
# different uids in a shared group only works while every file stays
# group-writable, and a single 0644 file dropped by the agent would stall
# sync on that path with nothing but a permission error in the log.
# The same uid/gid hermes-agent runs as (hermes-agent.nix), so both peers
# share files without depending on umask — two uids in a shared group only
# works while every file stays group-writable, and one 0644 file from the
# agent would silently stall sync.
hermesUid = 986;
# Which vault. `group` is what pairs the two peers — both must match or the
# bridge starts cleanly and simply never syncs anything.
# `group` pairs the two peers — mismatched and the bridge starts but never
# syncs.
#
# ⚠️ `database` must be the name entered in the Obsidian plugin for luna's
# vault. Get it wrong and nothing errors: the credential below is CouchDB's
# admin, so PouchDB CREATES the misnamed database and replicates an empty
# vault into it quite happily.
# ⚠️ `database` must match the name entered in the Obsidian plugin exactly:
# get it wrong and nothing errors, since the admin credential below lets
# PouchDB just create the misnamed database and replicate an empty vault.
peerGroup = "luna";
database = "luna_wiki";
in
{
# hermes-agent.nix declares the GROUP (gid 983) but no user: the container
# brings its own uid and needs no host account. The bridge does need one to
# run as, so the matching user is declared here.
# hermes-agent.nix declares the group (gid 983) but no user — the container
# needs no host account, but this service does, so it's declared here.
users.users.hermes = {
uid = hermesUid;
group = "hermes";
@@ -62,27 +50,23 @@ in
description = "Hermes agent uid, shared with the livesync-bridge service";
};
# Created here rather than by the service so they exist before anything
# tries to use them:
# - vaultDir before podman-hermes-agent starts, because a bind-mount
# source that does not exist is created by podman as root:root and the
# bridge then cannot write into its own vault;
# - appDir because WorkingDirectory applies to ExecStartPre as well, so a
# missing one fails the unit before preStart ever gets to create it.
# Created here, not by the service, so they exist before anything needs
# them: vaultDir before podman-hermes-agent starts (else podman creates it
# as root:root), and appDir before ExecStartPre runs (WorkingDirectory
# applies to it too).
systemd.tmpfiles.rules = [
"d ${vaultDir} 0770 hermes hermes -"
"d ${appDir} 0750 hermes hermes -"
"d ${stateDir}/deno 0750 hermes hermes -"
];
# The bridge's peer config, rendered by sops because it carries three
# secrets inline (CouchDB password + both passphrases) and the file format
# has no include mechanism.
# Rendered by sops (three inline secrets: CouchDB password + both
# passphrases; the json format has no include mechanism).
#
# ⚠️ sops substitutes placeholders into the ALREADY-RENDERED json, so a
# secret containing a double quote or a backslash produces an invalid config
# and the bridge logs "Could not parse configuration!" and then sits there
# with zero peers — it does not exit. Keep all three values alphanumeric.
# ⚠️ sops substitutes into the ALREADY-RENDERED json, so a secret with a
# quote or backslash yields invalid config — the bridge then just sits with
# zero peers logging "Could not parse configuration!" instead of exiting.
# Keep all three values alphanumeric.
sops.templates."livesync-bridge.json" = {
owner = "hermes";
content = builtins.toJSON {
@@ -96,11 +80,10 @@ in
username = "obsidian";
password = config.sops.placeholder.couchdb_luna_password;
passphrase = config.sops.placeholder.obsidian_luna_passphrase;
# The plugin derives path obfuscation from the same passphrase it
# uses for content, so this is the same secret. Split into its own
# field because the bridge takes them separately — if paths come
# back as garbage while contents decode fine, this is the field that
# is wrong.
# Same secret as the content passphrase — the plugin derives path
# obfuscation from it too, but the bridge takes them as separate
# fields. If paths come back as garbage while contents decode fine,
# this is the field to check.
obfuscatePassphrase = config.sops.placeholder.obsidian_luna_passphrase;
# Reads the chunking tweaks the plugin stored in the remote, instead
# of guessing sizes that then disagree with every other client.
@@ -137,22 +120,17 @@ in
HOME = stateDir;
};
# Copy the pinned source out of the store and install its locked deps.
# It cannot run from /nix/store directly: deno.jsonc sets
# `nodeModulesDir: manual` with byonm, so `deno install` must write a
# node_modules/ next to the sources.
# Copies the pinned source out of the store and installs locked deps,
# since deno.jsonc's `nodeModulesDir: manual` (byonm) needs to write
# node_modules/ next to the sources — it can't run from /nix/store directly.
#
# The copy target is a FIXED path on purpose. Deno keys localStorage —
# which is where the bridge records per-file sync state (Peer.ts:119) — by
# the main module's origin, and stores it under
# DENO_DIR/location_data/<sha of that origin>. VERIFIED by running the same
# source from two paths against one DENO_DIR: two separate origin dirs
# appear. Running straight from /nix/store would therefore change the
# origin on every input bump and silently reset the bridge to a full
# rescan of both peers.
# The copy target is a FIXED path on purpose: Deno keys its localStorage
# (where the bridge tracks per-file sync state) by the main module's
# origin, so running straight from /nix/store would change that origin —
# and reset the bridge to a full rescan of both peers — on every input bump.
#
# Guarded by a stamp file so this is a no-op on ordinary restarts; only a
# flake input bump pays for the re-install (which needs network).
# Guarded by a stamp file: a no-op on ordinary restarts, only a flake
# input bump pays for the (networked) re-install.
preStart = ''
set -eu
stamp=${stateDir}/.src
hosts/mars/luna-sites-test.nix
+3 -3
View File
@@ -29,9 +29,9 @@ let
cmd = [ "/bin/sleep" "infinity" ];
};
# The "app" luna builds on top of. No network in the VM, so it is loaded
# from the store instead of pulled. Runs under luna-apps, which has no
# /nix/store mount — hence the closure inside the image.
# The "app" luna builds on top of, loaded from the store since the VM has
# no network. Runs under luna-apps, which has no /nix/store mount — hence
# the closure baked into the image.
app = busyboxImage {
name = "testapp";
extraCommands = "mkdir -p www && echo hello > www/index.html";
hosts/mars/luna-sites.nix
+38 -54
View File
@@ -13,31 +13,22 @@
# /var/lib/luna-sites/live/<name>.caddy root-owned, imported by caddy
# /opt/data/sites-status.txt what was accepted, and why not
#
# Why a registry of {name, port} instead of letting her drop Caddyfile
# snippets: a snippet can proxy to anything on this box (the dashboard on
# 9119, the webhook listener on 8644, node-exporter) or file_server anything
# caddy can read, and one syntax error keeps caddy from coming up on the next
# boot. The generator only ever emits one fixed shape from a validated name
# and a port inside portMin..portMax, so none of that is expressible.
# A registry of {name, port}, not raw Caddyfile snippets from her: a snippet
# could proxy to anything on the box or break caddy on the next boot, while
# the generator only ever emits one validated shape.
#
# Why paths, not <name>.mars.sol: mars has no fixed DHCP lease, and a wildcard
# needs one. `address=/…/` takes an IP, and pihole-FTL's dnsmasq skips
# wildcard --cname entries outside authoritative zones (cache_reload():
# `if (a->alias[1] != '*' …)`). Moving to subdomains later only changes the
# fragment the generator writes; the registry format stays.
# Paths, not <name>.mars.sol: mars has no fixed DHCP lease, and pihole-FTL's
# dnsmasq can't wildcard-CNAME without one.
#
# Why a podman socket instead of ssh: what she needs is long-running processes
# OUTSIDE her own container (anything started inside it dies with the
# container, and sits next to her Telegram/gitea tokens). The socket gives
# exactly that and no host shell. It is not a strong boundary on its own —
# rootless podman socket access is code execution as luna-apps, which can read
# whatever that user can — but luna-apps owns nothing and cannot enter
# /var/lib/hermes (0750 root:hermes), so the apps cannot reach her tokens.
# A podman socket, not ssh: gives her long-running processes outside her own
# container (which dies on restart and holds her tokens) with no host shell.
# It's not a strong boundary by itself — socket access is code execution as
# luna-apps — but luna-apps can't enter /var/lib/hermes (0750 root:hermes), so
# her apps can't reach her tokens.
#
# She learns all this from a read-only README mounted at
# /opt/data/sites-README.md (luna-sites-README.md). She self-manages her
# memories, so nothing in this file reaches her otherwise — see the dropped
# repo clone in hermes-agent.nix's header for what happens when it doesn't.
# /opt/data/sites-README.md (luna-sites-README.md) — she self-manages her own
# memory, so nothing else in this file reaches her.
#
# VM test: nix build .#checks.x86_64-linux.luna-sites -L (luna-sites-test.nix)
let
@@ -77,29 +68,26 @@ in
isNormalUser = true;
inherit uid;
description = "luna's hosted web apps (rootless podman)";
# Nothing ever logs in as this user. Only its systemd user manager runs,
# kept up without a session by linger, which is what brings the podman
# socket and podman-restart back after a reboot.
# No interactive login; linger keeps its systemd user manager (and thus
# the podman socket) running across reboots without a session.
linger = true;
autoSubUidGidRange = true; # rootless podman's user namespace
hashedPassword = "!";
shell = "${pkgs.shadow}/bin/nologin";
};
# `--restart=always` containers only come back after a reboot through this
# unit — rootless podman has no daemon to remember them. The podman module
# already enables podman.socket for every user's manager; this one is
# scoped to luna-apps.
# Rootless podman has no daemon to bring `--restart=always` containers back
# after a reboot; the podman module enables this for every user, scoped
# here to luna-apps.
systemd.user.services.podman-restart = {
wantedBy = [ "default.target" ];
unitConfig.ConditionUser = user;
};
# ---- the socket luna's container talks to ----
# luna-apps's own socket lives under /run/user/1001 (0700), which the
# container's uid cannot enter. This re-exposes it to group hermes, and the
# proxy behind it runs as luna-apps, so it holds no access beyond the socket
# it forwards to.
# luna-apps's own socket lives under /run/user/1001 (0700), unreachable to
# the container's uid; this re-exposes it to group hermes via a proxy that
# itself runs as luna-apps, so it holds no more access than the socket.
systemd.sockets.luna-apps-podman = {
wantedBy = [ "sockets.target" ];
listenStreams = [ "${socketDir}/podman.sock" ];
@@ -124,9 +112,9 @@ in
# Merges into hermes-agent.nix's container definition.
virtualisation.oci-containers.containers.hermes-agent = {
volumes = [
# The directory, not the socket file: the socket is created by systemd
# at boot, and a file bind mount would pin whatever inode was there when
# the container started. Read-only still permits connect().
# Mounts the directory, not the socket file — a file bind mount would
# pin the inode present at container start, before systemd creates the
# socket. Read-only still permits connect().
"${socketDir}:${socketDir}:ro"
"${config.virtualisation.podman.package}/bin/podman:/usr/local/bin/podman:ro"
"${readme}:/opt/data/sites-README.md:ro"
@@ -163,16 +151,13 @@ in
description = "Turn luna's site registry into caddy routes";
# Also runs once at boot, for edits made while nothing was watching.
wantedBy = [ "multi-user.target" ];
# After caddy, so the reload below never races caddy's own start. Nothing
# orders caddy after THIS unit, which is what keeps the blocking
# `systemctl reload caddy` from waiting on its own start job.
# After caddy, so the reload below can't race caddy's own start; nothing
# orders caddy after this unit, so that reload never waits on its own.
after = [ "caddy.service" ];
# No start rate limit. The default (5 starts in 10s) is hit by nothing
# more than a handful of quick writes — the VM test does exactly that —
# and when it is, systemd also fails luna-sites.path for good
# (unit-start-limit-hit): every later registration is silently ignored
# until someone runs reset-failed. Bursts are absorbed by the debounce at
# the top of the script instead.
# No start rate limit: the default (5/10s) trips from just a handful of
# quick writes and permanently disables luna-sites.path (unit-start-
# limit-hit) until someone runs reset-failed. Bursts are absorbed by the
# script's own debounce instead.
startLimitIntervalSec = 0;
path = [ pkgs.jq pkgs.util-linux pkgs.diffutils config.services.caddy.package ];
# caddy validate wants somewhere to write its data/config dirs.
@@ -195,9 +180,9 @@ in
script = ''
set -euo pipefail
# Everything that touches luna's tree runs as the container's uid, never
# as root: she controls every path under it, including swapping one for
# a symlink into /etc between a check here and its use.
# Runs as the container's uid, never root — she controls every path
# under it, including swapping one for a symlink between a check here
# and its use.
as_luna() { setpriv --reuid=${hermesUid} --regid=${hermesGid} --clear-groups -- "$@"; }
if [ ! -d ${hermesHome} ]; then
@@ -313,15 +298,14 @@ in
publish_report
}
# Debounce: writes usually come in bursts (several files, or an editor's
# write-then-rename), and every trigger that lands while this oneshot
# is still activating merges into this same start job instead of
# queuing another. One second collapses a burst into one run.
# Debounce: any trigger landing while this oneshot is still activating
# merges into the same start job, so one second collapses a burst of
# writes (several files, an editor's write-then-rename) into one run.
sleep 1
# That merging also means an entry written mid-run would otherwise wait
# for the next unrelated change. Compare the registry before and after,
# and go again. Bounded, so a writer in a loop cannot pin the unit.
# That same merging means an entry written mid-run would otherwise wait
# for the next unrelated trigger, so compare the registry before/after
# and rerun if it changed — bounded, so a writer in a loop can't pin it.
for attempt in 1 2 3 4 5; do
before=$(entries)
generate
hosts/mars/secrets.nix
+26 -51
View File
@@ -22,25 +22,16 @@
password=${config.sops.placeholder.samba_password}
'';
# Hermes Agent (hermes-agent.nix) — moved here from jupiter (see that
# host's git history); same Telegram bot token, opencode key, and
# Authentik OIDC client secret, so no new bot/app to provision.
# Hermes Agent (hermes-agent.nix) — same Telegram bot token, opencode key,
# and Authentik OIDC client secret as it used before moving here from
# jupiter, so no new bot/app to provision.
sops.secrets.opencode_go_api_key = { };
sops.secrets.telegram_bot_token = { };
sops.secrets.hermes_dashboard_oidc_client_secret = { };
# Same value as in secrets/jupiter.yaml (the sending side), stored WITHOUT a
# trailing newline — a stray newline would change the key the HMAC is
# computed with and fail every delivery. `scripts/edit_secrets` writes a
# bare value. hermes-agent.nix trims one anyway, belt and braces.
#
# This is NOT in the container's env any more. It used to be, because
# hermes-agent-webhook-route ran `hermes webhook subscribe` inside the
# container and read the secret back out of its environment — which meant
# podman-hermes-agent had to be restarted first on rotation, or the
# subscription silently pinned the stale value. The route config is now
# written host-side (hermes-agent-webhook-routes reads this file directly),
# so that ordering constraint is gone and the secret no longer sits in an
# env var luna can read with `env`.
# Same value as secrets/jupiter.yaml (the sending side), stored WITHOUT a
# trailing newline — a stray newline would change the HMAC key and fail
# every delivery. Written host-side by hermes-agent-webhook-routes, so it
# no longer needs to sit in the container's env where luna could read it.
sops.secrets.gitea_hermes_webhook_secret = {
restartUnits = [ "hermes-agent-webhook-routes.service" ];
};
@@ -54,47 +45,31 @@
HERMES_DASHBOARD_OIDC_CLIENT_SECRET=${config.sops.placeholder.hermes_dashboard_oidc_client_secret}
'';
# luna's own gitea push token (services/dev/gitea.nix provisions the
# account + PR-tier repo access on jupiter; this is the per-user token
# generated once via `gitea admin user generate-access-token --username
# luna --scopes write:repository,read:user` on jupiter — read:user is
# required, `tea logins add` fails without it). Read directly by
# hermes-agent.nix's prepare-dirs oneshot (default root:root owner is
# fine — that oneshot already runs as root) to set up a git
# credential-store file and a `tea` login, both written into hermesHome
# so they're visible inside the container at /opt/data/....
# restartUnits re-provisions both on rotation, without a full mars deploy.
# luna's gitea push token (services/dev/gitea.nix provisions the account +
# PR-tier access), generated once via `gitea admin user generate-access-token
# --username luna --scopes write:repository,read:user` on jupiter — read:user
# is required or `tea logins add` fails. restartUnits re-provisions the git
# credential-store file and `tea` login on rotation, without a full deploy.
sops.secrets.gitea_luna_token.restartUnits = [ "hermes-agent-prepare-dirs.service" ];
# livesync-bridge (livesync-bridge.nix) — luna's Obsidian vault, mirrored
# out of CouchDB on jupiter. Both values are consumed by the rendered
# config.json rather than read directly, so the sops default of root:root
# 0400 is correct here; only the TEMPLATE needs an owner (set where it is
# defined, next to the vault path it references).
# from CouchDB on jupiter. Consumed only via the rendered config.json, so
# the sops default of root:root 0400 is fine here.
#
# couchdb_luna_password holds jupiter's `obsidian` ADMIN password — the same
# value as secrets/jupiter.yaml's couchdb_admin_password — and
# obsidian_luna_passphrase is the same passphrase as the personal vault.
# That is a deliberate choice to reuse what already existed, but it is worth
# being clear about what it costs: mars can decrypt and read EVERY vault
# database, not just luna's, and mars is the box running an autonomous
# agent. The two are independent to fix, cheapest first:
#
# 1. A vault-specific passphrase (re-encrypts luna's remote database, but
# leaves the personal vault's contents unreadable from here).
# 2. A CouchDB account scoped to luna's database via _security (three curl
# calls, in README -> "Obsidian vaults"), which also stops mars from
# reaching the other databases at all.
#
# Neither is required for the bridge to work; both shrink the blast radius
# if mars is ever compromised.
# ⚠️ couchdb_luna_password is jupiter's `obsidian` ADMIN password (same as
# secrets/jupiter.yaml's couchdb_admin_password) and obsidian_luna_passphrase
# reuses the personal vault's passphrase — reusing what already existed, but
# it means mars (running an autonomous agent) can decrypt and read EVERY
# vault database, not just luna's. To shrink that blast radius: give luna's
# vault its own passphrase, and/or scope a CouchDB account to her database
# via _security (README -> "Obsidian vaults"). Neither is required for the
# bridge to work.
sops.secrets.couchdb_luna_password = { };
# The E2EE passphrase for luna's vault, as entered in the Obsidian plugin.
# Vault passphrases otherwise never leave the clients (see the note in
# services/dev/obsidian-livesync.nix) — this one has to be here because mars
# IS a client: it decrypts in order to write real markdown to disk. Path
# obfuscation uses the same passphrase in the plugin, so the bridge's
# separate obfuscatePassphrase field is fed from this one value.
# Vault passphrases otherwise never leave the clients (obsidian-livesync.nix)
# — this has to be here because mars IS a client, decrypting to write real
# markdown to disk. Also feeds the bridge's separate obfuscatePassphrase
# field, since the plugin derives path obfuscation from the same value.
sops.secrets.obsidian_luna_passphrase = { };
}
hosts/mercury/configuration.nix
+8 -9
View File
@@ -16,26 +16,25 @@
networking.hostName = "mercury";
# ---- Static networking ----
# A DNS/DHCP server must have a fixed address. Fill in the Pi's real values
# (from `ip -brief a` / `ip route` on the running Pi). eth0 = the Pi's NIC.
# A DNS/DHCP server needs a fixed address (values from `ip -brief a` / `ip
# route` on the running Pi; eth0 is its NIC).
networking.useDHCP = false;
networking.usePredictableInterfaceNames = false; # keep it named eth0
networking.interfaces.eth0.ipv4.addresses = [
{ address = "10.0.0.10"; prefixLength = 24; } # the Pi's current IP
];
# Stable IPv6 (FRITZ!Box ULA prefix) so mercury is a fixed IPv6 DNS target.
# SLAAC still provides the GUA + default route. Announce THIS address as the
# DNSv6 server in the FRITZ!Box so IPv6 clients resolve .sol via pihole.
# Stable IPv6 (FRITZ!Box ULA prefix) so mercury is a fixed IPv6 DNS target —
# SLAAC still handles the GUA + default route. Announce this address as the
# FRITZ!Box's DNSv6 server so IPv6 clients resolve .sol via pihole.
networking.interfaces.eth0.ipv6.addresses = [
{ address = "fd18:df17:9078:0::10"; prefixLength = 64; }
];
networking.defaultGateway = { address = "10.0.0.1"; interface = "eth0"; };
networking.nameservers = [ "1.1.1.1" "9.9.9.9" ];
# Never take the tailnet's DNS on THIS host: headscale points every node at
# pihole, which runs here — mercury would be resolving through itself. Keep
# the public resolvers above for the Pi's own lookups, exactly as the
# unbound resolveLocalQueries note in CLAUDE.md requires.
# Never take the tailnet's DNS here: headscale points every node at pihole,
# which runs on this host, so mercury would resolve through itself — keep
# the public resolvers above for its own lookups.
services.tailscale.extraUpFlags = [ "--accept-dns=false" ];
# ---- pihole web admin password (from sops) ----
hosts/mercury/secrets.nix
+4 -5
View File
@@ -2,11 +2,10 @@
# sops-nix wiring for mercury. Encrypted values in ../../secrets/mercury.yaml.
#
# SD images have no `--extra-files` step, so mercury uses a DEDICATED age key
# placed on the ROOT filesystem (the Pi's vfat partition isn't mounted at
# runtime — u-boot reads it pre-boot). `./deploy flash mercury <dev>` drops
# ~/.config/homelab/mercury/age.txt there automatically.
# The key never enters the repo, the nix store, or the image itself.
# SD images get no `--extra-files` step, so mercury uses a dedicated age key
# on the root filesystem instead of the admin key — the Pi's vfat boot
# partition isn't mounted at runtime (u-boot reads it pre-boot), so the key
# can't live there.
{
sops.defaultSopsFile = ../../secrets/mercury.yaml;
sops.age.keyFile = "/var/lib/sops-nix/age.txt";
hosts/neptun/configuration.nix
+22 -62
View File
@@ -43,30 +43,19 @@
# default via fe80::1 dev eth0 metric 1024 onlink
networking.defaultGateway6 = { address = "fe80::1"; interface = "eth0"; };
networking.nameservers = [ "9.9.9.9" "1.1.1.1" "2620:fe::fe" ];
# Addressing is fully static above, but netcup's router still sends periodic
# RAs on this segment; the kernel then tries (and fails, since the static
# route already exists) to install its own default route from them, spamming
# "ndisc_router_discovery failed to add default route" on the console. Stop
# it from processing RAs on eth0 at all rather than just live with the noise.
# netcup's router still sends periodic RAs on this segment despite fully static
# addressing, spamming "ndisc_router_discovery failed to add default route" on the
# console. Stop processing RAs on eth0 entirely instead of living with the noise.
boot.kernel.sysctl."net.ipv6.conf.eth0.accept_ra" = 0;
# ---- Local split-DNS stub ----
# neptun must NOT take the tailnet's DNS: headscale points every node at
# pihole on mercury, and making a public reverse proxy's name resolution
# depend on a Pi behind a domestic line would take ACME renewals — and so
# the certs for the control server every node needs — down with it. It is
# also circular, since tailscaled has to resolve vpn.mgaction.town to
# connect in the first place.
#
# So neptun opts out with --accept-dns=false and does its own split DNS.
# tailscaled still answers MagicDNS on 100.100.100.100 whenever it is
# running (--accept-dns only governs whether it rewrites resolv.conf), so
# dnsmasq forwards just the tailnet suffix there and everything else to the
# public resolvers above. jupiter's address is therefore resolved live and
# never pinned — nothing to update when the tailnet is rebuilt.
#
# resolveLocalQueries (default) points resolv.conf at 127.0.0.1 and feeds
# networking.nameservers to dnsmasq as upstreams via resolvconf.
# neptun must NOT take the tailnet's DNS: headscale points every node at pihole on
# mercury, and a public reverse proxy depending on a Pi on a domestic line for name
# resolution (and thus for its own ACME renewals) would be fragile and circular.
# It opts out (--accept-dns=false) and runs its own split DNS instead: dnsmasq
# forwards the tailnet suffix to MagicDNS (100.100.100.100, still answered by
# tailscaled) and everything else to the public resolvers above — jupiter's address
# is resolved live, never pinned.
services.tailscale.extraUpFlags = [ "--accept-dns=false" ];
services.dnsmasq = {
enable = true;
@@ -112,49 +101,20 @@
'';
# ---- Obsidian LiveSync (CouchDB on jupiter) ----
# Obsidian's mobile apps refuse cleartext HTTP and *.jupiter.sol cannot hold
# a publicly trusted cert, so the vault database is published here instead of
# staying on the LAN. That means a credentialed database on the open
# internet; two things keep it sane:
# Published publicly (mobile apps refuse cleartext HTTP; *.jupiter.sol has no public
# cert), kept safe by the plugin's end-to-end encryption (jupiter stores only
# ciphertext) plus this allowlist — CouchDB otherwise exposes Fauxton, /_all_dbs and
# /_node/_local/_config, the last of which can rewrite the server's config with admin
# creds. Use the tailnet directly for those: `curl http://jupiter.orbit.sol:5984/_utils/`.
#
# 1. The plugin's end-to-end encryption, switched on BEFORE the first sync.
# jupiter then stores only ciphertext, so a breach here is not a leak of
# the notes themselves.
# 2. This allowlist. CouchDB serves far more than the replication API —
# Fauxton (/_utils), /_all_dbs, and /_node/_local/_config, the last of
# which REWRITES the server's config given admin credentials. Only the
# paths the plugin actually speaks are proxied; everything else is
# answered here and never reaches jupiter. Use the tailnet for the rest:
# `curl http://jupiter.orbit.sol:5984/_utils/`.
# The regex keys off CouchDB's own naming rule (system paths start with `_`, user
# databases can't) rather than listing vaults, plus `_session` for cookie auth — so a
# mistyped-but-legal name reaches CouchDB (real 404) while an illegal one gets
# caddy's 404 with no CORS, which Obsidian shows as a silent connection failure.
# Never point two vaults at the same database (LiveSync merges them, not reversibly).
#
# ONE DATABASE PER VAULT, and the matcher keys off CouchDB's own naming rule
# rather than listing them: every system endpoint begins with `_`, and a
# user-creatable database never can (CouchDB requires a lowercase letter
# first). So adding a vault needs no edit here. `_session` is the single
# underscore path let through, for cookie auth.
#
# The flip side of not listing them: a mistyped but otherwise LEGAL database
# name is proxied through and reaches CouchDB, which answers a real 404 the
# plugin can report. An ILLEGAL one — anything starting with a capital or an
# underscore — fails the matcher instead and gets caddy's 404, which carries
# no CORS headers and surfaces in Obsidian as a connection failure with no
# error message at all. If a new vault refuses to connect and the plugin
# says nothing, check the database name is lowercase first.
#
# Never point two vaults at one database: LiveSync merges them into a single
# file tree, which is not cleanly reversible.
#
# Known consequence: LiveSync's "Check database configuration" panel reads
# /_node/_local/_config and so reports the server as unconfigured from
# outside. Expected — that config is declarative in
# services/dev/obsidian-livesync.nix and is not the plugin's to patch.
#
# `flush_interval -1` is required, not tuning: replication rides a
# continuous _changes feed, which caddy would otherwise buffer — sync then
# stalls until the buffer fills (same reason vpn.mgaction.town sets it).
#
# No netcup edge-firewall change: this rides the 443 the other vhosts
# already use, unlike gitea's :2222.
# `flush_interval -1` is required, not tuning — replication rides a continuous
# _changes feed that caddy would otherwise buffer, stalling sync.
services.caddy.virtualHosts."notes.mgaction.town".extraConfig = ''
@livesync path_regexp ^/(_session|[a-z][a-z0-9_$()+-]*)?(/.*)?$
handle @livesync {
hosts/neptun/secrets.nix
+11 -18
View File
@@ -14,13 +14,11 @@
sops.secrets.darman_password.neededForUsers = true;
users.users.darman.hashedPasswordFile = config.sops.secrets.darman_password.path;
# Authentik takes a single systemd EnvironmentFile (services/identity/authentik.nix).
# No `owner` here on purpose: systemd reads EnvironmentFile as root before
# dropping to the service's DynamicUser, so root:root 0400 is what we want.
#
# AUTHENTIK_SECRET_KEY signs sessions/tokens — rotating it logs everyone out.
# The BOOTSTRAP_* vars only take effect on the very first start, where they
# create the `akadmin` superuser; they're inert on every boot after that.
# Authentik takes a single systemd EnvironmentFile (services/identity/authentik.nix);
# no `owner` here on purpose, since systemd reads it as root before dropping to
# DynamicUser. AUTHENTIK_SECRET_KEY signs sessions (rotating it logs everyone out);
# the BOOTSTRAP_* vars only matter on the very first start (create `akadmin`) and are
# inert after.
sops.secrets.authentik_secret_key = { };
sops.secrets.authentik_bootstrap_password = { };
sops.secrets.authentik_bootstrap_email = { };
@@ -38,17 +36,12 @@
ACME_EMAIL=${config.sops.placeholder.caddy_acme_email}
'';
# Headplane: cookie_secret_path takes a path natively (no store leak).
# oidc.client_secret + the headscale API key are still REPLACE_ME
# placeholders (see services/vpn/headplane.nix) until Authentik/headscale are
# actually deployed and those get created for real.
#
# owner: unlike authentik's EnvironmentFile above, headscale and headplane
# open these paths themselves, already running as the headscale user — so
# the root:root 0400 default would fail and each needs an explicit owner.
#
# headscale's OIDC client is a SEPARATE Authentik application from
# headplane's (services/vpn/headscale.nix), hence the second client secret.
# Headplane's cookie_secret_path takes a path natively (no store leak); oidc.client_secret
# and the headscale API key are still REPLACE_ME placeholders (services/vpn/headplane.nix)
# until Authentik/headscale are deployed for real. Unlike authentik's EnvironmentFile,
# headscale/headplane open these paths themselves as the headscale user, so each needs
# an explicit owner — and headscale's OIDC client is a separate Authentik app from
# headplane's, hence the second client secret.
sops.secrets.headscale_oidc_client_secret.owner = "headscale";
sops.secrets.headplane_cookie_secret.owner = "headscale";
hosts/terra/configuration.nix
+34 -75
View File
@@ -44,17 +44,9 @@ in
# https://nix.dev/permalink/stub-ld ----
programs.nix-ld.enable = true;
# The default set above is deliberately minimal and carries no X11,
# freetype, wayland or xkbcommon, so a prebuilt *graphical* binary dies
# before it draws anything. JetBrains IDEs installed through Toolbox are the
# case that surfaced this: their bundled JBR aborts with `libX11.so.6:
# cannot open shared object file` unless the Toolbox GUI — itself an FHS
# wrapper — is what launches them, which makes them unusable from a terminal
# or from a per-repo devShell. These are the libraries `ldd` reports missing
# across a JBR's own .so files, plus the three it resolves by dlopen rather
# than DT_NEEDED: fontconfig for font discovery, libGL, and libsecret for
# the credential store. Definitions merge, so this adds to the module's base
# list rather than replacing it (zlib is already there).
# JetBrains IDEs installed via Toolbox bundle a JBR that aborts with
# `libX11.so.6: cannot open shared object file` under the default (X11-less)
# nix-ld set. Additive — merges with the module's own base list (zlib etc).
programs.nix-ld.libraries = with pkgs; [
freetype
fontconfig
@@ -72,28 +64,19 @@ in
libxinerama
libxcb
# CLion Nova's C++ backend (the clion-radler plugin) is a .NET 10
# application bundling its own runtime, and .NET refuses to start
# without ICU: libSystem.Globalization.Native.so dlopens libicuuc.so
# and libicui18n.so, and failing that the IDE reports "Couldn't find a
# valid ICU package installed on the system" and comes up degraded.
# CLion Nova's C++ backend is a .NET 10 app that needs ICU or reports
# "Couldn't find a valid ICU package installed on the system".
icu
];
# ---- envfs: serves /bin and /usr/bin from the calling process's PATH ----
# NixOS ships only /bin/sh, but plenty of third-party tooling writes scripts
# with a hardcoded interpreter. JetBrains Toolbox is the standing example:
# it generates ~/.local/share/JetBrains/Toolbox/scripts/{clion,rider,...}
# with `#!/bin/bash`, so every one of those shims fails with `bad
# interpreter` in any shell. envfs resolves such shebangs against PATH,
# which fixes them all at once instead of per-IDE wrappers.
# NixOS only ships /bin/sh; envfs serves /bin and /usr/bin from PATH so
# third-party scripts hardcoding `#!/bin/bash` (e.g. JetBrains Toolbox's
# generated launchers) still resolve.
services.envfs.enable = true;
# ---- home-manager (user-level config for darman) ----
# Base settings (useGlobalPkgs/useUserPackages/backupFileExtension) and the
# shared zsh baseline now live in common.nix + home/common.nix, applied to
# every host. This just layers terra's desktop/dev-specific profile on top
# — home-manager.users.darman.imports merges additively across modules.
# Base settings + shared zsh baseline live in common.nix + home/common.nix
# (every host); this layers terra's desktop profile on top (imports merge).
home-manager.extraSpecialArgs = { inherit unstable inputs; };
home-manager.users.darman.imports = [ ./home.nix ];
@@ -102,71 +85,47 @@ in
boot.loader.efi.canTouchEfiVariables = true;
hardware.cpu.amd.updateMicrocode = true;
# mercury (aarch64) is built/flashed from here. Without this, `nix build`
# for it dies with "platform mismatch" — no qemu binfmt handler registered
# and aarch64-linux missing from nix.settings.extra-platforms. This module
# sets up both (see CLAUDE.md's aarch64 gotcha).
# Lets `nix build` target mercury (aarch64) from here — see CLAUDE.md's
# aarch64 gotcha.
boot.binfmt.emulatedSystems = [ "aarch64-linux" ];
# ---- GPU (Radeon RX 6800 XT / Navi 21) ----
hardware.enableRedistributableFirmware = true;
boot.initrd.kernelModules = [ "amdgpu" ];
# /dev/dri/renderD128 is root:render 0660, so rootless podman containers can
# only reach the GPU if the *host* user is in render. Needed by the Vulkan
# whisper.cpp/llama.cpp containers in ~/Data/Dev/repos/content-trigger-scanner.
# /dev/dri/renderD128 is root:render 0660 — host user needs render group for
# rootless podman GPU containers (Vulkan whisper.cpp/llama.cpp).
users.users.darman.extraGroups = [ "render" "video" ];
# ---- ollama (local LLM server, ROCm on the 6800 XT) ----
# Navi 21 is gfx1030 — officially supported by ROCm, so no
# rocmOverrideGfx/HSA_OVERRIDE_GFX_VERSION needed (that's for gpus ROCm
# doesn't recognize, e.g. RDNA1/gfx101x). The upstream module runs the
# service under DynamicUser with SupplementaryGroups=["render"] and
# DeviceAllow for char-kfd/char-drm/char-fb already, so unlike jellyfin's
# static user it needs no extraGroups wiring here.
# Navi 21 (gfx1030) is officially ROCm-supported, so no
# HSA_OVERRIDE_GFX_VERSION needed. Upstream module already runs under
# DynamicUser with render/kfd/drm access wired, unlike jellyfin's static user.
services.ollama = {
enable = true;
package = pkgs.ollama-rocm;
# keep in sync with services/desktop/librechat.nix's endpoints.custom
# default model — LibreChat's config schema needs a non-empty default
# even though fetch=true replaces it with whatever's actually pulled.
# gemma4:12b: general chat/coding daily driver, fits fully in 16G VRAM —
# also doubles as the memory-extraction agent (see librechat.nix): a
# 3b model (llama3.2:3b, dropped) couldn't reliably tell the user's
# stated facts apart from its own boilerplate, e.g. saving "I am an AI
# assistant with tool calling capabilities" as the user's personal_info
# after "Hi I'm Erik Simon". Reusing gemma4:12b for both roles also means
# no second model needs to swap into VRAM while it's already the active
# chat model.
# qwen3.6:35b-a3b: MoE (3B active/36B total), ~24GB Q4_K_M — doesn't fit
# in VRAM alone, so ollama offloads the inactive experts to CPU RAM.
# Sparse activation makes that far less painful than it'd be for a dense
# model this size, but still expect it to run slower than the two above.
# VladimirGav/qwen3.8-27B-14GB-IQ4: dense 27B at IQ4, ~14GB of weights —
# nominally fits the 6800 XT's 16G, but that leaves only ~2G for the KV
# cache and the compositor, so expect partial CPU offload as context grows
# (OLLAMA_CONTEXT_LENGTH below applies to every model on this server).
# keep default model in sync with services/desktop/librechat.nix's
# endpoints.custom default (its schema needs a non-empty value even
# though fetch=true overrides it).
# gemma4:12b: daily-driver chat/coding model, fits fully in 16G VRAM; also
# doubles as LibreChat's memory-extraction agent (librechat.nix) since a
# smaller model confused the user's stated facts with its own boilerplate.
# qwen3.6:35b-a3b: MoE (3B active/36B total, ~24GB Q4_K_M) — doesn't fit
# in VRAM alone, so ollama offloads inactive experts to CPU RAM; sparsity
# makes that less painful than for a dense model this size, but still slower.
# VladimirGav/qwen3.8-27B-14GB-IQ4: dense 27B at IQ4 (~14GB) — nominally
# fits the 16G card but leaves little headroom, so expect partial CPU
# offload as context grows.
loadModels = [
"gemma4:12b"
"qwen3.6:35b-a3b"
"VladimirGav/qwen3.8-27B-14GB-IQ4"
];
# Ollama truncates context far below the model's real window unless
# told otherwise (the OpenAI-compat /v1 route it's reached through has
# no way to set this per-request). 131072 chosen as the practical
# ceiling after load-testing with real prompts, not just idle
# `ollama ps` checks:
# 32768 (31.6k-token prompt) and 65536 (40.8k-token prompt) both stayed
# 100% GPU with VRAM barely moving (~10.1G / ~10.67G of 16G) — KV cache
# cost barely grows with context, likely sliding-window/local attention
# on most of gemma4:12b's layers. At 131072 that stopped being true: a
# ~108k-token prompt pushed VRAM to ~11.4G/16G (still 100% GPU, no CPU
# spillover, negligible GTT) but with visibly shrinking headroom, and
# prefill throughput measurably dropped (~490 -> ~460 tok/s) over just
# the last 13k tokens — filling the full window would take minutes of
# pure prompt processing. Stopped here rather than push further: next
# doubling would risk CPU spillover under any concurrent GPU load
# (desktop compositor, jellyfin transcode) for diminishing benefit.
# Ollama truncates context far below a model's real window unless told
# otherwise. 131072 is the practical ceiling from load-testing: VRAM stays
# 100% GPU with no CPU spillover up to here, but headroom and prefill
# throughput both degrade near the top — going higher risks CPU spillover
# under concurrent GPU load (compositor, jellyfin transcode) for little gain.
environmentVariables.OLLAMA_CONTEXT_LENGTH = "131072";
};
hosts/terra/disk-config.nix
+9 -23
View File
@@ -5,27 +5,14 @@
# `fileSystems.*` entries, so hardware-configuration.nix must NOT define
# fileSystems for "/" or "/boot".
#
# ⚠️ disko's `mkfs` create step SKIPS formatting when `blkid` still detects a
# filesystem signature on the freshly-cut partition:
#
# if ! (blkid "$device" -o export | grep -q '^TYPE='); then
# mkfs.btrfs "$device" -f # ← -f only runs WHEN this line runs
# fi
#
# The disk previously held a CachyOS btrfs root. The whole-disk `wipefs`
# disko runs before partitioning clears the signature at the OLD layout's
# offsets, but `sgdisk --clear --align-end` then re-cuts the partitions, so
# a stale btrfs superblock survives at the NEW root partition's own 64 KiB
# offset. `blkid` sees TYPE=btrfs, `mkfs` is skipped entirely, and the
# later `mount` fails on the leftover bytes ("wrong fs type / bad
# superblock"). Switching ext4→btrfs did NOT fix this: `mkfs.btrfs -f` is
# never reached, because the guard is on whether `mkfs` runs at all, not on
# its flags. The ESP hits the same trap (its `mkfs.vfat` gets skipped too).
#
# Fix: `preCreateHook = wipefs --all --force "$device"` on each partition's
# content. The hook runs AFTER sgdisk re-cuts the partition but BEFORE the
# `blkid` guard, so it erases the stale signature at the FINAL offset;
# `blkid` then comes back empty and `mkfs` actually runs.
# ⚠️ disko's `mkfs` step skips formatting if `blkid` still detects a
# filesystem signature on the partition. Repartitioning doesn't erase
# signatures at the new offsets, so this disk's old CachyOS btrfs
# superblock survived, causing mkfs (and the ESP's mkfs.vfat) to be
# skipped and the later mount to fail on the stale superblock.
# Fix: `preCreateHook = wipefs --all --force "$device"` on each
# partition — it runs after sgdisk re-cuts the partition but before the
# `blkid` guard, so the guard sees no signature and `mkfs` actually runs.
#
# ⚠️ This disk is WIPED on install. This is the Kingston SA400 SSD that
# currently holds CachyOS (btrfs root+subvols on sdb2, ESP on sdb1).
@@ -58,8 +45,7 @@
type = "btrfs";
extraArgs = [ "-f" ];
mountpoint = "/";
# erase the stale CachyOS btrfs superblock before disko's blkid
# format-guard, otherwise mkfs.btrfs is skipped (see header comment)
# same wipefs fix as the ESP above (see header comment)
preCreateHook = ''wipefs --all --force "$device"'';
};
};
hosts/terra/home.nix
+12 -20
View File
@@ -2,23 +2,17 @@
let
tome = pkgs.callPackage ../../pkgs/tome.nix { src = inputs.tome; };
# SUDO_ASKPASS helper: renders sudo's password prompt in the quickshell
# shell (HyprChrome/Widgets/Askpass) instead of on the terminal.
# SUDO_ASKPASS helper: shows sudo's password prompt in quickshell
# (HyprChrome/Widgets/Askpass) instead of the terminal. sudo doesn't speak
# polkit (setuid + PAM reading the tty), so this reuses the polkit dialog's
# look via the askpass mechanism instead — `run0` is the actual polkit-native
# alternative.
#
# sudo does NOT speak polkit — it is setuid + PAM reading the tty, and no
# sudoers option bridges the two — so this is the askpass mechanism, a
# separate path that happens to reuse the polkit dialog's look. `run0` is the
# polkit-native alternative if you want the agent itself.
# Must be a package, not a dotfiles file: SUDO_ASKPASS needs an executable,
# and xdg.configFile copies keep store-copy permissions.
#
# A package rather than a file in dotfiles/quickshell because SUDO_ASKPASS
# must point at something EXECUTABLE, and xdg.configFile copies keep their
# store mode — which is why open_launcher.sh has to be invoked as
# `bash <path>` rather than run directly.
#
# The secret comes back over a 0600 fifo, never in argv or the environment,
# so it is not visible in /proc to anything. Cancelling closes the fifo
# without writing: `cat` reads nothing, this exits non-zero, and sudo aborts
# instead of burning a retry on an empty password.
# The secret returns over a 0600 fifo (never argv/env, so not visible in
# /proc); cancelling closes the fifo unwritten so sudo aborts cleanly.
qs-askpass = pkgs.writeShellApplication {
name = "qs-askpass";
runtimeInputs = [ pkgs.quickshell pkgs.coreutils ];
@@ -74,11 +68,9 @@ in
nix-direnv.enable = true;
};
# Rootless podman: containers run as darman, not root. services/containers.nix
# gives us the `docker` CLI shim (dockerCompat), but compose v2 is a separate
# binary and talks to a socket rather than the CLI — the NixOS podman module
# enables the *user* socket (systemd.user.sockets.podman), so point compose at
# it instead of the root /var/run/docker.sock.
# Rootless podman runs containers as darman; compose v2 talks to a socket
# rather than the docker CLI shim, so point it at the user podman socket
# instead of the root one.
home.sessionVariables.DOCKER_HOST = "unix:///run/user/1000/podman/podman.sock";
# Only sets WHICH helper sudo uses; it still only calls it when asked with
hosts/terra/home/hyprland.nix
+15 -36
View File
@@ -1,32 +1,16 @@
{ lib, pkgs, config, inputs, ... }:
# Hyprland config migrated from github.com/darman96/hyprland-dotfiles (the
# hyprlang `hypr/*.conf` files) into the home-manager lua-style `settings`
# (configType defaults to "lua" on stateVersion 26.05). Each top-level
# `settings` attr becomes an `hl.<name>(...)` call in ~/.config/hypr/hyprland.lua;
# `_args` lists become multi-arg calls, `_var` locals become `local x = ...`, and
# `lib.generators.mkLuaInline` values render as raw Lua expressions.
# Hyprland config migrated from github.com/darman96/hyprland-dotfiles into
# home-manager's lua-style `settings` (each attr becomes an `hl.<name>(...)`
# call in hyprland.lua). Imported by home.nix; system-level enable lives in
# ../../services/desktop/desktop-hyprland.nix.
#
# Imported by home.nix. System-level Hyprland enable (session entry, portals)
# lives in ../../services/desktop/desktop-hyprland.nix; this manages the user's
# own hyprland.lua.
#
# Deliberately NOT migrated:
# - hyprbars.conf: config for the third-party `hyprbevelbars` plugin, which
# isn't packaged in nixpkgs. Load it via
# `wayland.windowManager.hyprland.plugins` and re-add its config once
# available. (hyprredsquare.conf's plugin was renamed hypr-chrome and
# rewritten since - it's wired in below via the `hypr-chrome` flake
# input instead, with its own `plugin.hyprchrome` config.)
# - hyprqt6engine.conf + `QT_QPA_PLATFORMTHEME=hyprqt6engine`: terra themes Qt
# through qtct/Dracula in home.nix, so that env var is left off to avoid a conflict.
# - hyprlock.conf: a separate program (use `programs.hyprlock` if wanted).
# - the duplicate pamixer/amixer + `.wob` volume binds: kept only the clean
# pipewire `wpctl`/`playerctl` set (no wob overlay is configured here).
# - `XDG_MENU_PREFIX=arch-` and `VCPKG_ROOT`: Arch-/user-specific.
# Many binds reference apps/scripts not packaged on terra yet (vivaldi-stable,
# dolphin, vicinae, grimblast, waypaper, discord, gitkraken, qbz,
# ~/.config/scripts/start-communications.sh); add them separately.
# Not migrated: hyprbars (unpackaged plugin; its successor hypr-chrome is
# wired in below instead), hyprqt6engine (conflicts with home.nix's qtct/
# Dracula Qt theming), hyprlock (use programs.hyprlock), the old wob volume
# overlay (kept only wpctl/playerctl), and Arch-specific env vars. Several
# binds reference apps not yet packaged here (vivaldi-stable, dolphin,
# vicinae, grimblast, waypaper, discord, gitkraken, qbz).
let
lua = lib.generators.mkLuaInline;
@@ -37,11 +21,9 @@ let
cursorName = config.home.pointerCursor.name;
cursorSize = toString config.home.pointerCursor.size;
# Wallpaper images aren't checked into this repo (binary blobs) — pulled
# from the existing Wallhaven library on /mnt/hdd_01 instead. Picked once
# here rather than at runtime, since hyprpaper has no built-in "random"
# mode; re-pick and rebuild (or swap in real per-monitor selection) when
# this stops being a placeholder.
# Wallpapers aren't checked into this repo (binaries) — pulled from the
# Wallhaven library on /mnt/hdd_01. Picked once here since hyprpaper has
# no built-in "random" mode.
# wallpaper = "/mnt/hdd_01/data/Pictures/Wallhaven/wallhaven-ym81rl.png";
wallpaper = "/mnt/hdd_01/data/Pictures/Wallhaven/wallhaven-mlwz78.png";
@@ -317,11 +299,8 @@ in
"hyprland.start"
(lua ''
function()
-- No polkit agent is started here: quickshell registers one
-- itself (HyprChrome/Widgets/Polkit), and a session admits only
-- one. The hyprpolkitagent line this replaces had been dead for
-- a while anyway — the unit was never installed, so the start
-- failed silently and the session ran with no agent at all.
-- No polkit agent started here: quickshell registers its own
-- (HyprChrome/Widgets/Polkit), and a session admits only one.
hl.exec_cmd("cosmic-settings-daemon")
hl.exec_cmd("quickshell")
hl.exec_cmd("alacritty", { workspace = "special:terminal silent" })
hosts/terra/home/theme.nix
+8 -13
View File
@@ -23,14 +23,11 @@ in
};
};
# The cursor theme. XCURSOR_THEME alone is not enough for Steam: the client
# UI (steamwebhelper) runs inside a pressure-vessel container that rebuilds
# /etc, so the /etc/profiles/per-user/darman/share/icons entry of
# XCURSOR_PATH does not exist in there and libXcursor finds no theme by
# that name — it falls back to the built-in core X11 cursor. $HOME and
# /nix are bind-mounted into the container, so the ~/.icons symlink that
# `dotIcons` (on by default) drops does resolve. Same class of problem as
# the ~/.themes/~/.icons flatpak workaround above.
# XCURSOR_THEME alone isn't enough for Steam: steamwebhelper runs inside a
# pressure-vessel container with its own /etc, so XCURSOR_PATH doesn't
# resolve there and it falls back to the core X11 cursor. $HOME and /nix are
# bind-mounted in though, so the ~/.icons symlink `dotIcons` drops still
# resolves — same fix as the flatpak workaround below.
home.pointerCursor = {
name = "Bibata-Modern-Classic";
package = pkgs.bibata-cursors;
@@ -39,11 +36,9 @@ in
hyprcursor.enable = true;
};
# Flatpak apps are sandboxed and can't see XDG_DATA_DIRS/nix-store theme
# paths, so the portal-reported GTK theme / icon theme names resolve to
# nothing inside the sandbox and they fall back to Adwaita. Flatpak
# auto-exposes ~/.themes and ~/.icons read-only to every sandboxed app
# specifically for this case.
# Flatpak apps can't see XDG_DATA_DIRS/nix-store theme paths, so the
# portal-reported theme names resolve to nothing and fall back to Adwaita;
# Flatpak auto-exposes ~/.themes and ~/.icons read-only as the workaround.
home.file.".themes/Dracula".source =
"${pkgs.dracula-theme}/share/themes/Dracula";
home.file.".icons/${iconTheme}".source = iconThemeFolder;