Bereitstellung Jessie + FHEM Docker Image

Begonnen von StefanP., 17 April 2015, 21:34:02

Vorheriges Thema - Nächstes Thema

StefanP.

Hallo zusammen,

fühlt sich jemand in der Lage, FHEM in ein (auf der x86 Architektur) lauffähiges Docker Image zu packen ?

Meine neue Synology wird mit dem nächsten Firmware Update (5.2) ein Paket zum Betrieb von Docker Containern erhalten.

Die Idee, FHEM auf der Syno im Container zu betreiben, hört sich für mich recht reizvoll an, v.a. weil man damit den diversen Synology Gängeleien (nicht passende perl Version, Serial Port nicht installierbar, Abhängigkeit von IPKG, das bei jedem Update überschrieben wird etc. etc.) entkommen kann... FHEM läuft dann einfach im Container in seiner eigenen Welt :-)

Ich hab nur (noch) keinen Plan, wie man diese Docker Images erstellen und auf den Docker Hub raufladen kann... Ihr vielleicht... ?

Schöne Grüße,
Stefan

StefanP.

Hallo zusammen,

aufgrund der Vielzahl an positiven Rückmeldungen hab ich mich mal selbst am Docker Image versucht  :)

Ihr findet ein auf Jessie (aktuell RC3) / amd64 (also 64bit) basiertes Docker Image inkl. folgender Zusatzpakete im Docker Hub unter "xiberger/jessie_fhem":
- nano
- mc (Midnight Commander)
- fhem 5.6

Die Anleitung zum Installieren, Erzeugen und Upload des Images liefere ich gleich mit, wenn sich jemand selbst daran versuchen möchte. Achtung: es muss ein 64bit Debian sein, und Jessie empfiehlt sich, weil der aktuelle 3.16 Kernel bereits installiert wird.

Download mit "docker pull xiberger/jessie_fhem"

Viele Grüße und viel Spaß beim Probieren, Feedback gern!
Stefan


