Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨

[Satsh]

@Dragondrummer71

Du nutzt Docker nativ auf der Syno, oder?
Ich bin mir nicht sicher, ob der Kernel der Syno Capabilities überhaupt unterstützt. Roll doch einfach mal eine VM mit Linux aus und installiert da testweise Docker und probiere es da aus.

Du hast oben auch geschrieben, dass du NET_BIND_SERVICE "aktiviert" hast - wie hast du das denn gemacht?

Ansonsten wäre hier eher noch der Tip, dass ich an deiner Stelle dafür den Reverse Proxy der Syno nutzen würde, dann musst du am Docker Container nichts "fummeln". Aber das wird natürlich nur funktionieren, wenn du Kontrolle über deinen DNS Server hast und dort einen zusätzlichen Hostnamen eintragen kannst.

[Dragondrummer71]

@Satsh
Danke erst Mal - ja ich nutze es nativ auf der Synology habe aber Portainer installiert um das ganze zu verwalten. (und somit war ich der Meinung durch die Aktivierung von NET_BIND_SERIVCE dort auch eine Wirkung zu erzielen :confounded: ist wohl nicht so.
Ich hab mal nochmal etwas nachgelesen - es scheint wirklich so zu sein, das Docker auf der Synology die Capabilities nicht unterstützt "Docker --help" auf der Synology zeigt diese option auch gar nicht an.
Als Ersatz gibt es dort wohl die Option "Container mit hoher Priorität ausführen" macht wohl etwas ähnliches aber was genau habe ich nirgends gefunden.
Deshalb auch die Sudo Fehlermeldung beim Test Container - da hatte ich das nicht aktiviert.

Das mit dem Revese Proxy wäre auch noch eine Alternative, da gefällt mir aber die Umleitung des Port's direkt über das Skript besser, da ich dann alles zugehörige in den Verzeichnissen des Container's habe und somit wenn ich diese Verzeichnisse sichere / kopiere habe ich alle nötigen Info's und Skripte für den Container mit dabei -- und es funktioniert ja auch wenn ich den Container neu erstelle, ohne irgendetwas zu "fummeln" :blush:
Besten Dank für dein Mühe.

[andre]

@Dragondrummer71 sagte in buanet/iobroker node red port 80:

Ich hab mal nochmal etwas nachgelesen - es scheint wirklich so zu sein, das Docker auf der Synology die Capabilities nicht unterstützt "Docker --help" auf der Synology zeigt diese option auch gar nicht an.
Als Ersatz gibt es dort wohl die Option "Container mit hoher Priorität ausführen" macht wohl etwas ähnliches aber was genau habe ich nirgends gefunden.
Deshalb auch die Sudo Fehlermeldung beim Test Container - da hatte ich das nicht aktiviert.

Das finde ich ja spannend. Bin ich bisher noch nicht drüber gestolpert. :) Muss aber dazu sagen, dass ich den ioBroker produktiv gar nicht mehr auf der DS laufen habe. :)
Der sudo-Fehler kommt mir allerdings bekannt vor. Der kommt auch, wenn man den Container im Netzwerkmodus "Host" betreibt und sudo ausführen will. Das liegt dann an einer veralteten Kernelversion die im DSM verwendet wird. Der Bug ist bekannt, aber eine neue Kernel Version kommt erst mir DSM 7.

MfG,
André

[vepman]

@Dragondrummer71
Hallo, bist du bei dem Port80-Problem irgendwie weitergekommen?
Ich stehe wie du vor dem gleichen Problem.
Habe auf der Syno auch eine Docker Installation mit ioBroker und node-red.
Möchte auch den Amazon Echo Hub laufen lassen, um von Skill's oder iot.Adapter wegzukommen.
Für eine Lösung wäre ich dankbar

VG

[Dragondrummer71]

