IT security, FreeBSD, Linux, mail server hardening, post-quantum crypto, DNS, retro computing & hands-on hardware hacks. Privater Tech-Blog seit 2003.

Schlagwort: FOSS (Seite 2 von 3)

NEXT Biometrics NB-2020-U Fingerabdruckleser unter Linux zum Laufen gebracht

In meinem Fujitsu Notebook steckt ein Fingerabdruckleser. Ein NEXT Biometrics NB-2020-U, USB ID 298d:2020. Unter Windows funktioniert er, unter Linux nicht. Kein Treiber, kein Support, nichts. Das Gerät taucht in lsusb auf, wird aber von keinem Treiber erkannt. Im libfprint Wiki steht es auf der Liste der nicht unterstützten Geräte. Dort steht es schon eine Weile.

Das hat mich gestört.

Picture of NB-2020-U

libfprint kennt den NB-1010-U. Das ist ein externer USB Fingerabdruckleser von NEXT Biometrics, der seit einiger Zeit einen funktionierenden Treiber hat. Der NB-2020-U ist die eingebettete Variante desselben Sensors, gedacht für den Einbau in Notebooks. Wenn man sich Teardown Reports ansieht, etwa von System Plus Consulting oder Yole Group, dann stellt man fest: Beide Geräte verwenden den identischen Sensor Die. Gleiche Technik, anderes Gehäuse.

Das war der erste Anhaltspunkt. Wenn die Hardware gleich ist, sollte auch das USB Protokoll gleich sein. Und wenn das Protokoll gleich ist, sollte der vorhandene Treiber funktionieren.

Bevor ich aber einfach auf Verdacht losprogrammiert habe, wollte ich es absichern. Ich habe NEXT Biometrics direkt angeschrieben. Kevin Hung, Director FAE bei NEXT Biometrics, hatte mir bereits 2022 auf eine Anfrage zu Linux Treibern geantwortet. Damals war sein Vorschlag, über Fujitsu zu gehen. Das führte ins Leere. Diesmal habe ich konkret angeboten, selbst einen libfprint Treiber zu schreiben, und um das SDK gebeten.

Kevin hat mir daraufhin das NBBiometrics ANF SDK 3.0.0.1384 zugeschickt. Ein komplettes SDK mit Headern, Bibliotheken, Beispielcode und Dokumentation. Das war sehr hilfreich, denn die Header bestätigen einiges. Das SDK nutzt eine einzige Shared Library libNBBiometrics.so für alle Gerätetypen. Der NB-1010-U hat den internen Gerätetyp 200, der NB-2020-U den Typ 202. Beide verwenden dasselbe Scanformat: 180×256 Pixel bei 385 DPI. Die USB Vendor ID ist bei beiden 0x298d, nur die Product ID unterscheidet sich: 0x1010 beim einen, 0x2020 beim anderen.

Wichtig: Das SDK ist proprietär. Für den eigentlichen Treiber habe ich keinen Code daraus verwendet. libfprint akzeptiert nur sauberen, eigenständig entwickelten Code. Das SDK diente ausschließlich als Referenz, um die Protokollkompatibilität zu bestätigen.

Also habe ich es einfach ausprobiert. Den bestehenden nb1010.c Treiber genommen, die USB Product ID 0x2020 zur id_table hinzugefügt und gebaut. Dann auf dem Fujitsu Notebook getestet.

Es funktionierte sofort.

Geräteerkennung, USB Interface Claim, die State Machine für die Fingererkennung, alles lief auf Anhieb. fprintd-enroll hat Fingerabdrücke aufgenommen, fprintd-verify hat sie korrekt verifiziert. Der bestehende Treibercode brauchte keinerlei Anpassungen. Null. Nur die PID in der Tabelle und den Gerätenamen.

Ein Blick auf die USB Deskriptoren bestätigt das Bild. Der NB-2020-U hat exakt dasselbe Endpoint Layout wie der NB-1010-U: Bulk OUT auf Endpoint 0x02, Bulk IN auf Endpoint 0x83. Dazu kommt ein Interrupt Endpoint auf 0x81, den der Treiber nicht verwendet. Die Kommunikation läuft identisch ab.

