[gelöst]FHEM mit dblog in Docker

Begonnen von fhemjan, 23 August 2022, 22:59:53

Vorheriges Thema - Nächstes Thema

fhemjan

Hallo zusammen,
gefühlt betreibt jeder seine FHEM Installation mit dblog in Docker, aber nirgendwo finde ich einen Hinweis wie genau man das am besten umsetzt.
FHEM läuft bei mir auf einem Raspberry 4 mit 4GB und Bullseye in einem Docker Container. Welche Datenbank würdet ihr empfehlen? Mir scheint, dass häufig MariaDB genutzt wird. Habe mich an der Installation versucht, aber mir ist dann direkt unklar wie ich FHEM mit der Datenbank verbinde.
Kann mich jemand in die richtige Richtung schubsen?

Otto123

#1
Hi,

naja was soll da besonders sein? MariaDb konsequenterweise als Container, ich würde alles zusammen mit docker compose machen, und dann weiter wie immer?
help dblog

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

fhemjan

Hallo Otto,
vielen Dank schon einmal für deine Antwort. Ich tue mich tatsächlich immer etwas schwer unterschiedliche Container zu verknüpfen, da muss ich mich wohl noch mal in die Basics einlesen. Ich hatte gehofft das es vielleicht eine Anleitung gibt, das Wiki ist ja in der Regel eine Goldgrube, nur dazu bin ich nicht fündig geworden.
Würdest du den Ansatz verfolgen beide Container in ein gemeinsames Netzwerk zu stecken? Bzw. wie bekommt man es hin, dass die Container kommunizieren?
Ich bin einerseits begeistert vom Docker-Ansatz, andererseits alle paar Tage kurz vorm Verzweifeln  ;D

Ich habe dazu noch eine zweite Frage:
Mit der Zeit wird die Datenbank ja anwachsen, daher dachte ich es wäre vielleicht sinnvoll, wenn die Daten direkt auf meiner Synology gesichert werden.
Mithilfe dieser Anleitung: https://jsx.red/synology-nas-mit-dem-raspberry-verbinden/ habe ich mittels NFS einen Ordner gemountet (verstehe ich richtig, das die Dateien dann direkt auf der Synology sind und es kein gemeinsamer Ordner a la Dropbox ist oder?
Nur wenn ich nun einen mariadb Container starte und das Volume /config mit meinem gemounteten Ordner verknüpfe bekomme ich im Log von mariadb immer Fehler bzgl. Berechtigungen. Konnte ich auch soweit nachvollziehen: Sobald ich den Ordner im fstab habe und mounte sudo mount -a werden die Berechtigungen auf root:root gesetzt. Muss ich dem mariadb Container User und Gruppe root zuweisen damit es klappt?

Otto123

Naja wie gesagt: docker compose verwenden, wenn man da "sparsam" konfiguriert landen die automatisch in einem (docker) Netzwerk. ;)
Hier geht es nicht um mariaDb - aber vielleicht hilft das für den Einstieg?
Aber:
Anstatt die Datenbank Files auf die NAS zu packen, würde ich es vom Design her für besser halten die komplette MariaDb auf der NAS zu betreiben.

Da gab es mal unseren Stammtisch zum Thema dbLog, da findest Du im Anhang ein PDF, vielleicht hilft es.

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

kadettilac89

Zitat von: fhemjan am 23 August 2022, 22:59:53
Hallo zusammen,
gefühlt betreibt jeder seine FHEM Installation mit dblog in Docker, aber nirgendwo finde ich einen Hinweis wie genau man das am besten umsetzt.
FHEM läuft bei mir auf einem Raspberry 4 mit 4GB und Bullseye in einem Docker Container. Welche Datenbank würdet ihr empfehlen? Mir scheint, dass häufig MariaDB genutzt wird. Habe mich an der Installation versucht, aber mir ist dann direkt unklar wie ich FHEM mit der Datenbank verbinde.
Kann mich jemand in die richtige Richtung schubsen?

MariaDB ist eine Möglichkeit. Abhängig von der Datenmenge, und auch persönliche Vorzüge. Ich nuztze SQLite für Fhem da ich dann nur einen Container sichern muss. Wenn dir das MariaDB-Setup in der Lernphase zu kompliziert ist kannst auch mal mit SQLite anfangen, Fhem kennenlernen, Docker verstehen. Migrieren kannst auch später wenn nötig. SQLite schreibt alles in ein File im Filesystem und braucht keinen eigenen Container.

