D4rkst3randClaude Opus 5
70210c0363
Auf dieser Maschine gibt es weder Docker noch WSL. Das Abbild ist also ungebaut und der Container nie gelaufen; das gehoert auf eine Maschine mit Docker, bevor jemand darauf baut. Was trotzdem geprueft ist: Node 22 ist festgenagelt, und das ist kein Zufall. better-sqlite3 11.10.0 liefert fertige Binaerdateien nur fuer ABI 108 (Node 20), 115, 127 (Node 22) und 131 -- Node 24 hat ABI 137 und fehlt. Der naheliegende Griff zur neuesten Version faellt damit auf node-gyp zurueck und braucht python3, make und g++ im Abbild. Aus den Veroeffentlichungen des Projekts abgelesen, nicht aus dem Gedaechtnis. node dist/index.js -- der Startbefehl des Abbilds -- laeuft und antwortet auf /health. Bis hierher war der Dienst nur je ueber tsx gestartet worden. Der Healthcheck gibt Exitcode 0 bei laufendem und 1 bei totem Dienst. Dazu eine Falle, die im Compose steht, weil sie teuer ist: NODE_ENV=production setzt das Sitzungs-Cookie auf Secure. Wer den Container ohne HTTPS aufruft, bekommt auf die Anmeldung 200 -- und ist trotzdem nicht angemeldet, weil der Browser das Cookie still verwirft. Die naechste Anfrage ist 401. Im Browser gegen eine LAN-Adresse nachgemessen. Die naheliegende Gegenprobe ueber localhost fuehrt in die Irre: das gilt Browsern als sicherer Kontext und funktioniert. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
95 lines
4.3 KiB
YAML
95 lines
4.3 KiB
YAML
# d4rk_media — unser eigener Medien-Dienst. EIN Container.
|
|
#
|
|
# In Portainer: Stacks -> Add stack -> Repository
|
|
#
|
|
# Repository URL https://git.d4rkst3r.de/D4rkst3r/d4rk_media
|
|
# Compose path docker-compose.media.yml
|
|
#
|
|
# EINE Datei, und das ist wichtig: Portainer nimmt unter "Compose path" genau
|
|
# eine. Ergaenzungen werden stillschweigend uebergangen -- alle Container
|
|
# gesund, alles 502. Das hat beim Lite-Anlauf einen Nachmittag gekostet.
|
|
#
|
|
# Die Werte gehoeren in die STACK-VARIABLEN, nicht in eine Datei im Repo.
|
|
|
|
services:
|
|
media:
|
|
build:
|
|
context: ./server
|
|
image: d4rk-media:latest
|
|
container_name: d4rk-media
|
|
restart: unless-stopped
|
|
|
|
environment:
|
|
# Der Ursprung, unter dem der Dienst oeffentlich steht -- OHNE Pfad
|
|
# und ohne abschliessenden Schraegstrich:
|
|
# https://media.d4rkst3r.de
|
|
#
|
|
# Das /f/ haengt der Dienst selbst an. Wer es hier mitschreibt,
|
|
# bekommt Adressen mit /f/f/, und das faellt erst auf, wenn das
|
|
# erste Bild fehlt.
|
|
#
|
|
# Das :? ist Absicht: fehlt die Variable, bricht der Stack ab,
|
|
# statt mit einer Adresse hochzufahren, die niemand erreicht.
|
|
PUBLIC_URL: ${PUBLIC_URL:?PUBLIC_URL fehlt, z.B. https://media.d4rkst3r.de}
|
|
|
|
# Wird beim ERSTEN Start als Benutzer "admin" angelegt. Ein spaeter
|
|
# geaenderter Wert setzt das bestehende Passwort nicht zurueck.
|
|
ADMIN_PASSWORD: ${ADMIN_PASSWORD:?ADMIN_PASSWORD fehlt}
|
|
ADMIN_USERNAME: ${ADMIN_USERNAME:-admin}
|
|
|
|
# EIN NAME (leer, Standard): Dashboard und API an der Wurzel,
|
|
# Dateien unter /f/.
|
|
#
|
|
# ZWEI NAMEN: hier den Hostnamen eintragen, unter dem es dann
|
|
# ausschliesslich Dateien gibt -- kein Dashboard, keine API, nichts
|
|
# anzumelden. Die URLs kommen dann ohne /f/ aus, und PUBLIC_URL ist
|
|
# der Datei-Name. Beide Namen muessen im Proxy auf diesen Port
|
|
# zeigen. Welche Betriebsart laeuft, sagt der Dienst beim Start.
|
|
FILES_HOST: ${FILES_HOST:-}
|
|
|
|
MAX_UPLOAD_MB: ${MAX_UPLOAD_MB:-64}
|
|
SESSION_DAYS: ${SESSION_DAYS:-30}
|
|
|
|
# NODE_ENV=production setzt das Sitzungs-Cookie auf "Secure". Hinter
|
|
# NPM mit TLS ist das richtig.
|
|
#
|
|
# WER OHNE HTTPS AUSPROBIERT, SPERRT SICH AUS -- und zwar auf die
|
|
# unangenehme Art. Nachgemessen im Browser gegen
|
|
# http://192.168.2.33:8096:
|
|
#
|
|
# POST /api/dash/auth/login -> 200, sieht nach Erfolg aus
|
|
# document.cookie -> leer, still verworfen
|
|
# GET /api/dash/auth/me -> 401 "nicht angemeldet"
|
|
#
|
|
# Die Anmeldung MELDET Erfolg und ist trotzdem keine. Genau die
|
|
# Sorte Rueckmeldung, wegen der wir hier neu bauen.
|
|
#
|
|
# Und die naheliegende Gegenprobe fuehrt in die Irre: ueber
|
|
# http://localhost geht es, weil Browser localhost als sicheren
|
|
# Kontext behandeln. Also entweder ueber den Proxy mit HTTPS
|
|
# testen -- oder zum Ausprobieren NODE_ENV weglassen.
|
|
NODE_ENV: production
|
|
|
|
volumes:
|
|
# Bilder UND media.db in einem Volume. Eine Sicherung ist damit
|
|
# genau ein Kopiervorgang.
|
|
- media-data:/data
|
|
|
|
ports:
|
|
# Links der Host-Port, rechts der im Container. Nur die LINKE Zahl
|
|
# muss auf diesem Server einmalig sein.
|
|
#
|
|
# Belegt sind 80, 81, 443, 2224, 3000, 3080, 3478, 8000, 8080,
|
|
# 8090, 9000, 9443, 11000 -- und 9100/9101, solange der Lite-Stack
|
|
# als Vergleichsmassstab weiterlaeuft. Deshalb 9102.
|
|
#
|
|
# Gebunden an ALLE Adressen, nicht an 127.0.0.1: NPM liegt im
|
|
# Standard-Bridge-Netz und kommt ueber die Docker-Bruecke herein,
|
|
# nicht ueber Loopback. Ein an 127.0.0.1 gebundener Port naehme die
|
|
# Anfrage nicht an. ZU MACHT IHN DIE FIREWALL, nicht die Bindung --
|
|
# 9102 gehoert von aussen dicht, oeffentlich ist nur NPM auf 80/443.
|
|
- '${BIND_ADDR:-0.0.0.0}:${HOST_PORT:-9102}:8080'
|
|
|
|
volumes:
|
|
media-data:
|