Der Patch selbst ist entsprechend klein. Drei Dateien, drei Zeilen rein, drei Zeilen raus:

  1. libfprint/drivers/nb1010.c: Die neue PID 0x2020 wird in die id_table eingetragen und der full_name auf "NextBiometrics NB-1010-U/NB-2020-U" erweitert.
  2. data/autosuspend.hwdb: Der Eintrag 298d:2020 wird von der Liste der nicht unterstützten Geräte in die Sektion des nb1010 Treibers verschoben.
  3. libfprint/fprint-list-udev-hwdb.c: Der Eintrag wird aus der Allowlist der nicht unterstützten Geräte entfernt, da er jetzt vom Treiber abgedeckt wird.

Den Merge Request habe ich bei libfprint upstream eingereicht: MR !569. Die CI Pipeline läuft durch, alle 124 Tests bestehen. Jetzt heißt es warten auf das Review durch die Maintainer.

Für alle, die denselben Fingerabdruckleser in ihrem Notebook haben: Sobald der Patch gemergt und in einer neuen libfprint Version enthalten ist, funktioniert der Sensor out of the box. Enrollment und Verifikation über fprintd laufen sauber. Wer nicht warten möchte, kann den Patch auch jetzt schon selbst auf ein aktuelles libfprint anwenden.

Im selben Fujitsu Notebook meiner Tochter steckt ein NB-2033-U, ein weiterer Fingerabdruckleser aus der gleichen Familie. Der verwendet allerdings ein komplett anderes Protokoll und ließ sich nicht einfach mit dem nb1010 Treiber ansprechen. Den habe ich per Reverse Engineering geknackt.

Von SEO zu AEO: Warum llms.txt, JSON-LD und Answer Engines das Web verändern

In den letzten Jahren war SEO, also Search Engine Optimization, für viele Webseitenbetreiber unglaublich wichtig. Man möchte schließlich, dass Suchmaschinen wie Google, Bing oder Yahoo Besucher auf die eigene Webseite bringen. Dafür will man möglichst weit oben in den Suchergebnissen auftauchen. Hat man viele Besucher, kann man Produkte besser verkaufen, Werbeflächen teurer anbieten oder mehr Dienstleistungen absetzen. Das ist nicht neu.

Schematische Darstellung des Übergangs von Suchmaschinen-SEO zu AI-basierten Answer Engines mit llms.txt und JSON-LD.

Manche erinnern sich vielleicht noch an die Gelben Seiten. Dort standen bestimmte Unternehmen in ihrer Branche ganz oben – nicht, weil sie besonders gut waren, sondern weil das Verzeichnis alphabetisch sortiert war. Wer mit „AAA“ anfing, war automatisch sichtbar. SEO ist im Grunde nichts anderes, nur technisch komplexer.

Über die Jahre ist SEO damit Stück für Stück zu einem eigenen Geschäftsfeld geworden. Ganze Agenturen leben davon, Suchmaschinen zufriedenzustellen. Diese Logik gerät gerade ins Wanken. AI verändert das Spiel spürbar.

Jeder von uns hat vermutlich schon bemerkt, dass bei vielen Suchmaschinen inzwischen zuerst eine AI-Antwort erscheint. Viele Fragen werden gar nicht mehr klassisch „gesucht“, sondern direkt in ein LLM – ein Large Language Model – eingegeben. Fragen wie:
„Wer war Bundespräsident in Deutschland zur Wiedervereinigung?“ oder
„Bester Gebrauchtwagenhändler in der Nähe von Bonn?“
werden sofort beantwortet.

Online-Suche entwickelt sich immer mehr zu einer Frage-Antwort-Interaktion mit einer AI. Es kommt damit weniger darauf an, ob man der Google First Hit ist, sondern darauf, ob man aus Sicht der AI die beste Antwort liefert.

Und genau hier verschiebt sich der Fokus.

Damit eine AI eine passende Antwort geben kann, muss der Inhalt maschinenverständlich aufbereitet sein. Lange, erklärende Fließtexte – wie dieser hier – sind dafür eher ungeeignet. Für AIs funktionieren klar strukturierte Informationen deutlich besser. FAQ-Formate, Frage-Antwort-Paare, saubere Metadaten.

Dinge wie JSON-LD bringen Struktur hinein. Autoren, Inhalte, Organisationen und Beziehungen lassen sich eindeutig beschreiben und verknüpfen. Dazu kommen neue Konzepte wie llms.txt oder llms-full.txt. Diese Dateien enthalten keinen SEO-Text, sondern eher eine Art Bedienungsanleitung für Maschinen:
Was ist diese Webseite?
Wie ist sie aufgebaut?
Welche Inhalte sind relevant?
Was darf genutzt werden – und was nicht?

