Closed SchulenITK closed 1 month ago
Das Schema ist defekt. Den Grund müsste man noch ermitteln. Können Sie auf den AdminClient mit https://meinserver/admin zugreifen? Wenn ja kann man das Schema einmal löschen und neu anlegen.
Welche Version liegt hier vor?
Das Schema wurde uns als leere Hülle vom "root" bereitgestellt. Eine Tabellenstruktur ist also noch nicht vorhanden.
Der Zugriff über den AdminClient besteht, das war mit "Admin-Konsole" gemeint und dort kommt auch der Fehler beim Migrationsversuch. Ich selbst kann mit "meinem SQL-User" kein neues Schema erstellen, auf dem vorhandenen Schema besteht aber Vollzugriff.
Die Version des svws-servers ist 0.9.2.
Beim Starten des SVWS-Server prüft dieser die von ihm verwalteten Schemata. Wenn dabei ein Fehler auftritt wird das Schema gesperrt, was zu dieser Meldung führen kann. Alternativ kann die Meldung aber auch bei Fehlern im Betrieb auftreten oder wenn man mehrere Schema-Operationen gleichzeitig auf das gleiche Schem versucht. Für die Fehleranalyse wäre als erstes ein Blick auf die Logs des SVWS-Servers bei Starten hilfreich. Kommt es da zu Fehlermeldungen?
In der Admin-Konsole -> das Schema ausgewählt -> Schild2-Schema migrieren -> Access (MDB), Datei ausgewählt -> Migrieren.
Welchen API Endpunkt nutzt diese Funktion? @ThomasBachran Könnte es sein, dass die den Priv. Endpunkt nutzt.
Beim Starten des SVWS-Server prüft dieser die von ihm verwalteten Schemata. Wenn dabei ein Fehler auftritt wird das Schema gesperrt, was zu dieser Meldung führen kann. Alternativ kann die Meldung aber auch bei Fehlern im Betrieb auftreten oder wenn man mehrere Schema-Operationen gleichzeitig auf das gleiche Schem versucht. Für die Fehleranalyse wäre als erstes ein Blick auf die Logs des SVWS-Servers bei Starten hilfreich. Kommt es da zu Fehlermeldungen?
Oben zu sehen ist der Log des docker-containers - nur je am Anfang der Zeile gekürzt um den Zeitstempel etc. für bessere Lesbarkeit. Das ist das einzig auffällige dort. Reicht das oder welche logs noch -> wo sind diese im container abgelegt?
Würde es helfen, wenn die Tabellenstrukur zuerst angelegt ist -> gibt es dafür ein Initialisierungs-Skript (ohne direkt eine MDB zu importieren)?
Würde es helfen, wenn die Tabellenstrukur zuerst angelegt ist -> gibt es dafür ein Initialisierungs-Skript (ohne direkt eine MDB zu importieren)?
Ja, das Schema über den SVWS Admin erstellen lassen. Der legt dann den Benutzer und das komplette Schema an.
Schauen Sie mal unter https://[svws-server]/debug Da sehen die API- Endpunkte, die verwendet werden können.
Nur für mein Verständnis: Andere MDBs haben funktioniert? Ist die der Datenbank-Schemata eine Liste mit leeren Schemata, die für Sie angelegt wurden? Man sieht das nicht so gut im Screenshot. Wenn man dort ein leeres Schema hat, müsste ein Menüpunkt "Initialisieren" dort stehen.
Würde es helfen, wenn die Tabellenstrukur zuerst angelegt ist -> gibt es dafür ein Initialisierungs-Skript (ohne direkt eine MDB zu importieren)?
Ja, das Schema über den SVWS Admin erstellen lassen. Der legt dann den Benutzer und das komplette Schema an.
Schauen Sie mal unter https://[svws-server]/debug Da sehen die API- Endpunkte, die verwendet werden können.
Die Datenbänkler haben bei uns nichts mit SchILD zu tun, die Verfahrensbetreuung kann ich denen nicht zumuten. Auch wenn es einfacher wäre ist leider nicht vorgesehen, dass wir eigene Schemata bei uns erstellen. Ob das CREATE DATABASE Recht für uns temporär freigeschaltet wird, müsste ich beantragen. Das sollte aber der letzte Ausweg sein.
Nur für mein Verständnis: Andere MDBs haben funktioniert? Ist die der Datenbank-Schemata eine Liste mit leeren Schemata, die für Sie angelegt wurden? Man sieht das nicht so gut im Screenshot. Wenn man dort ein leeres Schema hat, müsste ein Menüpunkt "Initialisieren" dort stehen.
Nein, bisher funktioniert damit noch nichts, die lokalen Tests waren ohne Docker.
Korrekt, das sind alles Schemata, welche leer für uns angelegt wurden und unser SQL-User drauf berechtigt ist. Allerdings steht in der .env-Datei des gestarteten containers bislang nur diese 1 Schule. Ich vermute, dass eine eingebundene svwsconfig.json an der richtigen Stelle später genutzt werden kann um mehrere Schulen auf einem container zu haben(?) - aber soweit sind wir ja noch nicht.
Oben im Screenshot ist das Schema angewählt und rechts steht "Initialisieren/Wiederherstellen", oder was meinen Sie? Der Menüpunkt "Schulkatalog -> initialisieren" fehlt hier aber.
Welche Rechte hat denn der DB User auf der Datenbank?
Welche Rechte hat denn der DB User auf der Datenbank?
Via wildcard:
GRANT ALL PRIVILEGES ON `schild_%`.* TO `schild_XY`@`%`
GRANT SHOW DATABASES ON *.* TO `schild_XY`@`%`
Ich versuche das gleich mal nachzustellen.
In der Admin-Konsole -> das Schema ausgewählt -> Schild2-Schema migrieren -> Access (MDB), Datei ausgewählt -> Migrieren.
Welchen API Endpunkt nutzt diese Funktion? @ThomasBachran Könnte es sein, dass die den Priv. Endpunkt nutzt.
An dieser Stelle wir die Privileged API genutzt. Die Methode heißt migrateMDBInto
bzw. "/api/schema/migrate/{schema}/mdb"
.
aber ohne /root
, das meinte ich.
So ich bekomme den Fehler auch, wenn ich versuche eine MDB zu importieren. Eine Funktion "Initialisieren" gibt es nicht.
Wenn ich versuche über /api/schema/create/{schema}
das Schema aufbauen zu lassen erhalte ich ebenso den Stinkefinger:
can't parse JSON. Raw result:
Datenbank-Schema ist zur Zeit deaktviert, da es fehlerhaft ist. Bitte wenden Sie sich an Ihren System-Administrator.
(btw: Bitte die Fehlermeldungen auch in JSON verpacken, wenn man dem Brower schon JSON ankündigt)
Und da ist es jetzt auch egal, welche Operation ich auf dem Schema ausführen will. Also wie hier: https://github.com/SVWS-NRW/SVWS-Server/issues/50
So, zweiter Versuch, mit dem Hinweis https://github.com/SVWS-NRW/SVWS-Server/issues/50#issuecomment-1902074154
Ich vermute @SchulenITK hat die DB vor dem Start des Servers in die Konfig eingetragen. Da habe ich sie jetzt rausgenommen und bekomme im Admin die Option "In Konfiguration aufnehmen".
Das führt dann zu folgende Meldung:
{
"env": {
"mode": "stable",
"version": "0.9.2",
"Commit": "8199ccef06ee70294318a2a89069b4e37ab5c6a1"
},
"error": {
"id": 1,
"name": "API-Fehler: Dieser Fehler wird durch eine fehlerhafte Kommunikation mit dem Server verursacht. In der Regel bedeutet das, dass die verschickten Daten nicht den Vorgaben entsprechen.",
"message": "Fetch failed for POST: /api/schema/root/import/existing/svws-demo - Status: 401",
"stack": [
"Kt@https://svws:8443/admin/assets/index.js:22:23636",
"postTextBased@https://svws:8443/admin/assets/index.js:22:26296",
""
],
"log": null
}
}
Ich werde das morgen versuchen nachzustellen. Danach melden wir uns hier...
Danke für die Zusammenstellung der Informationen, damit kann ich etwas anfangen!
Ich habe ein ähnliches Szenario erstellen können und habe einen Fehler behoben, der dies verursachen könnte. In diesem Zusammenhang daher bitte auf das nächste Pre-Release 0.9.3 warten.
Wann soll die denn kommen?
@kroerig ist da
Am besten direkt mit der Version 0.9.4 testen. Die ist seit gestern vorhanden und bereinigt kleinere Fehler.
Vorweg: Wir haben zwischenzeitlich noch festgestellt, dass die collation utf8mb4_bin sein muss, es war bei uns ein anderes UTF8... hier sollte es am besten eine Fehlermeldung geben, wenn die DB bzw. der Serverstandard abweicht. Dadurch sind kuriose Fehler aufgetreten.
Vorgehen: Leeres MariaDB-Schema -> im svws-server log steht wieder, dass das Schema deaktiviert ist -> SVWS-Client/admin "Schema anlegen" bis Revision 26 -> die Revision auf 27 schlägt fehl:
svws-server-test-svws-server-1 | 2024-10-14T09:15:55.761 INFO - Setze die DB-Revision auf 26
svws-server-test-svws-server-1 | 2024-10-14T09:15:55.823 INFO * Aktualisiere auf Revision 27
svws-server-test-svws-server-1 | 2024-10-14T09:15:55.864 INFO - Verwerfe: 1 Trigger...
svws-server-test-svws-server-1 | 2024-10-14T09:15:55.873 INFO t_UPDATE_DavSyncTokenLehrer_Kurse
svws-server-test-svws-server-1 | 2024-10-14T09:15:55.884 INFO - Verwerfe: 0 Indizes
svws-server-test-svws-server-1 | 2024-10-14T09:15:55.918 INFO - Verwerfe: 0 Unique-Constraints
svws-server-test-svws-server-1 | 2024-10-14T09:15:55.971 INFO - Verwerfe: 0 Fremdschlüssel
svws-server-test-svws-server-1 | 2024-10-14T09:15:55.981 INFO - Erstelle: 0 Tabellen
svws-server-test-svws-server-1 | 2024-10-14T09:15:56.042 INFO - Hinzufügen: 0 Spalten
svws-server-test-svws-server-1 | 2024-10-14T09:15:56.100 INFO - Ausführen: 0 Befehle
svws-server-test-svws-server-1 | 2024-10-14T09:15:56.145 INFO Konnte die Schulform der Schule nicht bestimmen.
svws-server-test-svws-server-1 | 2024-10-14T09:15:56.276 INFO Fehler: Schema kann nicht aktualisiert werden. Das Schema wird deaktiviert.
Das Schema ist also weiter deaktiviert.
Starten wir eine Migration (aus MSSSQL), läuft diese durch und hebt die Revision auf 28.
Direkt in ein leeres Schema zu migrieren läuft auch durch inkl. Revision 28.
Da die Migration ansonsten durchläuft ist das Problem aus meiner Sicht damit erledigt, vielen Dank.
Als nächstes werden wir probieren eine Konfiguration mit einem container und mehrere Schulen zu erstellen. Falls es dazu bereits Tips oder eine Anleitung gibt, gerne her damit :)
Danke, die Vorschläge haben wir aufgenommen. Den Fehler mit der Schulform können wir reproduziefren, Bugfix kommt....
Als nächstes werden wir probieren eine Konfiguration mit einem container und mehrere Schulen zu erstellen. Falls es dazu bereits Tips oder eine Anleitung gibt, gerne her damit :)
Einfach die Datenbanken über den Admin oder die API migrieren. Was noch nicht geht ist die Schulen einer SVWS Instanz auf mehrer DB-Server zu verteilen https://github.com/SVWS-NRW/SVWS-Server/issues/124
Da hilft dann nur ein DB-Cluster. Daher wäre mein Vorschlag aktuell zu schauen, welche Schulen vermutlich die meiste Last erzeugen könnten und die mit kleineren zu kombinieren.
Da wir hier aber ja in der Dockerwelt unterwegs sind, will man ja eigentlich pro Schule eine SVWS Instanz.
Vielen Dank, dann werden wir das mal probieren und die Datei nach /opt/app/svws/svwsconfig.json einbinden.
Einen eigenen container pro Schule macht in unserem Testumfeld keinen Sinn, die würden ja die meiste Zeit nichts tun. Da wir - wie Hr. Hagel in Köln - momentan pro container abgerechnet werden, wären das unnötige Kosten. Mit den DBs wäre das bei uns genau so ein Drama geworden, aber wir konnten intern eine vertretbare Lösung ausfechten.
Ob wir produktiv einen container pro Schule einsetzten, müssen wir noch ausdiskutieren bzw. wird das die Praxis zeigen.
Durch https://github.com/SVWS-NRW/SVWS-Server/pull/157 erkennt der Container, dass bereits eine Konfig vorhanden ist und erstellt sie auch nicht bei jedem Start neu.
Hallo,
der Docker-Container startet mit folgenden Einträgen, die korrekt sind, denn es ist nur ein leeres Schema vorhanden (auf welches wir Vollzugriff haben, aber keinen root):
In der Admin-Konsole -> das Schema ausgewählt -> Schild2-Schema migrieren -> Access (MDB), Datei ausgewählt -> Migrieren.
Es kommt der Fehler: "Fehler beim Aufruf der API-Methode Service Unavailable (503)".
http response:
Haben wir hier noch einen Konfigurationsfehler?