Ich habe ein KeyCloak 17.0.1, das anscheinend ohne Probleme auf meinem Server funktioniert und für die Verwendung von MariaDB konfiguriert ist. Ich sage „anscheinend“, weil es heute noch nicht in Produktion ist, obwohl es im Produktionsmodus startet, aber es befindet sich auf einem Entwicklungsserver und ist eigentlich nur da, damit wir Entwickler damit spielen können. Ich starte es mit diesem Befehl:
bin/kc.sh -v start --hostname=my.real.hostname --https-certificate-file=/etc/letsencrypt/live/my.real.hostname/cert.pem --https-certificate-key-file=/etc/letsencrypt/live/my.real.hostname/privkey.pem --db-url-host localhost --db-username root --db-password my-real-password --proxy=reencrypt --db-schema=KEYCLOAK
Es läuft auf einem Debian 11-System mit einem Debian-gepackten MariaDB-Server. Damit es läuft, musste ich MariaDB-Daten auf ein Groß-/Kleinschreibung-unabhängiges ext4-Dateisystem verschieben und MariaDB so konfigurieren, dass Groß-/Kleinschreibung in Tabellennamen ignoriert wird (siehemein Beitrag hier). Davor gab es eine Schema "KEYCLOAK" not foundFehlermeldung.
Jetzt versuche ich, KC 17.0.1 auf KC 18 zu aktualisieren, nachdieser Leitfaden, aber wenn ich KC 18 starte, bekomme ichdiese Fehlermeldung(Zusamenfassend Schema "KEYCLOAK" not found).
Da KC 17.0.1 dieselbe Fehlermeldung ausgab und das Problem durch das Verschieben von MariaDB auf ein ext4-Dateisystem mit Groß- und Kleinschreibung gelöst wurde, wollte ich sicherstellen, dass MariaDB die Groß- und Kleinschreibung weiterhin ignoriert. Also versuchte ich, dieselbe SQL-Anweisung, die die KC-Fehlermeldung verursachte, manuell über die MariaDB-Konsole auszuführen:
MariaDB [(none)]> CREATE TABLE KEYCLOAK.DATABASECHANGELOGLOCK (ID INT NOT NULL, LOCKED BOOLEAN NOT NULL, LOCKGRANTED TIMESTAMP, LOCKEDBY VARCHAR(255), CONSTRAINT PK_DATABASECHANGELOGLOCK PRIMARY KEY (ID));
die mit einer anderen Fehlermeldung antwortete als die, die KC in den Protokollen meldet:
ERROR 1050 (42S01): Table 'databasechangeloglock' already exists
also versucht KC 18 während des Upgrade-Prozesses, eine Tabelle zu erstellen, die bereits existiert. Vielleicht denkt es, dass sie nicht existiert, weil es das KEYCLOAKSchema aus irgendeinem Grund nicht finden kann, und versucht, es zu erstellen, aber andererseits, woher hat KC 18 verstanden, dass es die Datenbank aktualisieren musste, wenn es sie nicht finden konnte? Ich suche nicht wirklich nach einer Antwort darauf: Ich wäre mit einer einfachen Problemumgehung zufrieden.
Um sicherzustellen, dass MariaDB sowohl Schemata als auch Tabellennamen tatsächlich in Groß- und Kleinschreibung umwandelt, habe ich Folgendes versucht:
# mysqladmin -u root -p variables | grep lower_case_table_names
| lower_case_table_names | 2
# mysql
MariaDB [(none)]> create database TESTDB;
Query OK, 1 row affected (0.000 sec)
MariaDB [(none)]> drop database testdb;
Query OK, 0 rows affected (0.001 sec)
MariaDB [(none)]> drop database nonexistingschemaname;
ERROR 1008 (HY000): Can't drop database 'nonexistingschemaname'; database doesn't exist
MariaDB [(none)]> create database TESTDB;
Query OK, 1 row affected (0.000 sec)
MariaDB [(none)]> use testdb;
Database changed
MariaDB scheint also korrekt zu funktionieren (zumindest aus Sicht von Casefold), aber KC 18 stürzt beim Start immer noch ab, während KC 17 funktioniert. Irgendwelche Hinweise?