Archiviert am 17.09.2026. Dieses Repository wird nicht mehr deployt. Die Konfiguration ist aufgeteilt in drei eigenständige Repos: tnix (Origin ~/tnix auf tnix, Mirror auf pinix-cgit), pinix (git@git.lukasrosier.com:pinix.git) und blunix (ssh://forgejo@blunix:2222/lukas/blunix.git). Ein nixos-rebuild aus diesem Stand würde alte Secrets, Routen und Dienste zurückbringen. Ablauf und Zuordnung: Plan.md, docs/repo-split-inventar.md.

NixOS-Plattform-Konfiguration

Ein deklaratives NixOS-Konfigurationsrepository zur Verwaltung einer Multi-Host-Plattforminfrastruktur mit Nix-Flakes und home-manager.

Übersicht

Dieses Repository stellt eine vollständige NixOS-Konfiguration für drei unterschiedliche Host-Typen in einer einheitlichen Plattform bereit:

• tnix: Desktop-/Laptop-System (x86_64-linux) mit Hyprland-Desktop
• pinix: Raspberry-Pi-System (aarch64-linux) für verteilte Dienste
• blunix: Server-System (x86_64-linux) für Webdienste und Kerninfrastruktur

Diese drei Hosts, zusammen mit dem Wireguard-Mesh und dem LDAP/Dex-Login, die sie verbinden, sind das Infrastruktur-Fundament. Auf diesem Fundament erfüllt die Plattform drei Zwecke:

1. Interne Kommunikation — XMPP/Prosody: Chat, Gruppen-MUCs, Benachrichtigungen.
2. Externe Kommunikation — das Fediverse: GoToSocial + Phanpy (ActivityPub, öffentlich föderiert).
3. Datenaustausch und Lagerung — Websites, Datei-Server (WebDAV/SMB), Git-Hosting (Forgejo), Kalender/Aufgaben (Radicale, Vikunja): alles, was Daten hält oder austauscht statt Nachrichten überträgt.

Alles, was über diese drei Pfeiler und ihr Fundament hinausgeht, ist bewusst optional und einzeln abschaltbar (siehe localServices/default.nix je Host).

Weitere, eigenständig betriebene Hardware kann dem Tailnet beitreten und eigene Dienste über die bestehende Traefik-/Dex-Schicht einbringen, ohne Teil dieses Flakes zu werden — die drei Pfeiler oben bleiben davon unberührt. Beispiel: fastpi, ein separat betriebenes DietPi-Gerät mit eigenen Diensten (u. a. Audiobookshelf, Mealie, Trek), das per Tailnet-IP in Traefik-Routen und Dex-Clients auftaucht, aber kein nixosConfigurations-Ziel dieses Repos ist.

Features

• Deklarative Konfiguration: alles als Code über Nix-Flakes definiert
• Multi-Architektur-Unterstützung: Cross-Compilation für ARM- und x86_64-Systeme
• Secret-Management: verschlüsselte Secrets über agenix
• Modulare Dienste: wiederverwendbare Service-Module über alle Hosts hinweg
• User-Environment-Management: deklarative Nutzerkonfigurationen mit home-manager
• Globale Konfiguration: zentrale Domain- und Variablenverwaltung

Architektur

Verzeichnisstruktur

├── hosts/                    # Host-spezifische Konfigurationen
│   ├── globalServices/       # Gemeinsame Dienste (SSH, Security, Pakete)
│   └── {hostname}/          # Individuelle Host-Konfigurationen
├── home/                    # Home-manager-Nutzerkonfigurationen
│   ├── globalModules/       # Gemeinsame User-Environment-Module
│   └── {username}/          # Nutzerspezifische Konfigurationen
├── secrets/                 # Verschlüsselte Secrets (agenix)
├── variables.nix           # Globale Domain-Konfiguration
└── variables-local.nix     # Persönliche Domain-Overrides (git-ignoriert)

Kerntechnologien

• NixOS: deklarative Linux-Distribution
• Nix-Flakes: reproduzierbares Paketmanagement
• Home-manager: User-Environment-Management
• agenix: Secret-Verschlüsselung und -Verwaltung
• Hyprland: Wayland-Compositor für den Desktop

Quick Start

Konfigurationen bauen

# Neue Konfiguration bauen und aktivieren
sudo nixos-rebuild switch --flake .#hostname

# Konfiguration testen (verwirft sich beim Reboot)
sudo nixos-rebuild test --flake .#hostname

# Auf entfernten Host deployen
nixos-rebuild switch --flake .#hostname --target-host hostname

Arbeits-Repository und Deployments

Der dauerhafte Administrations-Arbeitsplatz ist die codex-tmux-Sitzung auf blunix, unter /home/drone/nixos-config auf Branch dev. Damit bleibt die Sitzung verfügbar, während tnix ausgeschaltet ist.

nrsp steht weiterhin auf tnix für gewöhnliche lokale Builds zur Verfügung. Es baut die pinix-Konfiguration, kopiert den Nix-Closure auf den Raspberry Pi und aktiviert ihn:

nrsp

Die passenden Aliase sind nrst für tnix und nrsb für blunix.

Von blunix aus die AArch64-Konfiguration explizit im nixbuild.net-Remote-Store evaluieren und bauen:

nix build \
  --json \
  --eval-store auto \
  --store ssh-ng://eu.nixbuild.net \
  path:.#nixosConfigurations.pinix.config.system.build.toplevel

Den im JSON-Ergebnis gemeldeten Output-Pfad in den lokalen Nix-Store kopieren:

nix copy \
  --from ssh-ng://eu.nixbuild.net \
  /nix/store/<output-path>

Dann diesen Closure zu pinix kopieren und den exakten Store-Pfad aktivieren:

nix copy \
  --no-check-sigs \
  --to 'ssh-ng://pinix?remote-program=sudo%20nix-daemon' \
  /nix/store/<output-path>

nixos-rebuild switch \
  --no-reexec \
  --store-path /nix/store/<output-path> \
  --target-host pinix \
  --sudo

--no-check-sigs ist erforderlich: pinix' trusted-public-keys enthält den nixbuild.net-Signierschlüssel nicht, daher schlägt ein einfaches nix copy zu pinix mit „lacks a signature by a trusted key" fehl. --no-reexec ist bei nixos-rebuild erforderlich: ohne das versucht das Tool, sich selbst über <nixpkgs/nixos> via NIX_PATH neu zu bauen, bevor es --store-path beachtet — dieser Pfad ist auf diesem reinen Flake-System nicht eingerichtet.

Der Remote-Builder erhält den öffentlichen Flake-Quelltext und Build-Inputs. Niemals Klartext-Credentials im Repository oder in Derivation-Inputs ablegen; Secrets bleiben in agenix-Dateien, die nur auf dem Zielhost entschlüsselt werden.

Pinix hält außerdem einen aktuellen Checkout unter /home/drone/nixos-config für Recovery und optionale lokale Builds. Vor Nutzung mit einem Fast-Forward-Pull aktualisieren; der maßgebliche gemeinsame Branch ist Forgejos dev.

Lokale Infrastrukturwerte

Die eingecheckten Standardwerte liegen in variables.nix. Um die Konfiguration mit anderen Domains, Adressen oder LDAP-Benennung wiederzuverwenden, die git-ignorierte variables-local.nix anlegen:

{ ... }:
{
  domain = "example.org";
  domain2 = "example.net";
  adminEmail = "admin@example.org";
  ldapBaseDN = "dc=example,dc=org";
  publicIPv4 = "203.0.113.10";

  tailnetIPs = {
    blunix = "100.64.0.1";
    pinix = "100.64.0.2";
    dietpi = "100.64.0.3";
  };
}

Diese Werte sind Deployment-Metadaten, keine Credentials. Passwörter, API-Tokens, private Keys und OIDC-Client-Secrets bleiben in verschlüsselten agenix-Dateien.

Secrets verwalten

Das vollständige Inventar, Klartextformate, Empfänger und der Rotationsablauf sind in secrets/README.md dokumentiert.

# Verschlüsseltes Secret bearbeiten
agenix -e secrets/filename.age

# Secrets nach Key-Änderungen neu verschlüsseln
agenix -r

Flake-Operationen

# Alle Inputs aktualisieren
nix flake update

# Flake-Struktur anzeigen
nix flake show

VM-Boot-Checks

Der erste VM-Test prüft, dass die reale tnix-Konfiguration bis multi-user.target bootet. Er prüft bewusst keine Dienste, Netzwerk- oder Firewall-Regeln und keine Desktop-Session.

# Nur den tnix-Boot-Test ausführen
nix build .#checks.x86_64-linux.tnix-boot

# Alle Flake-Checks, einschließlich des Boot-Tests, ausführen
nix flake check

Weitere Boot-Tests folgen dem Muster in tests/tnix-boot.nix: Das Host-Modulset wird aus flake.nix übernommen, und das Testskript wartet nur auf das passende Systemziel. Weitergehende Dienst-, Netzwerk- oder Desktop-Prüfungen gehören als eigene, gezielt benannte Checks daneben.

Befehle

# WLAN manuell verbinden
sudo iwlist [INTERFACE] scan

oder in configuraion.conf

tnix

Keymaps in Neovim space fk

Roadmap

docs/roadmap.md hält die großen, konzeptionellen Richtungsfragen fest (VPS/IPv6, Abhängigkeitsreduktion als Ziel). Laufende Arbeit, gefundene Bugs und der Tagesstand stehen in der Git-History und den docs/intent/-Aufträgen, nicht mehr in einem separaten Sitzungslog.

Links

• Website
• Wiki
• Roadmap
• Repository-Übersicht
• Routing, DNS und An-/Abschalten von Diensten

Status

Aktive Entwicklung — die Konfigurationen entwickeln sich fortlaufend mit den Anforderungen der Plattform weiter.