From b76ca5d9be4d532ce175c08db49493add6f3e5a0 Mon Sep 17 00:00:00 2001 From: Hitonabi Date: Sat, 25 Jul 2026 22:01:06 +0200 Subject: [PATCH] docs(savepoint): install.sh und README-Umbau nachgetragen Der Block dokumentiert jetzt auch die letzte Runde: ein Befehl statt Checkliste, README neu aufgebaut, VM-CPU-Anleitung drin. Ehrlich als UNGETESTET markiert (neuer Punkt 6): install.sh ist nie als root durchgelaufen. Auf dieser VM sind alle root-Schritte No-Ops - Verzeichnisse liegen da, die Propagation ist schon shared - und sudo verlangt hier ein Passwort. Bewiesen sind Laufwerkserkennung (SCSI-Abgleich gegen die echte Hardware), die .env-Logik in drei Faellen und die Syntax. Das Anlegen der Verzeichnisse, mount --make-rshared und die systemd-Unit laufen erst bei einer echten Neuinstallation - das gehoert in die Uebergabe statt in eine Erfolgsmeldung. Co-Authored-By: Claude Opus 5 --- SAVEPOINT.md | 62 +++++++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 61 insertions(+), 1 deletion(-) diff --git a/SAVEPOINT.md b/SAVEPOINT.md index c3abf48..687157b 100644 --- a/SAVEPOINT.md +++ b/SAVEPOINT.md @@ -95,6 +95,59 @@ geworden. Zwei Lücken bleiben, beide **nicht gebaut, als Vorschlag**: - **Mehrere Laufwerke gleichzeitig.** Rippy sieht sie (`/dev/sr[0-9]*`), ob parallel gerippt wird, ist **unbewiesen** — mit einem Laufwerk nicht testbar. +### Installation: ein Befehl statt Checkliste (`install.sh`) + +Commander-Rückmeldung: „Das Docker Deployment ist mir zu kompliziert." Zu +Recht — es war eine Sechs-Schritte-Checkliste, von der zwei Punkte Fachwissen +verlangten. Jetzt: + +```bash +git clone rippy && cd rippy +sudo ./install.sh +``` + +Der schlimmste Punkt war das **Laufwerk**: MakeMKV braucht ZWEI Geräteknoten, +und die sg-Nummer ist je Host anders. Das Skript gleicht sie über die +SCSI-Adresse in `/sys` ab statt zu raten — auf der VM gegengeprüft +(`sr0 → 3:0:0:0`, `sg1 → 3:0:0:0` = dasselbe Gerät, korrekt erkannt). Dazu: +Verzeichnisse, Mount-Propagation **inklusive neustart-fester systemd-Unit** +(vorher stand in der README nur „reboot-fest persistieren", ohne zu sagen wie — +nach einem Reboot scheiterte das NAS-Einhängen aus dem UI stillschweigend), +`.env` schreiben ohne Bestehendes zu überschreiben, bauen, starten. +`./install.sh --nur-pruefen` sieht nur nach. Wiederholbar, damit auch der +Update-Weg: `git pull && sudo ./install.sh`. + +**Zwei Fallgruben fielen beim Testen auf, beide meine eigenen:** +- `--nur-pruefen` verlangte root und brach ab — ein Prüf-Modus, der nichts + ändert, darf daran nicht scheitern. +- `.env.example` hatte `OPTICAL_SG=/dev/sg1` **unkommentiert** vorbelegt. Der + Installer hätte den erkannten Wert deshalb nicht eingetragen („steht schon + drin") und auf jedem fremden Host still eine kaputte Konfiguration + hinterlassen — genau das, was er verhindern soll. Beide Gerätezeilen sind + jetzt auskommentiert (Compose hat ohnehin Vorgaben), plus eine Gegenprobe: + zeigt ein wirksamer Wert auf ein Gerät, das es hier nicht gibt („`.env` von + einem anderen Rechner"), wird das benannt statt kryptisch von Docker gemeldet. + +Die `.env`-Logik ist in drei Fällen auf der VM geprüft: frische Datei bekommt +den erkannten Wert, ein selbst gesetzter Wert bleibt unangetastet, zweimal +ausführen erzeugt genau eine Zeile. + +### README neu aufgebaut + +Vorher 293 Zeilen, in denen der Schnellstart zwischen `lsscsi`, sg-Knoten, +USB-Passthrough und `mount --make-rshared` begraben war. Jetzt: Installation in +zwei Zeilen oben, dann die Tabelle „Wenn etwas nicht geht" mit den vier Fällen, +die praktisch alles abdecken. Alles Technische darunter in aufklappbaren +Abschnitten, inklusive der Handarbeits-Variante. + +**Neu und ausdrücklich gewünscht: „Rippy schneller machen"** — der VM-CPU-Typ. +Warum Virtualisierer eine generische CPU ohne AVX2 geben, was das kostet +(gemessene 28–55 h je 4K-Film), die genauen Proxmox-Schritte (herunterfahren → +Hardware → Processors → Type auf `host` → starten, bzw. `qm set --cpu +host`), **warum ein Neustart von innen nicht genügt**, und wie man nachprüft: +Rippy zeigt die Vektorbefehle selbst an. Dazu der Nachteil (keine +Live-Migration auf andere CPUs) und die Alternative `x86-64-v3` für Cluster. + ### NOCH OFFEN 1. **Externe Worker im Praxistest** (Commander). @@ -105,7 +158,14 @@ geworden. Zwei Lücken bleiben, beide **nicht gebaut, als Vorschlag**: settings-Tabelle. Für Heimnetz erwartbar, aber der Webhook ist eine echte Zugangsberechtigung. 5. **Der VM-CPU-Typ steht auf `qemu64`.** `host` würde AVX2 freischalten und - jeden Software-Encode 2–4× beschleunigen. Ein VM-Neustart, nicht gemacht. + jeden Software-Encode 2–4× beschleunigen. Ein VM-Neustart, nicht gemacht — + **die Anleitung steht jetzt in der README** („Rippy schneller machen"). +6. **`install.sh` ist nie als root durchgelaufen.** Auf dieser VM sind alle + root-Schritte No-Ops (Verzeichnisse da, Propagation schon `shared`), und + `sudo` verlangt hier ein Passwort. Bewiesen sind Laufwerkserkennung, + `.env`-Logik (drei Fälle) und Syntax; **ungetestet bleiben das Anlegen der + Verzeichnisse, `mount --make-rshared` und die systemd-Unit** — die laufen + erst bei einer echten Neuinstallation. ---