DbLog Verbindungsproblem nach Update auf Debian Bullseye

[cbl]

Hallo,
ich habe gestern meine beiden Debiansysteme auf Bullseye (Debian 11) angehoben. Seitdem hat DbLog Probleme mit dem Zugriff auf die Datenbank, die unverändert auf dem gleichen Server ("dbserver") (nun halt mit Debian 11) liegt.

Ich kann mich mit den in der db.conf stehenden Daten (User: fhem) vom FHEM-Server aus in der Datenbank anmelden und dort per Kommandozeile agieren.
DbLog selbst liefert mir im configCheck diese Information:

Code Auswählen Erweitern

Result of version check

Used Perl version: 5.32.1
Used DBI (Database independent interface) version: 1.643
Used DBD (Database driver) version mysql: 4.050
Used DbLog version: 4.12.3.
Your local DbLog module is up to date.
Recommendation: No update of DbLog is needed. Your DBD version fulfills UTF8 support, no need to update DBD.

Result of configuration read check

Connection parameter store type: configDB (don't forget upload configuration file if changed. Use "configdb filelist" and look for your configuration file.)
Connection parameter: Connection -> mysql:database=fhem;host=dbserver;port=3306, User -> fhem, Password -> read o.k.

Result of connection check

Connection to database was not successful.
Recommendation: Plese check logfile for further information.

Ich habe die für DbLog genannten notwendigen Pakete geprüft. Die sind alle installiert und nicht beim Upgrade verloren gegangen.

Das Modul selbst liefert

Code Auswählen Erweitern

Access denied for user 'fhem_db'@'blomeraspi3.fritz.box' (using password: YES) at ./FHEM/93_DbLog.pm line 3238

Was übersehe ich? Wo könnte das Problem noch liegen?

Vielen Dank für jeden Tipp,
Christian

[DS_Starter]

Das ist eine Meldung des Datenbanksystems und hat nichts mit FHEM/DbLog an sich zu tun.
Deine FHEM Installation ist sicherlich ok.

Den Fehler kann man googeln, z.B. hier: https://www.stechies.com/error-1045-28000-access-denied-user-root-localhost/

Auch im Forum hier dürftest du etwas finden, ist nicht das erste mal dass dieses Problem auftritt.

LG,
Heiko

[cbl]

Hallo Heiko,

danke für die schnelle Antwort.

Ich habe _nicht_ root als Benutzer verwendet sondern einen speziellen User (mit nun zum Ausschluss von Rechteproblemen allen Rechten auf die Datenbank fhem) mit einem neu gesetzten Passwort. Dieses Passwort habe ich nach dem Anlegen in MySQL auch in die db.conf geschrieben.

Mit dem Benutzer fhem und diesem Passwort kann ich mich vom FHEM-Server auf der Kommandozeile per

Code Auswählen Erweitern

mysql -u 'fhem'@'dbserver' -p -h dbserver fhem
mit der Datenbank verbinden.

Den Klassiker bei MySQL/MariaDB mit den verschiedenen Hosts kann ich auch ausschließen. Der User ist gerade nicht auf einen bestimmten Host eingeschränkt.

Was macht FHEM beim Datenbankzugriff anders, so dass FHEM eine Antwort "Access denied" bekommt?
Ich komme mit anderen Anwendungen, die auf dem FHEM-Server laufen an die Datenbank (mediawiki, Bildergallerie, ...). Der MySQL-Server ist also auch von außen erreichbar.

Nachtrag da ich mit configDB arbeite:
Ich habe die db.conf auch wieder mit

Code Auswählen Erweitern

configDB fileimport ./db.conf
importiert.

Da scheint aber das Problem zu liegen. Denn nachdem ich gerade zu Testzwecken einen anderen Benutzer in die db.conf eingetragen habe und diese dann hochgeladen habe (wurde von FHEM erfolgreich quittiert mit der richtigen Dateigröße), sehe ich nach einem FHEM-Neustart (rereadcfg vorher hatte das gleiche Ergebnis) weiterhin die Fehlermeldung, dass der alte Benutzer sich nicht verbinden kann.
Offenbar ist die neue db.conf also nicht in der Datenbank gelandet und ich muss den Fehler bei configDB suchen.

[DS_Starter]

Guten Morgen Christian,

als Gedankenstütze dazu dient der Hinweis aus dem ConfigCheck:

Result of configuration read check

Connection parameter store type: configDB (don't forget upload configuration file if changed. Use "configdb filelist" and look for your configuration file.)
Connection parameter: Connection -> mysql:database=fhem;host=dbserver;port=3306, User -> fhem, Password -> read o.k.

[cbl]

Hallo,

der Hinweis ist wertvoll und daher hatte ich ja auch die geänderte db.conf importiert. Ich habe auch mit

Code Auswählen Erweitern

configdb fileshow ./db.conf geprüft, dass die Änderungen in der Datenbank gespeichert sind. Dort sehe ich die neuen Zugangsdaten.

Trotz Neustart und rereadcfg zeigt mir DBLog noch die alten Daten an (sowohl im configcheck als auch in der Übersicht der Internals sowie in der Fehlermeldung im state reading). Wo speichert DBlog die alten Zugangsdaten?

Gruß
Christian

[DS_Starter]

Hallo Christian,

Wo speichert DBlog die alten Zugangsdaten?

Diese Daten werden nicht gespeichert. Beim Start, was auch ein Define des Moduls beinhaltet, wird die Konfiguration jedesmal neu gelesen. Auch bei rereadcfg.
Wie sieht denn das Define von deinem DbLog Device aus ?

LG

[cbl]

Code Auswählen Erweitern

defmod DbLog DbLog /opt/fhem/db.conf .*:.*
attr DbLog DbLogSelectionMode Exclude/Include
attr DbLog DbLogType Current/History
attr DbLog asyncMode 1
attr DbLog room System
attr DbLog syncInterval 60

Und die dort liegende db.conf ist jene, die ich gestern auch über configdb importiert habe.

[DS_Starter]

Ja, dann passt das auch.
configDB habe ich persönlich auch nicht im Einsatz, kann nicht viel dazu beitragen.

Du könntest um die Ursache weiter einzugrenzen versuchen das Lesen der Konfig aus dem Filesystem zu erzwingen.

Wenn du es dir zutraust, ändere in 93_DbLog die Zeile 3169 statt:

Code Auswählen Erweitern


my ($err, @config) = FileRead($configfilename);


in

Code Auswählen Erweitern


my ($err, @config) = FileRead($configfilename, "file");


Ein nachfolgender Restart erzwingt das Lesen der Konfiguration aus dem File, also /opt/fhem/db.conf.
rereadcfg reicht dafür wegen der Codeänderung nicht.
Wenn das klappt, liegt es tatsächlich irgendwo an configDB und du kannst im passenden Forum die Info posten.

[betateilchen]

Code Auswählen Erweitern


my ($err, @config) = FileRead($configfilename, "file");


Das wird nicht funktionieren. Falsche Syntax für den Funktionsaufruf.

Setze mal verbose=5 und definiere testweise ein neues DbLog device. Dann sollte man im FHEM-Logfile wahrscheinlich sehen, was da passiert.

[DS_Starter]

Ach ja sorry, da war ich etwas voreinlig. So wäre es für diesen Test in Zeile 3169 richtig:

Code Auswählen Erweitern


my ($err, @config) = FileRead( { FileName => $configfilename, ForceType => "file" } );


[cbl]

Hallo,

beim neu angelegten DBLog Device erfolgt der Loginversuch auch mit den alten Logindaten.

Ich kann die Konfiguration speichern

Code Auswählen Erweitern

configdb info zeigt mir als letzte Versionen welche von heute an (state: 9142 entries saved: Thu Nov 25 20:52:10 2021)
Beim Laden wird sie auch aus der Datenbank geholt. Und wie oben geschrieben sehe ich mit

Code Auswählen Erweitern

configdb fileshow ./db.conf
auch die neuen Zugangsdaten, mit denen ich mich in der Datenbank anmelden kann. Ändere ich die db.conf und importiere neu, sehe ich die erneut geänderten Daten.

Der Fehler liegt damit irgendwo zwischen beiden Modulen.

Noch nicht erwähnt: FHEM ist auf dem aktuellen Stand.


Gruß
Christian

[cbl]

Hallo,

mit der Änderung im Modul kann ich kein DbLog-Device anlegen ("could not read connection").

Gruß
Christian

[DS_Starter]

Hast du auch meine korrigierten Testzeile probiert ?

[cbl]

Mit der ersten Fassung hatte ich den von betateilchen erwarteten Fehler.

Mit deiner korrigierten Fassung kommt genau diese Meldung.

[DS_Starter]

Zeig mal den Inhalt des Files /opt/fhem/db.conf. Passwort bitte entfernen.