Neuer Blogbeitrag: Monatsrückblick - Dezember 2025 🎄

[mcBirne]

Hallo zusammen,
ich bin wieder im Lande ;-)
mir ist aufgefallen, dass scheinbar seit der Neuinstallation und dem Rückspielen des Updates 3 Adapter ständig gelb sind und nicht funktionieren. Das würde ich gerne erstmal wider an Laufen bekommen, bevor wir schauen, ob man es besser aufsetzten kann.
Einer von denen ist der SQL Adapter. Ich erhalte folgende Fehlermeldung connect ECONNREFUSED 127.0.0.1:3308. hat jemand eine Idee, warum ich damit keiner Verbindung mehr herstellen kann? Die Datenbank (MariaDB 10) läuft und ich kann über phpMyAdmin daruf zugreifen.

[Homoran]

@mcbirne more Input!

@mcbirne sagte in Update vom Container gemacht und nun läuft nichts mehr:

Die Datenbank (MariaDB 10) läuft

wo?

[mcBirne]

@homoran
die Maria DB läuft auf dem Synology NAS, wo auch der ioBroker läuft. Also auf der selben IP

[Homoran]

@mcbirne sagte in Update vom Container gemacht und nun läuft nichts mehr:

@homoran
die Maria DB läuft auf dem Synology NAS, wo auch der ioBroker läuft. Also auf der selben IP

im selben Container?
oder haben diese Blechbüchsen da wieder was anderes?

127.0.0.1 ist localhost

[mcBirne]

@homoran
auf dem selben Gerät, aber nicht im selben Container. Vor der Neuinstallation vom ioBroker samt Rückspielen des Backups hat die Konstellation mit 127.0.0.1 funktioniert. Die Einstellungen wurden ja auch mit dem Backup wiederhergestellt.
Kann es sein, das bei dem neuen ioBrocker Container etwas anders ist und er eine andere IP hat?

[Homoran]

@mcbirne sagte in Update vom Container gemacht und nun läuft nichts mehr:

Kann es sein, das bei dem neuen ioBrocker Container etwas anders ist und er eine andere IP hat?

sag du es uns!
du sitzt an deiner Installation

[mcBirne]

@homoran
wie finde ich das heraus?

[mcBirne]

@mcbirne
es sollte keine eigene andere IP Adresse sein, da ich auf die Admin Konsole mit der gleichen IP komme, die ich auch für phpMyAdmin brauch.

[OliverIO]

@mcbirne sagte in Update vom Container gemacht und nun läuft nichts mehr:

es sollte keine eigene andere IP Adresse sein, da ich auf die Admin Konsole mit der gleichen IP komme, die ich auch für phpMyAdmin brauch.

wenn du mit docker arbeitest, dann sollten die einzelnen services auch in eigenen container sitzen. wenn man das nicht will und alles in einem vereint haben will, dann sollte man eine vm benutzen, da die vorteile von docker dann eh verloren sind.

leider hast du noch nichts erzählt, wie die konstellation genau ist. bei docker gibt es viele möglichkeiten

ich gehe mal davon aus, das du kein macvlan konfiguriert hast, mit dem du einzelnen container eine eigene ip adresse aus deinem lan vergeben kannst.
wahrscheinlich hast du die container im bridge modus laufen. dh die ports innerhalb des containers werden auf ports deiner synology gemappt.
daher musst du im iobroker by der db konfiguration auch die ip oder namen deiner synology eintragen + ggfs noch den port 3306 (falls durch mapping nicht geändert)

127.0.0.1 kann es definitiv nicht gewesen sein, ausser du hast die datenbank im iobroker installiert. aber wie gesagt, das würde ich nicht machen.

[Codierknecht]

@oliverio
Wer auf seiner Synology nicht noch etwas betreibt, das mit den Ports des ioBroker kollidiert, sollte den Container besser im Host-Mode betreiben.
Eher früher als später fehlt sonst mal wieder ein Port im Mapping.

[OliverIO]

@codierknecht

hm verstehe ich nicht so ganz.
durch den hostmode erhält der containre doch nicht automatisch eine eigene ip aus dem lan.
ich hab den unterschied immer so gesehen, das die container bei bridge netzwerktechnisch voneinander isoliert sind und bei host nicht.