@vepman
Hallo, ja bei mir funktioniert es jetzt. Ich habe die beiden Startskripte des Docker Containers verwendet um die Änderung auch nachhaltig zu gestalten. Um das ganze außerhalb des Container zu verwalten, habe ich mir noch ein Verzeichnis gemountet von meinem NAS docker/iobroker_userscripts auf das Verzeichnis /opt/userscripts im Container.
Das firststart Skript macht ein update auf das System und installiert iptables (kann auch bei laufenden Container einmalig direkt ausgeführt werden) und das everystart Skript Routet das Port 80 direkt auf 8080. (hier bitte auf die Netzwerkschnittstelle achten - bei mir ist es eth1 ip addr show).
Somit muß dann im "Amazon Echo Hub" node direkt das Port 8080 abgefragt werden.

userscript_firststart.sh

#!/bin/bash
# This is an example script file.
# To run the Script on the first start of a new container you have to rename it to userscript_firststart.sh.

# You can add your advanced script code here!
sudo apt-get update && sudo apt-get -y upgrade
sudo apt-get -y install iptables
update-alternatives --set iptables /usr/sbin/iptables-legacy
echo ' '
echo "I'm your startscript userscript_firststart.sh. I will run only on the FIRST startup of the container."
echo ' '
exit 0

und
userscript_everystart.sh

#!/bin/bash
# This is an example script file.
# To run the Script on every start of the container you have to rename it to userscript_everystart.sh.

# You can add your advanced script code here!
sudo iptables -A PREROUTING -t nat -i eth1 -p tcp --dport 80 -j REDIRECT --to-port 8080
echo ' '
echo "I'm your startscript userscript_everystart.sh. I will run on EVERY container startup."
echo ' '
exit 0

[vepman]

@Dragondrummer71
Danke für deine ausführliche Antwort. Toll!
Morgen teste ich das mal aus.👍

[vepman]

@Dragondrummer71
Ich will wenigstens mal kurz berichten.
Leider läuft die Portweiterleitung (im Beispiel mit Port 8008) nicht bei mir:

iptables is already the newest version (1.8.2-4).
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
root@buanet-iobroker1:~# sudo iptables -t nat -L
sudo: unable to resolve host buanet-iobroker1: Name or service not known
iptables v1.8.2 (legacy): can't initialize iptables table `nat': Permission denied (you must be root)
Perhaps iptables or your kernel needs to be upgraded.
root@buanet-iobroker1:~# sudo iptables -t nat -L     
sudo: unable to resolve host buanet-iobroker1: Name or service not known
iptables v1.8.2 (legacy): can't initialize iptables table `nat': Permission denied (you must be root)
Perhaps iptables or your kernel needs to be upgraded.
root@buanet-iobroker1:~# sudo iptables -A PREROUTING -t nat -i eth1 -p tcp --dport 80 -j REDIRECT --to-port 8008
sudo: unable to resolve host buanet-iobroker1: Name or service not known
getsockopt failed strangely: Operation not permitted

Im Moment bin ich ratlos

[Dragondrummer71]

@vepman Versuchs mal ohne sudo.

[vepman]

@Dragondrummer71

Dann kommt dieses:

root@buanet-iobroker1:/opt/iobroker# iptables -A PREROUTING -t nat -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 8008
getsockopt failed strangely: Operation not permitted
root@buanet-iobroker1:/opt/iobroker#

[Dragondrummer71]

@vepman Bekommst du eine Ausgabe bei:

iptables -t nat -L

Der Befehl sollte auch ohne sudo funktionieren.
Es gab verschiedene Versionen des Docker Conatiners, bei welchen sudo nicht funktioniert hatte :

v3.0.2beta (2019-06-13)
    using gosu instead of sudo
    changing output of ioBroker logging

Du kannst das ganze mal mit gosu versuchen. Ich bin jetzt auch nicht der Linux Spezialist deshalb muss ich da auch mehr vermuten als zu wissen.
Vielleicht wäre es mal eine Möglichkeit einen neuen Container mit der aktuellen Version und deinen Daten aufzusetzen und dann das ganze zu versuchen. Ich selbst bin auf McVlan mit eigener IP Adresse umgestiegen .
Ein weiteres Thema was mir noch einfällt: Läuft der Container "mit hoher priorität"? Ohne geht es glaube ich nicht.

