fix: ein fehlendes Laufwerk darf Rippy nicht am Starten hindern

WAS: Die `devices:`-Eintraege fliegen aus docker-compose.yml. Was dieser
Host wirklich hat, ermittelt deploy/geraete-override.sh und schreibt es in
docker-compose.override.yml — die zieht Compose von allein dazu, der
Befehl bleibt `docker compose up -d`.

WARUM (Vorfall heute, 28.08.2026): Das USB-Laufwerk haengt nicht mehr an
der VM. Ein ganz normaler Deploy legte daraufhin api, worker UND ui still:

  Error response from daemon: error gathering device information while
  adding custom device "/dev/sr0": no such file or directory

Ein `devices:`-Eintrag ist eine STARTBEDINGUNG — und keiner der drei
Container braucht zum STARTEN ein Laufwerk. Rippy war unten, und die
Meldung stand mitten im Build-Rauschen (dieselbe Klasse wie das geschluckte
`|| echo` beim .env-Kopieren am 26.07.).

DER WIDERSPRUCH WAR AELTER ALS DER VORFALL: install.sh sagt bei fehlendem
Laufwerk ausdruecklich "die Installation laeuft trotzdem durch; diese
Maschine dient dann als reine KOMPRIMIER-Maschine" — die Compose-Datei sah
das anders. Eine Maschine ohne Laufwerk ist ein VORGESEHENER Betriebsfall:
der Windows-Worker und der GPU-Encoder sind genau das.

Das Skript uebernimmt die Erkennung aus install.sh unveraendert: sr- und
sg-Knoten ueber die SCSI-Adresse in /sys abgeglichen, nicht geraten. Und
es schreibt die Override AUCH dann, wenn kein Laufwerk da ist — sonst
bliebe eine alte Datei mit /dev/sr0 liegen und der Fehler waere derselbe,
nur schwerer zu finden, weil sie gitignored ist und in keinem Diff auftaucht.

deploy.sh ruft es vor dem Start auf.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

deploy/geraete-override.sh

