Verständnis-Frage zur security3.fdb

Forum für Fragen rund um die Installation, Konfiguration und Inbetriebnahme von Firebird.

Moderator: martin.koeditz

Hamburgo
Beiträge: 120
Registriert: Di 28. Mai 2019, 17:28

Hallo zusammen,

zur Zeit beschäftige ich mich mal wieder mit meinem Projekt
"Migrieren von FB 2.5 auf FB 3.0" und dazu habe ich mal eine
Verständnis-Frage zur "security3.fdb".

in 2019 hatte ich schon einmal FB 3.04 auf meinem Extra-Server
für die Migration installiert.

Heute kam mir die Idee "mal eben kurz FB 3.0.10" installieren zu
wollen, um gleich auf der neuesten FB 3.0 Version zu sein.

Die ersten Verbindungs-Versuche scheiterten natürlich, weil ich
vergessen hatte den User "SYSDBA" einzutragen.

Dann wollte ich besonders schlau sein und habe einfach die
security3.fdb von der FB 3.0.4 in den Ordner der FB 3.0.10 kopiert,
in der wohl naiven Annahme, dass die kompatibel sind.

Da habe ich mich wohl getäuscht.

Bedeutet das etwa, dass ich bei jedem Versions-Wechsel innerhalb
von einer Versions-Serie z.B. FB 3.0.x jedes mal für ALLE FDB's einzeln
wieder den "SYSDBA" und alle weiteren User manuell registrieren muss ?

Danke und Gruss
vr2
Beiträge: 158
Registriert: Fr 13. Apr 2018, 00:13

Hallo Hamburgo,
Hamburgo hat geschrieben: Sa 19. Nov 2022, 17:03 Bedeutet das etwa, dass ich bei jedem Versions-Wechsel innerhalb von einer Versions-Serie z.B. FB 3.0.x jedes mal für ALLE FDB's einzeln wieder den "SYSDBA" und alle weiteren User manuell registrieren muss ?
Nein. Und Du kannst die security-DB zwischen Unterversionen (zb 3.0.4, 3.0.10) einer Vollversion (3) kopieren. Das hat hier andere Ursachen.

Die security-db wird default für alle DBs verwendet, es sei denn, Du hast in databases.conf bei einer DB eine andere security-db konfiguriert. Den Fall können wir glaube ich ausschließen, das macht man nur mit einem besonderen Grund.

Außerdem spielt eine Rolle, welche security plugins (UserManager) der Server konfiguriert hat. Ich vermute, die sind bei Deiner alten und neuen 3er Version unterschiedlich. Der Eintrag in firebird.conf lautet

Code: Alles auswählen

#UserManager = Srp
UserManager = Legacy_UserManager
und steht werksseitig default auf Srp. Im Beispiel oben ist stattdessen Legacy_UserManager konfiguriert, falls Du alte Clients hast, die mit dem neuen security-Interface noch nicht klarkommen. User, die Du anlegst, werden pro security plugin angelegt, verwaltet und benutzt. Dh, wenn Du im alten 3er einen sysdba über den Legacy_UserManager angelegt hast, Dein neuer 3er aber auf UserManager Srp steht, sieht der den sysdba natürlich nicht und deswegen musstest Du den neu anlegen.

Führ mal als ein User, der sowohl rdb$adamin als auch sec$admin ist (wichtig, beides, das ist nicht dasselbe), also zb sysdba, folgendes Statement auf irgendeiner DB aus:

Code: Alles auswählen

 select s.sec$user_name, iif(s.sec$admin, 'true', 'false') sec$admin, s.sec$plugin, 
 cast(list(distinct trim(p.rdb$relation_name)) as varchar(1000)) roles 
 from sec$users s
 left join rdb$user_privileges p on p.rdb$user = s.sec$user_name and p.rdb$privilege = 'M'
 group by 1, 2, 3
Dann siehst Du, welche User Du in der security.db hast und über welche sec-plugins die registriert wurden.

