NEWS
buanet/iobroker node red port 80
-
Ich bin mittlerweile am verzweifeln....
Erst Mal zu meinem Setup. Ich habe auf einer Synology einen buanet/iobroker mit macvlan laufen - Dateien sind ausgelagert auf volume1. Ich haben ihn aktuell mit "latest" neu aufgesetzt. Der NET_BIND_SERVICE ist aktiviert und wenn ich alles richtig verstanden habe, sollte es dann auch möglich sein das port 80 anzusprechen. Ich versuche gerade den Amazon-Echo-Hub in node red zum laufen zu bringen, jedoch bekomme ich bei port 80 die Fehlermeldung: [error] Error: listen EACCES: permission denied 0.0.0.0:80.
Ich habe es auch versuch eine portweiterleitung über iptables (musste ich vorher installieren) versucht, jedoch kommt hierbei immer eine Fehlermeldung.
Es könnte auch mit der Fehlermeldung im iobroker Fixer zu tun haben:
Failed to set capabilities on file `/usr/bin/node' (Operation not supported)
The value of the capability argument is not permitted for a file. Or the file is not a regular (non-symlink) fileIrgendwelche Ideen?
@andre -
Ich bin mittlerweile am verzweifeln....
Erst Mal zu meinem Setup. Ich habe auf einer Synology einen buanet/iobroker mit macvlan laufen - Dateien sind ausgelagert auf volume1. Ich haben ihn aktuell mit "latest" neu aufgesetzt. Der NET_BIND_SERVICE ist aktiviert und wenn ich alles richtig verstanden habe, sollte es dann auch möglich sein das port 80 anzusprechen. Ich versuche gerade den Amazon-Echo-Hub in node red zum laufen zu bringen, jedoch bekomme ich bei port 80 die Fehlermeldung: [error] Error: listen EACCES: permission denied 0.0.0.0:80.
Ich habe es auch versuch eine portweiterleitung über iptables (musste ich vorher installieren) versucht, jedoch kommt hierbei immer eine Fehlermeldung.
Es könnte auch mit der Fehlermeldung im iobroker Fixer zu tun haben:
Failed to set capabilities on file `/usr/bin/node' (Operation not supported)
The value of the capability argument is not permitted for a file. Or the file is not a regular (non-symlink) fileIrgendwelche Ideen?
@andreBin mittlerweile etwas weiter. Konnte nun iptables zum laufen bringen (aktuell nur im legacy mode) in dem ich dem Container privilegierte rechte eingeräumt habe. Ich bekomme nun auch die Port weiterleitung hin, aber bekomme diese nach dem Neustart nicht wieder automatisch geladen.
Nach installation von apt-get install iptables-persistent
sollte eigentlich die /etc/iptables/rules.v4 beim neustart geladen werden. Funktioniert aber nicht.
Auch hier (wie bei iptables im nft mode) kommt aber wieder bei der Installation die Fehlermeldung:
ip6tables/1.8.2 Failed to initialize nft: Protocol not supported
Nach meinen Recherche liegt das am Kernerl. - NFT wird ab 3.13 und im Container ist 3.10.102 installiert.
Kann man iptables-persistent auch im legacy mode verwenden - oder sollte man den Kernel updaten. -
Bin mittlerweile etwas weiter. Konnte nun iptables zum laufen bringen (aktuell nur im legacy mode) in dem ich dem Container privilegierte rechte eingeräumt habe. Ich bekomme nun auch die Port weiterleitung hin, aber bekomme diese nach dem Neustart nicht wieder automatisch geladen.
Nach installation von apt-get install iptables-persistent
sollte eigentlich die /etc/iptables/rules.v4 beim neustart geladen werden. Funktioniert aber nicht.
Auch hier (wie bei iptables im nft mode) kommt aber wieder bei der Installation die Fehlermeldung:
ip6tables/1.8.2 Failed to initialize nft: Protocol not supported
Nach meinen Recherche liegt das am Kernerl. - NFT wird ab 3.13 und im Container ist 3.10.102 installiert.
Kann man iptables-persistent auch im legacy mode verwenden - oder sollte man den Kernel updaten.So wieder etwas weiter hab jetzt die Portweiterleitung gemacht, jedoch gibt es danach das Problem, das Alexa und Telegram nicht mehr starten, wenn ich den Port vor dem ioBroker start umleite.
Ich bräuchte hier echt mal hilfe.
Hat irgend jemant eine Idee wie ich es möglich mache, den Port 80 direkt im Docker Container zu verwenden.
Hier zur Info was ich gemacht habe:Userdefined startup scripts im Container gemountet****
/opt/userscripts iobroker_userscripts
userscript_everystart.sh mit folgenden inhalt:iptables-restore < /etc/iptables/rules.v4folgende Befehle im Container ausgeführt:
pkill -u iobroker sudo apt-get update && sudo apt-get -y upgrade sudo apt-get -y install iptables sudo apt-get install iptables-persistent update-alternatives --set iptables /usr/sbin/iptables-legacyPortweiterleitung auf 8090
sudo iptables -I INPUT 1 -p tcp --dport 80 -j ACCEPT sudo iptables -A PREROUTING -t nat -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 8090 sudo iptables -t nat -LSpeichern der Portweiterleitung
iptables-save > /etc/iptables/rules.v4 iptables-restore < /etc/iptables/rules.v4Nach Neustart funktioniert zwar der node red Adapter für Alexa, jedoch Alexa2 und telegram nicht mehr.
-
So wieder etwas weiter hab jetzt die Portweiterleitung gemacht, jedoch gibt es danach das Problem, das Alexa und Telegram nicht mehr starten, wenn ich den Port vor dem ioBroker start umleite.
Ich bräuchte hier echt mal hilfe.
Hat irgend jemant eine Idee wie ich es möglich mache, den Port 80 direkt im Docker Container zu verwenden.
Hier zur Info was ich gemacht habe:Userdefined startup scripts im Container gemountet****
/opt/userscripts iobroker_userscripts
userscript_everystart.sh mit folgenden inhalt:iptables-restore < /etc/iptables/rules.v4folgende Befehle im Container ausgeführt:
pkill -u iobroker sudo apt-get update && sudo apt-get -y upgrade sudo apt-get -y install iptables sudo apt-get install iptables-persistent update-alternatives --set iptables /usr/sbin/iptables-legacyPortweiterleitung auf 8090
sudo iptables -I INPUT 1 -p tcp --dport 80 -j ACCEPT sudo iptables -A PREROUTING -t nat -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 8090 sudo iptables -t nat -LSpeichern der Portweiterleitung
iptables-save > /etc/iptables/rules.v4 iptables-restore < /etc/iptables/rules.v4Nach Neustart funktioniert zwar der node red Adapter für Alexa, jedoch Alexa2 und telegram nicht mehr.
So jetzt habe ich eine Lösung die auf jeden Fall mal funktioniert :
(wieso die Lösung mit iptables-restore nicht geht verstehe ich nicht).Wichtig ist, das der Container mit hoher priorität läuft sonst funktioniert es nicht.
Userdefined startup scripts im Container mounten
/opt/userscripts iobroker_userscripts
userscript_everystart.sh mit folgenden inhalt:sudo iptables -A PREROUTING -t nat -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 8080folgende Befehle im Container ausgeführt:
pkill -u iobroker sudo apt-get update && sudo apt-get -y upgrade sudo apt-get -y install iptables update-alternatives --set iptables /usr/sbin/iptables-legacy iobroker startNach dem Neustart des Containers prüfen über
sudo iptables -t nat -Lob die Umleitung auch aktiv ist.
-
So jetzt habe ich eine Lösung die auf jeden Fall mal funktioniert :
(wieso die Lösung mit iptables-restore nicht geht verstehe ich nicht).Wichtig ist, das der Container mit hoher priorität läuft sonst funktioniert es nicht.
Userdefined startup scripts im Container mounten
/opt/userscripts iobroker_userscripts
userscript_everystart.sh mit folgenden inhalt:sudo iptables -A PREROUTING -t nat -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 8080folgende Befehle im Container ausgeführt:
pkill -u iobroker sudo apt-get update && sudo apt-get -y upgrade sudo apt-get -y install iptables update-alternatives --set iptables /usr/sbin/iptables-legacy iobroker startNach dem Neustart des Containers prüfen über
sudo iptables -t nat -Lob die Umleitung auch aktiv ist.
Also ich bin mir nicht ganz so sicher, ob du das mit dem Docker und diesen Containern richtig verstanden hast...
Ein Docker Container ist so konzipiert, dass man ihn einfach wegschmeissen und neu deployen kann - und alles funktioniert danach noch genauso wie vorher, weil jegliche Daten außerhalb des Containers gespeichert werden. Dies impliziert aber auch, dass man innerhalb eines Containers keine Veränderungen durchführt, weil sie im Zweifel nach einem Redeploy weg sind. Ein Container darf außerhalb der persistierten Bereiche nicht verändert werden.Wenn du in deinem Container etwas installierst, dann wirst du den Container nie wieder anfassen können - weil es ja nur in deiner einen Instanz existiert. Sprich: du wirst auch niemals ein Update durchführen können. Denn innerhalb eines Containers verändert man ja nichts...
Wenn du zusätzlich zu iobroker noch etwas anderes benötigst, dann solltest du dafür einen extra Container des Herstellers (oder der Community) benutzen und die beiden irgendwie vernetzen.
Daher nur der gut gemeinte Rat: Was du gerade tust, wird dir sehr bald leid tun, weil du dich in eine Sackgasse manövriert hast.
Noch ein Tip am Rande: verwende bei buanet/iobroker nie den :latest Tag! Andre selbst warnt davor, da im :latest auch "beta" Features sein könnten, die entweder gar nicht richtig funktionieren oder noch buggy sind. Gerade bei iobroker sollte man Updates nur sehr gezielt einsetzen, da man sich sonst das gesamte System zerschießen kann. Aktuell ist imho die v1.5.0 und diesen Tag solltest du auch deployen.Just my .02€
S -
Also ich bin mir nicht ganz so sicher, ob du das mit dem Docker und diesen Containern richtig verstanden hast...
Ein Docker Container ist so konzipiert, dass man ihn einfach wegschmeissen und neu deployen kann - und alles funktioniert danach noch genauso wie vorher, weil jegliche Daten außerhalb des Containers gespeichert werden. Dies impliziert aber auch, dass man innerhalb eines Containers keine Veränderungen durchführt, weil sie im Zweifel nach einem Redeploy weg sind. Ein Container darf außerhalb der persistierten Bereiche nicht verändert werden.Wenn du in deinem Container etwas installierst, dann wirst du den Container nie wieder anfassen können - weil es ja nur in deiner einen Instanz existiert. Sprich: du wirst auch niemals ein Update durchführen können. Denn innerhalb eines Containers verändert man ja nichts...
Wenn du zusätzlich zu iobroker noch etwas anderes benötigst, dann solltest du dafür einen extra Container des Herstellers (oder der Community) benutzen und die beiden irgendwie vernetzen.
Daher nur der gut gemeinte Rat: Was du gerade tust, wird dir sehr bald leid tun, weil du dich in eine Sackgasse manövriert hast.
Noch ein Tip am Rande: verwende bei buanet/iobroker nie den :latest Tag! Andre selbst warnt davor, da im :latest auch "beta" Features sein könnten, die entweder gar nicht richtig funktionieren oder noch buggy sind. Gerade bei iobroker sollte man Updates nur sehr gezielt einsetzen, da man sich sonst das gesamte System zerschießen kann. Aktuell ist imho die v1.5.0 und diesen Tag solltest du auch deployen.Just my .02€
S@Satsh
ja ich hab das schon richtig verstanden.
Ich finde leider keine andere Möglichkeit den Port 80 in node red zu verwenden.
Was ich nicht beschrieben habe aber funktioniert ist auch das firststart script zu verwenden. Da diese ja außerhalb des Docker Containers liegen und somit nicht mit weggeworfen werden wird es nach recreate wieder so hergestellt.Wenn man das untere Script in das Startscript: userscript_firststart.sh einbindet
sudo apt-get update && sudo apt-get -y upgrade sudo apt-get -y install iptables update-alternatives --set iptables /usr/sbin/iptables-legacyund
sudo iptables -A PREROUTING -t nat -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 8080in das userscript_everystart.sh
dann wird alles wieder genau so angelegt das es funktioniert.
Was ich jedoch noch nicht herausgefunden habe, wie ich einen Docker container kopiere in welche sowohl das macvlan als auch die bridge aktive sind. Ich muss immer die Bridge nach dem Containerstart wieder hinzufügen.Vielleicht hast du ja noch eine andere Möglichkeit das port 80 zu verwenden ohne irgendetwas zu ändern.
-
Also ich bin mir nicht ganz so sicher, ob du das mit dem Docker und diesen Containern richtig verstanden hast...
Ein Docker Container ist so konzipiert, dass man ihn einfach wegschmeissen und neu deployen kann - und alles funktioniert danach noch genauso wie vorher, weil jegliche Daten außerhalb des Containers gespeichert werden. Dies impliziert aber auch, dass man innerhalb eines Containers keine Veränderungen durchführt, weil sie im Zweifel nach einem Redeploy weg sind. Ein Container darf außerhalb der persistierten Bereiche nicht verändert werden.Wenn du in deinem Container etwas installierst, dann wirst du den Container nie wieder anfassen können - weil es ja nur in deiner einen Instanz existiert. Sprich: du wirst auch niemals ein Update durchführen können. Denn innerhalb eines Containers verändert man ja nichts...
Wenn du zusätzlich zu iobroker noch etwas anderes benötigst, dann solltest du dafür einen extra Container des Herstellers (oder der Community) benutzen und die beiden irgendwie vernetzen.
Daher nur der gut gemeinte Rat: Was du gerade tust, wird dir sehr bald leid tun, weil du dich in eine Sackgasse manövriert hast.
Noch ein Tip am Rande: verwende bei buanet/iobroker nie den :latest Tag! Andre selbst warnt davor, da im :latest auch "beta" Features sein könnten, die entweder gar nicht richtig funktionieren oder noch buggy sind. Gerade bei iobroker sollte man Updates nur sehr gezielt einsetzen, da man sich sonst das gesamte System zerschießen kann. Aktuell ist imho die v1.5.0 und diesen Tag solltest du auch deployen.Just my .02€
S@Satsh
Zum unteren Absatz. (Noch ein Tip am Rande).
Da verstehe ich leider einiges nicht.
latest zieht das letzte freigegebene Release und somit akutell die Version V5.0
und nicht die Beta. Was du mit v1.5.0 meinst verstehe ich auch nicht ein solche Version gibt es gar nicht bei buanet/iobroker.Mit dem iobroker selbst hat der Docker Container "eigentlich garnicht so richtig was zu tun", da dieser ja beim Container Start installiert wird bzw. die vorhandene - ausgelagerte Installation verwendet wir. Also ich hatte derartige Probleme noch nie und falls etwas nicht funktioniert verwende ich einfach den alten Docker Container wieder - Ich hab ja ein Backup :blush:
-
@Satsh
Zum unteren Absatz. (Noch ein Tip am Rande).
Da verstehe ich leider einiges nicht.
latest zieht das letzte freigegebene Release und somit akutell die Version V5.0
und nicht die Beta. Was du mit v1.5.0 meinst verstehe ich auch nicht ein solche Version gibt es gar nicht bei buanet/iobroker.Mit dem iobroker selbst hat der Docker Container "eigentlich garnicht so richtig was zu tun", da dieser ja beim Container Start installiert wird bzw. die vorhandene - ausgelagerte Installation verwendet wir. Also ich hatte derartige Probleme noch nie und falls etwas nicht funktioniert verwende ich einfach den alten Docker Container wieder - Ich hab ja ein Backup :blush:
Sorry, hatte mich mit der Version vertan - schrieb ja auch, dass ich mir nicht ganz sicher war. Hatte es mit einem anderen Deployment verwechselt.
Aber du bist - wie viele andere vor dir - auf ":latest" hereingefallen in dem Glauben, dass es immer die aktuellste Version enthält. Das ist falsch. :latest ist nur ein Default Tag, der vergeben wird, wenn kein Tag gesetzt ist. Sprich: :5.0.0 könnte theoretisch aktueller als :latest sein - je nachdem ob und wie der Publisher :latest setzt. Denn :latest ist NICHT dynamisch, sondern ein fester Tag.
Grundsätzlich gilt: :latest ist ein undefinierter Tag. Man sollte :latest NUR nutzen, wenn man GANZ genau weiß, WARUM man :latest benutzt oder benutzen will.Die Ursache warum du Port 80 nicht nutzen kannst ist einfach, dass jegliche Ports <1024 nur von root geöffnet werden können und iobroker nicht mit root Rechten im Container läuft.
Die Frage, die sich mir stellt, ist aber: warum willst du denn unbedingt Port 80 benutzen? Außer mit solchen Verrenkungen wie du sie gemacht hast, ist das eigentlich nicht möglich und aus meiner Sicht auch nicht sinnvoll. Alle Änderungen, die du gemacht hast, sind ja nach einem Redeploy weg, denn es ist auch nicht sichergestellt, dass die Scripte nicht ausgetauscht werden bei einer der nächsten Versionen... alles auf jeden Fall sehr fragil und nicht so gedacht.
-
Sorry, hatte mich mit der Version vertan - schrieb ja auch, dass ich mir nicht ganz sicher war. Hatte es mit einem anderen Deployment verwechselt.
Aber du bist - wie viele andere vor dir - auf ":latest" hereingefallen in dem Glauben, dass es immer die aktuellste Version enthält. Das ist falsch. :latest ist nur ein Default Tag, der vergeben wird, wenn kein Tag gesetzt ist. Sprich: :5.0.0 könnte theoretisch aktueller als :latest sein - je nachdem ob und wie der Publisher :latest setzt. Denn :latest ist NICHT dynamisch, sondern ein fester Tag.
Grundsätzlich gilt: :latest ist ein undefinierter Tag. Man sollte :latest NUR nutzen, wenn man GANZ genau weiß, WARUM man :latest benutzt oder benutzen will.Die Ursache warum du Port 80 nicht nutzen kannst ist einfach, dass jegliche Ports <1024 nur von root geöffnet werden können und iobroker nicht mit root Rechten im Container läuft.
Die Frage, die sich mir stellt, ist aber: warum willst du denn unbedingt Port 80 benutzen? Außer mit solchen Verrenkungen wie du sie gemacht hast, ist das eigentlich nicht möglich und aus meiner Sicht auch nicht sinnvoll. Alle Änderungen, die du gemacht hast, sind ja nach einem Redeploy weg, denn es ist auch nicht sichergestellt, dass die Scripte nicht ausgetauscht werden bei einer der nächsten Versionen... alles auf jeden Fall sehr fragil und nicht so gedacht.
Hallo @Satsh wie in meinem ersten post beschrieben, benutze ich in node red den Skill node-red-contrib-amazon-echo und hiervon das node "Amazon Echo Hub" um Sprachbefehle von Alexa im ioBroker umzusetzen. Hierbei muß zwingen Port 80 verwendet werden, da die Echo's der 2. und 3. Generation (besser ab einem bestimmten Update) nur noch auf diesem Port nach Geräten suchen.
Das mit den Root Rechten und <1024 weiß ich, jedoch sollte aus meiner Sicht die "Capabilitie" -"NET_BIND_SERVICE" es zulassen dies auch ohne Root Rechte zu verwenden. (siehe post1) Dies funktioniert aber anscheinend nicht.
Die Skripte welche ich verwende sind speziell als User Skripte ausgelegt, deshalb sollten diese auch weiterhin Bestand haben und auch durch Updates nicht angefasst werden.
Wichtig wäre mir ob irgendjemand vielleicht noch eine Idee hat, wieso es über das setzen von "NET_BIND_SERVICE" nicht funktioniert oder ist das ein Fehler im Docker Image. -
Hallo @Satsh wie in meinem ersten post beschrieben, benutze ich in node red den Skill node-red-contrib-amazon-echo und hiervon das node "Amazon Echo Hub" um Sprachbefehle von Alexa im ioBroker umzusetzen. Hierbei muß zwingen Port 80 verwendet werden, da die Echo's der 2. und 3. Generation (besser ab einem bestimmten Update) nur noch auf diesem Port nach Geräten suchen.
Das mit den Root Rechten und <1024 weiß ich, jedoch sollte aus meiner Sicht die "Capabilitie" -"NET_BIND_SERVICE" es zulassen dies auch ohne Root Rechte zu verwenden. (siehe post1) Dies funktioniert aber anscheinend nicht.
Die Skripte welche ich verwende sind speziell als User Skripte ausgelegt, deshalb sollten diese auch weiterhin Bestand haben und auch durch Updates nicht angefasst werden.
Wichtig wäre mir ob irgendjemand vielleicht noch eine Idee hat, wieso es über das setzen von "NET_BIND_SERVICE" nicht funktioniert oder ist das ein Fehler im Docker Image.@Dragondrummer71
Bitte sieh mir nach, wenn ich den Thread jetzt nur überflogen habe, aber generell musst du, wenn du die Capabilities beim Erstellen des containers gesetzt hast, nach dem Start die capabilities per "setcap" auch noch für das Programm setzen, das diese Berechtigung verwenden soll. Hier mal ein Beispiel aus der Doku des radar2 Adapters für das Setzen der Capabilities für node:sudo setcap cap_net_admin,cap_net_raw,cap_net_bind_service=+eip $(eval readlink -f `which node`)MfG,
André -
@Dragondrummer71
Bitte sieh mir nach, wenn ich den Thread jetzt nur überflogen habe, aber generell musst du, wenn du die Capabilities beim Erstellen des containers gesetzt hast, nach dem Start die capabilities per "setcap" auch noch für das Programm setzen, das diese Berechtigung verwenden soll. Hier mal ein Beispiel aus der Doku des radar2 Adapters für das Setzen der Capabilities für node:sudo setcap cap_net_admin,cap_net_raw,cap_net_bind_service=+eip $(eval readlink -f `which node`)MfG,
AndréHallo @andre
genau so etwas habe ich gesucht, doch leider funktioniert das nicht. Ich denke der "ioBroker fixer" macht das gleiche, jedoch kommt dabei auch diese Fehlermeldung (wie im 1. Post geschrieben für den ioBroker Fixer):root@iobroker-master:/usr/bin# sudo setcap cap_net_admin=+eip $(eval readlink -f `which node`) Failed to set capabilities on file `/usr/bin/node' (Operation not supported) The value of the capability argument is not permitted for a file. Or the file is not a regular (non-symlink) fileIch habe diese beiden Themen gefunden klingen etwas wie meins:
https://github.com/buanet/docker-iobroker/issues/37
https://github.com/ioBroker/ioBroker/issues/146 -
Hallo @andre
genau so etwas habe ich gesucht, doch leider funktioniert das nicht. Ich denke der "ioBroker fixer" macht das gleiche, jedoch kommt dabei auch diese Fehlermeldung (wie im 1. Post geschrieben für den ioBroker Fixer):root@iobroker-master:/usr/bin# sudo setcap cap_net_admin=+eip $(eval readlink -f `which node`) Failed to set capabilities on file `/usr/bin/node' (Operation not supported) The value of the capability argument is not permitted for a file. Or the file is not a regular (non-symlink) fileIch habe diese beiden Themen gefunden klingen etwas wie meins:
https://github.com/buanet/docker-iobroker/issues/37
https://github.com/ioBroker/ioBroker/issues/146@Dragondrummer71 sagte in buanet/iobroker node red port 80:
Failed to set capabilities on file `/usr/bin/node' (Operation not supported)
The value of the capability argument is not permitted for a file. Or the file is not a regular (non-symlink) fileHast du dash hier auch gefunden?
https://serverfault.com/questions/665709/allowing-node-js-applications-to-run-on-port-80Dort die Antwort 2. Offenbar liegt bei dir unter /usr/bin/node ein symlink. Du könntest mal schauen wohin der führt und das setcap dann dagegen ausführen... Was allerdings komisch ist, ist dass es bei mir im Container einwandfrei funktioniert. Eigentlich sollten die Container alle gleich aufgebaut sein. Werde gleich nochmal testen ob ich das irgendwie reproduziert bekomme....
MfG,
André -
@Dragondrummer71 sagte in buanet/iobroker node red port 80:
Failed to set capabilities on file `/usr/bin/node' (Operation not supported)
The value of the capability argument is not permitted for a file. Or the file is not a regular (non-symlink) fileHast du dash hier auch gefunden?
https://serverfault.com/questions/665709/allowing-node-js-applications-to-run-on-port-80Dort die Antwort 2. Offenbar liegt bei dir unter /usr/bin/node ein symlink. Du könntest mal schauen wohin der führt und das setcap dann dagegen ausführen... Was allerdings komisch ist, ist dass es bei mir im Container einwandfrei funktioniert. Eigentlich sollten die Container alle gleich aufgebaut sein. Werde gleich nochmal testen ob ich das irgendwie reproduziert bekomme....
MfG,
André@andre
Ich denke das ist kein symlink:root@iobroker-master:/opt/iobroker# which node /usr/bin/node root@iobroker-master:/opt/iobroker# ls -la /usr/bin/node -rwxr-xr-x 1 root root 48646656 Jul 22 17:00 /usr/bin/nodeHatte gestern auch nochmal einen ganz neuen Container ohne irgendetwas zu verändern aufgesetzt, gleiches Ergebniss: Failed to set capabilities............ Hier bekomme ich aber auch noch einen "sudo" fehler.
root@test:/opt/iobroker# sudo setcap cap_net_admin=+eip $(eval readlink -f `which node`) sudo: Die Audit-Nachricht kann nicht gesendet werden: Die Operation ist nicht erlaubt Failed to set capabilities on file `/usr/bin/node' (Operation not supported) The value of the capability argument is not permitted for a file. Or the file is not a regular (non-symlink) file -
@andre
Ich denke das ist kein symlink:root@iobroker-master:/opt/iobroker# which node /usr/bin/node root@iobroker-master:/opt/iobroker# ls -la /usr/bin/node -rwxr-xr-x 1 root root 48646656 Jul 22 17:00 /usr/bin/nodeHatte gestern auch nochmal einen ganz neuen Container ohne irgendetwas zu verändern aufgesetzt, gleiches Ergebniss: Failed to set capabilities............ Hier bekomme ich aber auch noch einen "sudo" fehler.
root@test:/opt/iobroker# sudo setcap cap_net_admin=+eip $(eval readlink -f `which node`) sudo: Die Audit-Nachricht kann nicht gesendet werden: Die Operation ist nicht erlaubt Failed to set capabilities on file `/usr/bin/node' (Operation not supported) The value of the capability argument is not permitted for a file. Or the file is not a regular (non-symlink) fileDu 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.
-
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.
@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. -
@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.@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é -
@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.@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 dankbarVG
-
@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 dankbarVG
@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 0und
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
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 0und
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@Dragondrummer71
Danke für deine ausführliche Antwort. Toll!
Morgen teste ich das mal aus.👍 -
@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 0und
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@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 permittedIm Moment bin ich ratlos
840
Online32.5k
Benutzer81.7k
Themen1.3m
Beiträge