SYSDBA deaktivieren

[im-tom]

Hallo, wie kann ich den SYSDBA deaktivieren oder das Kennwort des SYSDBA ändern?
Bzw. wie kann ich es erreichen, das sich nicht ein User einfach mit SYSDBA anmeldet und somit Vollzugriff auf alle hat?
Gruß
Tom

[miboe]

Deaktivieren geht nicht ... aber im Installationsverzeichnis der Firebird liegt ein Quickstart Guide als pdf, wo der Ablauf zur Paßwortänderung zum einen beschrieben und zum anderen wärmstens aus genau diesen Gründen empfohlen wird.

Geht allerdings nur über das Kommandozeilentool GSEC, welches im \bin des Installationsverzeichnisses liegt.

Gruß
Michael

[im-tom]

Vielen Dank, Michael.
Ich habe das Passwort dank deiner Hilfe jetzt geändert.

Liebe Grüße

Tom

[wjjl]

moin,

wollte das auch allerdings kommt bei mir die meldung..

find/modify record error
invalid request BLR at offset 103
table USERS ist not defined

könnte mir das jemand n tip geben danke

[miboe]

Richtige Datenbank ausgewählt? Mit dem GSEC Tool muß man auf die Security.fdb zugreifen, und da gibt es nur die Tabelle USERS ... GSEC nicht auf die averp.fdb anwenden!

Gruß
Michael

[wjjl]

Danke danke ich seh schon ich habs nicht so drauf

[Geri12]

Hallo,
um hier an die Änderung des SYSDBA-Passworts anzuschließen:

Kann es sein, dass durch diese Änderung das Programm GBAKSchd.exe bei der Datensicherung ins Trudeln kommt ? Bei mir wird seither die Datensicherung mit dem ff. Fehler beendet ...

Code: Alles auswählen

gbak: ERROR: Your user name and password are not defined. Ask your database administrator to set up a Firebird login.

In AvERP einloggen als SYSDBA mit dem neuen Passwort ist OK

Gruß
Geri12

[miboe]

Ich habe mit Gbaksched noch nicht gearbeitet, aber die gepostete Fehlermeldung legt genau das als Fehlerursache nahe. Mal prüfen, ob es für das Programm irgendwo eine .ini oder .cfg oder sowas gibt. Ich kann mir nicht vorstellen, daß man das bei einem solchen Programm nicht einstellen kann ... zumal ja die ganze Welt das Startpaßwort eine Firebird-Datenbank kennt

Gruß
Michael

[miboe]

So ich habe gerade nochmal in den Gbak Scheduler reingeschaut, den man bei Synerpy runterladen kann und dort kann man für jeden Backup- und Restoretask die Connection Parameter getrennt einstellen ... und dazu gehören auch Username und Paßwort ----> einfach nochmal die Tasks im Gbak Scheduler neu einrichten oder ändern. Je nachdem was einfacher ist.

Gruß
Michael

[Geri12]

Hallo miboe,
ja wenn's doch nur so einfach wäre

Ich hatte mit GSEC das SYSDBA-Passwort in der security.fdb geändert. Danach natürlich in der AvERP-Anmeldung, in der IBExpert-Anmeldung und in dem Sicherungs-Task bei GBAKSchd.exe. Das neue Passwort funktioniert auch bei AvERP und beim IBExpert. Nur die Sicherung über GBAK wird mit obigem Fehler abgebrochen.

Ich habe jetzt mal gerade auf dem Entwicklungsrechner getestet -> SYSDBA-Passwort auf das völlig unbekannte Startpasswort zurückgeändert: AvERP-Anmeldung -> OK, IBExpert-Anmeldung -> OK, Sicherungs-Task bei GBAKSchd.exe -> OK

Da bin ich baff

Demzufolge müsste das alte Passwort ja NOCH irgendwo stehen. Oder es ist in GBAKSchd.exe fest einprogrammiert ?! Doch wozu dann die Möglichkeit, jedem Sicherungstask zur Datenbank auch das Passwort mitzugeben ?

[miboe]

Ich passe In case of emergency call SYNxx