Zusammen mit strukturierten Daten bildet das eine solide Basis, damit AI-Systeme Webseiten einordnen, bewerten und korrekt referenzieren können.

Nun ein kurzer, aber wichtiger Exkurs.

AIs müssen trainiert werden. Dieses Training passiert auf großen Datensätzen, den sogenannten Trainingsdaten. Wird eine AI neu trainiert, greift sie oft wieder auf das gleiche Datenmaterial zurück. Das ist nicht zwangsläufig aktuell.

Fragt einfach einmal eure AI des Vertrauens, von wann ihre Trainingsdaten stammen. Die freie Version von ChatGPT sagt mir aktuell, dass sie auf Daten bis Oktober 2024 basiert. Das bedeutet ganz grob: Alles danach ist unbekannt.

Fragt man also, wer aktuell Bundeskanzler von Deutschland ist, bekommt man Olaf Scholz als Antwort. Gleichzeitig „weiß“ die AI aber, dass wir inzwischen 2026 haben und dass sich theoretisch etwas geändert haben könnte. Ohne Zugriff auf aktuelle Informationen bleibt sie trotzdem bei dem alten Stand.

Freie Modelle können meist keine Live-Recherche durchführen. Bezahlte Modelle hingegen kombinieren ihr gelerntes Wissen zunehmend mit eigenen Online-Suchen. Sie gleichen Informationen ab, aktualisieren und korrigieren.

Das klingt logisch – ist aber teuer.
Online-Recherche kostet Zeit, Rechenleistung und Geld. Genau deshalb findet man solche Funktionen fast ausschließlich in kostenpflichtigen Angeboten. Betreiber müssen ständig den Sweet Spot zwischen Antwortqualität, Antwortzeit und Gewinnmaximierung finden.

Und genau hier wird es interessant.

Wenn eine AI Informationen bereits strukturiert kennt, wenn Beziehungen und Metadaten schon im Trainingsmaterial vorhanden sind, muss sie deutlich weniger nachrecherchieren. Inhalte lassen sich schneller bewerten, aktualisieren und in Antworten einbauen.

An dieser Stelle kommen wir zu AEO – Answer Engine Optimization.

AEO ist im Grunde die Weiterentwicklung von SEO für AI-basierte Antwortsysteme. Statt Suchmaschinen zu optimieren, optimiert man Inhalte für Antwortmaschinen. In diesem Zusammenhang wird seit etwa zwei Jahren verstärkt über llms.txt und llms-full.txt gesprochen.

Diese Dateien sind nicht für Menschen gedacht. Sie sind nicht für Suchmaschinen optimiert und sollen auch nicht schön sein. Sie sind rein maschinell. Zusammen mit JSON-LD liefern sie AI-Systemen genau das, was sie brauchen: Struktur, Kontext, Beziehungen und Einordnung.

Ein wichtiger Punkt dabei: llms.txt ersetzt keine Inhalte. Sie erklärt sie.

Wo liegen diese Dateien nun?

Ganz pragmatisch:
Im Root der Webseite.

Also zum Beispiel:

Alternativ – technisch ebenfalls sauber – unter:

  • /.well-known/llms.txt

Beides funktioniert. Wichtig ist nur, dass der Pfad stabil, öffentlich erreichbar und nicht blockiert ist.

Zusätzlich kann man diese Dateien auch extern bekannt machen. Es gibt inzwischen erste Verzeichnisse und Hubs, die solche Dateien sammeln und auffindbar machen. Dort geht es weniger um Ranking, sondern um Auffindbarkeit für Systeme, die gezielt nach strukturierten Quellen suchen.

Ob das langfristig relevant bleibt, weiß niemand. Aber auch hier gilt: Sichtbarkeit schadet nicht.

Eine weitere Frage taucht fast immer auf:
Kann man llms.txt über die robots.txt einbinden?

Kurzfassung: Ja – aber nicht als Zwang, sondern als Hinweis.

Die robots.txt ist historisch für Crawler gedacht. Sie regelt Zugriffe, nicht Metadaten. Trotzdem hat sie sich über die Jahre zu einer Art maschineller Einstiegspunkt entwickelt. Dinge wie Sitemap: waren auch einmal nur Konvention.

Ein Beispiel:

User-agent: *
Allow: /

Sitemap: https://www.example.org/sitemap.xml
LLMS: https://www.example.org/llms.txt
LLMS-Full: https://www.example.org/llms-full.txt

Diese Direktiven sind kein Standard. Google ignoriert sie. Bing vermutlich auch. Aber experimentelle Crawler, AI-Agenten oder eigene Indexer können sie sehr einfach auswerten.

