fix: freie Host-Ports, und der Weg ist jetzt belegt statt vermutet

Die Containerliste des Servers beantwortet beides.

Der NPM-Container hat 172.17.0.3 und liegt damit im Standard-Bridge-Netz,
nicht in "web". Meine Vermutung, "web" sei das Proxy-Netz, war falsch — es
gilt Weg B ueber den Host, so wie d4rkbot auf 3080 und cdn-files auf 8090
schon laufen. Im README steht das jetzt als Feststellung und nicht mehr als
Wahrscheinlichkeit.

Und die Ergaenzung wollte ausgerechnet 9000 und 8080 oeffnen — beide vergeben,
an Portainer und an nextcloud-aio. Jetzt 9100 und 9101, und ueber
MINIO_HOST_PORT und LITE_HOST_PORT einstellbar: die naechste Kollision ist dann
eine Variable und keine Dateiaenderung. Im Container bleibt es bei 9000 und
8080; nur die Seite zum Host wandert.

Belegt waren: 80, 81, 443, 2224, 3000, 3080, 3478, 8000, 8080, 8090, 8443,
9000, 9443, 11000.

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

docker-compose.hostports.yml

@@ -1,39 +1,47 @@
 # Ergaenzung fuer einen Reverse Proxy, der NICHT im selben Docker-Netz haengt.
 #
-# Der Nginx Proxy Manager auf diesem Server erreicht seine Ziele ueber
-# `host.docker.internal:<port>` — so laufen dort schon Bot und Hub. Dieses
-# Muster braucht offene Ports auf dem Host, denn ueber den Host geht der Weg.
+# Der Nginx Proxy Manager auf diesem Server liegt im Standard-Bridge-Netz
+# (172.17.0.3) und erreicht seine Ziele ueber `host.docker.internal:<port>` —
+# so laufen dort schon d4rkbot auf 3080 und cdn-files auf 8090. Dieses Muster
+# braucht offene Ports auf dem Host, denn ueber den Host geht der Weg.
 #
 # Zusammen benutzen:
 #
 #   docker compose -f docker-compose.yml -f docker-compose.hostports.yml up -d
 #
-# In Portainer: unter "Compose path" beide Dateien angeben, durch Komma
-# getrennt.
+# In Portainer unter "Compose path", durch Komma getrennt:
+#   docker-compose.yml,docker-compose.hostports.yml
 #
 # Danach in NPM:
 #
-#   fivecdn.d4rkst3r.de  ->  http://host.docker.internal:9000   (die Dateien)
-#   <oberflaeche>        ->  http://host.docker.internal:8080   (Lite)
+#   fivecdn.d4rkst3r.de  ->  http://host.docker.internal:9100   (die Dateien)
+#   <oberflaeche>        ->  http://host.docker.internal:9101   (Lite)
+#
+# WARUM 9100 UND 9101 und nicht die naheliegenden 9000 und 8080: beide sind auf
+# diesem Server vergeben — 9000 an Portainer, 8080 an nextcloud-aio. Im
+# Container bleibt es bei 9000 und 8080; nur die Seite zum Host wandert.
+#
+# Kollidiert spaeter noch etwas, sind es zwei Variablen und keine Dateiaenderung:
+#   MINIO_HOST_PORT   Standard 9100
+#   LITE_HOST_PORT    Standard 9101
+#
+# Belegt waren beim Anlegen: 80, 81, 443, 2224, 3000, 3080, 3478, 8000, 8080,
+# 8090, 8443, 9000, 9443, 11000.
 #
 # GEBUNDEN AN 127.0.0.1, nicht an alle Adressen. Damit ist der Port vom
 # Internet aus zu, und nur der Host — und damit NPM — kommt heran.
 #
-# Ein Vorbehalt dazu: ob `host.docker.internal` eine Bindung an 127.0.0.1
-# erreicht, haengt an der Docker-Fassung. Unter Linux braucht der
-# NPM-Container dafuer `extra_hosts: ["host.docker.internal:host-gateway"]`,
-# und der Weg fuehrt dann ueber die Docker-Bruecke statt ueber Loopback — dann
-# muss die Bindung `0.0.0.0` lauten und die FIREWALL den Port zumachen.
-#
-# Kurz: klappt es mit 127.0.0.1 nicht, ist die Bindung nicht der Fehler,
-# sondern der Weg. Sauberer waere es ohnehin, NPM ins Netz `proxy` zu haengen
-# — dann braucht es diese Datei gar nicht und keinen offenen Port.
+# Ein Vorbehalt: ob `host.docker.internal` eine Bindung an 127.0.0.1 erreicht,
+# haengt an der Docker-Fassung. Unter Linux fuehrt der Weg ueber die
+# Docker-Bruecke statt ueber Loopback; dann muss die Bindung 0.0.0.0 lauten und
+# die FIREWALL den Port zumachen. Bei d4rkbot auf 3080 funktioniert es — wie es
+# dort gebunden ist, sagt `docker port d4rkbot`.
 
 services:
   minio:
     ports:
-      - "127.0.0.1:9000:9000"
+      - "127.0.0.1:${MINIO_HOST_PORT:-9100}:9000"
 
   lite:
     ports:
-      - "127.0.0.1:8080:8080"
+      - "127.0.0.1:${LITE_HOST_PORT:-9101}:8080"