@@ -0,0 +1,112 @@
+#!/usr/bin/env bash
+#
+# Erzeugt docker-compose.override.yml mit den optischen Laufwerken DIESES Hosts.
+#
+# ## Warum es das gibt (Vorfall 28.08.2026)
+#
+# In docker-compose.yml stand:
+#
+#     devices:
+#       - ${OPTICAL_SR:-/dev/sr0}:/dev/sr0
+#
+# Das ist eine STARTBEDINGUNG. Fehlt das Laufwerk, startet der Container nicht:
+#
+#     Error response from daemon: error gathering device information while
+#     adding custom device "/dev/sr0": no such file or directory
+#
+# Genau das ist passiert, als das USB-Laufwerk von der VM abgezogen wurde: Ein
+# ganz normaler Deploy legte api, worker UND ui still — obwohl keiner der drei
+# ein Laufwerk zum Starten braucht. Rippy war unten, und die Meldung stand
+# mitten im Build-Rauschen.
+#
+# Der Widerspruch war schon vorher da: `install.sh` sagt bei fehlendem Laufwerk
+# ausdrücklich „die Installation läuft trotzdem durch; diese Maschine dient dann
+# als reine KOMPRIMIER-Maschine" — die Compose-Datei sah das anders. Eine
+# Maschine ohne Laufwerk ist ein vorgesehener Betriebsfall (der Windows-Worker
+# und der GPU-Encoder sind genau das).
+#
+# Seither steht in docker-compose.yml KEIN devices-Block mehr. Was dieser Host
+# wirklich hat, landet in docker-compose.override.yml — die zieht Compose von
+# allein dazu (`docker compose up` braucht keinen extra Schalter), und sie ist
+# gitignored, weil die Geräteknoten je Rechner anders heißen.
+#
+# Aufruf:  ./deploy/geraete-override.sh [zielverzeichnis]
+#          (ohne Argument: das aktuelle Verzeichnis)
+#
+set -u
+
+ZIEL="${1:-.}"
+DATEI="$ZIEL/docker-compose.override.yml"
+
+# MakeMKV spricht Laufwerke über die SCSI-Generic-Schicht an und braucht deshalb
+# ZWEI Knoten: /dev/srN und den passenden /dev/sgM. Welche sg-Nummer dazugehört,
+# ist je Host anders — sie wird über die SCSI-Adresse ermittelt statt geraten.
+# Beide Knoten zeigen in /sys auf dasselbe Geräteverzeichnis (z. B. 3:0:0:0).
+# (Dieselbe Herleitung wie in install.sh, Prüfung 2/5.)
+SR=""
+SG=""
+LAUFWERK=""
+for srpfad in /sys/block/sr*; do
+  [ -e "$srpfad" ] || continue
+  srname=$(basename "$srpfad")
+  adresse=$(basename "$(readlink -f "$srpfad/device" 2>/dev/null)" 2>/dev/null)
+  [ -n "$adresse" ] || continue
+  for sgpfad in /sys/class/scsi_generic/sg*; do
+    [ -e "$sgpfad" ] || continue
+    if [ "$(basename "$(readlink -f "$sgpfad/device" 2>/dev/null)" 2>/dev/null)" = "$adresse" ]; then
+      SR="/dev/$srname"
+      SG="/dev/$(basename "$sgpfad")"
+      LAUFWERK="$(cat "$srpfad/device/vendor" 2>/dev/null) $(cat "$srpfad/device/model" 2>/dev/null)"
+      break 2
+    fi
+  done
+done
+
+kopf() {
+  cat <<KOPF
+# ERZEUGT von deploy/geraete-override.sh — nicht von Hand ändern.
+# Diese Datei ist gitignored: Die Geräteknoten heißen auf jedem Rechner anders.
+# Neu erzeugen nach jedem An- oder Abstecken eines Laufwerks:
+#     ./deploy/geraete-override.sh && docker compose up -d
+KOPF
+}
+
+if [ -z "$SR" ]; then
+  # KEIN Laufwerk. Wichtig: trotzdem eine gültige Datei schreiben und die alte
+  # damit überschreiben. Bliebe eine alte Override mit /dev/sr0 liegen, wäre der
+  # Fehler beim nächsten Start genau derselbe — nur schwerer zu finden, weil die
+  # Datei gitignored ist und in keinem Diff auftaucht.
+  {
+    kopf
+    echo "#"
+    echo "# Auf diesem Host wurde KEIN optisches Laufwerk gefunden."
+    echo "# Rippy läuft damit als reine Komprimier-Maschine — das ist ein"
+    echo "# vorgesehener Betriebsfall, kein Fehler. Zum Rippen das Laufwerk"
+    echo "# anstecken (in einer VM: USB-Passthrough) und dieses Skript erneut"
+    echo "# aufrufen."
+    echo "services: {}"
+  } > "$DATEI"
+  echo "Kein optisches Laufwerk gefunden — $DATEI ohne Geräte geschrieben."
+  echo "Rippy startet und kann komprimieren; Rippen geht erst mit Laufwerk."
+  exit 0
+fi
+
+{
+  kopf
+  echo "#"
+  echo "# Gefunden: $(echo "$LAUFWERK" | tr -s ' ')"
+  echo "# $SR + $SG (über die SCSI-Adresse abgeglichen, nicht geraten)"
+  cat <<YAML
+services:
+  api:
+    devices:
+      - $SR:/dev/sr0
+  worker:
+    devices:
+      - $SR:/dev/sr0
+      - $SG:/dev/sg1
+YAML
+} > "$DATEI"
+
+echo "Laufwerk gefunden: $(echo "$LAUFWERK" | tr -s ' ')"
+echo "  $SR + $SG  ->  $DATEI"