Anleitung:
    Download und Installation Debian 8 amd64 "Jessie"
    Login via ssh
    Erzeugen einer chroot Umgebung mittels debootstrap,
        siehe http://www.aossama.com/build-debian-docker-image-from-scratch/
        debootstrap jessie /vdisks/chroot/jessie http://ftp.us.debian.org/debian
    Wechsel in die chroot Umgebung:
        chroot /vdisks/chroot/jessie /bin/bash
        Installation mc, nano, fhem (siehe https://debian.fhem.de/), update fhem
        Start fhem: sudo /etc/init.d/fhem start
    Installation docker im Debian Host:
        apt-get install lxc
        wget https://get.docker.io/builds/Linux/x86_64/docker-latest -O docker
        chmod +x docker
        mv docker /usr/bin/
    Erzeugen und Upload des Docker Images
        tar -C /vdisks/chroot/jessie/ -c . | docker import – xiberger/jessie
        docker push xiberger/jessie_fhem


Zephyr

An sich 'ne sehr coole Idee. Ob man nun FHEM auf seinem NAS laufen lassen will oder nicht... Sei mal dahingestellt. Es schien nicht soooo viel Arbeit zu sein, kann das sein?

Eine Frage stellt sich mir: Warum musstest Du die Synology dafür bootstrappen?

VG
Zephyr
FHEM 5.5 auf Fritz!Box 7390 und Beagle Bone black mit RFXtrx433

StefanP.

Hi Zephyr,

das Image muss ja nicht notwendigerweise auf dem NAS laufen, sondern kann prinzipiell (auch als Dienst) auf jedem Host laufen, der Docker unterstützt - Windows, Linux, Mac OS, jetzt eben dann auch Synology, etc.
Von da her gesehen ist das Docker Konzept recht genial - schlank, schnell, universell einsetzbar. Leider noch sehr kommandozeilen-orientiert und eher weniger was für unbedarfte Endanwender.

Zur Vorgehensweise bei der Image Erstellung:
ich habe nicht die Syno gebootstrapt, sondern auf meinem PC eine neue Debian64 (Jessie RC3) VM aufgesetzt, und darunter dann über die debootstrap und chroot Tools das Docker Image aufgebaut.
Dieses Image habe ich dann auf dem Docker Hub hochgeladen.
Es wird dann über docker pull auf der Synology deployed, sobald die neue DSM 5.2 verfügbar ist.

Viele Grüße,
Stefan

StefanP.

#4
Hallo zusammen,

hier noch eine Kurzanleitung, wie man das Image nutzt:
(1) Installation Docker: siehe https://docs.docker.com/installation/
(2) Pull des Images: docker pull xiberger/jessie_fhem
(3) Start des Images: docker run -it -p 8083:8083 xiberger/jessie_fhem /bin/bash
(4) Start fhem: /etc/init.d/fhem start

Alternativ kann man das Image auch als Daemon im Hintergrund laufen lassen. Dazu habe ich ein kleines Shell Script geschrieben, das in einer Endlosschleife läuft, damit sich der Prozess, den man beim Start des Containers mitgibt, nicht beendet:
(3) Start des Images: docker run -d -p 8083:8083 xiberger/jessie_fhem /bin/bash -c /opt/fhem/fhem.sh

Anschließend kann fhem ganz normal über den gemappten Port 8083 unter der Host IP Adresse gestartet werden.

Mittlerweile hat Synology die Version 5.2 rausgebracht, allerdings ist der Build 5565 noch etwas buggy. Sobald die gröbsten Fehler ausgemerzt sind, werde ich der Sache mal einen Versuch geben.

Viele Grüße,
Stefan

graszegger

Hallo,

vielen Dank für dieses Image!
Leider bekomme ich meinen CUL nicht zum laufen.

Im Log finde ich nur folgendes:

2015.05.22 09:15:24 1: usb create starting
2015.05.22 09:15:24 1: PERL WARNING: Can't exec "lsusb": No such file or directory at ./FHEM/98_autocreate.pm line 366.
2015.05.22 09:15:24 1: usb create end


Auf der Seite FHEM.de steht, dass für CUL ein perl serial module benötigt wird (sudo cpan Device::SerialPort).
Ist es möglich, das dieses hier nicht installiert ist?

Viele Grüße,
Roland


StefanP.

Hallo Roland,

ich hab mich aufgrund der zahlreichen negativen Rückmeldungen zum 5.2er Release von Synology noch nicht getraut, es einzuspielen... und warte lieber noch die nächsten Updates ab. Es kann aber gut sein, dass die Installation noch nicht 100% komplett ist, ich hab das Docker Image bis jetzt immer nur "trocken" auf dem Laptop getestet.
Wird der CUL denn als USB Device auf der Synology erkannt ? Mögl.weise musst Du noch das "USB Serial Drivers" Package installieren ?

Gib mir noch ein paar Tage Zeit, dann trau ich mich an den Upgrade und probier's selbst...

Schöne Grüße,
Stefan

StefanP.

#7
Hallo noch einmal,

hab jetzt auf 5.2 aktualisiert, fhem läuft auf der Syno unter docker wie eine 1 (RAM: 45MByte).

Vorgehensweise noch einmal im Detail:
(1) Anstecken des CUL Sticks am USB Anschluss
(2) Check, ob der Stick erkannt wird:
- dmesg
- im Output am Ende nach Einträgen ähnlich zu "cdc_acm 1-1.3:1.0: ttyACM0: USB ACM device" suchen
(3) Check /dev/ Verzeichnis, ob ttyACM0 Device vorhanden (ls -l ttyA*)
(4) Erweitern der Rechte, um dem fhem User Zugriff auf das device zu geben: chmod 666 ttyACM0
(5) Start des Docker Images mit zusätzlichen Parametern:
- "--device=/dev/ttyACM0": Freigabe des USB Devices (CUL Stick)
- "-v /volume1/public:/mnt/public": Mounten des "public" Verzeichnisses (wenn man z.B. eine bestehende fhem Installation migrieren möchte)
- nicht vergessen, die Ports 8083 ff übers GUI im Docker Package freizugeben
(6) Setzen der Timezone (das Docker Image läuft als Default auf der UTC Kernel Zeit):
- "echo Europe/Berlin > /etc/timezone && dpkg-reconfigure --frontend noninteractive tzdata"

Anschließend: Check der Installation, das Logfile sieht dann aus wie im Anhang.

Viel Spaß & Grüße,
Stefan

P.S.: ich habe alle Docker Operationen direkt über ssh in der Command Line abgesetzt

P.P.S.: Logfile (Auszug):
2015.05.27 09:02:35 1: Including fhem.cfg
2015.05.27 09:02:35 3: WEB: port 8083 opened
2015.05.27 09:02:35 3: WEBphone: port 8084 opened
2015.05.27 09:02:35 3: WEBtablet: port 8085 opened
2015.05.27 09:02:35 3: telnetPort: port 7072 opened
2015.05.27 09:02:35 2: eventTypes: loaded 1660 events from ./log/eventTypes.txt
2015.05.27 09:02:35 3: Opening CUL_0 device /dev/ttyACM0
2015.05.27 09:02:35 3: Setting CUL_0 baudrate to 9600
2015.05.27 09:02:35 3: CUL_0 device opened
2015.05.27 09:02:35 3: CUL_0: Possible commands: BbCFiAZEGMKUYRTVWXefmltux
2015.05.27 09:02:35 2: Switched CUL_0 rfmode to HomeMatic
2015.05.27 09:02:36 1: Including ./log/fhem.save
2015.05.27 09:02:36 1: usb create starting
2015.05.27 09:02:36 1: PERL WARNING: Can't exec "lsusb": No such file or directory at ./FHEM/98_autocreate.pm line 368.
2015.05.27 09:02:36 1: usb create end
2015.05.27 09:02:36 0: Server started with 115 defined entities (version $Id: fhem.pl 8574 2015-05-14 07:59:32Z rudolfkoenig $, os linux, user fhem, pid 1077)
2015.05.27 09:02:36 3: telnetForBlockingFn: port 34102 opened
2015.05.27 09:02:41 3: Device HM_Fensterkontakt_WZ added to ActionDetector with 028:00 time
2015.05.27 09:02:41 3: Device HM_RaumTemp_WZ added to ActionDetector with 000:10 time
2015.05.27 09:02:41 3: Device HM_SteckdoseWZ added to ActionDetector with 000:10 time
2015.05.27 09:02:41 3: Device HM_Thermostat_Hobby added to ActionDetector with 000:10 time
2015.05.27 09:02:41 3: Device HM_Thermostat_Keller added to ActionDetector with 000:10 time
2015.05.27 09:02:41 3: Device HM_Thermostat_Kueche added to ActionDetector with 000:10 time
2015.05.27 09:02:41 3: Device HM_Thermostat_WZ added to ActionDetector with 000:10 time

overkill2010

#8
Hallo,

vielen dank für das Docker Image. Coole Idee...

Hänge zurzeit hier fest:

dmesg

[21781.648881] cdc_acm 2-1:1.0: ttyACM0: USB ACM device


cd /dev

ls -l ttyA*

crw-rw-rw-    1 root     root      166,   0 May 27 12:27 ttyACM0

anschliessend kommt:

"--device=/dev/ttyACM0"
-ash: --device=/dev/ttyACM0: not found

hat jemand eine Idee ?

PS: habe ebenfalls eine Synology 415+ mit DSM 5.2-5565 Update 1 drauf

StefanP.

Die komplette Anweisung zum Starten des Docker Images lautet:
docker run -it -v /volume1/public:/mnt/public -p 8083:8083 --device=/dev/ttyACM0 xiberger/jessie_fhem /bin/bash

Der "--device" Parameter wird beim "run" Aufruf mit übergeben.

Viel Spaß & Grüße,
Stefan

overkill2010

Super viele dank hat geklappt.

musste nur noch:

/etc/init.d/fhem start

ausführen.

Wie kann ich dies nun im Autostart einfügen? Mein Synology fährt automatisch um 23.00 runter und startet um 7.00 Uhr wieder.


StefanP.

Hallo,

statt dem Parameter "-it" (für interactive) müsstest Du "-d" (als Daemon) mitgeben + mein Start Script ausführen:
docker run -d -v /volume1/public:/mnt/public -p 8083:8083 --device=/dev/ttyACM0 xiberger/jessie_fhem /bin/bash -c /opt/fhem/fhem.sh

Schöne Grüße,
Stefan


overkill2010

Sorry ich nochmal

kann es sein das meine Diskstation nach einen Neustart folgende rechte vergisst ?

HDD1> cd /dev
HDD1> ls -l ttyA*           
crw-------    1 root     root      166,   0 May 27 13:11 ttyACM0
HDD1> chmod 666 ttyACM0
HDD1> ls -l ttyA*
crw-rw-rw-    1 root     root      166,   0 May 27 13:12 ttyACM0

dadurch stand bei mein CUL_0 STATE disconnected


StefanP.

Hi,

sorry, da muss ich passen... sieht so aus, ja, aber warum und weshalb - am besten Onkel Google oder das Synology Forum befragen... sorry...

Schöne Grüße,
Stefan

overkill2010

#14
Danke trotzdem..

bin ja schon recht weit dank deiner Hilfe gekommen.

Super Job

PS

Habe nun einen Job erstellt der jeden morgen ausgeführt wird.
( chmod 666 /dev/ttyACM0 )

StefanP.

Hi,

der Start des Docker Containers muss tatsächlich über ssh erfolgen. Danach taucht der Container im GUI auf und kann dann ganz normal verwaltet werden, z.B. können die Ports 8083, 84, 85 und 7072 übers GUI geöffnet werden, die Logs werden angezeigt, laufende Prozesse etc.

Warum der --device Parameter dem GUI nicht bekannt ist - keine Ahnung. Vermutlich ein Bug.

Noch 3 Dinge, die mir im Laufe der Testerei aufgefallen sind:
1. die Zeitzone muss beim Start des Containers auf Europe/Berlin eingestellt werden
2. damit das PRESENCE Modul via LAN Ping funktioniert, brauchts den Befehl "chmod u+s `which ping`"
3. mit "docker exec -it <containerId> /bin/bash" kann man sich mit dem laufenden Daemon Container verbinden (wird vom GUI auch noch nicht unterstützt)

Generell würde ich immer mit der Kommandozeile über ssh arbeiten - das GUI ist (wie so oft) zwar anwenderfreundlich, aber doch sehr eingeschränkt, was die Features von Docker betrifft.

Viel Spaß,
Stefan

graszegger

#16
Hallo,

ich kann den Container und FHEM Starten:


2015.05.28 07:48:59 1: Including fhem.cfg
2015.05.28 07:48:59 3: telnetPort: port 7072 opened
2015.05.28 07:48:59 3: WEB: port 8083 opened
2015.05.28 07:48:59 3: WEBphone: port 8084 opened
2015.05.28 07:48:59 3: WEBtablet: port 8085 opened
2015.05.28 07:48:59 2: eventTypes: loaded 0 events from ./log/eventTypes.txt
2015.05.28 07:48:59 1: Including ./log/fhem.save
2015.05.28 07:48:59 1: usb create starting
2015.05.28 07:48:59 1: PERL WARNING: Can't exec "lsusb": No such file or directory at ./FHEM/98_autocreate.pm line 366.
2015.05.28 07:48:59 3: Probing CUL device /dev/ttyACM0
2015.05.28 07:48:59 1: define CUL_0 CUL /dev/ttyACM0@9600 1034
2015.05.28 07:48:59 3: Opening CUL_0 device /dev/ttyACM0
2015.05.28 07:48:59 3: Setting CUL_0 baudrate to 9600
2015.05.28 07:48:59 3: CUL_0 device opened
2015.05.28 07:48:59 3: CUL_0: Possible commands: BCFiAZEGMRTVWXefmltux
2015.05.28 07:48:59 1: usb create end
2015.05.28 07:48:59 2: SecurityCheck:  WEB,WEBphone,WEBtablet has no basicAuth attribute. telnetPort has no password/globalpassword attribute.  Restart FHEM for a new check if the problem is fixed, or set the global attribute motd to none to supress this message.
2015.05.28 07:48:59 0: Server started with 10 defined entities (version $Id: fhem.pl 6913 2014-11-08 10:32:44Z rudolfkoenig $, os linux, user fhem, pid 7)



--device=/dev/ttyACM0 wird aber von der GUI nicht unterstützt und ist dort beim Container auch nicht zu sehen.
Starte ich den Container über die GUI wird das device nicht verbunden/gefunden.

In der Hilfe auf der Synology finde ich dazu folgendes:

Zitat
Die Ausführung von Docker unterstützt nicht die nachstehenden Parameter:
"a", "attach"
"add-host"
"c", "cpu-shares"
"cap-add"
"cap-drop"
"cidfile"
"cpuset"
"device"
"dns"
"dns-search"
"entrypoint"
"env-file"
"expose"
"h", "hostname"
"i", "interactive"
"lxc-conf"
"net"
"restart"
"rm"
"security-opt"
"sig-proxy"
"t", "tty"
"u", "user"
"w", "workdir"

Führe ich den befehl über telnet erneut aus wird ein zweiter Container erstellt und gestartet.
docker run -d -p 8083:8083 --device=/dev/ttyACM0 xiberger/jessie_fhem /bin/bash -c /opt/fhem/fhem.sh

Somit sind natürlich auch alle einstellungen verloren ... der name des Containers wird scheinbar irgendwie zufällig generiert.
Ich vermute nach einem Neustart sind also alle Einstellungen verloren?

Des weiteren ist mir auch aufgefallen, wenn das Paket über die GUI heruntergeladen wird wird es über SSH nicht erkannt und erneut heruntergeladen.

Gibt es einen Befehl um den vorhanden Container mit dem Device zu starten?

Vielen Dank!

fg
Roland

StefanP.

Hi,

die oben beschriebenen Sachverhalte sind (fast) alle korrekt.

Docker hat gewisse Eigenheiten, an die muss man sich erst gewöhnen.
Ich würde das Einlesen in die Docker Basis Doku empfehlen, da sind die meisten Fragen beantwortet: https://docs.docker.com/userguide/

Im Detail:
- mit der Kommandozeile über ssh arbeiten, da mächtiger als das GUI
- das Image ziehen, dann den Container starten und Modifikationen vornehmen
- wenn im Container Änderungen am Image vorgenommen werden (Konfig, Aktualisierungen, Anpassungen der fhem.cfg etc.), dann können diese Änderungen mit dem "docker commit" Befehl im Image persistiert / zurück geschrieben werden. Am besten ein sprechendes Label / "Tag" mitgeben, sonst verliert man bei der wachsenden Anzahl von Images den Überblick
- jeder Container bekommt dafür eine eigene Id
- wenn die Änderungen im Image persistiert sind (mit einem Tag, z.B. ":v2"), würde der Start eines neuen Containers entsprechend mit dem modifizierten Image "xiberger/jessie_fhem:v2" erfolgen
- "docker list images" zeigt alle Images, "docker ps" zeigt alle Container
- "docker rm" und "docker rmi" löschen Container bzw. Images

Docker braucht eine gewisse Einarbeitungszeit. Es ist nicht immer selbsterklärend. Man muss viel mit den selbstgenerierten Ids arbeiten, was nicht 100% intuitiv ist.
Man wird dafür mit einer schlanken lauffähigen fhem Installation belohnt, die grad einmal 40MB Speicher braucht...

Viel Spaß & Grüße,
Stefan

graszegger

Vielen Dank für den Link mit der Doku!

Zitat
By default, Docker containers are "unprivileged" and cannot, for example, run a Docker daemon inside a Docker container. This is because by default a container is not allowed to access any devices, but a "privileged" container is given access to all devices (see lxc-template.go and documentation on cgroups devices).

When the operator executes docker run --privileged, Docker will enable to access to all devices on the host as well as set some configuration in AppArmor or SELinux to allow the container nearly all the same access to the host as processes running outside containers on the host. Additional information about running with --privileged is available on the Docker Blog.

If you want to limit access to a specific device or devices you can use the --device flag. It allows you to specify one or more devices that will be accessible within the container.

In der GUI findet man unter den "Erweiterten Einstellungen" / "Umwelt" (dort wo auch der Ausführungsbefehl angegeben werden kann) die Option "Container mit hoher Priorität ausführen".
Ich vermute dies entspricht der option "--privileged".

Auf jeden fall funktioniet es mit dieser Option nun auch in der GUI ohne die CLI anfassen zu müssen :)
Ein CHMOD sollte dadurch auch nicht mehr notwendig sein....

