NEWS
[HowTo] ioBroker unter Docker auf Synology DiskStation
-
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… 😀😀👍👍👍👍👍
697
Online32.5k
Benutzer81.6k
Themen1.3m
Beiträge