Schließlich würde ich noch empfehlen, gleich auf Firebird 4 zu gehen. Der 4er hat einige Kompatibilitätschalter, die Dir das Migrieren von 2.5 erleichtern und ist dem 3er noch sehr ähnlich, Du bekommst bei gleichem oder sogar geringerem Migrationsaufwand einige Features dazu, zb vollständig ausgebaute window functions. Udfs kannst Du auch mit einem 4er noch nutzen, wenn Du den so konfigurierst. Und bist dann wirklich auf dem aktuellen Stand der Entwicklung.

Grüße, Volker
Hamburgo
Beiträge: 120
Registriert: Di 28. Mai 2019, 17:28

Hallo Volker,

das durchzulesen verschiebe ich auf Morgen, weil ich jetzt einfach platt bin
und hoffe das Morgen gut zu verstehen.

Aber eines möchte ich heute Abend doch noch los werden.

Vielen herzlichen Dank für diese Hilfen, vor allem von der Ausführlichkeit und
Geduld bin ich immer wieder schwer beeindruckt.

Einen schönen Abend wünsche ich noch.

Gruß
Hamburgo
bfuerchau
Beiträge: 388
Registriert: Mo 7. Mai 2018, 18:09

Bzgl. der 4er-Version ist die Abwärtskompatibilität viellicht mal einen Versuch Wert. Mal sehen, ob das Problem mit vielen Satzversionen oder Abfragen über Millionen Zeilen bei starker Fragmentierung einer Tabelle besser funktionieren.
Unerklärlich sind bei 3.0 die unterschiedlichen Indexaufbauzeiten bei ca. 25 Mio Zeilen zwischen 5 Minuten und 2-3 Stunden.
Hamburgo
Beiträge: 120
Registriert: Di 28. Mai 2019, 17:28

Hallo Volker,

mit Deiner Vermutung liegst genau richtig. Ich habe die firebird.conf
in 2018 in folgenden Zeilen angepasst und dies leider vergessen, dass
ich DAU das auch bei der neuen Version auch zu machen habe.

ServerMode=Classic
AuthServer = Legacy_Auth, WinSspi
AuthClient = Legacy_Auth, Srp, WinSspi #Windows clients
UserManager = Legacy_UserManager
WireCrypt = Disabled

Somit gehe ich davon aus, wenn zusätzlich zur security-DB auch die
firebird.conf verschiebe, dann klappt wohl alles wie gewohnt.

Nun habe ich gelesen im Chapter "Macro substitution", dass man
wohl die security-DB und vieles andere, u.a. auch firebird.conf in
andere Ordner verschieben kann.

Das könnte ich gut brauchen, vorausgesetzt, dass die 32-Biter und
die 64-Biter in diesen Dingen kompatibel sind, da ich unter PHP die
64 Bit laufen lasse und für meinen DB-Manager die 32 Bit brauche.

Weisst Du, ob das funktioniert ?

Du empfiehlst mir gleich auf die FB 4.x zu gehen, worüber ich auch
schon nachgedacht habe.

Aber in der offiziellen Migrations-Anleitung von 2.5 auf 4.x von FireBird.Org
ist die Rede davon, dass das nicht direkt geht, wenn ich das richtig
verstanden habe.

Mann soll also zuerst mit gbak 3.x eine FDB produzieren, dann
davon wieder eine GBK erstellen und dann gbak 4.x die finale FDB.

Das wäre mir aber zuviel Arbeit, weil bei mir noch das Pumpen von
ISO auf UTF8 dazu kommt und das mit 48 DB's.

Kann nach Deiner Einschätzung gbak 4.x direkt GBKs von
gbak 2.5 korrekt lesen ?

Und in Foren wird in mehreren Teads geraten erstmal die DB
unter 3.x ausgiebig zu testen, bevor man auf 4.x geht.

Da ich weder FB-spezifische Features nutze und erst recht
keine versions-spezifischen, wäre ein direkter Schritt nach
FB 4.x sehr interessant.

Danke und viele Grüße
vr2
Beiträge: 158
Registriert: Fr 13. Apr 2018, 00:13

Hallo Hamburgo,

