Umstieg auf Firebird 3.0

[waldforest]

Hallo Zusammen,

ich bin aktuelle auf der Suche nach einer Anleitung "Umstieg" von Firebird 2.5 auf 3.0.

In Firebird 3.0 wurde ja das security geändert, so dass ein zugriff über sysdba und masterkey nicht mehr funktioniert.

Aber leider komme ich über die im Netz beschriebene Art und Weise im Serverbetrieb nicht auf die Datenbank.

Zeos habe ich bereits auf die neue Version umgestellt und auch auf das firebird3-Protokoll umgestellt.
im Embedded (ohne Kennwort) funktioniert der Zugriff.

Mit der Beschreibung unter ReleasNotes "Upgrading a v.2.x Security Database" komme ich nicht weiter.

Anliegende Vorgehensweise (aus dem Netz) funktioniert auch nicht.




Stop the Firebird server.

2. In a suitable shell, start an isql interactive session, opening the employee database via its alias:
> isql -user sysdba employee
3. Create the SYSDBA user:
SQL> create user SYSDBA password 'SomethingCryptic';
SQL> commit;
SQL> quit;

einen User angelegt, bzw. ein Kennwort vergeben. Ich erhalte (auch wenn ich isql im Adminmodus starte) den Hinweis, keine Berechtigung habe einen user anzulegen. Gleiche Problematik mit gsec.

Was muss ich anders machen, damit es funktioniert meine Datenbank auf Firebird 3 umzustellen.

[madas]

Eventuell mal hier auf Seite 115 nachschauen.

madas

[waldforest]

Hallo,
diese Empfehlungen bin ich schon durch, leider bisher ohne Erfolg.
Immer wieder loginprobleme, also Themen mit dem User und Password.

Ich habe noch einmal alles gelöscht, deinstalliert. Nach Neuinstallation und Restore der Datenbank gings. Irgendwie habe ich (einen für mich nicht nachvollziebaren) Fehler beim Installieren gemacht.

[madas]

Zitat von waldforest:

Ich habe noch einmal alles gelöscht, deinstalliert. Nach Neuinstallation und Restore der Datenbank gings. Irgendwie habe ich (einen für mich nicht nachvollziebaren) Fehler beim Installieren gemacht.

Hm, und bei der zweiten Installation eigentlich wieder alles so gemacht, wie bei der ersten? Schon komisch.

[tsteinmaurer]

Bzgl. Authentifizierung wurde in Firebird 3 die neue "SRP" (Secure Remote Procedure) Methode eingeführt, die auch der Default ist. D.h. sofern du nichts anderes in firebird.conf einstellst, ist diese Art von Authentifizierung aktiv. Hier ist schon mal wichtig zu wissen, dass aus Client-Sicht (z.b. isql oder auch deiner Anwendung) ein Login nur mit der fbclient.dll aus Firebird 3 möglich ist. Mit der Firebird 2.5 Client Library wird das nicht funktionieren. Dazu müßte man auf der Serverseite in firebird.conf den Legacy Modus bzgl. Authentifizierung aktivieren, mit den bekannten Limitierungen wie z.b. nur die ersten 8 Buchstaben des Passworts werden evaluiert etc. Firebird 3 Server vs. 2.5 Clientbibliothek war vielleicht schon mal ein Stolperstein bzw. Unterschied bei deinen Versuchen ...

Die zweite Sache ist, das bei der ZIP Distribution kein SYSDBA User ausgeliefert wird, sondern die Security-DB leer ist. Somit klappt ein Login mit der Servervariante (d.h. nicht Embedded) nicht. Es muss ein SYSDBA User angelegt werden. Darum auch die Vorgehensweise in den Release Notes auf Seite 115. Wichtig hier ist, dass KEIN anderer Firebird Serverprozess, egal welcher Version, bei dieser Initialisierung läuft. Somit ist sichergestellt, dass der Connect mit isql über Firebird 3 Embedded erfolgt. Dies wiederum stellt sicher, dass der SYSDBA User mit der SRP Methode angelegt wird. Das Ganze ist vielleicht Stolperstein 2.

Dann gibt es noch eine dritte Sache: Praktisch kann für jede Datenbank eine eigene Security-Datenbank verwendet werden, obwohl das nicht der Default ist. D.h. initial gibt es wiederum eine (wie in vorangegangenen Versionen) serverweite Security-DB security3.fdb, aber in databases.conf (die wiederum die aliases.conf ablöst) kann je DB-Alias eine eigene Security-DB angegeben werden. Muss aber nicht. Somit kann man z.b. eine eigene Security-DB auslieferen, wo sich dann der SYSDBA Account nicht mit anderen Installation am selben Server in die Quere kommen. Ein Anwendungsfall hierfür wäre ein Firebird Shared Web-Hosting auf einem Server. Soll jetzt aber nicht heißen, dass man SYSDBA als Owner der DB und Tabellen verwenden sollte ...

Das ganze schnell hingeschrieben. Ich hoffe das hilft dir weiter bzw. gibt dir einen Anhaltspunkt warum es einmal nicht und einmal schon funktoniert hat.

LG
Thomas