buanet/iobroker node red port 80
-
@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.
-
@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
-
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. -
@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 -
@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 -
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
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"
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é -
@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 -
@Dragondrummer71
Danke für deine ausführliche Antwort. Toll!
Morgen teste ich das mal aus.
-
@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
-
@vepman Versuchs mal ohne sudo.
-
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# -
@vepman Bekommst du eine Ausgabe bei:
iptables -t nat -LDer 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 loggingDu 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. -
@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. -
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
