NEWS
[HowTo] ioBroker unter Docker auf Synology DiskStation
-
@ilovegym ok das sieht so aus
ich habe bei meiner diskstation 2 netzwerkanschlüsse die als bond konfiguriert wurden.
Mein Problem ist, dass ich von dem neuen mediola adapter auf dem port 1902 und 1901 udp broadcasts empfangen sollte. aber die kommen nicht an. ich weiss jetzt grad nicht was ich noch tun soll. hättest du einen vorschlag?
-
@ilovegym ok das sieht so aus
ich habe bei meiner diskstation 2 netzwerkanschlüsse die als bond konfiguriert wurden.
Mein Problem ist, dass ich von dem neuen mediola adapter auf dem port 1902 und 1901 udp broadcasts empfangen sollte. aber die kommen nicht an. ich weiss jetzt grad nicht was ich noch tun soll. hättest du einen vorschlag?
netzwerkseitig sieht alles gut aus
ip und broadcast adresse passen zusammender broadcast sender muss sich im gleichen netzsegment befinden wie der empfänger
broadcast geht immer nur innerhalb eines segmentsbei macvlan gibt es noch die besonderheit, das wenn der sender/empfänger der host ist und der sender/empfänger ein container ist, die sich nicht erreichen können.
man muss dazu einen link einrichten -
@ilovegym ok das sieht so aus
ich habe bei meiner diskstation 2 netzwerkanschlüsse die als bond konfiguriert wurden.
Mein Problem ist, dass ich von dem neuen mediola adapter auf dem port 1902 und 1901 udp broadcasts empfangen sollte. aber die kommen nicht an. ich weiss jetzt grad nicht was ich noch tun soll. hättest du einen vorschlag?
@drapo sagte in [HowTo] ioBroker unter Docker auf Synology DiskStation:
ich habe bei meiner diskstation 2 netzwerkanschlüsse die als bond konfiguriert wurden.
Mehr ein Schuss ins Blaue:
Hast Du mal mit deaktiviertem/aufgehobenem Bond probiert und zum Testen mal einen Anschluss abgeschaltet?
Beim Bonding sind ja 2 Seiten im Boot. Zum einen die Syno und zum anderen der Switch, an dem die beiden Ports der Syno hängen. Nicht dass es am Ende am Switch (warum auch immer) klemmt. -
Oliver, richtig, hatte ich ganz vergessen, mein Script (hab ich irgendwo aus dem Netz..) in der Syno sieht so aus, steht auf
Ausfuehren als root, alle 15 min, wenn fehlgeschlagen Email-Benachrichtung.#!/bin/sh if ip link | grep "mac1@ovs_eth3" > /dev/null; then echo "Device mac1 existiert" else echo "Device mac1 anlegen" ip link del mac1 ip link add mac1 link ovs_eth3 type macvlan mode bridge ip addr add 10.1.1.9/28 dev mac1 ip link set mac1 up ip route add 10.1.1.9 dev mac1 fiDie 10.1.1.9 ist die MacVlan IP, ovs_eth3 das Interface der Syno, das script schaut so alle 15min, ob die Mac noch exestiert und falls nicht, wird sie angelegt. Damit hast du bei einem Reboot oder Verlust der Mac(Interface neu gestartet) keine Arbeit.
-
Oliver, richtig, hatte ich ganz vergessen, mein Script (hab ich irgendwo aus dem Netz..) in der Syno sieht so aus, steht auf
Ausfuehren als root, alle 15 min, wenn fehlgeschlagen Email-Benachrichtung.#!/bin/sh if ip link | grep "mac1@ovs_eth3" > /dev/null; then echo "Device mac1 existiert" else echo "Device mac1 anlegen" ip link del mac1 ip link add mac1 link ovs_eth3 type macvlan mode bridge ip addr add 10.1.1.9/28 dev mac1 ip link set mac1 up ip route add 10.1.1.9 dev mac1 fiDie 10.1.1.9 ist die MacVlan IP, ovs_eth3 das Interface der Syno, das script schaut so alle 15min, ob die Mac noch exestiert und falls nicht, wird sie angelegt. Damit hast du bei einem Reboot oder Verlust der Mac(Interface neu gestartet) keine Arbeit.
besser ist das skript in das verzeichnis
/etc/network/if-up.d/dockermacvlan
zu legen#!/bin/sh if [ "$IFACE" = "enp3s0" ]; then ip link add macvlan0 link enp3s0 type macvlan mode bridge ip addr add 192.168.1.80/28 dev macvlan0 ip link set macvlan0 up fidas wird dann automatisch ausgeführt, sobal ein netzwerkdevice zur verfügung steht.
-
werden thread hier findet und das verzeichnis bei sich aber nicht findet:
nicht alle distributionen verwenden den networkmanager.daher muss dann nach anderen alternativen gesucht werden, wie ein userscript auf basis eines ereignisses ausgeführt werden kann.
für DSM werden hier ein paar sachen diskutiert
https://community.synology.com/enu/forum/11/post/133969?page=1&sort=oldest -
netzwerkseitig sieht alles gut aus
ip und broadcast adresse passen zusammender broadcast sender muss sich im gleichen netzsegment befinden wie der empfänger
broadcast geht immer nur innerhalb eines segmentsbei macvlan gibt es noch die besonderheit, das wenn der sender/empfänger der host ist und der sender/empfänger ein container ist, die sich nicht erreichen können.
man muss dazu einen link einrichten -
@oliverio den link hab ich eingerichtet ist aber nicht das problem. Da es in diesem fall nicht der host ist welcher mit dem container kommunizieren muss
-
@ilovegym bevor ich das tu. nur dass ich das richtig verstehe. die 172. Schnittstelle ist für die Kommunikation von Conatinern untereinander korrekt? Wenn ich die abschalte haben container untereinander keine Kommunikation mehr stimmt das?
Bei mir läuft noch Redis auf einem eigenen Container. Kann der dann noch mit dem iobroker kommunizieren wenn ich die 172. Schnittstelle ausschalte? -
ja dann geht’s nicht… lass den an.
Kann man den Adapter nicht richtig konfigurieren, wie bei mqtt, und vielen anderen?
Was sagt denn der Developer dazu? -
ja dann geht’s nicht… lass den an.
Kann man den Adapter nicht richtig konfigurieren, wie bei mqtt, und vielen anderen?
Was sagt denn der Developer dazu? -
folgende Ausgangssituation:
Synology 1 - Docker iobroker (macvlan) (v9.0.1), redis(host), alles in Portainer gemanaged
iobroker laeuft als Master, Slave ist ein iobroker LXC in Proxmox auf ner anderen Maschine, keine Probleme.Synology 2 - Docker iobroker (macvlan) (v9.0.1)
startet alleine mit json/json ohne probleme. Dieser soll jetzt aber auch ein Slave von iobroker-Syno1 werden.
Vorgehensweise, lt. doku
in der Console den maintenance mode on, iob setup custom, alles auf den redis-host (ich hab das schon bestimmt 50x auch mit anderen Systemen gemacht), maintenance mode off, Docker neu starten...
Normalweise sollte der neue iobroker als Slave auftauchen, macht er nur in den Objekten, und der Container beendet sich mit "stop iobroker first"
Frage:
das aktivieren von "multihost on" im Docker geht nicht, da sich iobroker beendet und der ganze Container dann haengt. Starte ich den Container dann neu, ist natuerlich multihost "slave verbindungen zulassen" wieder deaktiviert...
Lt. Doku soll das bei Redis ja auch garnicht notwendig sein, mit nem LXC/VM unter Proxmox hatte ich da nie probleme. -
folgende Ausgangssituation:
Synology 1 - Docker iobroker (macvlan) (v9.0.1), redis(host), alles in Portainer gemanaged
iobroker laeuft als Master, Slave ist ein iobroker LXC in Proxmox auf ner anderen Maschine, keine Probleme.Synology 2 - Docker iobroker (macvlan) (v9.0.1)
startet alleine mit json/json ohne probleme. Dieser soll jetzt aber auch ein Slave von iobroker-Syno1 werden.
Vorgehensweise, lt. doku
in der Console den maintenance mode on, iob setup custom, alles auf den redis-host (ich hab das schon bestimmt 50x auch mit anderen Systemen gemacht), maintenance mode off, Docker neu starten...
Normalweise sollte der neue iobroker als Slave auftauchen, macht er nur in den Objekten, und der Container beendet sich mit "stop iobroker first"
Frage:
das aktivieren von "multihost on" im Docker geht nicht, da sich iobroker beendet und der ganze Container dann haengt. Starte ich den Container dann neu, ist natuerlich multihost "slave verbindungen zulassen" wieder deaktiviert...
Lt. Doku soll das bei Redis ja auch garnicht notwendig sein, mit nem LXC/VM unter Proxmox hatte ich da nie probleme.@ilovegym Liegt vielleicht daran, dass du deinem Container in der Config nicht gesagt hast, dass er ein Slave sein soll. Zumindest fehlt laut Log die Umgebungsvariable "IOB_MULTIHOST".
Wenn ich deinen Fall richtig verstehe, dann sollte die ja auf Slave stehen. Dann würde er auch nicht versuchen den Hostnamen zu ändern... Außerdem ist es immer hilfreich in solch einem Fall "DEBUG" = "true" zu setzen. Gerade bei dem Multihost-Gedöns habe ich reichlich Logging eingebaut...MfG,
André -
@ilovegym Liegt vielleicht daran, dass du deinem Container in der Config nicht gesagt hast, dass er ein Slave sein soll. Zumindest fehlt laut Log die Umgebungsvariable "IOB_MULTIHOST".
Wenn ich deinen Fall richtig verstehe, dann sollte die ja auf Slave stehen. Dann würde er auch nicht versuchen den Hostnamen zu ändern... Außerdem ist es immer hilfreich in solch einem Fall "DEBUG" = "true" zu setzen. Gerade bei dem Multihost-Gedöns habe ich reichlich Logging eingebaut...MfG,
AndréDanke, die Env hab ich tatsächlich übersehen.. 🙈🙈🙈
Kaum macht man‘s richtig, funktioniert es… 😀😀👍👍👍👍👍
834
Online32.4k
Benutzer81.5k
Themen1.3m
Beiträge