NEWS
Docker Container Port
-
Updating Linux packages on first run... Done. Registering maintenance script as command... Done. -------------------------------------------------------------------------------- ----- Step 2 of 5: Detecting ioBroker installation ----- -------------------------------------------------------------------------------- There is no data detected in /opt/iobroker. Restoring initial ioBroker installation... Done. -------------------------------------------------------------------------------- ----- Step 3 of 5: Checking ioBroker installation ----- -------------------------------------------------------------------------------- (Re)setting permissions (This might take a while! Please be patient!)... Done. Fixing "sudo-bug" by replacing sudo with gosu... Done. Initializing a fresh installation of ioBroker... Done. Hostname in ioBroker does not match the hostname of this container. Updating hostname to "buanet-iobroker1"... The host for instance "system.adapter.admin.0" was changed from "buildkitsandbox" to "buanet-iobroker1". The host for instance "system.adapter.discovery.0" was changed from "buildkitsandbox" to "buanet-iobroker1". The host for instance "system.adapter.backitup.0" was changed from "buildkitsandbox" to "buanet-iobroker1". Done. -------------------------------------------------------------------------------- ----- Step 4 of 5: Applying special settings ----- -------------------------------------------------------------------------------- Some adapters have special requirements/ settings which can be activated by the use of environment variables. For more information see ioBroker Docker Image Docs (https://docs.buanet.de/iobroker-docker-image/docs/). -------------------------------------------------------------------------------- ----- Step 5 of 5: ioBroker startup ----- -------------------------------------------------------------------------------- Starting ioBroker... ##### #### ### ## # iobroker.js-controller log output # ## ### #### ##### host.buanet-iobroker1 check instance "system.adapter.admin.0" for host "buanet-iobroker1" host.buanet-iobroker1 check instance "system.adapter.discovery.0" for host "buanet-iobroker1" host.buanet-iobroker1 check instance "system.adapter.backitup.0" for host "buanet-iobroker1" ================================== > LOG REDIRECT system.adapter.admin.0 => true [system.adapter.admin.0.logging] ================================== > LOG REDIRECT system.adapter.admin.0 => false [Process stopped] ================================== > LOG REDIRECT system.adapter.admin.0 => false [system.adapter.admin.0.logging] Send diag info: {"uuid":"fac0af65-39f4-423e-a984-179fd3b42468","language":"de","country":"Germany","hosts":[{"version":"4.0.24","platform":"Javascript/Node.js","type":"linux"}],"node":"v18.16.1","arch":"x64","docker":true,"adapters":{"admin":{"version":"6.3.5","platform":"Javascript/Node.js"},"discovery":{"version":"3.1.0","platform":"Javascript/Node.js"},"backitup":{"version":"2.6.23","platform":"Javascript/Node.js"}},"statesType":"jsonl","objectsType":"jsonl","noInstances":3,"compactMode":false,"noCompactInstances":0,"model":"Intel(R) Celeron(R) CPU J3355 @ 2.00GHz","cpus":2,"mem":6067273728,"ostype":"Linux","city":"Berlin"} ================================== > LOG REDIRECT system.adapter.admin.0 => true [system.adapter.admin.0.logging] Recived termination signal (SIGTERM). Shutting down ioBroker... .================================== > LOG REDIRECT system.adapter.admin.0 => false [Process stopped] ================================== > LOG REDIRECT system.adapter.admin.0 => false [system.adapter.admin.0.logging] . DoIch sehe da nichts Auffälliges außer vielleicht
Hostname in ioBroker does not match the hostname of this container. Updating hostname to "buanet-iobroker1"... The host for instance "system.adapter.admin.0" was changed from "buildkitsandbox" to "buanet-iobroker1".Entsprechend deiner Signatur hast du sogar ziemlich genau meine Hardware. Die DS218+, die 7590, Homematic (CCU3?), Hue etc. und ein 3 B+ (der bei mir am 3D-Drucker hängt)
-
Recived termination signal (SIGTERM). Shutting down ioBroker...Das würde mir mehr Gedanken machen.
Ich kann leider nicht gegentesten, da ich ganz andere Versionen benutze.@haselchen Das war wohl ich mit dem Schieber, der den Container wieder deaktiviert. Ich wollte dir einen Überblick von Start bis Ende geben ;)
-
@haselchen Das war wohl ich mit dem Schieber, der den Container wieder deaktiviert. Ich wollte dir einen Überblick von Start bis Ende geben ;)
Hast du mal versucht den Iobroker Ordner zu mounten?
Eigentlich habe ich das vorausgesetzt. Aber fragen kost ja nix 😉Edit : gesehen in deinen Screenshots das du das gemacht hast
Tja mehr Ideen habe ich leider nicht .
Normal ganz easy das Ganze.
Aber bei dir ist da irgendwo der Wurm drin -
Hast du mal versucht den Iobroker Ordner zu mounten?
Eigentlich habe ich das vorausgesetzt. Aber fragen kost ja nix 😉Edit : gesehen in deinen Screenshots das du das gemacht hast
Tja mehr Ideen habe ich leider nicht .
Normal ganz easy das Ganze.
Aber bei dir ist da irgendwo der Wurm drin@haselchen Auf jeden Fall noch einmal vielen Dank für deine Hilfe. Ich tüftle morgen und die nächsten Tage weiter dran ;) Falls ich es schaffe, poste ich natürlich die Lösung.
-
@haselchen Den automatischen Neustart habe ich nur für Testzwecke ausgeschaltet, bzw. nicht eingeschaltet. Ich hatte beim PiHole mal einen Bootloop.
Leider auch bei hoher Prio weder über https 8081 noch über http 8080 erreichbar.
@tjaden sagte in Docker Container Port:
Leider auch bei hoher Prio weder über https 8081 noch über http 8080 erreichbar.
Ein frisch aufgesetzter Container ist nicht über httpS://<IP>:8081 zu erreichen, sondern über http://<IP>:8081. Vielleicht ist das schon dein Problem!?
-
@haselchen Das war wohl ich mit dem Schieber, der den Container wieder deaktiviert. Ich wollte dir einen Überblick von Start bis Ende geben ;)
-
@tjaden sagte in Docker Container Port:
Leider auch bei hoher Prio weder über https 8081 noch über http 8080 erreichbar.
Ein frisch aufgesetzter Container ist nicht über httpS://<IP>:8081 zu erreichen, sondern über http://<IP>:8081. Vielleicht ist das schon dein Problem!?
@marc-berg Oh Mann...
Du hast Recht! Aber warum?
Der andere Container war doch über das Port Mapping direkt mittels HTTPS erreichbar. Der bleibt auch nach gelöschtem Mapping nicht erreichbar, egal mit welcher Protokoll-Port-Kombination.
Warum auch immer das so funktioniert:
Danke! Danke, Danke, Danke! :+1: :+1: :+1: :+1:
-
@marc-berg Oh Mann...
Du hast Recht! Aber warum?
Der andere Container war doch über das Port Mapping direkt mittels HTTPS erreichbar. Der bleibt auch nach gelöschtem Mapping nicht erreichbar, egal mit welcher Protokoll-Port-Kombination.
Warum auch immer das so funktioniert:
Danke! Danke, Danke, Danke! :+1: :+1: :+1: :+1:
Nachtrag: Alles läuft – bis auf vis:
$ iobroker add vis --host buanet-iobroker-bullseye NPM version: 9.5.1 Installing iobroker.vis@1.4.16... (System call) host.buanet-iobroker-bullseye Cannot install iobroker.vis@1.4.16: 6 ERROR: Process exited with code 25Nachtrag: Die Installation von 1.4.5 hat aber funktioniert.
Nachtrag 2: Das Upgrade von 1.4.5 zu 1.4.16 hat dann auch funktioniert. -
Nachtrag: Alles läuft – bis auf vis:
$ iobroker add vis --host buanet-iobroker-bullseye NPM version: 9.5.1 Installing iobroker.vis@1.4.16... (System call) host.buanet-iobroker-bullseye Cannot install iobroker.vis@1.4.16: 6 ERROR: Process exited with code 25Nachtrag: Die Installation von 1.4.5 hat aber funktioniert.
Nachtrag 2: Das Upgrade von 1.4.5 zu 1.4.16 hat dann auch funktioniert. -
@haselchen Jepp. Ich werde wohl in Zukunft im Zweifel einfach den Container austauschen. Die diversen Besonderheiten habe ich mir notiert, damit ich mich auch in einem halben Jahr noch daran erinnern kann ;)
Ich mache ja sonst sehr selten was mit Linux bzw. Debian und jedes Mal ist es so ein Krampf. Das motiviert nicht gerade sich da tiefer einzuarbeiten.
-
@haselchen Jepp. Ich werde wohl in Zukunft im Zweifel einfach den Container austauschen. Die diversen Besonderheiten habe ich mir notiert, damit ich mich auch in einem halben Jahr noch daran erinnern kann ;)
Ich mache ja sonst sehr selten was mit Linux bzw. Debian und jedes Mal ist es so ein Krampf. Das motiviert nicht gerade sich da tiefer einzuarbeiten.
@tjaden sagte in Docker Container Port:
Ich mache ja sonst sehr selten was mit Linux bzw. Debian und jedes Mal ist es so ein Krampf.
Das eine könnte ursächlich für das andere sein.
-
@haselchen Jepp. Ich werde wohl in Zukunft im Zweifel einfach den Container austauschen. Die diversen Besonderheiten habe ich mir notiert, damit ich mich auch in einem halben Jahr noch daran erinnern kann ;)
Ich mache ja sonst sehr selten was mit Linux bzw. Debian und jedes Mal ist es so ein Krampf. Das motiviert nicht gerade sich da tiefer einzuarbeiten.
@tjaden sagte in Docker Container Port:
Ich mache ja sonst sehr selten was mit Linux bzw. Debian und jedes Mal ist es so ein Krampf
Die "Spezialitäten" von Containern sind unabhängig von Linux
-
@marc-berg Oh Mann...
Du hast Recht! Aber warum?
Der andere Container war doch über das Port Mapping direkt mittels HTTPS erreichbar. Der bleibt auch nach gelöschtem Mapping nicht erreichbar, egal mit welcher Protokoll-Port-Kombination.
Warum auch immer das so funktioniert:
Danke! Danke, Danke, Danke! :+1: :+1: :+1: :+1:
@tjaden sagte in Docker Container Port:
Der andere Container war doch über das Port Mapping direkt mittels HTTPS erreichbar.
Keine Ahnung, was jetzt gerade der "andere Container" ist. So wie ich dich verstanden hatte, war der ursprüngliche Container im Host-Modus aufgesetzt. Da muss man grundsätzlich keine Ports weiterleiten.
Der bleibt auch nach gelöschtem Mapping nicht erreichbar, egal mit welcher Protokoll-Port-Kombination.
Auch hier: welcher ist jetzt "Der"?
Wenn ioBroker per HTTPS auf deinem ursprünglichen Container erreichbar war, dann hattest du ja in jedem Fall etwas manuell angepasst. Das kann jetzt auf einem jungfräulichen Container noch nicht aktiv sein.
-
@tjaden sagte in Docker Container Port:
Der andere Container war doch über das Port Mapping direkt mittels HTTPS erreichbar.
Keine Ahnung, was jetzt gerade der "andere Container" ist. So wie ich dich verstanden hatte, war der ursprüngliche Container im Host-Modus aufgesetzt. Da muss man grundsätzlich keine Ports weiterleiten.
Der bleibt auch nach gelöschtem Mapping nicht erreichbar, egal mit welcher Protokoll-Port-Kombination.
Auch hier: welcher ist jetzt "Der"?
Wenn ioBroker per HTTPS auf deinem ursprünglichen Container erreichbar war, dann hattest du ja in jedem Fall etwas manuell angepasst. Das kann jetzt auf einem jungfräulichen Container noch nicht aktiv sein.
@marc-berg said in Docker Container Port:
Keine Ahnung, was jetzt gerade der "andere Container" ist.
Ich hatte im Endeffekt noch zwei neue Container angelegt (bzw. hatte ich diese neuen noch "übrig", nachdem ich andere Versuchskandidaten wieder gelöscht hatte)
@marc-berg said in Docker Container Port:
Auch hier: welcher ist jetzt "Der"?
Ein und derselbe. Nennen wir ihn C. Der Container C wurde mit gemapptem 8081-Port angelegt. Das hatte ja auch funktioniert mittels https-Protokoll direkt ab Installation. Deswegen war ich bei diesem Container C dann auch schon einen Schritt weiter und habe das Backup vom alten Container "wiederhergestellt". Nun hatte ich bei Container C den einen gemappten Port wieder gelöscht und konnte ihn dennoch nicht via http und 8081, bzw. allen anderen möglichen Kombinationen aufrufen.
Der zuvor angelegte Container B wurde im Host-Modus, d. h. mit der gleichen Netzwerknutzung wie Docker angelegt und war nun mit der Kombination http/8081 erreichbar.
@Thomas-Braun
Wo hast du nur bei meinem letzten Thread gesteckt? :grin:@homoran said in Docker Container Port:
Die "Spezialitäten" von Containern sind unabhängig von Linux
Container sind aber mehr oder weniger mein einziger Berührungspunkt. Ansonsten hatte ich lediglich für den Pi ein fertiges Octoprint-Image genutzt und mache da allenfalls Updates über SSH.
-
@marc-berg said in Docker Container Port:
Keine Ahnung, was jetzt gerade der "andere Container" ist.
Ich hatte im Endeffekt noch zwei neue Container angelegt (bzw. hatte ich diese neuen noch "übrig", nachdem ich andere Versuchskandidaten wieder gelöscht hatte)
@marc-berg said in Docker Container Port:
Auch hier: welcher ist jetzt "Der"?
Ein und derselbe. Nennen wir ihn C. Der Container C wurde mit gemapptem 8081-Port angelegt. Das hatte ja auch funktioniert mittels https-Protokoll direkt ab Installation. Deswegen war ich bei diesem Container C dann auch schon einen Schritt weiter und habe das Backup vom alten Container "wiederhergestellt". Nun hatte ich bei Container C den einen gemappten Port wieder gelöscht und konnte ihn dennoch nicht via http und 8081, bzw. allen anderen möglichen Kombinationen aufrufen.
Der zuvor angelegte Container B wurde im Host-Modus, d. h. mit der gleichen Netzwerknutzung wie Docker angelegt und war nun mit der Kombination http/8081 erreichbar.
@Thomas-Braun
Wo hast du nur bei meinem letzten Thread gesteckt? :grin:@homoran said in Docker Container Port:
Die "Spezialitäten" von Containern sind unabhängig von Linux
Container sind aber mehr oder weniger mein einziger Berührungspunkt. Ansonsten hatte ich lediglich für den Pi ein fertiges Octoprint-Image genutzt und mache da allenfalls Updates über SSH.
@tjaden sagte in Docker Container Port:
Wo hast du nur bei meinem letzten Thread gesteckt?
Vermutlich hab ich da was von Container-Gedönse gelesen und bin gleich weiter gesprungen.
Support us
968
Online32.5k
Benutzer81.8k
Themen1.3m
Beiträge