erstmal Danke für das Lob. Dafür wurde das Internet erfunden ;-)
Hallo Volker,

mit Deiner Vermutung liegst genau richtig. Ich habe die firebird.conf in 2018 in folgenden Zeilen angepasst und dies leider vergessen, dass ich DAU das auch bei der neuen Version auch zu machen habe.
;-)
Somit gehe ich davon aus, wenn zusätzlich zur security-DB auch die firebird.conf verschiebe, dann klappt wohl alles wie gewohnt.
Ich würde eher mit WinMerge o.ä. die beiden vergleichen und dann die 4er firebird.conf aktualisieren und Änderungen aus der 3er einzeln übernehmen. Da sind noch ein paar Erweiterungen hinzugekommen, Schalter, die Du brauchst, und Du hast den aktuellen Stand.
Nun habe ich gelesen im Chapter "Macro substitution", dass man wohl die security-DB und vieles andere, u.a. auch firebird.conf in andere Ordner verschieben kann.

Das könnte ich gut brauchen, vorausgesetzt, dass die 32-Biter und die 64-Biter in diesen Dingen kompatibel sind, da ich unter PHP die 64 Bit laufen lasse und für meinen DB-Manager die 32 Bit brauche.

Weisst Du, ob das funktioniert ?
Du brauchst keinen 32-Bit-Firebird für einen 32-Bit-Client, denn die beiden Programme kommunizieren nur über Ports miteinander, die sind vollkommen separat. Was der 32-Bit-Client braucht, ist eine 32-Bit-fbclient, das ist alles. Die Version dieser fbclient (2.5.9, 3, 4) hängt davon ab, was der Client kann. Du kannst auch mit einer 2.5.9er fbclient einen 4er Server ansprechen. Dann sollte der eben legacy konfiguriert sein, so wie Du das beim alten 3er hattest. Du kannst also einen 64-Bit-Firebird 4 betreiben, holst Dir außerdem aus dem zip eines 32-Bit-Firebird der gewünschten Version nur die fbclient und machst die dem Client zugänglich. Wenige Clients kommen bisher mit Firebird 4 klar, Flamerobin ist einer, und bei den connectivity-libs für Anwendungen sieht es auch nicht so prall aus.
Du empfiehlst mir gleich auf die FB 4.x zu gehen, worüber ich auch schon nachgedacht habe.
Aber in der offiziellen Migrations-Anleitung von 2.5 auf 4.x von FireBird.Org ist die Rede davon, dass das nicht direkt geht, wenn ich das richtig verstanden habe.
Mann soll also zuerst mit gbak 3.x eine FDB produzieren, dann davon wieder eine GBK erstellen und dann gbak 4.x die finale FDB.
Das ist nicht richtig. Man kann direkt von 2.5.9 auf 4 migrieren. Du kannst ein 2.5er fbk mit einem 4er restoren. Bei der Vorbereitung der Migration gibt es ein paar Bereiche zu beachten:

- verwendest Du current_timestamp in Stored procedures oder Triggern? Dann musst Du die Stellen durch localtimestamp ersetzen, da der 4er mit Zeitzonen arbeitet und dessen current_timestamp auch. Nur der 2.5.9er hat localtimestamp, dh, wenn Du ältere 2.5er im Einsatz hast, musst Du die erst updaten und die Änderung machen, bevor Du umziehen kannst.
- die zwei Schalter ReadConsistency und DataTypeCompatibility des 4ers solltest Du defensiv auf ReadConsistency = 0 und DataTypeCompatibility = 3.0 setzen, damit sich die Verarbeitung so verhält wie bisher.
- Umzug der User: Wenn Du viele User hast, die nicht alle ihr Password neu setzen sollen, musst Du die Userübernahme gemäß https://ib-aid.com/download/docs/fb4mig ... ger_plugin durchführen
Das wäre mir aber zuviel Arbeit, weil bei mir noch das Pumpen von ISO auf UTF8 dazu kommt und das mit 48 DB's.
Den Schritt würde ich separat anschließend machen. Die Migration ist schon ein großer Schritt, ich würde erst sicherstellen, dass alles läuft wie bisher.