Ob es gut ist den Container mit root rechten laufen zu lassen ist eine andere Frage .... !?

StefanP.

Ich hab in einem der vielen Docker Artikel gelesen (ich find ihn grad nicht mehr.. waren zuviele...), dass die --privileged Option vermieden werden sollte - der Container hat damit wohl root Zugriff auf die Host Ressourcen bzw Firmware (wie eben das tty device). Wenn der Container Amok läuft (aus welchen Gründen auch immer - z.B. rein hypothetisch angenommen, jemand würde es gelingen, einen Exploit als fhem pm Modul einzuschleusen), kann das die Syno killen... das wäre mir persönlich zu heiss.

Es gibt wohl die Möglilchkeit, mit einem "capabilities Flag" diese uneingeschränkten Rechte wieder zu beschränken:
http://opensource.com/business/15/3/docker-security-tuning

Ich würde da eher den chmod Weg beim Startup der Syno gehen, das kann ja auch über ein Startup Script erledigt werden. Der Container selbst braucht ja m.E. keine weiteren Rechte außer den Zugriff auf den CUL.


P.S.: das gehört jetzt nicht zum Security Thema: was mir selbst noch nicht klar ist: wenn die Syno (und damit der Container) neu gestartet wird, dann sind vermutlich die Inhalte des Containers (log Dateien, Erweiterungen etc.) verloren, wenn zwischendurch nicht ein docker commit abgesetzt worden ist... hmmm dazu muss ich mir mal Gedanken machen.

