[HowTo] ioBroker unter Docker auf Synology DiskStation
-
Man darf dann nur nicht vergessen, dass man dem InfluxDB und Mosquitto-Containern eine feste virtuelle IP zuweist (zB 172.17.0.4) und die Container über die iobroker-Adapter dann auch entsprechend über diese internen IPs ansprechen muss, nicht mehr über die IP vom RaspPi (bei mir zB 192.168.178.11)
-
@Holzlenkrad So, hab nun den Kernel von 4.19.97-v7l+ auf 4.19.114-v7l+ upgedatet (mit Reboot). Das hatte ich sogar schonmal ausgeführt, mich aber von den Warnungen abschrecken lassen und abgebrochen. Danach im ersten Versuch den Container neu erstellt, da kackte die Ausführung des Containers aber nach ner Weile im 2. Schritt des ioBroker-Starts ab. Also habe ich alles nochmals gelöscht und alles von vorne...
Ergebnis nun: Im Logfile sind nun die letzten Einträge Starting ioBroker (was vermutlich richtig ist?)...host.iobroker check instance "system.adapter.admin.0" for host "iobroker" host.iobroker check instance "system.adapter.discovery.0" for host "iobroker" host.iobroker check instance "system.adapter.info.0" for host "iobroker"Ich kann aber die IP 192.168.1.250 immer noch nicht anpingen von meinem Windows-PC 192.168.1.26. So gesehen brachte das keine Veränderung, außer dass im Logfile der vorherige Fehler
2020-04-13T00:59:02.436388708Z Cannot send diag info: ETIMEDOUT 2020-04-13T00:59:10.427076733Z failed to download new sources, use cached sources 2020-04-13T00:59:10.427240080Z Cannot download json from http://download.iobroker.net/sources-dist-hash.json. Error: Error: ETIMEDOUTnicht mehr auftritt.
Doch was falsch mit meiner Netzwerkkonfiguration?
Mod-Edit: Code/Log in Code Tags gepackt. Bitte benutzt die Code Tags Funktion -> </>
Hier gehts zur Hilfe. -
@Holzlenkrad Trotz Kernel-Update scheine ich immer noch genau an dem Problem zu hängen. Bin jetzt einen Schritt weiter: Wenn ich aus dem ioBroker-Container heraus meinen Windows-Rechner 192.168.1.26 anpinge, dann kann ich auch plötzlich vom Windows-Rechner .26 auf die ioBroker-Installation 192.168.1.250 zugreifen und die GUI von ioBroker im Browser aufrufen. Und mit meinem Notebook mit ip .24 verhält es sich exakt gleich. Das ist ja genau der Kernel-Bug, ne?
Was kann man als Linux-Anfänger beim Kernel-Update falsch machen? Deinen genannten Befehl duo rpi-update habe ich ohne Fehlermeldungen bis zum Ende ausgeführt. uname -r zeigt den neuen Kernel 4.19.114-v7l+ an. Muss man den Kernel irgendwie noch committen/aktivieren o.ä.? Reboot habe ich gemacht, Raspi war auch mal stromlos...
-
@stevie77
Ja, genau das sind die Symptome des Kernel-Bugs.
Du hast aber auch recht, dass bei dir der Kernel aktuell ist, wie er soll.Ich kann mir nur vorstellen, dass irgendein Teil deines Setups bzw. Netzwerk eben doch noch eine fehlerhafte ARP Tabelle hat.
Die Container hattest du in Portainer mal komplett gelöscht? Vielleicht auch mal das macvlan löschen?
Ansonsten könntest du auch mal die IP-Adresse ändern (also 192.168.1.250) und gucken ob es dann direkt funktioniert. Danach kannst du ja wieder zurück auf 250 gehen.Was mir noch gerade auffällt, wieso nutzt du eigentlich bei der IP-Range vom macvlan Netzwerk als Größe 32Bit? Bei der Subnetmask ist die Anzahl der verfügbaren IP-Adressen dann eigentlich 0. Lieber mal 30 oder eine kleiner Zahl nutzen.
Stand das in irgendeiner Anleitung so drin? -
@stevie77
Ich bin genau so vorgegangen, wie du es auch beschreibst -> rpi-update, anschließend sudo reboot, seitdem funktioniert das bei mir einwandfrei mit dem macvlan.
Mein Kernel ist ebenfalls auf 4.19.114-v7l ... dementsprechend solltest du wohl nichts falsch gemacht haben.
Das hilft dir jetzt zwar nicht wirklich weiter, ich hätte aber auch keine spontane Idee, was da bei dir anders sein soll.
Vllt. einfach mal ein
sudo apt-get update
gefolgt von
sudo apt-get upgrade
ausführen? (kann wohl nicht schaden mal alles auf den aktuellsten Stand zu bringen)
Ebenfalls wäre es noch eine Grashalm-Idee die IP vom MACVLAN mal von 250 auf z.b. 252 zu ändern.
(Achtung: Dein DHCP-Bereich hast du m.M.n. sehr groß gewählt (.2 - .249) -> Aufpassen, dass Geräte mit Statischen IPs außerhalb dieses Bereiches liegen und/oder nicht zufällig eine bereits per DHCP vergebene IP bekommen. Dir bleiben als statische IPs prinzipiell nur .250-.254 (.255 = Broadcast) Man kann zwar auch IPs aus dem DHCP-Bereich statisch vergeben, das kann aber auch zu Kollisionen führen)Alternativ - wenn auch nur ein Workaround, weil du scheinbar das macvlan gerne nutzen möchtest - könntest du den Container auf Bridge-Mode umstellen und erstmal die Ports 8081 & 8082 freigeben / publishen.
Sobald dir irgendwo benötigte Port-Freigaben über den Weg laufen, merkst du das eigentlich recht schnell daran, dass die gewünschte Seite eben einfach nicht erreichbar ist.
André hat hier schon eine sehr nutzige Aufzählung gestartet, die erstmal alles abdecken sollte.
node-red (1880), mqtt (1883) dürften schnell interessant werden
Falls du mit weiteren mqtt-Servern wie dem sonoff- oder dem shelly-adapter arbeitest, wirst du spätestens in der Einstellung des Adapters über den benötigten bzw. einstellbaren Port stolpern.
(Bei shelly ist das default 1882, bei sonoff 1883 - muss aber geändert werden, sofern ein anderer MQTT-Broker auf dem Port läuft)
Erreichbar ist die Admin-Seite dann unter der IP des RaspPis 192.168.1.16:8081 -
Ups...da war ich zu langsam...
@Holzlenkrad said in [HowTo][Anleitung] Installation ioBroker in Docker auf Synology DiskStation:
Was mir noch gerade auffällt, wieso nutzt du eigentlich bei der IP-Range vom macvlan Netzwerk als Größe 32Bit? Bei der Subnetmask ist die Anzahl der verfügbaren IP-Adressen dann eigentlich 0. Lieber mal 30 oder eine kleiner Zahl nutzen.
Stand das in irgendeiner Anleitung so drin?Ja, steht in der Anleitung so drin und ist m.M. auch richtig so -> 32-bit bedeutet doch genau eine IP (nicht 0).
-
@Holzlenkrad Moin. Ja, ich hab den ioBroker-Container komplett gelöscht, ebenso die nach der Anleitung angelegte Netzwerkkonfiguration sowie das daraus resultierende konkrete Netzwerk. Das wurde alles neu angelegt. Portainer selbst habe ich nicht gelöscht/neu angelegt, erscheint mir jetzt aber auch nicht zielführend.
Mit Subnetting stehe ich auf Kriegsfuß (bzw. kenne mich kaum aus), aber dieser Rechner hat mir dabei einen Host ausgeworfen oder interpretiere ich das falsch? http://jodies.de/ipcalc?host=192.168.1.250&mask1=32&mask2=
Du könntest aber gut Recht haben, bei /30 http://jodies.de/ipcalc?host=192.168.1.250&mask1=30&mask2= scheint HostMin und HostMax irgendwie mehr Sinn zu machen (249 und 250). Bei /32 ist HostMin 251 und HostMax 250, was komisch aussieht, wenn ich es mal länger ansehe. Ich kenne mich damit echt nicht aus...
Werde heute Abend nochmals alles löschen und es mit 192.168.1.250/30 probieren... -
@FoodFighter Stimmt, hatte ich mir doch nicht selbst ausgedacht. Dann kann's daran ja eigentlich auch nicht liegen und ich mir die Neuerstellung zum dritten Mal ersparen...
-
@stevie77 said in [HowTo][Anleitung] Installation ioBroker in Docker auf Synology DiskStation:
@FoodFighter Stimmt, hatte ich mir doch nicht selbst ausgedacht. Dann kann's daran ja eigentlich auch nicht liegen und ich mir die Neuerstellung zum dritten Mal ersparen...
Ich nutze übrigens auch eine 32-Bit IP-Range (in meinem Fall 192.168.178.12/32) und eine 24-Bit subnet (192.168.178.0/24). Das sollte nicht das Problem sein.
Vorstellen könnte ich mir aber nach wie vor, dass die Fritzbox sich mit der .250 verhaspelt (manchmal sind FBs eigen....mit der .20 haben die Dinger auch gerne Probleme, weil es die Start-Adresse des default-DHCP-Bereichs ist....auch wenn dieser geändert wurde, hängt die .20 wohl oft als Leiche irgendwo uneinsehbar im FB-Kopf). -
@FoodFighter Ich habe den Raspi an Ostern aufgesetzt und dann sudo apt-get update und sudo apt-get dist-upgrade nach einer Anleitung ausgeführt. Hatte gelesen dass sudo apt-get upgrade gefährlich sein kann und man sich über längere Zeit damit das System zerschießen würde. Aber ich probiere das gerne gleich mal, will ja nichts unversucht lassen.
-
@stevie77
Wenn du ein dist-upgrade gemacht hast, ist das OK.(upgrade updatet nur, installiert aber keine neuen Abhängigkeiten, dist-upgrade installiert neu benötigte Abhängigkeiten bzw. deinstalliert unbenötigte Abhängigkeiten. ...Insofern -> Ja, dist-upgrade ist die sicherere/empfehlenswertere Variante)
-
@FoodFighter said in [HowTo][Anleitung] Installation ioBroker in Docker auf Synology DiskStation:
Ja, steht in der Anleitung so drin und ist m.M. auch richtig so -> 32-bit bedeutet doch genau eine IP (nicht 0).
Ja wird dann wohl so richtig sein. Ich hab da fälschlicher Weise an eine normale Subnetz-Definition gedacht, bei der man ja noch die Broadcast-Adresse abziehen müsste. Aber bei der Definition einer IP-Range ist das ja nicht relevant.
-
@FoodFighter Ich hab das nun nochmals mit nem anderen Wert komplett neu erstellt: Subnet: 192.168.1.0/24, Gateway: 192.168.1.1, IP range: 192.168.1.249/32. Die Fritzbox vergibt IP-Adressen per DHCP nun von .2 bis .240. Nun kann ich beim Container-Start tatsächlich von außen von meinem Windows-Rechner aus die IP 249 tatsächlich sofort anpingen. Nur läuft jetzt beim Start von ioBroker im Container was schief. In Schritt 1 wird nano installiert, in Schritt 2 geht was schief und dann wird wieder bei Schritt 1 gestartet (siehe ioBroker.log).
Dabei scheint jedesmal eine andere IP meines Heimnetzwerks verwendet zu werden und es werden alle freien IPs durchgeklappert, die dann alle in der Fritzbox im Netzwerk auftauchen.
In Schritt 2 des ioBroker-Installationsskripts wird ausgegeben: "There is data detected in /opt/iobroker but it looks like it is no instance of iobroker or a valid backup file!, Please check/ recreate mounted folder/ volume and restart ioBroker container." Das verstehe ich nicht, weil mein gemountetes Verzeichnis außerhalb des Containers (/home/pi/docker-data/iobroker) leer ist. Und da der Container ja neu heruntergeladen wird, wird das interne Verzeichnis /opt/iobroker ja auch leer sein. Vielleicht ist diese Fehlermeldung die Ursache für den Restart und dies wiederum - warum auch immer - die vielen IP-Adressen, die in meinem Heimnetz auftauchen?!
-
@stevie77 sagte in [HowTo][Anleitung] Installation ioBroker in Docker auf Synology DiskStation:
@FoodFighter Ich hab das nun nochmals mit nem anderen Wert komplett neu erstellt: Subnet: 192.168.1.0/24, Gateway: 192.168.1.1, IP range: 192.168.1.249/32.
So, ich hab's nun hinbekommen. Mit der 249 funktioniert das. Wäre ja nie drauf gekommen, dass die 250 solche Probleme verursachen kann. Danke für den hilfreichen Tipp!
Dabei scheint jedesmal eine andere IP meines Heimnetzwerks verwendet zu werden und es werden alle freien IPs durchgeklappert, die dann alle in der Fritzbox im Netzwerk auftauchen.
Au Mann, Anfängerfehler. Hatte vor der Neuinstallation mein Container-externes Persistenz-Verzeichnis in der Raspbian-Oberfläche gelöscht und auf der Konsole mit ls kontrolliert. Erst mit ls -al habe ich nun bemerkt, dass da die versteckte Datei .npmrc der letzten Installation stehen geblieben war. Container neu gestartet ohne die Datei und schon lief alles.
Nun taucht auch diese verwirrende zusätzliche IP nicht mehr auf (die ich am Anfang mit der 250 hatte), es bleibt bei den beiden Raspi-Einträgen, die zu erwarten sind.
Ich danke euch herzlich, dass ihr mich auf die richtige Spur gebracht habt!
-
Leider doch nochmals ich...sorry...
Bei einem Reboot des Raspberry wurde nun neben den korrekten aktiven Verbindungen .25 und .249 in der Fritzbox eine weitere aktive Verbindung
angelegt. Diese kann man im Netzwerk nicht anpingen, wird nur kurz als aktiv in der Fritzbox angezeigt und wandert dann in die Tabelle ungenutzte Verbindungen. Warum passiert das? Die MAC-Adresse ist verschieden von denen für .25 und .249, falls das hilft die Frage zu klären... -
Na das freut mich, dass du es geschafft hast
Nachdem jetzt alles funktioniert könntest du spaßhalber mal versuchen, ob jetzt im Nachheinein die .250 funktioniert...falls nicht kannst du ja problemlos zurück auf die 249 schwenken (für den Versuch einfach eine zweite macvlan-config + macvlan anlegen und im Container auswählen).Mein Bauchgefühl sagt, dass es nicht funktionieren wird - ohne wissenschaftlichen Hintergrund.
Eine Lösung für die Fritzbox-Leichen habe ich leider nicht gefunden, wenn auch viel gesucht.
Ich hätte zum Beispiel gerne die .20 fest vergeben (für die Dreambox)...würde gut in mein ausgeklügeltes IP-Schma passen -> keine Chance...irgendeine Leiche in der FB blockiert die .20
Falls da jemand eine Lösung finden sollte -> Bitte melden!@stevie77 said in [HowTo][Anleitung] Installation ioBroker in Docker auf Synology DiskStation:
Warum passiert das?
DAS ist mir auch schon aufgefallen und geht mir auch gegen den Strich - so ganz bin ich noch nicht durch gestiegen, was das ist.
Mein RPI liegt auf .11, mein iobroker-vlan auf .12
DHCP-Bereich ist bei mir .150 - .254
Bei jedem Neustart des Containers bekommt der RPi einmal ganz kurz (unter variierenden MAC-Adressen...und damit immer eine neue IP) eine IP aus dem DHCP-Bereich, bevor dann letztendlich die .12 für das iobroker-vlan zieht (z.B. .158) - Diese bleibt dann logischerweise eine kleine Weile in der Fritzbox als aktiv gekennzeichnet, da diese ja nicht sekündlich die Erreichbarkeit der Teilnehmer kontrolliert, bevor die aus der Teilnehmer-Liste fleigen. Imho müssten das irgendwas zwischen 10-15min sein, die inaktive Teilnehmer noch aktiv angezeigt werden.Wieso der Container erstmal eine DHCP-IP bekommt und wieso dabei auch immer eine andere MAC-Adresse gemeldet wird, ist mir ein Rätsel.
Vielleicht haben die Profis da noch eine Idee ( @Holzlenkrad )? -
Dieses merkwürdige Verhalten mit dem zusätzlichen Eintrag in der FritzBox ist mir auch schon aufgefallen. Das ganze kommt aber auch erst bei neueren Kernel-Versionen vor, deswegen vermute ich, dass der ARP Stack zwar mittlerweile wieder funktionsfähig, aber noch nicht wirklich fehlerfei ist...
Wie ist das denn bei euch? Bekommt die FritzBox einen neuen Eintrag, wenn ihr den Container neu startet oder nur wenn ihr einen neuen Container erstellt?
-
@Holzlenkrad said in [HowTo][Anleitung] Installation ioBroker in Docker auf Synology DiskStation:
Wie ist das denn bei euch? Bekommt die FritzBox einen neuen Eintrag, wenn ihr den Container neu startet oder nur wenn ihr einen neuen Container erstellt?
Neustart des Containers genügt definitiv....ich habe da grade mal gespielt...jetzt wird der DHCP-Bereich langsam knapp
Was eine Möglichkeit ist: Wenn man im Container eine feste MAC-Adresse einstellt (zum Beispiel die aktuelle), dann bekommt der container wenigstens immer die gleiche "temporäre" IP und sprengt nicht den DHCP-Bereich.
(Irgendwas ähnliches hatte hier neulich mal jemand geschrieben)[Edit]
TS020339 war das - hierP.S....Boah der Aufbau dieses Forums ist echt....gewöhnungsbedürftig
-
@FoodFighter sagte in [HowTo][Anleitung] Installation ioBroker in Docker auf Synology DiskStation:
Ja, geht.
Container mit einem Netzwerk erstellen, danach den gestarteten Container anklicken (Übersicht) und dann unten auf "Join Network"Und dann wählt man unter "Join a network" den Eintrag bridge aus, also zusätzlich zum erstellten MACVLAN-Netzwerk iob_public? Das hat keine Nachteile, nur den Vorteil, dass der ioBroker dann auch mit anderen Apps in Containern auf dem Host sprechen kann?
-
@stevie77 said in [HowTo][Anleitung] Installation ioBroker in Docker auf Synology DiskStation:
Und dann wählt man unter "Join a network" den Eintrag bridge aus, also zusätzlich zum erstellten MACVLAN-Netzwerk iob_public?
Genau
Das hat keine Nachteile, nur den Vorteil, dass der ioBroker dann auch mit anderen Apps in Containern auf dem Host sprechen kann?
Mir würde kein Nachteil einfallen und ja, kommunizieren kannst du dann über die Container-IPs (meistens 172.17.0.x) intern über die Container hinweg.
Ich bin da auch kein Profi und auch kein ITler, ich fummel mich da grade mehr oder minder auch nur durch alles durch, also bezüglich der Nachteile will ich mich da nicht festlegen.