Ich habe auf unserem Server (der läuft auf MS2003) den normalen Taskscheduler von Windows benutzt und lasse ein Batchscript ausführen, was die notwendigen Kommandos enthält und direkt GBAK unf GFIX benutzt.

Gruß
Michael

[Geri12]

Hallo,
das direkte Ansteuern von GBAK war bei mir dann auch die letzte Alternative (vor einer perHand-Sicherung über IBExpert) und von mir als nächster logischer Schritt angedacht.

Ergebnis: Interessanterweise hat GBAK über eine Batchdatei angesteuert keinerlei Probleme mit dem neuen Passwort, somit würde ich die Merkwürdigkeit bzgl. SYSDBA-Passwortverweigerung dann wohl GBakSchd.exe in die Schuhe schieben.

Aber ein kleiner Schönheitsfehler bleibt mir noch: ich hätte gerne eine gepackte Protokolldatei wie beim GBakSchd (welches GBAK auch nur über die Kommandozeile ansteuert) und nicht eine so langatmige wie bei Angabe des Parameters "-v" (= Verbose). Allerdings bekomme ich ohne "-v" eine leere Protokolldatei

Irgendwie finde ich aber nirgends eine komplette Beschreibung der Parameter von GBAK.
Kann mir da einer weiterhelfen ?

@miboe
Das schöne an GBakSchd.exe ist, dass man automatisch Tages- und Wochensicherungen anlegen kann und dass diese Sicherungen auch gleich gezippt werden, was die Größe für die Datensicherung natürlich erheblich verringert.
... Ich kann natürlich auch 6 Tasks anlegen: 5 für die Wochentage und 1 extra für Freitags ...

P.S. Es besteht noch kein Notfall, ich teste die Datensicherung im Moment mit der FürAlleTestversion auf dem Server

[Gast]

[...]
Irgendwie finde ich aber nirgends eine komplette Beschreibung der Parameter von GBAK.
Kann mir da einer weiterhelfen ?

Hallo,

also ich habe mal unter Linux geschaut, direkte man-Pages gibt es in meinem Paket nicht, allerdings gibt google bei der Suche nach "man gbak" ein wenig Hilfe.
Diese Seite erklärt die Kommandos ein wenig ausführlicher, aber auf meinen ersten Blick auch nicht viel anderes als -v.
Wie sieht denn die "gepackte" Protokolldatei von GBakSchd im Vergleich zum Verbose-Output von gbak aus?

[Geri12]

Hallo hoFFy
ich habe hier eine sehr gute Dokumentation zu Firebird 1.5 bzw. 2.x gefunden ...
http://www.consic.de/de/download/firebird/index.htm

Allerdings finden sich dort ausser den von mir verwendeten Parametern keine weiteren bzgl. der Protokolldatei.

Diese sieht in der Kurzversion bei GBakSchd.exe folgendermaßen aus:

Code: Alles auswählen

BACKUP SUMMARY (TASK #3)

Started at 23.07.2008 15:41:17
Database 127.0.0.1:C:\Programme\Firebird_1x5\security.fdb
Target file F:\AVERP_Backup\security_3.DL3.zip
Ended at 23.07.2008 15:41:18

[miboe]

Hallo Geri12,

das zippen der Backupdatei kann man doch auch mit in das Batchfile schreiben, welches vom Taskscheduler ausgeführt wird. Also unser "Wartungs-Batchfile" macht eine ganze Menge Aufgaben:
* Datenbank offline setzen
* fdb-Datei als Datei zunächst mal in Sicherheit bringen, falls danach was schief geht
* isql Aufruf der die Prozedur P_JOB_BARTLHBU ausführt
* gfix -mend
* gfix -sweep
* altes Reportfile für Backup löschen, weil gbak ansonsten hängt
* gbak -b
* altes Reportfile für Restore löschen
* gbak -r (dann ist die Datenbank wieder schön sauber)
* gfix -online

Da wäre es natürlich kein Problem hinter das gbak -b noch ein pkzip oder sonstwas zum komprimieren zu setzen. Packer mit Kommandozeile gibt es ja "ein paar"

Das mit dem Logfile kann man soweit ich weiß leider wirklich nicht großartig steuern. Entweder nix oder volles Brett ...

Gruß
Michael