[vepman]

@Dragondrummer71 sagte in buanet/iobroker node red port 80:

@vepman
Ein weiteres Thema was mir noch einfällt: Läuft der Container "mit hoher priorität"? Ohne geht es glaube ich nicht.

Das war ein guter Tipp. Es kommen keine Fehlermeldungen mehr.
Ich dachte "hohe Priorität" bezieht sich auf die Zeit die der Container als Task bekommt.
Bedeutet wohl aber, dass er root-Rechte bekommt.
Jetzt suche ich mal, warum Alexa nichts findet.
Bin jetzt schon einen großen Schritt weiter. Danke!
Mit McVlan werde ich mich auch mal beschäftigen, aber erst später.

[Kefut]

Hi @Dragondrummer71 ,

danke Dir für die Skript. Ich war super happy als ich das gefunden hatte und es damit sofort ans Laufen bekommen habe. Nun habe ich aber ein anderes Problem: Jegliche Port 80 Anfragen werden ja nun an Node red geforwarded, also auch der Aufruf der Synology Oberfläche und (wenn ich es richtig verstehe) auch die response von Let's encrypt bei der Erneuerung von Zertifikaten.
Daher nun die Frage: Wie hast Du das gelöst? Kann man das temporär deaktivieren - bzw. wie rolle ich das zurück? Denn aktuell hilft noch nichtmal das Stoppen von Docker um die Synology wieder über Port 80 zu erreichen.

Viele Grüße,
Christoph

[Dragondrummer71]

Hi @Kefut
Das Problem habe ich nicht. Eigentlich verstehe ich eine Portweiterleitung so, dass die info's an allen Stellen auftauchen und somit sollten beide IP's weiterhin funktionieren. Ich habe meinen ioBroker im MCVlan laufen und somit zwei unterschiedliche IP Adressen (NAS / IoBroker) hast du hier eine Bridge? Ich hab's mal mit PhotoStation vesucht (benutzt ja auch Port 80) das funktioniert ganz normal.

Zum Thema zurückrollen: Die Portweiterleitung sollte eigentlich nach starten des Containers ohne everystart Skript wieder weg sein. Deshalb ja auch dieses Skript, da es bei mir nicht permanent war.
Ansonsten sollte das funktionieren: (das heißt der selbe Befehlt jedoch mit -D für delete)
sudo iptables -A PREROUTING -t nat -D -i eth1 -p tcp --dport 80 -j REDIRECT --to-port 8080

[Kefut]

Hi @Dragondrummer71
hab es jetzt auch ganz zum laufen bekommen! Das MACVlan war noch nicht richtig eingestellt. Danke Dir!
Wobei eine Frage hab ich noch an Dich: Benutzt Du Reverse Proxies die auf den Container zeigen? Die funktionieren bei mir trotz Bridge noch nicht.

[Dragondrummer71]

Hi @Kefut
ne sorry da kann ich nicht helfen. Das nutze ich nicht. Nutzt du hierzu das NAS (als Reverse Proxy). Denn dann denke ich funktinoiert das nicht (bin dazu aber nicht wirklich ein Spezialist), da du auf dem gleichen Host ja die gleiche Netzwerkkarte für die Kommunikation nutzt (Host und Docker). Wenn du zwei Netzwerkkarten hast, müsste es funktionieren. Aber wie gesagt keine Gewähr für das was ich hier sage.
Gruß Dragondrummer71

[Kefut]

Hi @Dragondrummer71
ich bin einen Schritt weiter. Ich folge der Anleitung hier: http://www.stueben.de/iobroker-im-docker-auf-der-synology-diskstation-im-gleichen-subnet/ und komme nun zumindest mit Remote Proxy (auf der NAS) auf die Admin Oberfläche. Irgendwas ist aber immer noch nicht 100% korrekt. Wenn ich über den Remote Proxy auf die Admin Oberfläche zugreife, werden die Adapter und das Log nicht geladen. Der Rest scheint zu funktionieren..