Sicherung ist wichtig, egal ob die DB wächst oder nicht. Nicht nur die DB-Daten sondern auch Fhem. Und nicht nur sichern, sondern auch mal testen ob du aus der Sicherung wieder zurückspielen kannst.

fhemjan

Hallo zusammen,
danke an Otto zunächst für den Link zu den Docker-Infos!

Zitat von: Otto123 am 24 August 2022, 10:43:12Anstatt die Datenbank Files auf die NAS zu packen, würde ich es vom Design her für besser halten die komplette MariaDb auf der NAS zu betreiben.

Interessanter Ansatz! Ich denke das könnte mein Weg werden. Falls ich zunächst doch verzweifle schau ich mir den Lösungsweg mit SQLite an.

Meine Sicherung mache ich händisch mit dem Windiskimager, nicht gerade komfortabel, aber es funktioniert ziemlich idiotensicher. Im Hinterkopf hab ich da immer noch eine Lösung mit rsync auf die Synology, da bin ich aber noch nicht zur Umsetzung gekommen...

ch.eick

#6
Zitat von: fhemjan am 24 August 2022, 12:18:40
Hallo zusammen,
danke an Otto zunächst für den Link zu den Docker-Infos!

Interessanter Ansatz! Ich denke das könnte mein Weg werden. Falls ich zunächst doch verzweifle schau ich mir den Lösungsweg mit SQLite an.

Meine Sicherung mache ich händisch mit dem Windiskimager, nicht gerade komfortabel, aber es funktioniert ziemlich idiotensicher. Im Hinterkopf hab ich da immer noch eine Lösung mit rsync auf die Synology, da bin ich aber noch nicht zur Umsetzung gekommen...
Hallo zusammen,
und noch ein Denkanstoß.
Da MySQL von Oracle auch direkt als Docker Container angeboten wird habe ich mich für den entschieden. Allerdings ist der Container nur für 64 Bit verfügbar.
Auf einem RPI habe ich deshalb die 64 Bit OS Version laufen und alles in allem läuft nun ca 1 Jahr stabiel. Der MySQL Container wird recht regelmäßig aktualisiert
und man ist direkzt am Original.
Aber Achtung, im Original gibt es bereits an einigen Stellen ziemliche Weiterentwicklungen, die auch teilweise andere SQL Abhängigkeuten haben. Besonders
merke ich das beim SELECT mit GROUP BY, was etwas gewöhnungsbedürftig ist.

Das DbLog Modul arbeitet bisher sauber und auch im Grafana merke ich bisher keine Probleme.


Version 8.0.30
amd64, arm64v8


Als Tools wäre da noch
- MySQL Workbench 8.0 CE
- SQLBackupAndFTP

VG
    Christian
RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick

fhemjan

Also mein Weg ist nun die MariaDB auf der Synology zu nutzen, dann kann ich sie dort auch direkt charmant mit phpmyadmin verwalten.
Der Part war denkbar einfach und läuft: Ich konnte über die Befehle aus der Datei  db_create_mysql.sql den fhemuser inkl. von mir definiertem Passwort und die entsprechenden Tabelleneinträge generieren.
Auf der Synology hab ich in der Firewall den Port 3306 freigegeben.
Ich habe dann die db.conf aus /contrib/dblog in das Hauptverzeichnis kopiert. Angepasst habe ich
host=ip-Synology, password= das generierte Passwort für den fhemuser
Wenn ich nun das DbLog device definieren will mit define logdb DbLog ./db.conf .*:.* komme ich entweder auf eine weiße Seite auf der etwas von Fehlercode 400 steht, oder, nach Neuladen der fhem Seite und erneuter Eingabe ein "could not read connection".

Habt ihr eine Idee wo es gerade noch hakt? Ich habe mal die Konfiguration vom Fhem Container angehängt falls das hilft. Er läuft im Bridge Netzwerk.





fhemjan

