Nach einem Dist-Upgrade auf Debian Trixie liefen meine die Firebird-Datenbank benutzenden eigenen Tools nicht mehr und es hat mich einige (!) Minuten gekostet, herauszufinden, was da genau die Ursache war. Vielleicht RTFM, aber Google & Co. fanden trotz neuerdings intensiver KI-Unterstützung nichts. (*)
Ein „apt search firebird“ liefert Hinweise, dass bei Debian 13 sowohl Firebird 3.0 als auch Firebird 4.0 installiert werden. Ein „apt install firebird“ spült beide Versionen ins System und damit auch Konfigurationsdateien für beide Versionen, die Verzeichniss „/etc/firebird/3.0“ und „/etc/firebird/4.0“ vorhanden.
Obwohl ein „service firebird3.0 status“ zeigte, dass Firebird lief, kam dies hier:
$ isql-fb localhost:foo Statement failed, SQLSTATE = 08006 Unable to complete network request to host "localhost". -Failed to establish a connection. Use CONNECT or CREATE DATABASE to specify a database SQL>
Hmm. Da schaut man erst einmal blöd und vermutet eine Fehlkonfiguration des Netzwerks, aber das lief ja. Oder irgendwas mit IPv4 und IPv6? Wenn ich mittels „CREATE DATABASE ‚foo.fdb‘;“ eine neue Datenbank erzeugte, dann gehörte diese anschließend nicht firebird:firebird sondern dem aktuellen Benutzer, und natürlich gelang dies nur in einem Verzeichnis, in dem der aktuelle Benutzer Schreibrechte hat. WTF ging hier vor sich?
Die Konfiguration in „/etc/firebird/3.0“ entsprach größtenteils der auf einem anderen Rechner, auf dem Firebird problemlos lief und immer noch läuft. Nach dem ich in der „/etc/firebird/3.0/firebird.conf“…
RemoteBindAddress = RemoteAccess = true
… konfiguriert und ein „service firebird3.0 restart“ durchgeführt hatte, kam ich auch wieder von remote auf meine existierende Datenbank. Aber lokal kam weiterhin die obige Fehlermeldung mit „Unable to complete network request to host“. Auch „servername:foo“ oder „127.0.0.1:foo“ nützte nichts. Was passierte hier?
Mittels
strace isql-fb localhost:foo 2> /tmp/strace.log
habe ich geschaut, was da genau passiert. Und siehe da: es ist alles voller „4.0“. Auszüge aus dem erzeugten Log:
execve("/usr/lib/firebird/4.0/bin/isql-fb
openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/firebird/4.0/firebird.conf
Obwohl der Server in Version 3.0 läuft, wird eine Version 4.0 von isql-fb gestartet, das auch die Konfiguration aus dem 4.0-Verzeichnis liest. Hä?
Ein Blick in „more $(which isql-fb)“ zeigt: Das ist ein Wrapper-Script, das abhängig von einer gesetzten Umgebungsvariable $FIREBIRD_VERSION die passende Version von isql-fb startet. Default ist 4.0, sprich wenn nicht gesetzt, dann wird isql 4.0 gestartet.
$ isql-fb -z localhost:foo -u sysdba -p masterkey ISQL Version: LI-V4.0.5.3140 Firebird 4.0 Statement failed, SQLSTATE = 08006 Unable to complete network request to host "localhost". -Failed to establish a connection. Use CONNECT or CREATE DATABASE to specify a database SQL> exit; $ export FIREBIRD_VERSION=4.0 $ isql-fb -z localhost:foo -u sysdba -p masterkey ISQL Version: LI-V4.0.5.3140 Firebird 4.0 Statement failed, SQLSTATE = 08006 Unable to complete network request to host "localhost". -Failed to establish a connection. Use CONNECT or CREATE DATABASE to specify a database SQL> exit; $ export FIREBIRD_VERSION=3.0 $ isql-fb -z localhost:foo -u sysdba -p masterkey ISQL Version: LI-V3.0.12.33787 Firebird 3.0 Server version: LI-V3.0.12.33787 Firebird 3.0 LI-V3.0.12.33787 Firebird 3.0/tcp (dd13)/P15:C LI-V4.0.5.3140 Firebird 4.0/tcp (dd13)/P15:C Database: localhost:foo, User: SYSDBA SQL> select 'Hallelujah' from RDB$Database; CONSTANT ========== Hallelujah
Aber warum genau scheitert isql-fb 4.0? Darum:
$ cat /etc/firebird/3.0/service-port.conf RemoteServicePort = 3050 $ cat /etc/firebird/4.0/service-port.conf RemoteServicePort = 3051
Firebird 3.0 lauscht auf Port 3050, isql-fb 4.0 möchte sich allerdings auf Port 3051 verbinden. Irgendjemand im Firebird- oder Debian-Team (?) hat sich wohl gedacht, dass es ganz furchtbar schlau ist, für den Default-Firebird-Client genau den Port zu verwenden, den der Default-Firebird-Server aber gar nicht verwendet. :rolleyes:
Jetzt muss ich nur noch schauen, was das alles für Auswirkungen auf meine PHP- und Perl-Scripts hat und wie ich die wieder zum Laufen bekomme… Fortsetzung folgt.
(*) Mal schauen, ob und wann die Inhalte dieser Seite von ihnen gefunden werden.