gamauf

Hallo Stefan!

Ich bin zwar kein Docker Experte, aber so wie ich das Konzept verstanden habe, sollte im Container nur die Binaries, also der Programmcode, aber nicht die individuelle Konfiguration (logs, fhem.cfg, etc) liegen. Das log Verzeichnis, fhem.cfg und was sonst noch zur Konfiguration gehört würde ich auf einer Freigabe der Disksation, die ich im Docker-Container mounte, ablegen.

StefanP.

Hi,

ja, stimmt, das ist eine gute Idee. Vermutlich müsste das ganze /opt/fhem Verzeichnis über ein share gemappt werden, dann geht nichts verloren. Die Updates laufen dann ja ohnehin in fhem und nicht über den Package Manager.

Die Frage, die ich mir grad stelle, ist, ob statt Docker nicht die VirtualBox mit einer "echten" virtuellen Linux Jessie Installation eine bessere Lösung ist (die zudem auch im Vgl. zum Docker Package auf allen Synology DSMs läuft)...

Naja, aber immerhin, die Docker Lösung funktioniert  8)

Schöne Grüße,
Stefan

SpenZerX

Hallo,

das Thema interessiert mich.
Wie viele Container mit FHEM könnte man denn auf aktueller Hardware x86 parallel laufen lassen? Wie wird dargestellt wie viel Rechenzeit die einzelnen Cointainer verbrauchen?
Würde gerne einen cloud FHEM-Entwicklungsserver aufbauen. Mit vielen Instanzen. wäre Docker da das richtige? Oder OpenShift?