Oh, und genau das erinnert mich an frühere Zeiten.
Interne Crawler, Security-Scanner, selbstgeschriebene Discovery-Tools – all das begann oft mit nicht standardisierten Hinweisen. Erst ignoriert, später übernommen, irgendwann vielleicht formalisiert. Oder auch nicht. Das Internet ist in dieser Hinsicht erstaunlich pragmatisch.

Wichtig ist nur, realistisch zu bleiben:

  • robots.txt ist keine Zugriffskontrolle
  • sie garantiert keine Nutzung durch eine AI
  • sie ersetzt nicht die Datei im Root

Aber sie ist ein zusätzliches, maschinenlesbares Signal – und kostet praktisch nichts.

Wenn man das alles zusammennimmt, zeichnet sich ein klares Bild ab. Werbung wandert langsam von Webseiten in LLM-Chats. Webseiten entwickeln sich weg von langen Erklärungstexten hin zu strukturierten Wissensbausteinen. SEO rückt in den Hintergrund. Klassische Blogs – auch dieser hier – werden langfristig seltener werden.

Ist das schlimm?
Nein.

Es ist einfach der nächste logische Schritt. Als ich angefangen habe, gab es BTX, Usenet, Foren und Chatrooms. Das meiste davon ist verschwunden. Für viele Menschen besteht das Internet heute aus YouTube, Instagram, Meta, X oder TikTok – zentralisierte, leicht konsumierbare Dienste einzelner Unternehmen.

So weit, dass man sich bei manchen Diensten nicht einmal mehr mit einer „nicht Google“-E-Mail-Adresse registrieren kann. DeepSeek ist ein Beispiel. Die McDonald’s-App ein anderes.

Veränderung an sich ist nichts Schlechtes.
Neu ist nur die Geschwindigkeit. Schaut man 100 Jahre zurück und betrachtet, was in welchen Zeiträumen passiert ist, wird schnell klar: In den letzten 20 Jahren ist in der IT unfassbar viel passiert. Und es wird nicht langsamer.

Wenn ihr euch also das nächste Mal mit einer Agentur über euren Webauftritt unterhaltet und jemand von SEO spricht, fragt ruhig nach einer llms.txt. Oder werft den Begriff AEO in den Raum.

Ich bin gespannt, was passiert.

Ist mein Netzwerk kompromittiert? Warum das kaum jemand merkt

Ich habe ja bereits etwas zum Thema IoT-Geräte geschrieben und warum diese oft deutlich schneller gehijackt werden, als man vielleicht erwartet.

Aber woher weiß man nun als normaler Anwender, ob zu Hause oder im eigenen Netzwerk etwas sein Unwesen treibt?
Nun ja; das ist leider überhaupt nicht so einfach.

Symbolische Darstellung eines kompromittierten Netzwerks mit Warnhinweisen, IoT-Kamera und verdächtigem Datenverkehr.

Klar, man kann sich ganz tolle IPS oder IDS aufbauen. Es gibt dafür auch Open-Source-Systeme; Snort fällt mir da als einer der älteren Vertreter als erstes ein.

Aber das alles ist nichts für den normalen Anwender oder den Privathaushalt. Dann gibt es noch ganz furchtbar viele Schlangenölanbieter mit ihrer „Sicherheitssoftware“ für Windows, Android und Co. Klar, man kann dort Firewall, Virenscanner usw. installieren. Aber hilft das wirklich? Jein, würde ich dazu sagen.

Ist man auf einem aktuellen Patchstand, sollten zumindest die bekannten Löcher geschlossen sein. Dann bleiben fast nur noch Zero-Day-Lücken Ein Virenfilter kennt diese in der Regel auch nicht und lässt so etwas dann schlicht durch.

Eine Firewall-Lösung kann zumindest erkennen, ob plötzlich ungewöhnlicher Traffic unterwegs ist oder ob versehentlich gestartete Dienste nach außen offen stehen. Nur steht und fällt das Ganze oft genau in dem Moment, in dem der Anwender nach einer Entscheidung gefragt wird.

Sicherheitssoftware muss naturgemäß sehr tief im Betriebssystem eingebettet werden. Hat diese Sicherheitssoftware dann selbst Sicherheitslücken, was deutlich häufiger vorkommt, als man zunächst glauben möchte, öffnet man im Zweifel die eigene Infrastruktur über genau die Software, die das eigentlich verhindern soll. Vertraut mir da bitte einfach, wenn ich sage, dass ich das schon sehr oft gesehen habe. Zudem installiert sich so eine Sicherheitssoftware oft nicht einfach auf einer Netzwerkkamera.

