Lab · Architektur und Betrieb
Systeme betreiben heißt, ihre Abstraktionen zu prüfen.
Ich betreibe einen Teil meiner Infrastruktur selbst, weil Betrieb andere Fragen stellt als ein Diagramm: Was bleibt erreichbar, wenn ein Datenträger ausfällt? Welche Berechtigung besitzt ein Modell wirklich? Welche Grenze hält, wenn eine öffentliche Anwendung kompromittiert wird?
Das Lab dokumentiert diese Fragen als Architektur, Experimente, Incidents und offene Arbeit. Es ist kein Live-Monitoring und kein vollständiges Inventar.
01 · Leitprinzip
Datensensibilität bestimmt die Isolation.
Die erste Frage lautet nicht, wo gerade Platz ist. Entscheidend sind die Daten, die notwendige Erreichbarkeit und der Schaden, den ein kompromittierter Workload verursachen könnte. Hardware und Provider können wechseln; diese Platzierungsregel soll stabil bleiben.
02 · Vertrauenszonen
Grenzen werden durch verbotene Pfade verständlich
Die Darstellung ist absichtlich abstrakt. Sie zeigt Rollen und Einschränkungen, nicht Hosts, Adressen, Ports oder geschützte Routen.
- 01
HOME / SENSITIVE
Private und sensible Verarbeitung in getrennten Laufzeitgrenzen.
Kein öffentlicher Ingress. Eine öffentliche Anwendung erhält keinen Rückweg in diese Zone.
- 02
PUBLIC / DEDI
Öffentliche Dienste und niedrigere Sensitivität mit logischer Trennung.
Erreichbar, aber kein Transit in private Verarbeitung. Geheimnisse bleiben auf den jeweiligen Dienst begrenzt.
- 03
EDGE
Schmale Netzwerkfähigkeit für definierte externe Anforderungen.
Widerrufbare, möglichst lesende Schlüssel. Keine Client-Datensätze und keine zweite Anwendungsplattform.
- Öffentliche Kompromittierung wird nicht zum eingehenden Pfad ins private Netz.
- Ein Edge kann keine Datensätze verlieren, die er nie speichert.
- Ein Modell kann keinen Token benutzen, den es nie erhält.
03 · Systemverzeichnis
Rollen statt Service-Kacheln
Der Stand beschreibt Aufgaben und Grenzen zum Zeitpunkt der letzten vollständigen Inventarprüfung. Er ist kein Verfügbarkeitsversprechen.
| Bereich | Rolle | Zustand | Zone | geprüft |
|---|---|---|---|---|
| Storage & Recovery | Redundanz, Snapshots und verschlüsselte Off-Host-Sicherungen | in Betrieb · Restore-Kette offen | HOME / SENSITIVE | |
| DNS & Netzwerk | Interne Auflösung, Filterung und Zertifikatsgrundlage | in Betrieb | HOME | |
| Dokumenten-Pipelines | Getrennte private und geschäftliche Dokumentverarbeitung | in Betrieb | HOME / SENSITIVE | |
| Öffentliche Plattform | Webdienste, Git/CI und kontrollierter HTTP-Rand | in Betrieb | PUBLIC / DEDI | |
| Statischer Egress | Eng begrenzter Ausgang für externe Allowlists | eingeschränkt | EDGE | |
| Agent-Systeme | Getrennte Runtimes und versionierte Fähigkeiten | aktive Entwicklung | nach Trust Domain |
04 · Aktuelle Arbeit
Drei offene Arbeitslinien
- Restore-Vertrauen
- Die vollständige Wiederherstellung über die gesamte Kette als geprobten Ablauf beweisen, nicht aus Einzelbackups ableiten.
- Agent-Fähigkeiten
- Fähigkeiten nach Bedarf verteilen, kanonisches Wissen lesend spiegeln und schreibende Aktionen an nachvollziehbare Freigaben binden.
- Migrationsreste
- Alte Proxy-, Dienst- und Dokumentationsspuren aus früheren Betriebsmodellen systematisch entfernen.
05 · Agent-Infrastruktur
Das Modell ist nicht die Sicherheitsgrenze
Die gemeinsame Schicht ist ein versioniertes Repository aus Regeln, Skills, Standards und Scripts. Kleine Router laden Kontext nur bei Bedarf. Die Laufzeit besitzt nur die Werkzeuge, die ihre Aufgabe tatsächlich braucht.
- 01
Wissen
Kanonische Notizen und Projektdokumentation; selbst betriebene Agenten lesen aus einem getrennten Mirror.
- 02
Fähigkeiten
Versionierte Verfahren mit eng zugeordneten Scripts, Referenzen und Vorlagen.
- 03
Trust Domains
Getrennte Umgebungen für unterschiedliche Haushalts- und Arbeitskontexte; Profile allein gelten nicht als Mandantentrennung.
- 04
Aktionsgrenze
Das Modell entwirft Text. Deterministischer Code hält Tokens, prüft Rollen und verlangt Freigabe für Seiteneffekte.
Nicht vertrauenswürdiger Text darf einen Entwurf beeinflussen. Er erhält damit kein Privileg.
06 · Incidents und Migrationen
Betrieb wird erst durch Geschichte glaubwürdig
Kurze Einträge halten fest, was sich änderte und welche Regel daraus entstand. Tieferer Inhalt bleibt bei der jeweiligen Note oder dem Project.
Homelab-Rebuild
Aus gewachsenem Bestand wurde ein dokumentiertes Modell. Nicht alle alten Container hatten brauchbare Backups.
Dedicated-Server-Rebuild
Komplexere Orchestrierung wich Caddy und normalen Compose-Stacks, provisioniert mit Ansible aus dem rostr-Repo.
DNS-Migration
Zwei Resolver wurden in einer eigenen Benchmark-Umgebung verglichen, bevor die Betriebsentscheidung fiel.
Dokumenten-Abgleich
Bestände wurden per SHA-256 und Datenbankmerkmalen versöhnt. Kein LLM war nötig.
NVMe aus dem Mirror verschwunden
Der Pool blieb degradiert erreichbar; aktuelle Sicherungen waren vor dem Eingriff geprüft. Kein Datenverlust.
Agent-Baseline-Migration
Benannter Snapshot und Full-Backup kamen vor Schemaänderung und Abnahmetests.
07 · Bekannte Mängel
Offene Arbeit gehört zum Systemzustand
Diese Punkte sind öffentlich unkritisch und in den vorhandenen Betriebsnotizen belegt. Sicherheitsbefunde, die eine reale Angriffsfläche offenlegen würden, gehören nicht hierher.
Restore-Vertrauen
Einzelne Sicherungen sind geprüft. Ein vollständiger Restore über die ganze Kette ist noch nicht als wiederholbarer Ablauf bewiesen.
Hardware-Lebenszyklus
Die ausgefallene und später wieder erschienene NVMe bleibt Austausch-Kandidat. Wieder sichtbar bedeutet nicht wieder vertrauenswürdig.
Migrationsrückstand
Nicht jeder frühere Dienst ist vollständig aus Proxy-Konfiguration und Dokumentation entfernt.