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.

[cbl]

Code Auswählen Erweitern

%dbconfig= (
    connection => "mysql:database=fhem;host=dbserver;port=3306",
    user => "fhem_db",
    password => "xxxx",
    utf8 => 1
);

Sieht für die configDB genauso aus - nur mit anderem User.

[DS_Starter]

Sieht erstmal gut aus. Die Fehlermitteilung besagt dass der Eintrag für "connection =>" nicht gelesen werden kann.
Wir hatten schonmal den Fall, dass das File mit einem "ungünstigen" Editor erstellt wurde und nicht sichtbare aber störende Zeichen enthalten waren.
Kannst du dieses File nochmal erstellen. Am besten mit einem vi (Linux) oder auch notepad++ ?
Den Inhalt eintippen , nicht per copy+paste.

[cbl]

Erstellt habe ich das mit dem MC-Editor. Das File hat noch nie einen Windows-PC oder eine grafische Oberfläche gesehen.

Ich habe in der Zwischenzeit das DBLog-Device komplett gelöscht und neu angelegt und dabei dämmerte mir, was das Problem ist:
Beim Einlesen in configDB habe ich ./db.conf verwendet. Im DBLog-Device stand /opt/fhem/db.conf. Das meint zwar dieselbe Datei, ist aber als Schlüssel in der configDB natürlich ein Unterschied.

Was mich wundert ist aber, dass das vor dem Update auf Debian 11 funktioniert hat. Am DBLog Device (und auch sonst) habe ich nichts rumgeschraubt. Ist da irgendeine beteiligte Perl-Bibliothek in einer neueren Version derart verändert, dass das vorher funktioniert hat mit der relativen Pfadangabe und nun strikter gehandhabt wird?

[DS_Starter]

Ist da irgendeine beteiligte Perl-Bibliothek in einer neueren Version derart verändert, dass das vorher funktioniert hat mit der relativen Pfadangabe und nun strikter gehandhabt wird?

Kann ich mir nicht vorstellen.

Hab noch nicht ganz verstanden was der Status jetzt ist. Geht es nun mit einem neu angelegten DbLog Device mit meiner Testzeile und/oder auch mit configDB ?

[cbl]

Es läuft jetzt mit einem neu angelegten DbLog Device. Das alte habe ich gelöscht. Ich vermute, dass es auch mit dem alten Device nun funktioniert hätte.
Ich verwende weiterhin configDB und habe (mit dem gewünschten User und neuem Passwort) die db.conf neu eingelesen.

Die echte Änderung ist, dass ich beim configdb fileimport die db.conf exakt so angegeben habe wie im DbLog Device. Das war vorher unterschiedlich.

Vielen Dank für die Tipps, die am Ende dazu geführt haben, dass ich beim wiederholten Draufschauen den Unterschied gesehen habe.

[DS_Starter]

Na dann weiterhin viel Spaß beim Loggen 

Allerdings erschließt sich mir noch nicht wieso aus dem File nicht korrekt gelesen werden konnte.
Nun ja ...

LG,
Heiko

[betateilchen]

Was mich wundert ist aber, dass das vor dem Update auf Debian 11 funktioniert hat. Am DBLog Device (und auch sonst) habe ich nichts rumgeschraubt. Ist da irgendeine beteiligte Perl-Bibliothek in einer neueren Version derart verändert, dass das vorher funktioniert hat mit der relativen Pfadangabe und nun strikter gehandhabt wird?

Das hat vorher nicht funktioniert. Du hast vorher im DbLog device /opt/fhem/db.conf verwendet.

Den Fehler hast Du beim Editieren Deiner Verbindungskonfiguration verbrochen...

mit einem neu gesetzten Passwort. Dieses Passwort habe ich nach dem Anlegen in MySQL auch in die db.conf geschrieben.


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

Code Auswählen Erweitern

configDB fileimport ./db.conf

importiert.

und damit hast Du zwei verschiedene Konfigurationsdateien in Deiner configDB.
Dass dann weiterhin die alte Konfigurationsdatei verwendet wird, ist absolut logisch, solange Du das im DEF Deines DbLog nicht änderst.

Hättest Du einfach mal meinen Tipp befolgt und verbose 5 gesetzt, hättest Du das im FHEM-Log bemerkt.

[cbl]

Hallo,

ich hatte verbose 5 schon vorher und habe dieses Detail übersehen.

Aber ich stimme dir zu, dass vermutlich alles korrekt funktioniert und - wie so oft - das Problem 60 cm vor dem Rechner saß und die neue Konfigurationsdatei nun nur mit relativem Pfad importiert hat. Das muss ich vor langer Zeit schon mal gemacht haben, da mir die Autovervollständigung im Browser den relativen Pfad vorschlug, den ich dann auch so verwendet habe. 

Was die ursprüngliche Ursache war, dass nach dem Update die Verbindung nicht mehr geklappt hat, kann ich jetzt nicht mehr nachvollziehen. Den hier nun diskutierten Fehler habe ich im Rahmen der "Analyse" reingebracht.

Danke für eure Hinweise.

Gruß
Christian