Kategorie: Linux

Firebird auf Debian 13 (Trixie)

Veröffentlicht amAutordh

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.

Kurztipp: Kartenleser mit Ubuntu 24.04 LTS

Veröffentlicht amAutordh

Problem: Nach dem dist-upgrade auf Ubuntu 24.04 LTS funktionierte der ReinerSCT Cyberjack Kartenleser nicht mehr. Der Daemon (pcscd) lief zwar, protokollierte aber nichts Gutes ins syslog:

pcscd[267998]: CYBERJACK: Started
pcscd[267998]: 00000000 auth.c:143:IsClientAuthorized() Process 267997 (user: 1000) is NOT authorized for action: access_pcsc
pcscd[267998]: 00000210 winscard_svc.c:355:ContextThread() Rejected unauthorized PC/SC client

Ursache: die „Treiber“ benutzen nun polkit für die Zugriffskontrolle, und standardmäßig ist halt nichts konfiguriert und damit jedem alles verboten.

Lösung: Man lege zwei polkit-Regeln an (das sind nicht mehr als kleine Textdateien mit ein wenig JavaScript-Code): Eine Regel, um auf den Kartenleser zugreifen zu können, und eine weitere Regel, um auf die Karten zugreifen zu können. (Details dazu siehe README.polkit aus dem pcscd-Paket, Link siehe unten). Und ja, man könnte auch alles in eine Datei packen, wenn man möchte.

Zunächst einmal sorgen wir dafür, dass überhaupt der Kartenleser vom Benutzer angesprochen werden kann (USER entsprechend durch Euren Benutzernamen ersetzen):

$ sudo su

# cd /etc/polkit-1/rules.d

# vi pcsc-access-reader.rules

polkit.addRule(function(action, subject) {
    if (action.id == "org.debian.pcsc-lite.access_pcsc" &&
        subject.user == "USER") {
            return polkit.Result.YES;
    }
});

Datei sichern, vi beenden. Neu gestartet werden muss nichts, die Zugriffsregel gilt sofort.

Nun müssen wir herausfinden, welchen Namen der Kartenleser hat, da wir diesen für die weitere Zugriffsregel benötigen. Das geht mittels pcsc_scan (steckt im Paket „pcsc-tools“, notfalls mit „sudo apt install pcsc-tools“ installieren):

$ pcsc_scan 
PC/SC device scanner
V 1.7.1 (c) 2001-2022, Ludovic Rousseau 
Using reader plug'n play mechanism
Scanning present readers...
0: REINER SCT cyberJack RFID standard (234247110815) 00 00
...

Alles was hinter „0: “ steht, benötigen wir nun für die folgende Regel, die den Zugriff auf die Smartcards regelt. Wie oben wechseln wir als root ins Verzeichnis und legen eine neue Regel an. READER muss entsprechend durch den obigen kompletten Namen (inkl. der ganzen Ziffern am Ende), USER wiederum durch den Namen des Benutzers ersetzt werden:

$ sudo su

# cd /etc/polkit-1/rules.d

# vi pcsc-access-card.rules

polkit.addRule(function(action, subject) {
    if (action.id == "org.debian.pcsc-lite.access_card" &&
        action.lookup("reader") == 'READER' &&
        subject.user == "USER") {
            return polkit.Result.YES;
    }
});

Wer auf so viele Details keine Lust hat, kann das alles sicherlich auch mit einer einzigen Regel erledigen, die immer die Erlaubnis erteilt, egal welcher Benutzer gerade welchen Kartenleser verwendet:

$ sudo su

# cd /etc/polkit-1/rules.d

# vi pcsc-allow-all-users-access-all-readers-and-cards.rules

polkit.addRule(function(action, subject) {
    if (action.id == "org.debian.pcsc-lite.access_pcsc") {
       return polkit.Result.YES;
    }
});

polkit.addRule(function(action, subject) {
    if (action.id == "org.debian.pcsc-lite.access_card") {
       return polkit.Result.YES;
    }
});

Links:

Kurztipp: System Policy prevents Wi-Fi scans (Ubuntu 24)

Veröffentlicht amAutordh