Der beste Schutz sind, meiner Meinung nach, noch immer gepflegte Systeme, gute Zugangsdaten und das nötige Misstrauen. Wie kam ich jetzt darauf? Ach richtig; wie findet man eigentlich heraus, ob es überhaupt ein Problem gibt?

Klar, man kann abwarten. Irgendwann merkt man es sicher; spätestens dann, wenn die Polizei mit einer Hausdurchsuchung vor der Tür steht und wissen möchte, was man denn da so alles im Internet verteilt oder angreift.

Eine wirklich gute Lösung habe ich da leider auch nicht. Am ehesten noch Dienste wie GreyNoise (https://check.labs.greynoise.io/). Dort kann man beispielsweise gegen AbuseDB prüfen, ob die eigene IPv4-Adresse irgendwo im Internet „auffällig“ geworden ist; etwa durch Portscans, Spam-Versand oder Malware-Traffic. Ebenfalls kann man hin und wieder bei Have I Been Pwned (https://haveibeenpwned.com/) vorbei schauen, um zu prüfen, ob die eignen Zugangsdaten irgendwo gefunden wurden.

Im Allgemeinen ist aber auch das nur ein Indiz. IP-Adressen wechseln; vor allem bei privaten Anschlüssen. Die eigene IP muss erst auffallen, gemeldet werden und so weiter.

Aber hey; vielleicht hat ja noch jemand einen besseren Tipp?

Fragen? Einfach melden.

Google Chrome: Hardwarebeschleunigung unter Linux (auch Flatpak) aktivieren

Wer Chrome unter Linux für Videocalls oder Microsoft Teams nutzt, kennt das Problem: hohe CPU-Auslastung, träge Performance, unscharfer Hintergrund fühlt sich an als wäre das System 15 Jahre alt. Ob Chrome aus den Paketquellen oder als Flatpak installiert ist, macht keinen Unterschied.

Die Ursache: Chrome nutzt unter Linux standardmäßig kaum GPU-Beschleunigung. Das lässt sich ändern.

Voraussetzung: VA-API prüfen

Zuerst sicherstellen, dass vainfo in der Konsole ohne Fehler läuft. Die meisten Distributionen bringen das out of the box mit. Falls nicht, gibt es im Arch Wiki gute Anleitungen dazu.

Aktuellen Status prüfen

In Chrome chrome://gpu aufrufen. Typischerweise sind Video Encode, Vulkan und WebGPU deaktiviert. Nach der Anpassung sieht es so aus:

  • Rasterization: Hardware accelerated on all pages (vorher: nur „Hardware accelerated“)
  • Video Encode: Hardware accelerated (vorher: Software only)
  • Vulkan: Enabled (vorher: Disabled)
  • WebGPU: Hardware accelerated (vorher: Disabled)

Konfiguration

Die Flags kommen in eine Konfigurationsdatei:

  • Chrome/Chromium aus Paketquellen: ~/.config/chromium-flags.conf
  • Chrome als Flatpak: ~/.var/app/com.google.Chrome/config/chrome-flags.conf
--ignore-gpu-blocklist
--enable-zero-copy
--enable-gpu-rasterization
--enable-gpu-compositing
--enable-smooth-scrolling
--canvas-oop-rasterization
--disable-direct-composition-bug-workarounds
--enable-unsafe-webgpu
--enable-features=VaapiVideoDecoder,VaapiVideoEncoder,VaapiIgnoreDriverChecks,Vulkan,DefaultANGLEVulkan,VulkanFromANGLE,UseOzonePlatform
--ozone-platform=x11

Chrome neu starten und chrome://gpu erneut prüfen.

Tipp für Flatpak-Nutzer: Flatseal macht die allgemeine Konfiguration von Flatpaks deutlich bequemer.

Fragen? Einfach melden.

Firmware- und BIOS-Updates unter Linux einfach mit fwupd durchführen

fwupd-Logo — das Open-Source-Tool fuer Firmware-Updates unter Linux.

Firmware- und BIOS-Updates waren unter Linux lange eine Qual. Hersteller lieferten ihre Tools nur für DOS oder Windows. Wer ein Update wollte, musste eine Platte ausbauen, Windows installieren, Treiber suchen, Herstellertool laden — für ein Update. So macht das keinen Spaß.

fwupd hat das grundlegend geändert. Ein paar GNOME-Entwickler haben zusammen mit Dell ein einheitliches Update-Framework gebaut. Hersteller müssen sich nicht mehr um Installer und Betriebssystem-Support kümmern — sie stellen ihre Firmware-Images in einem zentralen Repository (LVFS) bereit, und fwupd verteilt sie.

Was kann fwupd?

fwupd aktualisiert BIOS/UEFI, Thunderbolt-Controller, NVMe-Firmware, Intel ME, Netzwerkkarten, Logitech-Empfänger und vieles mehr. Über 1.000 Geräte werden unterstützt. Es läuft als Daemon im Hintergrund, prüft täglich auf neue Updates und kann sie automatisch installieren oder ankündigen. Gnome und KDE bringen grafische Frontends mit, auf der Kommandozeile geht es genauso einfach.

Geräte prüfen

Testgerät: ein Lenovo ThinkPad X1 Carbon. fwupdmgr get-devices zeigt, welche Hardware erkannt und unterstützt wird:

root@errorlap:~# fwupdmgr get-devices
20N588101
│
├─Thunderbolt Controller:
│     Current version:     20.00
│     Vendor:              Lenovo (TBT:0x0109)
│     Device Flags:        • Internal device
│                          • Updatable
│                          • Requires AC power
│                          • Device stages updates
│
├─SAMSUNG MZVLB256HB88-000L7:
│     Summary:             NVM Express Solid State Drive
│     Current version:     4M2QEXH7
│     Vendor:              Samsung Electronics Co Ltd
│     Device Flags:        • Internal device
│                          • Updatable
│
├─System Firmware:
│     Current version:     0.1.65
│     Vendor:              LENOVO
│     Device Flags:        • Updatable
│                          • Needs a reboot after installation
│                          • Cryptographic hash verification is available
│
└─UEFI Device Firmware (3×):
      Current version:     192.64.1551 / 0.1.19 / 1.1.8
      Device Flags:        • Updatable
                           • Needs a reboot after installation

Bei diesem Gerät werden Thunderbolt-Controller, NVMe-SSD, System-Firmware und drei UEFI-Komponenten erkannt. Die Device Flags zeigen Voraussetzungen — zum Beispiel „Requires AC power“ (Netzteil anschließen) und „Needs a reboot“ (Neustart nach dem Update).

Updates suchen und installieren

Zuerst den Firmware-Katalog aktualisieren — fwupd merkt auch selbst, wenn der Datenstand zu alt ist, und bietet das automatisch an:

root@errorlap:~# fwupdmgr refresh --force
Fetching metadata https://cdn.fwupd.org/downloads/firmware.xml.gz
Downloading…             [***************************************]
Successfully downloaded new metadata: 5 local devices supported

Dann fwupdmgr get-updates — hier gab es Updates für die System-Firmware (0.1.65 → 0.1.70, fünf BIOS-Versionen mit Security-Fixes und Bugfixes) und die Intel ME (192.64.1551 → 192.71.1681, unter anderem 16 CVEs). Die Changelogs kommen direkt vom Hersteller über LVFS.

Installation mit fwupdmgr update:

root@errorlap:~# fwupdmgr update
Upgrade available for UEFI Device Firmware from 192.64.1551 to 192.71.1681
20N588101 must remain plugged into a power source for the duration
of the update to avoid damage. Continue with update? [Y|n]: y
Downloading 192.71.1681 for UEFI Device Firmware...
Decompressing…           [***************************************]
Authenticating…          [***************************************]
Updating UEFI Device Firmware…
Scheduling…              [***************************************]
Successfully installed firmware

An update requires a reboot to complete. Restart now? [y|N]:

Beim Neustart übernimmt das UEFI — man sieht den Fortschritt auf dem Bildschirm (Fotos unten). Danach die Kontrolle:

root@errorlap:~# fwupdmgr get-updates
Devices that have been updated successfully:
 • System Firmware (0.1.65 → 0.1.70)
 • UEFI Device Firmware (192.64.1551 → 192.71.1681)

Sauber. Beide Updates eingespielt, keine Fehler. fwupd fragt am Ende noch, ob man einen anonymen Report hochladen möchte — das hilft den Herstellern, erfolgreiche und fehlgeschlagene Updates auf realer Hardware zu erkennen.

Was man wissen sollte

fwupd nutzt für BIOS-Updates den UEFI Capsule Update-Mechanismus. Das Firmware-Image wird in die EFI System Partition geschrieben, beim nächsten Boot übernimmt das UEFI die Installation. Dafür braucht das Gerät eine EFI System Partition und ein UEFI, das Capsule Updates unterstützt. Ältere BIOS-only-Systeme oder Hersteller ohne LVFS-Unterstützung fallen raus.

Es steht und fällt mit den Herstellern. Lenovo, Dell, HP und Intel sind gut dabei. Wenn euer Gerät nicht unterstützt wird — kurze Mail an den Hersteller-Support, warum sie nicht mit LVFS zusammenarbeiten. Jede Anfrage hilft.

Für FreeBSD-Nutzer: fwupd wurde 2021 auf der FOSDEM als BSD-Port vorgestellt und läuft mittlerweile auch auf FreeBSD. Die Abdeckung ist noch geringer als unter Linux, aber die Basis steht.

Wer noch Fragen hat — schreibt mir.

Siehe auch:

Bluetooth-Audio unter FreeBSD und GhostBSD: Workaround mit Creative BT-W2

Bluetooth-Audio und FreeBSD vertragen sich nicht. Der Bluetooth-Stack wird nicht mehr gepflegt, in OpenBSD wurde er komplett entfernt. Einen Bluetooth-Dongle oder eine eingebaute Bluetooth-Karte dazu zu bringen, sich mit einem Audio-Gerät zu verbinden, funktioniert unter FreeBSD praktisch nicht.

Der Workaround: Creative BT-W2

Die Lösung ist ein USB-Dongle, der sich selbst um Bluetooth kümmert: Der Creative BT-W2. Das Gerät meldet sich am Betriebssystem als normale USB-Soundkarte. Das Pairing mit dem Bluetooth-Kopfhörer oder -Lautsprecher macht der Dongle selbständig per Knopfdruck. FreeBSD sieht nur eine Soundkarte, kein Bluetooth.

Das Kernelmodul snd_uaudio kümmert sich um die Erkennung. In der /etc/rc.conf:

kld_list="snd_uaudio"

Nach dem Laden des Moduls erscheint das Gerät im dmesg:

uaudio0:  on usbus0
uaudio0: Play: 48000 Hz, 2 ch, 16-bit S-LE PCM format, 2x8ms buffer.
uaudio0: Record: 48000 Hz, 1 ch, 16-bit S-LE PCM format, 2x8ms buffer.
pcm5:  on uaudio0
uaudio0: HID volume keys found.

Pairing und Nutzung

Kurz den Knopf am Dongle drücken, er blinkt und verbindet sich mit dem nächsten Bluetooth-Audio-Gerät in Reichweite. Kopfhörer, Headsets, Lautsprecher und Mikrofone funktionieren. Die Qualität reicht auch für Telefonie, Latenz und Codec sind in Ordnung.

Das Audio-Device ist je nach Systemkonfiguration /dev/dsp5 oder ein anderer Index. Mit cat /dev/sndstat lässt sich prüfen welches Device der BT-W2 bekommen hat.

Nicht die eleganteste Lösung, aber sie funktioniert zuverlässig. Solange der Bluetooth-Stack auf FreeBSD nicht wiederbelebt wird, ist ein Dongle wie der BT-W2 der pragmatischste Weg.

Siehe auch: FreeBSD auf dem Desktop, GhostBSD und FreeBSD: GNOME-Keyring automatisch entsperren, GhostBSD 19.09 Ports benutzen

Fragen? Einfach melden.

GhostBSD 19.09 Ports benutzen

Veraltet: GhostBSD 19.09 ist stark veraltet. Aktuelle GhostBSD-Versionen nutzen pkg statt Ports. Siehe ghostbsd.org für die aktuelle Version.

GhostBSD basierte früher direkt auf FreeBSD. Inzwischen ist es aber auf TrueOS gewechselt. So sieht es ebenfalls mit den Ports aus. Man kann also nicht wie unter FreeBSD gewohnt mit portsnap arbeiten sondern muss einen gewissen „Umweg“ nehmen.

Die zu GhostBSD gehörenden Ports bekommt man nun so ins System:

sudo git clone https://github.com/ghostbsd/ghostbsd-ports.git /usr/ports

In GhostBSD Version 19.09 ist etwas Ordnung geschaffen worden und viele vermeintlich unnötige Pakete mussten weichen. Zum arbeiten mit den Ports benötigt man daher noch folgendes:

pkg install src os-generic-userland-devtools

Ab jetzt kann man wie gewohnt mit den Ports arbeiten!

Siehe auch: GhostBSD und FreeBSD: GNOME-Keyring automatisch entsperren, Bluetooth-Audio unter FreeBSD und GhostBSD: Workaround mit Creative BT-W2

Fragen? Einfach melden.

GhostBSD und FreeBSD: GNOME-Keyring automatisch entsperren

Ich nutze auf meinen Desktops GhostBSD und FreeBSD Systeme zusammen mit Mate und LightDM. Ebenfalls verwende ich für ein paar Kleinigkeiten den gnome-keyring. Dabei „stört“ es mich diesen nach der Anmeldung am Desktop gesondert entsperren zu müssen. Es gibt aber eine Möglichkeit dieses von pam nach der Anmeldung automatisch entsperren zu lassen. Dafür müssen nur folgende Zeilen in der /usr/local/etc/pam.d/lightdm ergänzt werden:
auth        optional    pam_gnome_keyring.so
session        optional        pam_gnome_keyring.so    auto_start

Meine sieht nun also wie folgt aus:

#
# PAM configuration for the "lightdm" service
#

# auth
auth		sufficient	pam_self.so		no_warn
auth		include		system
auth		optional	pam_gnome_keyring.so

# account
account		requisite	pam_securetty.so
account		required	pam_nologin.so
account		include		system

# session
session		include		system
session		optional	pam_gnome_keyring.so	auto_start

# password
password	include		system

Nach dem nächsten Login habe ich nun die Möglichkeit, beim Entsperren des Keyrings, einen Haken zu setzten und schon wird bei jedem Login mein Keyring automatisch geöffnet.

Siehe auch: FreeBSD Desktop mit MATE, GhostBSD 19.09 Ports benutzen, Bluetooth-Audio unter FreeBSD und GhostBSD: Workaround mit Creative BT-W2

Fragen? Einfach melden.

Matrix Server Synapse: Erste Stable-Version 1 erschienen

Es hat einige Zeit gedauert aber gestern ist Synapse in Version 1.0.0 erschienen.

https://matrix.org/blog/2019/06/11/introducing-matrix-1-0-and-the-matrix-org-foundation
https://matrix.org/blog/2019/06/11/synapse-1-0-0-released
https://github.com/matrix-org/synapse/releases/tag/v1.0.0

Eine ganz wichtige Änderung der Version ist, dass Zertifikate anderer Server ab jetzt gültig sein müssen.

Wer seinen Server mittels pip auf den letzten Stand bringen möchte:

$ pip install --upgrade matrix-synapse

„Meldet“ euch doch mal wenn es klappt 🙂

Fragen? Einfach melden.

Postfix MTA-STS Resolver für FreeBSD mit Logfile einrichten

Ich habe heute auch mal den postfix-mta-sts-resolver auf meinem privaten System zugeschaltet. Einfach um es mal zu „probieren“.

Tut einfach und wie beschrieben, ist so aber sicher nicht für größeren und produktiven Betrieb gedacht. So wie der resolver kommt schreibt er alle Meldungen leider nur in die Konsole, es gibt keinen File-Logger. Ich ähm will/brauch den aber!

Also habe ich einen Fork erstellt und ihn überredet in eine Datei zu loggen und direkt noch ein sehr rudimentäres rc.d init script beigelegt: https://github.com/Kernel-Error/postfix-mta-sts-resolver

Wer es also ebenfalls mal probieren möchte, viel Spaß.

Der mta-sts-daemon loggt nun per default in /var/log/mta-sts.log. Config über yml ist ebenfalls nun drin genau wie die Konfiguration per Startparameter. Das rc.d script für FreeBSD könnte sicher schöner sein und hätte gerne im default den Benutzer mta-sts im System. Wir wollen es ja nicht als Root laufen lassen, hm?

Das einzelne Programm mta-sts-query greift auf den gleichen Logger zu, gibt damit also nichts mehr in der Konsole aus sondern auch im Logfile. Vielleicht passe ich dieses noch an, wenn dann mache ich auch einen pull request. Sonst gehe ich mal davon aus, dass es eh bald im postifx ist *daumen-drück*


Update

Habe ich jetzt gemacht. Pullrequest wurde angenommen und das neue Release ist auch schon gemacht. Jetzt also mit Logfile und rc.d script für FreeBSD.

Fragen? Dann fragen.

Siehe auch: MTA-STS einrichten

Fragen? Einfach melden.

« Ältere Beiträge Neuere Beiträge »

© 2026 -=Kernel-Error=-RSS

Theme von Anders NorénHoch ↑