port mapping konflikte kannst du aber bei beiden bekommen.
daher setze ich macvlan ein. da kann ich einem container eine eigene ip zuordnen. broadcasts funktioniert dann auch wunderbar im lan.

ich kenne allerdings nur die docker terminologie und weiß nicht ob synology unter host mode etwas anderes versteht
https://docs.docker.com/network/drivers/host/

nachtrag:
https://kb.synology.com/de-de/DSM/help/Docker/docker_network?version=6
ne kein unterschied

evtl hier meine sichtweise
meine hostmaschine hat die ip
192.168.1.10
bridge modus
erster container 172.17.0.1
erster container 172.17.0.2
host modus
erster container 172.17.0.1
erster container 172.17.0.1

innere ports werden durch portmapping auf der host-maschine verfügbar gemacht.

bei macvlan erhält der container eine echte eigene ip-adresse, da der macvlan-treiber eine weitere virtuelle netzwerkkarte mit eigener MAX-Adresse (was die voraussetzung für eine eigene IP ist) erzeugt

[mcBirne]

@oliverio
OK, das Teil läuft auch auf meinem Docker im bridge Modus.

Meinen IO Broker erreiche ich mit 192.168.178.84:8081
Daher habe ich jetzt bei server IP al die 192.168.178.84 eingetragen. Mit folgendem Ergebnis:

Wie kann ich es dem Host erlauben auf die Datenbank zuzugreifen?

[OliverIO]

@mcbirne

die container dürfen immer nach kontakt aufnehmen. kenne da keine beschränkung.
kannst du mal schauen was im log steht?
mich wundert es etwas, das da die container ip steht (weiß aber nicht ob es die vom iobroker oder von mysql ist)
funktioniert den dein myphpadmin mit dem zugriff?
wenn nicht, dann stimmt was nicht mit der datenbank

nachtrag: ist die ip des iobrokers

[Codierknecht]

@oliverio sagte in Update vom Container gemacht und nun läuft nichts mehr:

durch den hostmode erhält der containre doch nicht automatisch eine eigene ip aus dem lan.

Nein - das natürlich nicht.
Aber die meisten Probleme handeln sich die User im Bridge-Mode ein, weil sie dann vergessen die benötigten Ports zu mappen.

Macvlan ist für die allermeisten auch schon ein paar Stufen zu hoch.

In der Regel dürfte die Synology lediglich als Datengrab dienen.
Ein ioBroker-Container im Host-Mode dürfte da keine Portkonflikte verursachen.

[OliverIO]

@codierknecht sagte in Update vom Container gemacht und nun läuft nichts mehr:

Ein ioBroker-Container im Host-Mode dürfte da keine Portkonflikte verursachen

wenn du nur iobroker drauf laufen lassen hast?
ich hab hier ca 20 container laufen, aber nicht alle mit einer eigenen ip
ok keine syno aber ein nuc. unterschied ist ja nur, das da keine große festplatte dran ist.
da musste ich schon einige mit anderen ports mappen und dann über einen reverseproxy wieder für mich einfach machen

[mcBirne]

@oliverio der phpMyAdmin Zugang funktioniert

[mcBirne]

@codierknecht said in Update vom Container gemacht und nun läuft nichts mehr:

e meisten Probleme handeln sich die User im Bridge-Mode ein, weil sie dann vergessen die benötigten Ports zu mappen.
Macvlan ist für die allermeisten auch schon ein paar Stufen zu hoch.

OK, kann ich den Container nachträglich auf den Host Modus umstellen?

[Codierknecht]

@mcbirne sagte in Update vom Container gemacht und nun läuft nichts mehr:

OK, kann ich den Container nachträglich auf den Host Modus umstellen?

Nein. Das lässt sich - zumindest mit den Bordmitteln der Synology - nicht ändern.

[Codierknecht]

@oliverio
Die wenigsten User haben hier eine Synology am Start, die potent genug wäre um da mit vielen Containern Probleme zu produzieren.

Auf Deinem NUC sieht das natürlich ganz anders aus.
Aber Du weißt ja auch was Du da tust ;-)

[mcBirne]

@codierknecht
OK, dann werde ich einen neuen Container aufsetzen und nicht den Bridge Mode verwenden.
Das zurückspielen des Backup hat ja gut funktioniert.
Sollte ich bei der Erstellung des Containers noch andere Dinge beachten?