Offizielles FHEM Docker Basis Image für verschiedene Plattformen

[Loredo]

Um genauer zu sein, die Reaktion auf meinen bug report haut mich ehrlich gesagt aus den Socken.
Ein bug report ist kein Ort für eine Diskussion, hier vielleicht schon. Mich würde schon interessieren, ob Ihr diesen Zugang (dem Admin dazwischenzupfuschen) in Ordnung findet.

Mir ist z.B. für ein produktives System dieses Image auch zu groß. Liebe eher kleine Image ... und wenn man mehr braucht, kann man ein 2. Größeres machen, welches aber auf dem minimalem aufbaut. Auch dieses wurde abgelehnt ...

Ich denke ich habe das schon mehrfach erklärt.


1. FHEM ist von seiner Systemarchitektur selbst kein guter Kandidat für ein klassisch-modernes Container Setup.
2. FHEM Module sind extrem divers in ihren Systemanforderungen und kaum durchschaubar. Die Systemabhängigkeiten herauszufinden ist oft sehr zeitaufwändig und für Anfänger oft eine unüberwindbare Hürde.
3. Der FHEM Installer zusammen mit dem Meta.pm Package sind beides Entwicklungen von mir, die (auch) darauf abziehlen, eine schlankere Systemumgebung zu ermöglichen bzw. eine Installation "On-Demand". Wem dies wichtig ist, der ist herzlich eingeladen dort aktiv mitzuwirken. Dies ermöglichte dann eine Verkleinerung des Images ohne Verlust des Komforts zur einfachen Nutzung der meisten FHEM Module.

Ergo: Wie schon richtig erkannt geht es hier nicht darum, dass Power Systemintegratoren ihre Wolllust befriedigt bekommen. Der Ansatz ist eher pragmatisch für die Mehrzahl der "normalen" Benutzer gewählt. Zu denen zählt ihr beide euch eben nicht. Das ist vollkommen okay, aber einsehen solltet ihr das eben auch

Als "Hintertür" gibt es für euch aber auch die Möglichkeit das Image selbst zu bauen. Das Dockerfile ist in Layern aufgeteilt und sehr viele lassen sich zur Buildzeit übergehen, wenn man die Umgebungsvariablen entsprechend setzt. Ich nehme an das ist für Kenner kein Problem dies zu tun.

[Loredo]

Bei anderen Projekten geht man deshalb mittlerweile anders vor:
Basis Image mit Basis-Funktionalität
- Erweitertes Image für Alexa
- Erweitertes Image für ....

Natürlich bauen die Erweiterten auf das Basis-Image auf.

Kann man alles machen, technisch kein Problem. Geht sogar fast schon mit dem aktuellen Dockerfile. Problem: Das CI/CD Setup dafür zu initialisieren und zu pflegen ist zeitlich sehr aufwändig und die kostenfreien Kapazitäten der Anbieter sind begrenzt. Wenn hier jemand Zeit investieren will - go for it, ich begleite das dann gerne. Ich kann da aber selbst derzeit keine zusätzlichen Ressourcen reinstecken.

[Wernieman]

Ich habe versucht Dir zu sagen, das ich Deinen Ansatz verstehe und Dich deshalb NICHT kritisiere .. auch wenn ich es anders machen würde ;o)

Übrigens .. gerade wegen der zeitlichen Begrenzung wäre ein aufsplitten sinnvoll. Kann aber bezüglich docker-hub selber diesbezüglich nicht mitreden, da wir hier eine eigene Pipeline haben .. die ich nur leider "privat" nicht nutzen darf (schon nachgefragt).

Mit "Klein" meinte ich übrigens nicht fhem sondern "nur" die mitgelieferten Libarys ....

[Sille]

Hat jemand  dash_dhcp mit dem offiziellen Docker Image zum Laufen gebracht?

Bei mir läuft fhem seit 2 Jahren im selbstgebauten Docker Image und ich wollte nun auf das offizielle umstellen.
Bei dash_dhcp habe ich das Problem, dass ich das Mapping nicht hin bekomme (im eigenen Container läuft es bestens)

Beim offizielle Image habe ich über den Parameter APT_PKGS die Pakete nachinstalliert:

Code Auswählen Erweitern

iptables iptables-persistent
Über das post-init.sh Script soll dann das Mapping erfolgen durch

Code Auswählen Erweitern

iptables -I PREROUTING -t nat -i eth0 -p udp --src 0.0.0.0 --dport 67 -j DNAT --to 0.0.0.0:6767

Docker meckert auch nicht, arbeitet den Befehl ab. ifconfig spuckt eth0 aus.

Auch wenn ich es manuell direkt im Docker Container ausführe kommt kein Fehler.
In die /etc/iptables/rules.v4 habe ich den Eintrag

-I PREROUTING -t nat -i eth0 -p udp --src 0.0.0.0 --dport 67 -j DNAT --to 0.0.0.0:6767

aufgenommen.

Trotzdem kommt als Fehler

2020.02.17 12:46:32.709 2: dashButton: failed to open port 67 IO::Socket::INET: Permission denied
2020.02.17 12:47:02.711 2: dashButton: failed to open port 67 IO::Socket::INET: Permission denied
2020.02.17 12:47:32.713 2: dashButton: failed to open port 67 IO::Socket::INET: Permission denied

NET_ADMIN ist aktiviert, als Netzwerk nutze ich jeweils macvlan. Ich habe den Verdacht, dass das Routing auf udp fehlschlägt...

Ich bin für jeden Hinweis dankbar!
LG Sille

[volschin]

Deine Fehlermeldung ist doch wohl ziemlich klar. Dein Dash Button Modul versucht Port 67 zu öffnen und nicht Port 6767.

