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\u00fctzung nichts. (*)<\/p>\n
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\u00fclt beide Versionen ins System und damit auch Konfigurationsdateien f\u00fcr beide Versionen, die Verzeichniss „\/etc\/firebird\/3.0“ und „\/etc\/firebird\/4.0“ vorhanden.<\/p>\n
Obwohl ein „service firebird3.0 status“ zeigte, dass Firebird lief, kam dies hier:<\/p>\n
$ isql-fb localhost:foo\r\nStatement failed, SQLSTATE = 08006\r\nUnable to complete network request to host \"localhost\".\r\n-Failed to establish a connection.\r\nUse CONNECT or CREATE DATABASE to specify a database\r\nSQL><\/pre>\nHmm. Da schaut man erst einmal bl\u00f6d 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\u00f6rte diese anschlie\u00dfend nicht firebird:firebird sondern dem aktuellen Benutzer, und nat\u00fcrlich gelang dies nur in einem Verzeichnis, in dem der aktuelle Benutzer Schreibrechte hat. WTF ging hier vor sich?<\/p>\n
Die Konfiguration in „\/etc\/firebird\/3.0“ entsprach gr\u00f6\u00dftenteils der auf einem anderen Rechner, auf dem Firebird problemlos lief und immer noch l\u00e4uft. Nach dem ich in der „\/etc\/firebird\/3.0\/firebird.conf“…<\/p>\n
RemoteBindAddress =\r\nRemoteAccess = true<\/pre>\n… konfiguriert und ein „service firebird3.0 restart“ durchgef\u00fchrt 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\u00fctzte nichts. Was passierte hier?<\/p>\n
Mittels<\/p>\n
strace isql-fb localhost:foo 2> \/tmp\/strace.log<\/pre>\nhabe ich geschaut, was da genau passiert. Und siehe da: es ist alles voller „4.0“. Ausz\u00fcge aus dem erzeugten Log:<\/p>\n
execve(\"\/usr\/lib\/firebird\/4.0\/bin\/isql-fb\r\nopenat(AT_FDCWD, \"\/usr\/lib\/x86_64-linux-gnu\/firebird\/4.0\/firebird.conf<\/pre>\nObwohl der Server in Version 3.0 l\u00e4uft, wird eine Version 4.0 von isql-fb gestartet, das auch die Konfiguration aus dem 4.0-Verzeichnis liest. H\u00e4?<\/p>\n
Ein Blick in „more $(which isql-fb)“ zeigt: Das ist ein Wrapper-Script, das abh\u00e4ngig 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.<\/p>\n
$ isql-fb -z localhost:foo -u sysdba -p masterkey\r\nISQL Version: LI-V4.0.5.3140 Firebird 4.0\r\nStatement failed, SQLSTATE = 08006\r\nUnable to complete network request to host \"localhost\".\r\n-Failed to establish a connection.\r\nUse CONNECT or CREATE DATABASE to specify a database\r\nSQL> exit;\r\n\r\n$ export FIREBIRD_VERSION=4.0<\/strong>\r\n\r\n$ isql-fb -z localhost:foo -u sysdba -p masterkey\r\nISQL Version: LI-V4.0.5.3140 Firebird 4.0\r\nStatement failed, SQLSTATE = 08006\r\nUnable to complete network request to host \"localhost\".\r\n-Failed to establish a connection.\r\nUse CONNECT or CREATE DATABASE to specify a database\r\nSQL> exit;\r\n\r\n$ export FIREBIRD_VERSION=3.0<\/strong>\r\n\r\n$ isql-fb -z localhost:foo -u sysdba -p masterkey\r\nISQL Version: LI-V3.0.12.33787 Firebird 3.0\r\nServer version:\r\nLI-V3.0.12.33787 Firebird 3.0\r\nLI-V3.0.12.33787 Firebird 3.0\/tcp (dd13)\/P15:C\r\nLI-V4.0.5.3140 Firebird 4.0\/tcp (dd13)\/P15:C\r\nDatabase: localhost:foo, User: SYSDBA\r\nSQL> select 'Hallelujah' from RDB$Database;\r\n\r\nCONSTANT \r\n========== \r\nHallelujah<\/pre>\nAber warum genau scheitert isql-fb 4.0? Darum:<\/p>\n
$ cat \/etc\/firebird\/3.0\/service-port.conf \r\nRemoteServicePort = 3050\r\n\r\n$ cat \/etc\/firebird\/4.0\/service-port.conf \r\nRemoteServicePort = 3051<\/pre>\nFirebird 3.0 lauscht auf Port 3050, isql-fb 4.0 m\u00f6chte sich allerdings auf Port 3051 verbinden. Irgendjemand im Firebird- oder Debian-Team (?) hat sich wohl gedacht, dass es ganz furchtbar schlau ist, f\u00fcr den Default-Firebird-Client genau den Port zu verwenden, den der Default-Firebird-Server aber gar nicht verwendet. :rolleyes:<\/p>\n
Jetzt muss ich nur noch schauen, was das alles f\u00fcr Auswirkungen auf meine PHP- und Perl-Scripts hat und wie ich die wieder zum Laufen bekomme… Fortsetzung folgt.<\/p>\n
\n(*) Mal schauen, ob und wann die Inhalte dieser Seite von ihnen gefunden werden.<\/p>\n","protected":false},"excerpt":{"rendered":"
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\u00fctzung nichts. (*) Ein „apt search firebird“ liefert Hinweise, dass bei Debian 13 sowohl Firebird Weiterlesen\u00a0\u2026<\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[22],"tags":[287,333],"class_list":["post-2231","post","type-post","status-publish","format-standard","hentry","category-linux","tag-debian","tag-firebird"],"_links":{"self":[{"href":"https:\/\/www.dirk-hagedorn.de\/index.php?rest_route=\/wp\/v2\/posts\/2231","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.dirk-hagedorn.de\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.dirk-hagedorn.de\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.dirk-hagedorn.de\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dirk-hagedorn.de\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=2231"}],"version-history":[{"count":1,"href":"https:\/\/www.dirk-hagedorn.de\/index.php?rest_route=\/wp\/v2\/posts\/2231\/revisions"}],"predecessor-version":[{"id":2232,"href":"https:\/\/www.dirk-hagedorn.de\/index.php?rest_route=\/wp\/v2\/posts\/2231\/revisions\/2232"}],"wp:attachment":[{"href":"https:\/\/www.dirk-hagedorn.de\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=2231"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dirk-hagedorn.de\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=2231"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dirk-hagedorn.de\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=2231"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}