MFG

StefanP.

Hallo,

Docker zeigt auf meiner Synology den Speicherbedarf für den laufenden Container mit 40MB an.
Ja, die Last wird ebenfalls angezeigt, benötigt minimal CPU - zu 98% läuft der Container (bei mir zumindest) im Leerlauf, hängt natürlich davon ab, was man mit der fhem Installation anstellt.

Zum Vergleich: meine VirtualBox VM (auch Jessie + fhem) läuft mit 128MB RAM.

Die Docker Installation hat einige Probleme verursacht (siehe oben) - das tty Device muss berechtigt werden, der ping lief am Anfang nicht, und interessanterweise machte der CUL Stick über Docker auch Probleme, auch wenn er problemlos erkannt und eingebunden worden ist.
Von da her gesehen bin ich jetzt auf die VirtualBox umgestiegen, out of the box alles problemlos, und für meinen Einsatzbereich (zur Ablösung meines Pi's) wohl die bessere Lösung.

Viel Erfolg,
Stefan

kunze

Hallo,

ich habe den Ansatz mit Docker noch mal weiterverfolgt und umgesetzt:
Mit diesem Docker Image (https://hub.docker.com/r/michaelatdocker/fhem/) läuft FHEM bei mir seit in paar Tagen auf der Synology.
Allerdings verwende ich keinen CUL stick sondern einen HM-CFG-USB-2 da ich weitgehend mit HomeMatic arbeite.
Der 'Treiber' (http://www.fhemwiki.de/wiki/HM-CFG-USB_USB_Konfigurations-Adapter#Einrichtung_auf_Synology_DiskStations)
für den HM-CFG-USB-2 läuft direkt auf der DiskStation und der Zugriff aus dem Docker Container erfolgt übers Netzwerk.

Schön Grüße

paj

Anyone stumbling across this due to fhem ttyusb access problems in a docker container you need to

1. use privileged mode
2. make sure the fhem container user is a member of the dialout group in the container i.e run usermod -a -G dialout fhem in your Dockerfile.