Dann die Zeichenkodierung umstellen. Dann aufräumen und Altlasten beseitigen, zb udfs durch stored functions ersetzen, wo möglich, Kompatibilitätsschalter umlegen, wo möglich.

Viele Grüße, Volker
Hamburgo
Beiträge: 120
Registriert: Di 28. Mai 2019, 17:28

Hallo Volker,

Stored procedures habe ich nicht, weil mir das Know-How dazu fehlt
und auch sehr wenige Trigger, aus selbem Grund.

In meinen Triggern benutze ich in Sachen Zeit-Stempel einzig:

Code: Alles auswählen

NEW.INDATE = 'NOW';
Ob da ein Problem mit Zeitzonen unter FB 4 drin steckt, kann ich
nicht beurteilen.

Da ich nicht nur meine DBs von ISO auf UTF8 umstelle, sondern auch
den PHP-Server selbst und alle Scripte, muss ich schon ein wenig
pumpen, um abschätzen zu können, ob alles läuft, wie bisher, wenn
ich keine ? auf dem Monitor und in neu-gespeicherten Datensätzen
haben will.

Um Alles zu testen müsste ich ca. 10 DBs konvertieren und davon
6 DBs pumpen. Da sind Hilfs-DBs dabei mit Orten, Strassen, mein
eigener Pendat zu Google-Maps usw.

Aber da ich ja nun von Dir gelernt habe, wie man mit überschaubarem
Aufwand recht schnell die FB-Version wechseln kann, werden ich mal
mal meine Haupt-DB nach FB 4.x konvertieren und pumpen um sehen
zu können, dass mindestens 75% funktioniert oder halt nicht.

Das braucht ca. 8 Stunden.

Gruss
Hamburgo
Beiträge: 120
Registriert: Di 28. Mai 2019, 17:28

Hallo Volker,
erstmal Danke für das Lob. Dafür wurde das Internet erfunden
Das Lob ist schon angebracht, was auch für @bfuerchau und @Martin gilt. Das
ist schon vorbildlich hier.

Vor kurzen habe ich gerade das krasse Gegenteil bei WordPress erlebt. Die Jungs sind
arrogant, selbst verliebt und nur mit begrenztem Know-How, selbst die Moderatoren.

Die haben garnicht verstanden, was ich von denen wollte, obwohl ich in Sachen WordPress
besser drauf bin, als bei FireBird.

Hier versteht mich jeder, egal wie amateurhaft ich frage. Das ist nicht selbstverständlich.

Gruss
vr2
Beiträge: 158
Registriert: Fr 13. Apr 2018, 00:13

Hi Hamburgo,

zu Deiner Frage, ob 'NOW' problematisch wird: Schau mal da: https://firebirdsql.org/file/documentat ... xtvars-now.

Code: Alles auswählen

NEW.INDATE = 'NOW';
So wie Du es verwendest, sollte es klappen, aber probier es aus, ob Du brauchbare Werte kriegst. Im Zweifelsfall musst Du NOW casten.

Grüße, Volker
Hamburgo
Beiträge: 120
Registriert: Di 28. Mai 2019, 17:28

Hallo Volker,

danke für die Info, die mich allerdings ein wenig zurückschrecken lässt,
weil da bei mir Irritationen entstehen.

Code: Alles auswählen

select cast('NOW' as timestamp) from rdb$database
-- returns e.g. 2008-08-13 14:20:19.6170
Da ich in meinem Programm viele (Arbeits-)Zeiten messe, habe ich
sehr viele Felder vom Typ "timestamp", aber alle OHNE Millisekunden.

Aus dem CAST-Beispiel entnehme ich, dass FB 4.x den "timestamp"
in Zukunft mit Millisekunden (hier .6170) ausliefert, was mein Programm
völlig ducheinander bringen würde, da ich immer nur VOLLE Sekunden
erwarte.

Verstehe ich da etwas falsch ?

Ich hoffe ja.

Danke und Gruss
Antworten