Achso, also am allerschönsten wäre es natürlich, wenn ich meinen ursprünglichen FHEM-Container weiternutzen könnte.. Da scheitert es nur leider wie gesagt schon dran an die Dateien in den Verzeichnissen zu gelangen :(

Vielleicht habt ihr ja auch da einen Tip?

kadettilac89

#9
Zitat von: fhemjan am 25 August 2022, 23:58:23
Achso, also am allerschönsten wäre es natürlich, wenn ich meinen ursprünglichen FHEM-Container weiternutzen könnte.. Da scheitert es nur leider wie gesagt schon dran an die Dateien in den Verzeichnissen zu gelangen :(

Vielleicht habt ihr ja auch da einen Tip?
hast du in Fhem das Attribut "dnsServer" gesetzt? Docker kennt den Host bzw. dessen IP nicht.

Teste es mal mit der IP statt dem Hostnamen.

fhemjan

Zitat von: kadettilac89 am 26 August 2022, 09:21:58
hast du in Fhem das Attribut "dnsServer" gesetzt? Docker kennt den Host bzw. dessen IP nicht.
Teste es mal mit der IP statt dem Hostnamen.
Nein, das Attribut hab ich noch nicht gesetzt. Klingt sinnvoll, das schau ich mir an. Du meinst also attr global dnsServer?

Tatsächlich habe ich in der db.conf immer die IP der Synology genommen, da ich das Konstrukt eh nur im internen Netz bei mir nutzen will. Der Datenbank Port ist im Router nicht freigegeben, nur in der Synology.

kadettilac89

wenn du 400 als Fehler bekommst ist das ein Netzwerk Problem oder Zugriff nur von localhost. Prüf mal im Eingabefeld oben einen Ping.

NAS durch deinen Hostnamen
192.168.0.30 durch deine IP ersetzen


{qx(ping -c 2 NAS)}
{qx(ping -c 2 192.168.0.30)}


Das sollte entweder erfolgreich sein, oder so was ähnliches brignen wenn Host nicht erreichbar ist. Ausgabe entweder direkt, oder im Log. Kann ein paar Sekundebn laufen ...

PING 192.168.0.30 (192.168.0.30): 56 data bytes
--- 192.168.0.30 ping statistics ---
2 packets transmitted, 0 packets received, 100% packet loss

ODER beim Hostname
ping: unknown host


Wenn Host und IP erreichbar ist, liegt es woanders. Zugriff ggf. nur von localhost aber nicht von extern erlaubt ... eins nach dem anderen.

kadettilac89

mach dann auch einmal einen config Check direkt im DBLog


set logdb configCheck


Das gibt dir aus, welche Config gelesen wird, ob auf Fhem alles passt. Du hattest die Frage zu den Files gestellt.

Otto123

Zitat von: fhemjan am 25 August 2022, 23:58:23
Achso, also am allerschönsten wäre es natürlich, wenn ich meinen ursprünglichen FHEM-Container weiternutzen könnte.. Da scheitert es nur leider wie gesagt schon dran an die Dateien in den Verzeichnissen zu gelangen :(

Vielleicht habt ihr ja auch da einen Tip?
Warum solltest Du den Container nicht nutzen können?
Warum kommst Du nicht an die Dateien in den Verzeichnissen?
ZitatIch habe dann die db.conf aus /contrib/dblog in das Hauptverzeichnis kopiert. Angepasst habe ich
Wie hasst Du denn das gemacht?
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

fhemjan

@kadettilac89: Danke für deine Lösungssschritte, ich teste sie sobald ich eine ruhige Minute am Rechner habe.

@Otto123: Das habe ich an einem neu aufgesetzten FHEM Container gemacht. Dabei habe ich auf dem Raspberry ein /docker-fhem Verzeichnis erstellt und das mit Bind in Portainer mit dem Container verbunden. Wenn ich den Container nun mit PUID und GID 1000 gestartet hab, konnte ich auf das Verzeichnis zugreifen. (Nur nebenbei, mit der Standard FHEM Einstellung PUID und GID 6061 bin ich an das Verzeichnis aufgrund der Rechte nicht mehr dran gekommen sobald der Container einmal gestartet war.

--> bei meinem ursprünglichen FHEM Container (den ich am liebsten, wenn denn möglich behalten würde) habe ich das Volume dummerweise in Portainer erstellt und direkt verbunden. Aufgrund von Schwierigkeiten die ich nicht ganz verstehe (man findet dazu etwas wenn man googled und brauch dafür scheinbar den Portainer Agent), fehlt bei mir in Portainer > Volumes der Button ein Volume zu browsen oder etwas hochzuladen. In der Portainer Doku sieht es kompett anders aus als bei mir, dort scheint es ganz leicht zu sein. Ich habe dann hinbekommen mich über die shell in das docker Verzeichnis selbst zu begeben mit docker exec -it und der ID des Containers. Ich habe so auch die Datei gefunden, mir ist es dann mit meinen Kenntnissen jedoch nicht gelungen die Datei im Container direkt zu ändern. Es gab Fehler a la "Bash kennt die Befehle nicht (nano, cp, usw.)". An dem Punkt hatte ich mit meinem ursprünglichen Container erst einmal aufgegeben und überlegt ob es sinnvoller ist in den sauren Apfel zu beißen und eine Neukonfiguration zu machen...