diff --git a/archive-kanban/tickets/RET-15.md b/archive-kanban/tickets/RET-15.md index a87c8495..77004b55 100644 --- a/archive-kanban/tickets/RET-15.md +++ b/archive-kanban/tickets/RET-15.md @@ -9,12 +9,12 @@ Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Archive (Ret Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche. ## Auftrag -RET-11 implementiert Storage-Object-Lock über `chattr +i`. Auf beiden bisher geprüften Hosts (131, 204) scheitert `chattr +i` strukturell mit `EPERM`, weil beide unprivilegierte LXC-Container auf ZFS-Root sind (RET-11-PRUEFPROTOKOLL.md, bestätigt erneut in QA-02/QA-07/QA-05, Archive-Board). Der erfolgreiche Pfad (chattr-fähiger, privilegierter Host bzw. chattr-fähiges Dateisystem) wurde in diesem Projekt bislang auf keinem Host real bestätigt. `wormstore.Store.Put` ist fail-closed: schlägt `chattr +i` fehl, wird der Schreibvorgang verworfen — das ist technisch sicher (kein stiller Integritätsverlust), aber die eigentliche WORM-Garantie (Akzeptanzkriterium 1/2 aus RET-11) ist bislang nur per Code-Analyse, nicht per echtem End-zu-Ende-Test belegt. +RET-11 implementiert Storage-Object-Lock über `chattr +i`. Auf beiden bisher geprüften Hosts (131, 204) scheitert `chattr +i` strukturell mit `EPERM` — die Untersuchung in `RET-11-NACHTRAG-CHATTR-UNTERSUCHUNG.md` hat die Ursache geklärt: **nicht das Dateisystem (ZFS)**, sondern dass beide Hosts **unprivilegierte LXC-Container** sind. `CAP_LINUX_IMMUTABLE` wird im Kernel bewusst nicht namespace-bewusst geprüft (per rohem ioctl bestätigt, nicht nur am `chattr`-Binary), 8 Alternativen wurden geprüft und als unzureichend befunden (einzige strukturell gleichwertige Alternative: echtes S3/MinIO-Object-Lock-Backend, Architekturwechsel). Der erfolgreiche Pfad (ein tatsächlich privilegierter Host/Container) wurde in diesem Projekt bislang nirgends real bestätigt. `wormstore.Store.Put` ist fail-closed: schlägt `chattr +i` fehl, wird der Schreibvorgang verworfen — das ist technisch sicher (kein stiller Integritätsverlust), aber die eigentliche WORM-Garantie (Akzeptanzkriterium 1/2 aus RET-11) ist bislang nur per Code-/Kernel-Analyse, nicht per echtem End-zu-Ende-Test auf einem funktionierenden Host belegt. -**Technische Grundlage:** chattr-fähiger Host oder chattr-fähiges Dateisystem (z. B. ext4 statt ZFS), oder eine der in der Untersuchung (siehe Nachtrag-Dokument, falls vorhanden) geprüften Alternativen. +**Technische Grundlage:** ein tatsächlich privilegierter Host/Container (`CAP_LINUX_IMMUTABLE` im Host-Namespace), unabhängig vom Dateisystem — oder das in RET-11-NACHTRAG-CHATTR-UNTERSUCHUNG.md als einzige gleichwertige Alternative genannte externe Object-Lock-Backend (S3/MinIO Compliance-Mode), falls ein privilegierter Host nicht verfügbar gemacht werden kann. ## Ausgangslage -Setzt auf folgenden bereits fertigen Kacheln auf: RET-11, QA-02, QA-07, QA-05 (alle Archive-Board). Prüfe vor Beginn, ob zwischenzeitlich ein Nachtrag-Dokument zur chattr-Untersuchung existiert (`archive/docs/RET-11-NACHTRAG-CHATTR-UNTERSUCHUNG.md` oder ähnlich benannt) und baue darauf auf, statt die Untersuchung zu wiederholen. +Setzt auf folgenden bereits fertigen Kacheln auf: RET-11, QA-02, QA-07, QA-05 (alle Archive-Board). Lies vor Beginn `archive/docs/RET-11-NACHTRAG-CHATTR-UNTERSUCHUNG.md` vollständig (PR #312) — die Ursachenanalyse und alle 8 geprüften Alternativen sind dort bereits dokumentiert, nicht wiederholen. ## Akzeptanzkriterien 1. Ein Host oder eine Umgebung mit tatsächlich wirksamem `chattr +i` (oder einer als gleichwertig befundenen Alternative) ist identifiziert und dokumentiert diff --git a/archive-kanban/tickets/RET-16.md b/archive-kanban/tickets/RET-16.md index 9982f280..e4266bb7 100644 --- a/archive-kanban/tickets/RET-16.md +++ b/archive-kanban/tickets/RET-16.md @@ -1,4 +1,4 @@ -# RET-16 – STORAGE-KONZEPT.md: Widerspruch ZFS als WORM-Backend klären +# RET-16 – STORAGE-KONZEPT.md: Voraussetzung für Storage-Object-Lock (unprivilegierter Container statt ZFS) klären **Epic:** ⏳ Retention & WORM | **Rolle:** Backend | **Komplexität:** Einfach | **Aufwand:** 0,5 Personentage | **Welle:** 9 @@ -8,15 +8,15 @@ Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Archive (Retention & WORM, Compliance & eDiscovery, Backup & Wiederherstellung, Kennzahlen), das sich an Alfresco, ecoDMS und restic/Borg orientiert. ## Auftrag -`STORAGE-KONZEPT.md` (Abschnitt 2) listet ZFS als gleichwertige Stufe-1-Backend-Option. `RET-11-PRUEFPROTOKOLL.md` (Prüfung 3) sieht das WORM-Basisverzeichnis ausdrücklich NICHT auf ZFS vor, weil `chattr +i` auf ZFS strukturell nicht funktioniert (bestätigt auf Host 131 und 204, siehe QA-02/QA-05/QA-07-Nachträge Archive-Board). Dieser Widerspruch zwischen Betriebsdokumentation und tatsächlicher technischer Einschränkung muss aufgelöst werden, bevor eine produktive Stufe-1-Inbetriebnahme auf ZFS-Basis erfolgt. +`STORAGE-KONZEPT.md` (Abschnitt 2) listet ZFS als gleichwertige Stufe-1-Backend-Option, ohne auf eine Einschränkung bei Storage-Object-Lock hinzuweisen. `RET-11-PRUEFPROTOKOLL.md` samt Nachtrag (`RET-11-NACHTRAG-CHATTR-UNTERSUCHUNG.md`) hat die tatsächliche Ursache geklärt: **nicht ZFS** verhindert `chattr +i`, sondern dass Host 131/204 **unprivilegierte LXC-Container** sind — `CAP_LINUX_IMMUTABLE` wird im Kernel bewusst nicht namespace-bewusst geprüft (Kernel-Design-Entscheidung, Patch dafür 2014 abgelehnt). Das Problem träte identisch auf ext4/XFS/Btrfs auf, solange der Container unprivilegiert ist. Dieser Zusammenhang muss in der Betriebsdokumentation korrekt stehen, bevor eine produktive Stufe-1-Inbetriebnahme erfolgt — sonst wird fälschlich am Dateisystem statt an der Container-Privilegierung gesucht. ## Akzeptanzkriterien -1. `STORAGE-KONZEPT.md` Abschnitt 2 enthält einen expliziten Ausnahmevermerk: ZFS ist für das WORM-Basisverzeichnis (Archive-Modul) nicht geeignet, sofern keine alternative Durchsetzung (siehe RET-15) nachgewiesen ist -2. Verweis auf RET-11-PRUEFPROTOKOLL.md als Quelle des Befundes ist im Dokument ergänzt +1. `STORAGE-KONZEPT.md` Abschnitt 2 enthält einen expliziten Hinweis: Storage-Object-Lock (`chattr +i`, RET-11) setzt einen privilegierten Host/Container voraus (oder ein alternatives, von RET-15 nachgewiesenes Verfahren) — unabhängig vom gewählten Dateisystem (ZFS, ext4, XFS, Btrfs) +2. Verweis auf RET-11-PRUEFPROTOKOLL.md und dessen Nachtrag als Quelle des Befundes ist im Dokument ergänzt 3. Keine andere inhaltliche Aussage von STORAGE-KONZEPT.md wird verändert ## Prüfungen vor der Abnahme -1. Dokument-Review: Ausnahmevermerk ist vorhanden, eindeutig und widerspricht keiner anderen Stelle im Dokument +1. Dokument-Review: Hinweis ist vorhanden, eindeutig, nennt die richtige Ursache (Container-Privilegierung, nicht Dateisystem) und widerspricht keiner anderen Stelle im Dokument 2. Diff-Prüfung: keine ungewollten Änderungen außerhalb des betroffenen Abschnitts ## Nicht Bestandteil dieser Kachel