|
Unvailble Datatbase
Guten Tag Delphi-Gemeinde,
folgendes Problem: nach dem Umzug von einem Windows 2012-Server auf einen Windows-2022 Server, kann das Programm nicht mehr aufgerufen werden. Fehlermeldung "unvailble Database". Die Zuweisung zur Datenbank wird über einen Eintrag in einer INI-Datei: "GDB=\\lvhost\goldene-sonne\Datenbank\LOGE-AKTUELL.GDB" von der EXE-Datei ausgelesen. Auf dem vorherigen Server gab es damit auch keine Probleme. Wenn zum Beispiel die Datenbank auf das Laufwerk "C:\Test" kopiert und der Datenbankpfad entsprechend geändert wird, dann kann das Programm korrekt gestartet werden! Welche Einstellungen auf dem Server können noch vorgenommen werden oder gibt es andere Aufrufmöglichkeiten? Vielen Dank für eventuelle Hilfen. |
AW: Unvailble Datatbase
probier mal
lvhost:C:\goldene-sonne\Datenbank\LOGE-AKTUELL.GDB mit \\ vorne wird als protokoll netbeui versucht und entweder mag dein server oder dein client das nicht und gebe dem server damit einen realen pfad wo der server die datenbank lokal auf einer platte finden kann nicht irgendwelche shares, ggf benutze alternativ firebird alias einträge weitere infos auch hier  https://www.firebirdfaq.org/faq260/ |
AW: Unvailble Datatbase
Hallo Holger,
ich habe Deinen Rat verfolgt und die beiden BackSlaches entfernt. Das Ergebnis bleigt das Gleiche. Dnach habe ich dieses versucht: "GDB=lvhost:L:\Logen\goldene-sonne\Datenbank\LOGE-AKTUELL.GDB" war aber auch nicht erfolgreich. Ich werde mich mit dem Admin des Servers auseinader setzen und die von die vorgeschlagene Seite durchgehen. |
AW: Unvailble Datatbase
Läuft auf dem Server ein Firebird-Datenbankserver?
Wenn ja: Zuerst den Namen des Servers angeben. Wenn nicht der Defaultport für den Firebird-Datenbankserver genutzt wird Slash und Port. Dann ein Doppelpunkt und dann die Verzeichnisangabe aus Sicht des Datenbankservers. Servername/3050:Laufwerksbuchstabe:\Verzeichnis(se)\Datenbank name.fdb Der Client muss weder die Datenbankdatei sehen können noch Rechte auf das Verzeichnis haben, noch benötigt er irgendwelche Schreib- und/oder Leserechte. Heißt der Server lvhost und die Datenbankdatei liegt dort unter c:\Logen\goldene-sonne\Datenbank\, dann muss es "GDB=lvhost:c:\Logen\goldene-sonne\Datenbank\LOGE-AKTUELL.GDB" heißen. Ob die Datenbankdatei aus Sicht des Clients auf L: iiegt, ist dabei irrelevant. Sprich: L:\Logen\goldene-sonne\Datenbank\LOGE-AKTUELL.GDB muss die lokale Laufwerks- und Verzeichnisangabe auf dem Server sein. Die Nutzung von Datenbankaliassen könnte da hilfreich sein, um die Verwirrung bei der Angabe von Laufwerk und Verzeichnis für die Datenbankdatei zu beheben. https://firebirdsql.org/rlsnotesh/config-db-alias.htmlDer Datenbankserver hat die Konfigurationsdatei databases.conf. Wenn Du dort einen Eintrag der Form LOGE-AKTUELL=Laufwerk:\Verzeichnis(se)\LOGE-AKTUELL.GDB machst, sollte in der INI-Datei ein Eintrag in der Form "GDB=lvhost:LOGE-AKTUELL" ausreichen. Sollte die Datenbankdatei auf dem Server dann irgendwann mal umziehen müssen, so reicht es, in der databases.conf auf dem Server den Eintrag LOGE-AKTUELL zu ändern. Für die Clients sollte das absolut transparent sein. |
AW: Unvailble Datatbase
Hallo,
ich bin der Admin, mit dem sich Noname1 auseinandersetzen muss. Das Laufwerk L: vorhergehenden Nachrichten ist ein Netzlaufwerk, das auf ein Verzeichnis mit der Datenbank zeigt. Für mich stellt sich die Frage: Kann Firebird nur auf reguläre Laufwerke, wie C., D, u.s.w. zugreifen? Oder kann Firebird auch auf Shares und UNC Pfade zugreifen. Bis jetzt hat das System nur mit dem regulären Pfad funktioniert. Das würde aber das erdachte Sicherheitskonzept aufweichen. Gruß Peasadas |
AW: Unvailble Datatbase
Zitat:
Shares als Sicherheitskonzept? |
AW: Unvailble Datatbase
klassiker könnte auch sein, das du auf dem alten server fb25 oder älter hattest und der unwissende admin einfach mal einen fb3 oder neuer installiert hat.
das würde ohne backup/restore mit der datenbank eh nicht gehen, aber der zugriff ist dann auch nur mit einer fbclient.dll oder gds32.dll von fb>=3 möglich, es sei denn der server hat den legacy mode aktiv, da befürchte ich aber das der admin vom neuen server eh nicht weiss wovon ich da rede, daher spreche mit dem noch mal ab welche fb version da installiert wurde. |
AW: Unvailble Datatbase
Port auf dem neuen Server in der Firewall freigegeben ?
Gruß, Tom |
AW: Unvailble Datatbase
nun denn, da haben wir dich ja schon als verantwortlichen.
shares als sicherheitskonzept ist gruselig, freut aber jeden trojaner .... firebird braucht gar keine shares und wird bei betrieb auf netzwerkshares (was im application mode gehen würde) auch noch unnötig lahm. per default ist firebird aber als dienst installiert mit dem systemuser als kontext und da sollte es mich wundern, wenn ihr dem die zugriffsrechte auf dem share gegeben habt. und wie ich gerade eben schon schrieb: welche firebird version ist installiert und welche war vorher installiert? ist die firebird/fbserver/fb_inet_server exe in der firewall freigeschaltet? die datenbank auf einem share abzulegen macht man nur, wenn es den kollegen, die mit der zugehörigen software arbeiten sollen, eh egal ist, wie lahm die software ist. leg die datenbank auf einem lokalen pfad ab, dafür braucht kein einziger client eine freigabe, der server weiss dann aber wo die datenabnk datei ist. und wenn das variabel sien soll, schau die die aliases.conf/databases.conf an um dort eine alias einzutragen Zitat:
|
AW: Unvailble Datatbase
Ok,
erst einmal herzlichen Dank für die Antworten. Es existieren ca. 30 kleine Datenbanken, die jeweils in einem eigenen Verzeichnis abgelegt werden. Und auf dieses Verzeichnis darf nur der entsprechende Benutzer beziehungsweise die entsprechende Benutzergruppe zugreifen. Das mit den Datenbanken in den Verzeichnissen ist vom Entwickler so vorgegeben. Diese Benutzergruppen haben keinen Zugriff auf reale Laufwerke, auf keine anderen Verzeichnisse und Ressourcen auf dem System, deshalb die Shares. Somit ist ein Trojaner auf das Verzeichnis des Benutzers begrenzt. (Das Restrisiko ist bekannt) Ich kenne Firebird nicht, aber bei anderen SQL-Installationen werden die Datenbanken in den SQL-Server eingehängt und dann findet der Zugriff über <Servername oder IP><eventuell Port> und <Datenbankname> aus der Anwendung heraus statt. Hier wird aus der Anwendung auf die Datenbank im Verzeichnis zugegriffen und dabei gibt es das Problem, dass Firebird anscheinend nur reale Datenpfade akzeptiert. Und somit bin ich wieder bei meiner gestellten Frage: Geht das nur mit realen Pfaden. Ich freue mich auf eure Antworten und Verbesserungsvorschläge (Das ist nicht ironisch gemeint) Mit herzlichen Grüßen Peasadas |
AW: Unvailble Datatbase
Der "Local System Account" (darunter laufen idR die Dienste) kennt keine Shares. Diese sind nur beim angemeldeten Benutzer bekannt. Verwende stattdessen einen UNC-Pfad für die Verbindung und nimm in die Freigabe auch den Local System Account mit auf. So ist es zumindest bei anderen DBMS mit ähnlicher Zugriffsstruktur.
|
AW: Unvailble Datatbase
Hallo,
Du bist ja auf FB5 umgestiegen. Da gibt es NETBUI nicht mehr, deshalb klappt \\ nicht mehr. Und FB will keine Netzlaufwerke haben. |
AW: Unvailble Datatbase
Die Benutzer benötigen keinerlei Zugriff auf die Verzeichnisse bzw. die Datenbankdateien. Den Zugriff benötigt nur der Datenbankserver. Den "Rest" kannst Du über die Konigurationsdateien des Firebirddatenbankservers konfigurieren.
Genaugenommen kann / sollte / muss es dem Entwickler egal sein, wo die Datenbankdatei liegt. Es reicht aus, wenn er den Aliasnamen vorgibt, unter dem seine Software auf "seine" Datenbank zugreift. Wenn Nonames Datenbank LOGE-AKTUELL heißen soll, dann wird nur in der Konfiguration eine Alias LOGE-AKTUELL benötigt, bei dem Du dann für den Firebirdserver angibts, wo er die entsprechende Datenbankdatei findet. Die darf dann überall liegen wo der Firebirdserver bzw. der Benutzer, unter dessem Account er läuft, Zugriff hat. Noname muss dann in der Ini-Datei lediglich "GDB=lvhost:LOGE-AKTUELL" angeben. Und wenn morgen das Laufwerk, auf dem zur Zeit die Datenbankdateien liegen, zu klein wird, kannst Du einen Teil oder alle Datenbankdateien morgen auf ein anderes Laufwerk verschieben. Du muss dann nur den Alias in "Deiner" Firebirdkonfiguration ändern. Für den Client ist das transparent, sprich: Der merkt nix davon. Seine Konfiguration muss nicht angepasst werden, seine Benutzer oder Benutzergruppen müssen keine neuen oder geänderte Zugriffsrechte erhalten, derweil: Die brauchen die schlicht und einfach nicht. Sollten sie die Rechte doch benötigen, dann gewiss nicht für die Datenbankdatei. (Dann sollte man allerdings das genutzte Konzept hinterfragen.) Bei 'ner Oracle-, SQL-Server-, PostGres-, MySQQL-Datenbank benötigen die Benutzer auch keine Zugriffsrechte auf die Datenbankdateien. Sie müssen nur wissen, wie sie den Datenbankserver erreichen, aber nicht, wo er die Daten letztlich physikalisch ablegt. Das ist bei FireBird nicht anders, auch wenn es mit mehr oder weniger viel Aufwand bei Firebird im Rahmen des Möglichen ist. Sehen wir es analog zur Delphipraxis: Wenn ich darauf zugreifen will, gebe ich im Browser halt https//:www.delphipraxis.net ein. Aber wo der dahinterliegende Datenbankserver seine Datenbankdateien hat, um welches Datenbanksystem es sich überhaupt handelt, muss ich nicht wissen, es geht mich nichtmal was an. Und irgendwelche Rechte auf dem Server benötige ich schonmal garnicht.Das sollte bei eurer Software (meiner Meinung nach) nicht anders sein. In der Ini-Datei sollte nur der Name des Servers stehen, gefolgt von dem Namen (Alias) unter dem die Datenbank zu erreichen ist. Prinzipell passt das von Dir beschriebene System Zitat:
In die Ini-Datei gehören auch unter FireBird <Servername oder IP><eventuell Port> und <Datenbankname>. Wie Du dann als Admin letztlich den Datenbankserver einrichtest, sollte alleine Deine Aufgabe sein, da solten auch die Entwickler keine Vorgaben bezüglich der Verzeichnisstrucktur und / oder der Dateinamen für die Datenbanken machen. Das Einzige, auf das Ihr euch einigen müsst / solltet / könnt, ist der Name des Servers und des Alias, über die dann die Kommunikation zwischen Software und Datenbank stattfinden soll. Aber da das Informationen sind, die aus einer INI-Datei gelesen werden, solltest Du selbst das vorgeben dürften. |
AW: Unvailble Datatbase
Zitat:
Warum nicht mit dem embedded? der läuft als dll mit in deiner laufenden exe und kann eine datenbank datei überall öffnen wo die via lokaler rechte auch erreichbar wäre. Wenn dann auf der db mehr als ein prozess läuft, d.h. mehr als ein user braucht den gleichzeitigen zugriff auf die db ohne das ein server irgendwo installiert ist, dann geht das ab firebird 3 auch problemlos, man muss dann für den embedded client in der lokalen firebird.conf halt ganz unten classic einstellen. das hätte bei dem betrieb auf einem share aber weiterhin alle schon bekannten nachteile in der performance. und ohne das du mit der alten datenbankversion von jeder datenbank ein backup zB mit gbak machst in der alten version und dann das restore mit dem fb5 gbak o.ä. wirst du dann eh nicht weiter kommen. bei der Konstellation die euer Entwickler da hinterlassen hat, kann es auch noch gut sein, das du noch andere lustige nebeneffekte feststellen wirst, wenn der Client nicht angepasst ist (also die delphi exe zB bestimmte tfield objekte referenziert die in fb5 anders kommen wie count ist int64 usw. ) das kann man alles lösen, aber irgendwie hat euer entwickler da schon ein sehr seltsames konstrukt als basis hinterlassen. bessere performance bei fb5 für single user datenbanken auf shares kannst du aber vergessen, falls das die motivation zum umstieg ist. wenn das um lauffähig machen geht bleib einfach bei fb25 auch auf dem neuen server, dann solltest du eigentlich nichts an der alten config ändern müssen. |
AW: Unvailble Datatbase
Noch eine vielleicht doofe Frage: wird "lvhost" im DNS überhaupt aufgelöst? Ich arbeite bei den Datenbanpfaden im Netzwerk immer mit der IP-Adresse (der Datenbankserver sollte ja eine feste IP haben...).
Hartmut |
AW: Unvailble Datatbase
Zitat:
Gruß Fred |
AW: Unvailble Datatbase
Herzlichen Dank für die Antworten,
der Server läuft tatsächlich im embedded Mode und die Anwendungen greifen über DLL auf die Datenbanken zu. Ich habe die File-Struktur abgeändert, die Datenbanken sind jetzt über reale Laufwerke erreichbar und funktionieren. Persönlich würde ich es lieber sehen, wenn die Datenbanken im Firebird registriert wären und der Zugriff über IP-Adresse auf den Firebird läuft. Das Leben ist kein Ponyhof, darum muss ich damit leben. Noch mal herzlichen Dank für die konstruktiven Vorschläge. Mit herzlichen Grüßen Fred |
AW: Unvailble Datatbase
Zitat:
Zitat:
Noch wichtiger für Admins: Firebird ist nicht VSS fähig! Man kann die FDB nicht im laufenden betrieb sichern und erwarten dass die Sicherung funktioniert oder dass der Server fehlerfrei weiterläuft ohne das sich z.b. Transactions aufhängen und nicht mehr beendne... Also Firebird von live sicherungen über den Schattenkopien-dienst ausschließen und über gback sichern. |
AW: Unvailble Datatbase
Zitat:
Da steht aber auch "DO NOT ENABLE THIS OPTION UNLESS YOU REALLY KNOW WHAT YOU ARE DOING." Siehe dazu auch: http://www.firebirdfaq.org/faq46/Aber sie benutzen doch gar keinen Server. Peasadas schreibt "der Server läuft tatsächlich im embedded Mode". Das heißt, der "Datenbankserver" läuft tatsächlich auf dem Client! Ich nehme mal an, das Prozedere mit den Freigaben für jeden User stammt noch aus der Urzeit, wo man möglicherweise mit Paradox oder dBase direkt auf die Daten zugegriffen hat. Und weil sich das so bewährt hat, wurde es für Firebird beibehalten. Einen "echten" Server nutzt man nicht, denn klar kann man über Alias auf die Datenbanken zugreifen, und klar kann man sich dann die Freigaben komplett sparen (ein Sicherheitsrisiko weniger!), und klar reicht es für den Client völlig aus, die IP des Servers zu kennen samt dem Alias, aber wie verhindert man, dass User A unberechtigt auf den Datenbank-Alias von User B zugreift? Das scheint das Hauptproblem zu sein; der Trojaner ist m.E. nur vorgeschoben. |
| Alle Zeitangaben in WEZ +1. Es ist jetzt 14:01 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz