SQL Strict Mode ändern [SOLVED]

[Krisi]

Ich habe ein Shopsystem das ich seit 10 Jahren pflege.
Updates mussten immer recht aufwändig im Dateisystem gemerged werden.
Immer wieder kam es zu Reibereien mit dem SQL Strict Mode.
Beim aktuellen Update geht nicht mehr viel wegen vermutlich der Strict Einstellung.
Ist die folgende Anleitung ratsam oder gibt es besser Lösungen?
-> https://manuals.gfi.com/en/helpdesk/adm ... server.htm

Eine per User Konfiguration wäre für mich perfekt.
Eine ~/.my.cnf finde ich im User Homeverzeichnis nicht.
Müsste ich vermutlich anlegen, kann ich als User aber wegen fehlender Schreibrechte nicht.
Was würdet ihr mir raten?

[OlliTheDarkness]

Was würdet ihr mir raten?

Nutze ein aktuelles ShopSystem

Hast nach einem Rat gefragt.

[24unix]

Abgesehn davon, dass man gerade bei einem Shop, wo Kundendaten und Zahlungsinformationen im Spiel sind keine veraltete Software nutzen sollte.

Eine ~/.my.cnf finde ich im User Homeverzeichnis nicht.
Müsste ich vermutlich anlegen, kann ich als User aber wegen fehlender Schreibrechte nicht.
Was würdet ihr mir raten?

Code: Select all

vi .my.cnf

Erst "i" drücken, dann Text reinpasten, dann ESC drücken und mit ":x" beenden, fertig.

[Krisi]

Als User?

PS: ich habe im Startbeitrag mal "alt" entfernt. Bei ausgeprägter selektiver Wahrnehmung könnte es den Eindruck erwecken, dass das Shopsystem im vorhandenen Zustand veraltet wäre.

[24unix]

Als User?

Ja, der User in dessem Kontext die Webseite ausgeliefert wird.

PS: ich habe im Startbeitrag mal "alt" entfernt. Bei ausgeprägter selektiver Wahrnehmung könnte es den Eindruck erwecken, dass das Shopsystem im vorhandenen Zustand veraltet wäre.

Eine Software, die solcher Klimmzüge bedarf würde ich aber auch nicht als modern bezeichnen

[Krisi]

Das Verzeichnis gehört doch root?!
Wenn es mit vi gehen soll, dann doch auch mit nano.

Hier der Fehler bei vi:

Code: Select all

".my.cnf" E212: Can't open file for writing

[24unix]

Das Verzeichnis gehört doch root?!

Kann sein, dass das ursprünglich mal so war.
Aber da das nicht praxistauglich ist, habe ich das dann wohl geändert.
Sonst kann man ja auch seine dotfiles nicht einspielen, kein Oh-My-Zsh und was man sonst noch alles braucht.
Dann dürften nicht mal ssh keys und pgp Config gehen.

Dann halt ein "sudo chown <username>:<username> <homedir>"

Wenn Du da "Sicherheitsbedenken" hast, legst Du halt die eine Date als root an und macht dann auf die .my.cnf ein chown.

Wenn es mit vi gehen soll, dann doch auch mit nano.

Hier der Fehler bei vi:

Code: Select all

".my.cnf" E212: Can't open file for writing

Wenn man sich den nano antun will, mit installiert wird er ja eh

[Florian]

Hallo,


Wen du den deaktivieren willst dann öffne eine der Konfigdatein unter /etc/mysql/mariadb.conf.d/, z.B die 90-tuning.cnf und füge die Zeile hinzu:

Code: Select all

sql_mode=""

Datenbankserver neustarten.

Eine .my.cnf im Userverzeichnis würde auch nichts bringen, weil der Keyhelp User ja nicht im MySQL als User existiert.

[24unix]

Eine .my.cnf im Userverzeichnis würde auch nichts bringen, weil der Keyhelp User ja nicht im MySQL als User existiert.

Muss er ja auch gar nicht.

Die ~/.my.cnf gilt für den User. Und in dessen Kontext läuft auch der FPM-Service.

(ssh) tracer@keyhelp : ~
[0] % mysql
ERROR 1045 (28000): Access denied for user 'tracer'@'localhost' (using password: NO)

(ssh) tracer@keyhelp : ~
[1] % vi .my.cnf

(ssh) tracer@keyhelp : ~
[0] % mysql
ERROR 1045 (28000): Access denied for user 'blubb'@'localhost' (using password: NO)

Und in der .my.cnf kann ich dann angeben was ich will, z.B. den user mit dem man sich bei der DB anmeldet.

Code: Select all

(ssh) tracer@keyhelp : ~
[1] % cat .my.cnf
[client]
user=blubb

Edit: Am einfachsten wäre es aber, der Shop setzt nach dem Verbindungsaufbau 'sql_mode=""' ab.

[Florian]

Hi,

das ist mir bewusst, aber geht man nach dem bisherigen Verlauf konnte man davon ausgehen, dass wenn nur die sql_mode Anweisung in die .my.cnf geschrieben wird, was nichts bringt. Darauf bezog sich meine Aussage.

Ich habe jetzt auch noch weiter recherchiert, aber ich bezweifle, dass man den sql_mode als User so einfach überschreiben kann.

[24unix]

Ich habe jetzt auch noch weiter recherchiert, aber ich bezweifle, dass man den sql_mode als User so einfach überschreiben kann.

Session Scope.


"Each client can change its session sql_mode value at any time."

https://dev.mysql.com/doc/refman/5.7/en/sql-mode.html

[Krisi]

Ich werde beide Methoden ausprobieren.
Zuerst auf User Ebene, ansonsten global.

Gibt es eine Möglichkeit, zu prüfen ob die Einstellung greift?

[Tobi]

Wenn dein Shop funktioniert, funktioniert es, wenn nicht dann nicht?!?

Falls du uns verraten magst welche Shopsoftware du einsetzt könnte man dir noch gezielter helfen.
Mir persönlich ist keine aktuelle Software bekannt welche noch Probleme mit dem Strict-Mode hätte.

[Krisi]

Ich habe im Shopsystem eine Server Info, die mir den Strict mode anzeigt.
Ich kann den Server nicht so oft zum Testen neu starten, deswegen habe ich es global eingesetzt.
Der Strict mode war dann deaktiviert, der Fehler im Shop aber weiterhin vorhanden.
Also wieder auskommentiert und ein weiteres mal neugestartet.

Die eigentliche Frage ist geklärt.
Ob es über den User geht noch nicht. Das müsste ich auf einem anderen Server machen.

[Tobi]

Du brauchst doch nicht gleich den ganzen Server neu starten.
Es reicht MariaDB neu zu starten.
Das darf / sollte nicht länger als ein, zwei Sekunden dauern.

Und was ist nun mit der Software?
Magst du uns verraten welche Software du einsetzt oder nicht?

Nachtrag:
========

der Fehler im Shop aber weiterhin vorhanden.

Und zwar welcher?