HitonabiandClaude Opus 5
05ab655116
Ampel / ampel (push) Successful in 40s
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>
113 lines
4.0 KiB
Bash
113 lines
4.0 KiB
Bash
#!/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"
|