-v /dev:/dev oder -v /run/udev:/run/udev und vor allem –privileged
In deinem Skript fehlt --privileged
Unter der Voraussetzung, dass die Reichweite des WiFi oder Ethernet verfügbar ist. Ich verstehe die Idee, ich denke, die Pods werden diesem Bedarf gerecht werden.
Die Kritikalität ist zwischen Router und Koordinator dieselbe, man kann dasselbe mit dem Dongle ausdrücken, wenn er ausfällt, hast du nichts mehr. Man sollte einfach nichts anderes empfehlen, als was das zigbee2mqtt-Projekt zur Reichweitenvergrößerung definiert. (Ein Router ist nichts anderes als ein Koordinator mit einer anderen Firmware).
Ich werde heute Abend dein Image testen, ich werde dir ein Feedback geben
Tatsächlich hatte ich nicht gesehen, dass du diesen Parameter hinzugefügt hast, da ich den manuellen Start verwendet habe
Vielen Dank, jetzt kann ich endlich alles testen
Bei mir funktioniert es ohne diese Option, die ich so weit wie möglich vermeiden möchte, da sie dem Container Root-Zugriff auf die gesamte Host-Maschine gibt.
Schon das Teilen des gesamten /dev ist fragwürdig…
Um eure Meinung zu hören, dachte ich, man könnte vielleicht udev-Regeln erstellen, die die Dongles in /dev/zigbee oder /dev/zwave je nach angeschlossenem Dongle definieren, und dann könnte man nur diese mit dem Gladys-Container teilen.
Was haltet ihr davon?
Cool!
Das wird uns weiterbringen.
Hast du gesehen, dass ich für zigbee2mqtt ein Netzwerk für eine isolierte Kommunikation zwischen den Containern erstellt habe? Anschließend verbinde ich Gladys mit dem MQTT-Container, indem ich den Containernamen in der URL verwende.
Könntest du also, @duvalale, mit und ohne die Option --privileged testen, um meine Aussage zu bestätigen?
Warum das?
Das Netzwerk entspricht einer privilegierten Verbindung (wie ein virtuelles Ethernet-Kabel) für die Kommunikation zwischen den 2 Containern (Gladys und MQTT). Es hängt weder vom Betriebssystem noch von der Hardware ab, sondern ist eine Docker-Schicht.
Andere Dienste, die mit dem MQTT-Broker kommunizieren müssen, können die lokale Adresse des Computers verwenden, auf dem dieser (der Broker) läuft.
Ich habe nie das Gegenteil behauptet, ich sage auch nicht, dass dein Gedanke falsch ist, aber wir kontrollieren diese Umgebung nur auf dem raspbian-Image.
Ich nehme mich wieder als Beispiel (ihr werdet sagen, dass ich nervig bin), bei mir läuft Gladys nicht auf einem Raspberry Pi, noch auf einem Network-Bridge/Host.
Bei dir erstellst du ein Netzwerk für Gladys, aber ein anderer Benutzer kann es anders machen.
Daher funktioniert die Entwicklung in meiner Umgebung nicht, es sei denn, ich mache Änderungen auf der Docker- oder Gladys-Seite.
Wir müssen alle Fälle abdecken. Vielleicht erreichen wir nicht 100%, aber wir sollten uns daran annähern und den Rest dokumentieren.
Übrigens hast du mir eine Idee gegeben, man kann das Netzwerk des Containers „maitre“ wiederverwenden und die „enfant“-Container im gleichen Netzwerk erstellen.
So nutzen wir die Namensauflösung über den Hostnamen.
Ich bin absolut dafür, so viele Fälle wie möglich abzudecken. Ich selbst lasse Gladys auf einem NAS OMV laufen.
Was ich vorschlage, bleibt auf Docker-Ebene, sollte also für alle funktionieren.
Aber sag mir mal, läuft Gladys immer noch unter Docker, oder?
Genau das mache ich, aber da Gladys heute nicht mit einem Netzwerk gestartet wurde, das dem Container zugeordnet ist, musste ich eines erstellen, das ich dann zur Kommunikation mit den externen Containern und zur Nutzung der Docker-Namensauflösung verwende.
Eigentlich glaube ich, wir sagen fast dasselbe, aber per Textnachricht ist es nicht immer einfach, sich zu verstehen.
Tatsächlich brauche ich die Option --privileged auch nicht, aber wir haben dieselbe Distribution, also heißt das nicht unbedingt, dass das für alle gilt …
Ich teste ein paar Tage und gebe dann ein kurzes Feedback. Ich habe schon ein paar Probleme festgestellt, aber man wird sehen, ob die von Zigbee2Mqtt kommen oder nicht
@Reno Ich habe gerade den Container gestartet, sind wir uns einig, dass wir zwingend über deine Container gehen müssen? Gibt es im Moment keine Möglichkeit, einen bestehenden MQTT-Server zu verwenden?
Der Log: (ich weiß nicht, wofür er sich angemeldet hat :D)
vonox ~ docker logs gladys-zigbee2mqtt
> gladys-server@ start:prod /src/server
> cross-env NODE_ENV=production node index.js
Initialising OpenZWave 1.6.974 binary addon for Node.JS.
OpenZWave Security API is ENABLED
ZWave device db : /etc/openzwave
User settings path : /src/server/services/zwave/node_modules/openzwave-shared/build/Release/../../
Option Overrides : --Logging false --ConsoleOutput false --SaveConfiguration true
2020-05-08T12:25:23+0200 <info> index.js:20 (Object.start) Starting Dark Sky service
2020-05-08T12:25:23+0200 <info> index.js:16 (Object.start) Starting zwave service
2020-05-08T12:25:23+0200 <info> index.js:19 (Object.start) Starting telegram service
2020-05-08T12:25:23+0200 <info> index.js:13 (Object.start) Starting usb service
2020-05-08T12:25:23+0200 <info> service.start.js:16 (Service.start) Service darksky is not configured, so it was not started.
2020-05-08T12:25:23+0200 <info> service.start.js:16 (Service.start) Service telegram is not configured, so it was not started.
2020-05-08T12:25:23+0200 <info> service.start.js:16 (Service.start) Service zwave is not configured, so it was not started.
2020-05-08T12:25:23+0200 <info> service.start.js:16 (Service.start) Service zigbee2mqtt is not configured, so it was not started.
2020-05-08T12:25:23+0200 <info> service.start.js:16 (Service.start) Service mqtt is not configured, so it was not started.
2020-05-08T12:25:23+0200 <info> index.js:63 (Server.<anonymous>) Server listening on port 4080
2020-05-08T12:27:06+0200 <info> docker.stopContainer.js:18 (Docker.stopContainer) container zigbee2mqtt stopped
2020-05-08T12:27:07+0200 <info> docker.startContainer.js:18 (Docker.startContainer) container zigbee2mqtt started
2020-05-08T12:31:55+0200 <info> connect.js:23 (Zigbee2mqttManager.connect) Zigbee2mqtt USB dongle attached to /dev/ttyACM0
2020-05-08T12:31:55+0200 <info> subscribe.js:12 (Zigbee2mqttManager.subscribe) Subscribing to MQTT topic zigbee2mqtt/#
Ich glaube nicht, dass wir den Zugriff des Gladys-Containers auf die Maschine einschränken wollen.
Ich erinnere daran, dass das Raspbian-Gladys-Image während des gesamten Lebenszyklus des Raspberry Pi des Benutzers funktionieren muss.
Stellen Sie sich vor, der Benutzer installiert Gladys im Jahr 2020 und wechselt den Pi im Jahr 2030. In 10 Jahren, wenn wir Funktionen hinzufügen, neue Integrationen in Gladys entwickelt werden, muss das Raspbian-Image evolutionsfähig sein und alle Dongles, die angeschlossen werden, von Gladys verwaltet werden.
Wenn wir den Benutzer bitten müssen, Gladys alle paar Tage neu zu installieren, dann haben wir unsere Mission verfehlt.
Ich zitiere einen Beitrag, den ich zu einem anderen Thema geschrieben habe:
Warum verwenden wir Docker?
In Gladys 3 erinnere ich daran, dass wir Gladys direkt auf der Maschine ohne Docker ausgeführt haben, sodass Gladys Zugriff auf die gesamte Maschine hatte.
In Gladys 4 verwenden wir Docker, um die Verpackung, den Deployment und das Update der Gladys-Instanzen zu erleichtern. Da wir im Bereich der eingebetteten Systeme arbeiten und Zugriff auf Peripheriegeräte (USB, GPIO, Kamera Pi über den Kamerabus usw.) benötigen, ist es durchaus sinnvoll, Gladys vollen Zugriff auf die Maschine zu geben, wie es der Fall wäre, wenn wir das Programm einfach direkt auf dem Raspberry Pi ausführen würden.
Wir sind nicht im Docker-Gebrauch eines Cloud-Anbieters, der die Ausführung von nicht vertrauenswürdigem Code isolieren, den Zugriff auf die physische Maschine einschränken und die Ressourcennutzung eines Drittanbieters begrenzen möchte.
Hier führt der Benutzer auf seiner eigenen Maschine ein eingebettetes Programm aus, das intensive Nutzung externer Peripheriegeräte und Hardware betreibt. Im Gegenteil: Wir wollen die Superfähigkeiten des Raspberry Pi nutzen und die gleichen Funktionen haben, als würden wir Gladys direkt auf dem Host wie die meisten Programme ausführen.
Der Versuch, den Zugriff des Containers auf den Pi einzuschränken, hat keinen Sinn und fügt keine Sicherheit hinzu…
Man muss so langfristig wie möglich denken und die Benutzererfahrung an erste Stelle setzen.
Was ist das Problem mit dem Freigeben von /dev? Gladys ist für die Hausautomatisierung da, nicht um in einem Container eingeschlossen zu bleiben ^^
Bei jedem Neustart kannst du eine andere Mounting-Option haben.
Man könnte einfach in der Dokumentation (mit Regeln) vorschlagen und bleibt standardmäßig bei der Entwicklung. Oder man kann es in den Build des Images integrieren.
Aus Sicht des Benutzers ist es einfacher
Das eine schließt das andere nicht aus.
Ich bleibe aber bei der vollständigen Freigabe aller Geräte (ja, es gibt zwei Themen).
Ich glaube, ich habe nicht verstanden, was Sie vorhaben
Ach wirklich? Das wusste ich nicht. Wenn du einen Trick dagegen hast, bin ich interessiert! Die einzige Einschränkung ist, dass es generisch im Image gemacht werden muss, dass es für alle funktioniert und dass es zeitbeständig ist.
)
(für den Namen des Sticks)