Der hier geschilderte Kurztipp funktioniert unter Ubuntu 24 leider nicht mehr, weil – kurz gesagt – sich etwas bei polkit geändert hat. Nachdem ich nun ein dist-upgrade auf Ubuntu 24.04 LTS durchgeführt habe, erhielt ich nach dem Login über RDP spätestens nach einem Klick auf das Netzwerk-Icon in der Taskbar wieder folgende Meldung:

Die Regelsyntax hat sich bei polkit geändert, nun ist eine JavaScript-artige Form an anderer Stelle erforderlich:

$ sudo su

# cd /etc/polkit-1/rules.d/

# vi 51-allow-network-manager-wifi-scan.rules

Nun kopiere man folgende Zeilen hinein, speichere und beende den vi.

polkit.addRule(
   function(action, subject) {
      if (action.id == "org.freedesktop.NetworkManager.wifi.scan"
         // && subject.user == "USERNAME"
      ) {
         return polkit.Result.YES;
      }
   }
);

Hinweis: Diese Regel erlaubt allen Benutzern den Wi-Fi-Scan, da die Zeile mit der Überprüfung des Benutzernamens durch die beiden „//“ auskommentiert ist.

Nach dem Ausloggen und erneuten Einloggen über RDP oder XDMCP sollte die Meldung nicht mehr erscheinen. Falls doch: Reboot tut gut.

Kurztipp: VirtualBox meldet „Can’t find help file“

Veröffentlicht amAutordh

Problem: VirtualBox meldet unter Ubuntu-Linux 22.04.4 „Can’t find help file“.

Ein „strace virtualbox“ liefert

access("/usr/share/doc/virtualbox/UserManual_C.qhc", F_OK) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
access("/usr/share/doc/virtualbox/UserManual.qhc", F_OK) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)

Und in der Tat, unter /usr/share/doc/virtualbox/ liegt nur „UserManual.pdf“ aber nichts mit Endung „qhc“

Es scheint ein Bug zu sein, beim Packaging wurden die benötigten Dateien irgendwie vergessen.

Lösung: Direkt von virtualbox.org das zur Version passende deb-Package herunterladen, die UserManual-Dateien herausfummeln (z.B. mit dem Midnight Commander „mc“) und in /usr/share/doc/virtualbox/ ablegen.

Kurztipp: XFCE über xrdp

Veröffentlicht amAutordh

Neues Notebook mit vorinstalliertem Ubuntu Desktop und nachinstalliertem xubuntu-desktop: Beim Remote-Zugriff über RDP erscheint jedoch nur ein Login ohne Auswahlmöglichkeit des Window-Managers, und in meinem Falle wurde immer der Ubuntu-Desktop gestartet.

Abhilfe: Man erzeuge eine ~/.xsession und schreibe „startxfce4“ hinein.

echo "startxfce4" > ~/.xsession

Nach der nächsten Anmeldung startet dann der XFCE-Desktop.

Siehe auch: Kurztipp: KDE über xrdp

Kurztipp: PDF in JPG umwandeln

Veröffentlicht amAutordh

Um ein PDF in JPG(s) umzuwandeln, braucht es unter Linux nicht viel und lässt sich auch wunderbar für Scripting nutzen:

pdftoppm foo.pdf | convert - bar.jpg

pdftoppm (aus den poppler-utils) wandelt PDF in Portable Pixmap um, liest in dem Beispiel die Datei foo.pdf und schreibt das PPM auf die Standardausgabe.

convert (aus dem ImageMagick-Paket ) liest von der Standardeingabe und wandelt (bei einseitigen PDF) in bar.jpg um, bei mehrseitigen PDF in bar-0.jpg, bar-1.jpg, bar-2.jpg, …

Mittels entsprechender Optionen – und convert kennt dutzende! – kann man natürlich auch gleich Einfluss auf das zu erzeugende JPG nehmen. Hier ein Beispiel, wie man (ein) Vorschaubildchen mit 240 Pixel Breite erzeugen kann:

pdftoppm foo.pdf | convert - -geometry 240 thumb-bar.jpg

Links:

Lazarus, UTF8, Firebird und Default Character Set NONE

Veröffentlicht amAutordh

