Hallo Heiko,
ich wollte nun gemäß deinem Wiki Artikel das serverseitige Restore auf einem neu aufgesetzten Raspi3 mit minimal Fhem testen, damit die Hektik im Ernstfall nicht allzugroß wird.
Aber besonders weit bin ich nicht gekommen, es scheitert vermutlich noch an Rechteproblemen.
Aber nun Schritt für Schritt:
DbLog und DbRep auf Raspi3 installiert, läuft ohne erkennbare Probleme, old-DbLog und old-DbRep zusätzlich noch angelegt (eigentlich 1:1 Kopie der nahezu leeren Datenbank).
Ein Test von DbLog mit configCheck bemängelt lediglich einen fehlenden "Report_Idx".
Will ich diesen Index über DbRep anlegen wird folgende Fehlermeldung angezeigt:
DBD::mysql::db do failed: ALTER command denied to user 'Reinhard'@'localhost' for table 'history' at ./FHEM/93_DbRep.pm line 6852.
2020.08.25 20:19:59 2: DbRep old_DBReport - user "Reinhard" doesn't have rights "INDEX" and "ALTER" as needed - try use adminCredentials automatically !
Logge ich mich über SSH, mit User "Reinhard" und entsprechendem Kennwort direkt in MySQL ein, so sehe ich alle Datenbanken und alle Tabellen.
Auch ein set <reportdevice> adminCredentials <Benutzer> <Kennwort> mit <reportdevice> useAdminCredentials 1
löst das Problem nicht.
Ein set sqlCmd show grants; ergibt folgende Rechte:
GRANTS FOR REINHARD@%
GRANT USAGE ON *.* TO `Reinhard`@`%` IDENTIFIED BY PASSWORD '*A4164700429DF3587D1CCBDC12740C8B01FD37A2'
GRANT SELECT, INSERT, UPDATE, DELETE ON `fhem`.* TO `Reinhard`@`%`
GRANT SELECT, INSERT, UPDATE, DELETE ON `old-fhem`.* TO `Reinhard`@`%`
Sicher keine große Sache, aber irgendwie komm ich da selbst nicht dahinter und benötige noch einen Tipp.
Anbei noch mein Logdevice:
Internals:
COLUMNS field length used for Device: 64, Type: 64, Event: 512, Reading: 64, Value: 128, Unit: 32
CONFIGURATION /opt/fhem/contrib/dblog/old-db.conf
DEF /opt/fhem/contrib/dblog/old-db.conf aaaaa:bbbbb
FUUID 5f453a05-f33f-b86d-ac35-bb52db86d8f03abb
FVERSION 93_DbLog.pm:v4.10.2-s22246/2020-06-23
MODE asynchronous
MODEL MYSQL
NAME old_DBLogging
NR 17
NTFY_ORDER 50-old_DBLogging
PID 1812
REGEXP aaaaa:bbbbb
STATE connected
TYPE DbLog
UTF8 1
dbconn mysql:database=old-fhem;host=localhost;port=3306
dbuser Reinhard
HELPER:
COLSET 1
DEVICECOL 64
EVENTCOL 512
OLDSTATE connected
PACKAGE main
READINGCOL 64
TC current
TH history
TYPECOL 64
UNITCOL 32
VALUECOL 128
VERSION 4.10.2
READINGS:
2020-08-25 20:43:54 CacheUsage 0
2020-08-25 20:43:54 NextSync 2020-08-25 20:44:24 or if CacheUsage 500 reached
2020-08-25 20:43:54 state connected
Attributes:
DbLogExclude .*
DbLogSelectionMode Exclude/Include
DbLogType Current/History
asyncMode 1
bulkInsert 1
devStateIcon connected:it_network .*disconnect:control_home .*done:general_ok running:refresh
disable 0
excludeDevs .*
group Hardware
icon system_backup
room Logging
verbose 2
und mein Reportdevice:
Internals:
DATABASE old-fhem
DEF old_DBLogging
FUUID 5f453a80-f33f-b86d-0a89-4e31a2cc0c686d7a
FVERSION 93_DbRep.pm:v8.40.5-s22492/2020-07-29
LASTCMD countEntries history
MODEL Client
NAME old_DBReport
NOTIFYDEV global,old_DBReport
NR 18
NTFY_ORDER 50-old_DBReport
ROLE Client
STATE done
TYPE DbRep
UTF8 1
HELPER:
DBLOGDEVICE old_DBLogging
GRANTS UPDATE,INSERT,DELETE,USAGE,SELECT
IDRETRIES 2
MINTS 1970-01-01 01:00:00
PACKAGE main
SQLHIST
VERSION 8.40.5
DBREPCOL:
COLSET 1
DEVICE 64
EVENT 512
READING 64
TYPE 64
UNIT 32
VALUE 128
OLDREADINGS:
READINGS:
2020-08-25 20:41:08 __COUNT_history__no_aggregation -
2020-08-25 20:41:08 state done
Attributes:
DbLogExclude .*
allowDeletion 1
devStateIcon connected:it_network .*disconnect:control_home .*done:general_ok running:refresh
dumpDirLocal /opt/fhem/backup
dumpDirRemote /opt/fhem/backup
dumpFilesKeep 3
fastStart 1
group Hardware
icon system_backup
room Logging
useAdminCredentials 1
verbose 2
Danke für die Hilfe
Gruß Reinhard
Hallo Reinhard,
ja, ist ein Rechteproblem.
ZitatLogge ich mich über SSH, mit User "Reinhard" und entsprechendem Kennwort direkt in MySQL ein, so sehe ich alle Datenbanken und alle Tabellen.
Das "sehen" ist nicht der Punkt sondern das Recht "INDEX" und "ALTER" welches deinem Reinhard-User fehlt.
ZitatAuch ein set <reportdevice> adminCredentials <Benutzer> <Kennwort> mit <reportdevice> useAdminCredentials 1
löst das Problem nicht.
Hat denn der verwendete Admin-User diese Rechte bzw. umfassende Rechte auf deine Datenbanken ? Deswegen "Admin" User.
Du könntest deinem Reinhard-User diese Rechte auch über ein Tool (z.B. phpMyAdmin) zuweisen, aber die Verwendung eines entsprechenden Admin-Users soll es dem User einfacher machen.
ZitatEin set sqlCmd show grants; ergibt folgende Rechte:
Diese Kommando zeigt dir die Rechte des aktuellen Users den du im DbLog, und demzufolge auch DbRep, für die Datenbankaktionen verwendest.
Dein list zeigt dir auch die aktuellen Rechte unter HELPER:
GRANTS UPDATE,INSERT,DELETE,USAGE,SELECT
Also überprüfe nochmal den eingegebenen Admin-User. Typischerweise kann der Datenbank "root" alles, oder du kopierst die deinen Reinhard-User und gibst diesem dann umfassende Rechte für solche Admin-Tätigkeiten. Vllt. die bessere Variante.
Grüße,
Heiko
Hallo Heiko,
da muss ich gestern einen Blackout gehabt haben, ich habe immer unter"adminCredentials" den gleichen User eingegeben, mit welchem ich von Fhem an der Datenbank angemeldet bin und da fehlen natürlich die notwendigen Rechte.
Irgendwie habe ich da aber noch einen Knoten im Hirn, denn ich kann mich mit keinem anderen User als "Reinhard" unter dem Linux Benutzer "Pi" anmelden.
Nur mit "sudo mysql -u root -p" kann ich mich unter Linux mit root-Rechten als Benutzer "root" anmelden, hier hätte ich auch alle erforderlichen Rechte, aber in DbRep kann ich ja unter "adminCredentials" nicht sudo vor den Usernamen anhängen.
MariaDB [(none)]> show grants;
+--------------------------------------------------------------------------------------------------------------------------------------------------+
| Grants for root@localhost |
+--------------------------------------------------------------------------------------------------------------------------------------------------+
| GRANT ALL PRIVILEGES ON *.* TO `root`@`localhost` IDENTIFIED VIA unix_socket USING '*C4134700251DF3588D1ACBDC12440A8A01FB97C0' WITH GRANT OPTION |
| GRANT PROXY ON ''@'%' TO 'root'@'localhost' WITH GRANT OPTION |
+--------------------------------------------------------------------------------------------------------------------------------------------------+
Da ich die MySQL Datenbank auf einem "nackten" Raspi3 neu aufsetze, kann ich diese jederzeit wieder löschen und mit der Installation wieder von vorne beginnen.
Mein Ziel wäre es, neben dem Benutzer "Reinhard" noch einen Benutzer "admin" oder "root" mit allen erforderlichen Rechten anzulegen, welchen ich unter DbRep mit "adminCredentials", für Datenbankoperationen verwenden kann.
Ich denke mein Fehler liegt schon bei den Linux Rechten, ich hänge hier mal meine Aufzeichnungen an, nach welchen ich die SQL Datenbank bei mir installiere, eventuell kannst du ja mein Problem erkennen. Die komplette SQL-Installation habe ich als Linux User "root" ("su") durchgeführt.
Da diese als CodeTags sehr schwer zu lesen sind, ausnahmsweise als PDF-Datei.
Edit:
Sorry für den Alarm, nach einem "rereadcfg" funktioniert alles (bisher) bestens.
Leider bestehen noch Probleme.
Lege ich einen weiteren User an und erteile diesen alle Rechte, so klappt mit "adminCredentials" damit die Wartung der Datenbank. Ein Restore wird aber wieder mit Rechteproblemen abgelehnt ( mit oder ohne "adminCredentials")
DBD::mysql::st execute failed: Access denied for user 'Reinhard'@'%' (using password: YES) at ./FHEM/93_DbRep.pm line 8242.
Gruß Reinhard
Hallo Reinhard,
die Verwendung des privilegierten Nutzers habe ich bis jetzt nur für einige spezifische Befehle implementiert, wie zum Beispiel die Index-Wartung. Deswegen wirkt dieser User nicht bei einem Restore.
Für ein Restore will ich es auch nicht aufbohren, damit man nicht ungwollt eine DB überschreibt die es hätte nicht sein sollen.
(Security Feature)
Das bedeuted das Restore wird mit dem User ausgeführt, den du in der DbLog.conf angegeben hast, d.h. den Standdarduser "Reinhard".
Was zeigt denn ein
set dbrep sqlCmd show grants
?
Hallo Heiko,
show grants; ergibt bei mir:
GRANTS FOR REINHARD@%
GRANT USAGE ON *.* TO `Reinhard`@`%` IDENTIFIED BY PASSWORD '*C4142900421DF3586A1CCBDC16740A8C01FC37A2'
GRANT SELECT, INSERT, UPDATE, DELETE ON `fhem`.* TO `Reinhard`@`%`
Benötige ich für Restore noch das Recht "File"?
Ich könnte ja zukünftig dieses Recht bei der Neuanlage des Users gleich mit vergeben.
Gruß Reinhard
ZitatBenötige ich für Restore noch das Recht "File"?
Eigentlich nur für das Backup dachte ich, aber setz das mal. Es schadet ja nicht.
Hallo Heiko,
ich denke jetzt haben wir (vorerst) den Knoten durch :)
Das Recht "FILE" hat noch gefehlt, damit ein serverseitiges Backup File über "restoreMySQL" mit DbRep wieder eingelesen werden konnte.
Ich habe das Recht mit:
GRANT File ON *.* TO 'fhemuser'@'%';
einfach auf der Konsole, noch unter "sudo mysql -u root -p" nachgepflegt. Jetzt meckert DbRep nicht mehr. Wenn ich richtig gelesen habe, muss ich das File Privileg für alle Datenbanken erteilen und kann dieses nicht nur auf Fhem beschränken.
Bitte verifizier das noch, ob das Rechteproblem nur bei mir bestand, ich habe meine MySQL Datenbank angelegt, wie im PDF-Anhang im Betrag https://forum.fhem.de/index.php/topic,113821.msg1081037.html#msg1081037 (https://forum.fhem.de/index.php/topic,113821.msg1081037.html#msg1081037) beschrieben.
Sollte das generell notwendig sein, so wäre ein Hinweis im WIKI, unter Restore nicht verkehrt.
Es gibt ja nicht nur Linux Profis und das stolpert sicher noch ein User drüber.
Vielen Dank für deine Hilfe, Reinhard
Hallo Reinhard,
sehr gut. Eine wichtige Erkenntnis die ich ins DbRep Wiki und auch in die commandRef aufnehme.
Das FILE Recht ist üblicherweise nicht gleich einem User zugewiesen. Und es ist global gültig, hast du richtig beobachtet.
Danke für die Info und LG,
Heiko