[Sille]

Das verstehe ich schon, dass versucht wird Port 67 zu öffnen. Das will ich ja auch, der Dashbutton ist ja so definiert. Ich benötige aber dazu ein udp Mapping von 67 auf 6767 und verstehe nicht, warum es in diesem Docker Container mit obigen Befehlen nicht klappt, in meinem selbstgebauten - auch Debian Buster - schon.
LG Sille

[volschin]

Wenn Dein fhem nicht unter Root läuft, steht dort sicher als Attribut auch Port 6767. dein iptables Eintrag macht ja überhaupt keinen Sinn, wenn Du doch versuchst auf Port 67 zu horchen.

[Sille]

Richtig, root ist der Unterschied! Ich versuche heute Abend, den Container auch unter root laufen zu lassen und gucke, ob das Mapping dann klappt.
LG Sille

[Schlimbo]

Nutze die Dash Buttons auch in Docker, habe einfach das Port Mapping in die docker-compose File aufgenommen:

Code Auswählen Erweitern

ports:
      - 67:6767/udp
Und schon geht's.

[Sille]

OK, das kann ich auch noch versuchen. So läuft auch mein eigener fhem Container, da ich über docker-compose noch weitere abhängige Container mitstarte. Momentan habe ich das offizielle Docker Image über Portainer eingerichtet und dort auch das Mapping eingetragen. Ich vermute aber eher, dass es an der root Rechten liegt. Werde es heute Abend ausprobieren und berichten.

Schlimbo, nutzt du das offizielle Docker Image für fhem oder hast du auch ein eigenes?

LG Sille

[Wernieman]

An den root-Rechten sollte es nicht liegen, da Docker Selber immer mit diesen Rechten läuft .. würde Dir das Mapping auch empfehlen! Egal ob mit docker-compose oder direkt bei Docker ...

[Schlimbo]

Schlimbo, nutzt du das offizielle Docker Image für fhem oder hast du auch ein eigenes?

Nutze das offizielle FHEM Docker aus diesem Thread.
An den Rechten habe ich auch nichts geändert, läuft so Out of the box.

[Sille]

Irgendwie will es nicht so wie ich es will... Ich bin auch kein Netzwerkauskenner...

Der Container ist gestartet mit

Code Auswählen Erweitern

ports:
      - 67:6767/udp

und mit dem Netzwerk macvlan

Code Auswählen Erweitern

networks:
          macvlan0:
            ipv4_address: 192.168.1.104


Auf dem Host erkenne ich auf Port 67 den Dashbutton

Code Auswählen Erweitern

sille@nuc:~/docker/fhem-official/install$ sudo tcpdump -nli eno1 udp port 67
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eno1, link-type EN10MB (Ethernet), capture size 262144 bytes
19:07:44.827942 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from fc:a6:67:xx:ac:ba, length 261

Im Docker Container auch nur auf Port 67

Code Auswählen Erweitern

root@fhem-official:/opt/fhem# tcpdump -nli eth0 udp port 67
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
19:08:12.080633 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from fc:a6:67:xx:ac:ba, length 261

Dann wird 67 nicht auf 6767 gemappt...

Ich weiss nun, warum es im selbgebauten Dockercontainer läuft.... Dort ist das Netzwerk "host" und fhem läuft als "root". Der Dashbutton lauscht auf 67, was natürlich so klappt...

@Schlimbo, welches Netzwerk nutzt du?

[Wernieman]

Was mir an Deinem Beitrag so auffällt ...

Dort ist das Netzwerk "host"

ports:
      - 67:6767/udp

- Lege mal den Port um, egal welches protokol (also udp weg)
- Warum vergiiebst Du eigentlich die Netzwerkadresse des Containers fest? und .. wie ist das Netzwerk überhaupt konfiguriert?

[Sille]

So es läuft nun. Ich habe auf dem Docker Host alles zurückgesetzt, auf dem Docker Container ebenfalls. Da muss von den vielen Versuchen irgendetwas schief gewesen sein...

Über APT_PKGS ist iptables zusätzlich installiert und in das pre-start.sh Script (vorher habe ich das post-init.sh benutzt) habe ich folgenden Befehl eingetragen:

Code Auswählen Erweitern

iptables -I PREROUTING -t nat -i eth0 -p udp --src 0.0.0.0 --dport 67 -j DNAT --to 0.0.0.0:6767

Mein Netzwerk ist mit dem macvlan-driver erzeugt

Code Auswählen Erweitern

docker network create -d macvlan \
  --subnet=192.168.1.0/24 \
  --gateway=192.168.1.254 \  (<=Fritzbox)
   -o parent=eno1 pub_net

und zusätzlich in den Netzwerkeinstellungen des Docker Hosts (/etc/network/interfaces):

Code Auswählen Erweitern

auto eno1
iface eno1 inet manual

auto macvlan0

iface macvlan0 inet static
    address 192.168.1.99 (<=Dockerhost)
    network 192.168.1.0
    netmask 255.255.255.0
    broadcast 192.168.1.255
    gateway 192.168.1.254 (<=Fritzbox)
    dns-nameservers 192.168.1.254 (<=Fritzbox)
    pre-up ip link add link eno1 name macvlan0 type macvlan mode bridge

Das hat den Vorteil, dass jeder Docker Container eine eigene IP-Adresse bekommt und man über z.b. 8080 und die jeweilige IP-Adresse des Docker Containers zugreifen kann und nicht nur einmal pro Dockerhost.

Ich habe zur Zeit 12 Container, da waren einige Ports doppelt und ich war es leid, immer die Ports umzuleiten und mir diese zu merken....

LG Sille