Ich habe in den letzten Tagen ein wenig mit Lazarus herumgespielt, um damit eventuell (auf Linux) portierbare Frontends für alte, existierende Datenbanken zu bauen. Dabei bin ich über die Problematik gestolpert, dass Lazarus standardmäßig überall mit UTF8 arbeitet, die alten Datenbanken sich aber um Zeichensätze nicht gekümmert haben. Alte Frontends liefen unter Windows irgendwie mit einem Zeichensatz vergleichbar (identisch?) mit ISO Latin 1 (a.k.a ISO 8859-1), der Firebird-Datenbank war es eh egal, was an Zeichen rausgeholt und darin gesichert wurde, kurzum: passte alles. Mit Lazarus/UTF8 und alten Datenbankinhalten in Latin-1 wird alles ein wenig herausfordernder. Aber letztlich ist das alles nichts wirklich Wildes, wenn man weiß, wie es funktioniert.

Man hat drei Möglichkeiten, mit dieser Herausforderung umzugehen:

  1. Für neue Projekte legt man die Datenbank selbst („create database ‚/path/to/db/foobar.fdb‘ default character set UTF8;“) und alle Spalten („foo varchar(42) character set UTF8“) direkt als UTF8 an. Dann muss man im mit Lazarus und den Firebird/Interbase-Datenbankkomponenten gebauten Frontend (so gut wie nichts) beachten.
  2. Ältere Datenbanken konvertiert man komplett mit allen Spalten und allen Inhalten von NONE auf UTF8. Dann hat man wie oben im Frontend auch Ruhe, aber solch eine Konvertierung kann in Arbeit ausarten.
  3. Oder man lässt die alte Datenbank in Ruhe und sorgt im neuen Frontend an den entscheidenden Stellen manuell für eine Zeichensatzumwandlung.

Für den dritten Fall ist Folgendes zu tun (ohne Anspruch auf Vollständigkeit):

  • TIBConnection: Die Datenbankverbindung auf CharSet:= ‚ISO8859_1‘ setzen und mittels UseConnectionCharSetIfNone:= True eine automatische Umwandlung von Datenbankinhalten für die visuellen Datenbankkomponenten aktivieren. In einem DBGrid beispielsweise werden deutsche Umlaute dann richtig dargestellt (stünde das hingegen auf False, dann sähe man nur Fragezeichen statt Umlauten)
  • uses … LConvEncoding
  • Bei jeder TSQLQuery müssen Zeichenketten aus dem Frontend in Richtung Datenbank mittels UTF8ToISO_8859_1() umgewandelt werden. Wer sich SQL-Statements also zusammenbaut und dafür die Inhalte von Eingabefelder verwendet, muss die erst einmal durch die Zeichensatzumwandlung jagen.

Eventuell schreibe ich es demnächst noch ausführlicher auf, aber der geneigte Lazarus-Programmierer sollte vielleicht damit schon auf den richtigen Lösungsweg kommen.

Links:

Kurztipp: no matching host key type found

Veröffentlicht amAutordh

Nach dem Upgrade auf Ubuntu 22.04. scheitert erneut der Zugriff per ssh auf eine VM mit einem Uralt-SCO-Unix, in diesem Falle mit folgender Fehlermeldung:

$ ssh vmsco
Unable to negotiate with 192.168.47.11 port 22: no matching host key type found. Their offer: ssh-rsa,ssh-dss
lost connection

Warum auch immer (bestimmt aus Sicherheitsgründen) übermittelt ssh den id_dsa.pub nicht mehr an den SSH-Server. Abhilfe:

Beim einmaligen Zugriff erweitert man den Aufruf von ssh/scp um eine Option:

$ ssh -oHostKeyAlgorithms=+ssh-dss vmsco

Um die Option dauerhaft zu setzen, packe man diese in die globale SSH-Konfiguration für den Namen und die IP-Adresse des SSH-Servers (die alten Optionen stammen noch aus dem älteren Tipp):

$ sudo vi /etc/ssh/ssh_config.d/vmsco.conf

Host vmsco
  HostKeyAlgorithms +ssh-dss
  KexAlgorithms +diffie-hellman-group1-sha1
  Ciphers +aes128-cbc

Host 192.168.47.11
  HostKeyAlgorithms +ssh-dss
  KexAlgorithms +diffie-hellman-group1-sha1
  Ciphers +aes128-cbc