bisko.be - Dev

Ollama mit älteren GPUs unter CachyOS betreiben

Sat, 28 Feb 2026 00:00:00 GMT

TL;DR;

ollama-cuda unterstützt unter CachyOS (zum jetzigen Zeitpunkt) nur compute >= 7.5.

Wenn du ältere GPUs mit niedrigerem compute hast, MUSST du eines von 2 Dingen tun:

ollama-cuda aus dem Quellcode bauen, mit Unterstützung für die älteren Compute-Targets
ollama-vulkan installieren

Ich habe mich für ollama-vulkan entschieden und es läuft einwandfrei!

Storytime

Heute kam mir die Eingebung, endlich meine Windows-11-VM abzuschalten und auf Linux zu migrieren.

Die Anforderungen waren, dass Folgendes laufen muss:

Ollama – für lokale Modell-Magie
Docker – für Remote-Entwicklung
Steam – zum Zocken
Jellyfin – für das Heimvideo-Archiv

Ich konzentriere mich jetzt nur auf Ollama, denn es war eine interessante Erfahrung und hat mich zum Nachdenken gebracht, warum die Dinge nicht offensichtlicher sind.

In der Maschine stecken 2 GPUs:

GTX 1070 – 8 GB
GTX 970 – 4 GB

Ich wollte Ollama darauf laufen lassen, um mit lokalen Modellen herumzuspielen und zu schauen, wie ich sie in ein paar Projekte integrieren könnte. Zum Beispiel: Daten lokal anonymisieren, eine nicht-destruktive OpenClaw-Implementierung bauen, die zu meinen Anwendungsfällen passt, lokale OCR für Dokumente, die ich mit dem Handy scanne, und einige Dinge im Alltag der Haushaltsverwaltung automatisieren.

Also habe ich ganz selbstverständlich ollama und ollama-cuda installiert, da ich 2 Nvidia-GPUs drin habe, und erwartet, dass das problemlos funktioniert, schließlich lief es unter Windows ja noch ein paar Minuten zuvor.

Ich habe Ollama gestartet, qwen3:8b für ein schnelles Experiment geladen und… es lief auf der CPU 🤔

Die GPUs wären völlig in der Lage gewesen, das Modell im VRAM zu halten, aber aus irgendeinem Grund entschied sich Ollama, es auf der CPU laufen zu lassen.

Nachdem ich versucht hatte, es anhand der Logs herauszufinden, habe ich Claude um Hilfe gebeten, und der kam mit einem ziemlich entmutigenden Ergebnis um die Ecke:

The logs tell the story clearly. Both your GPUs are detected but then filtered out because they fail CUDA initialization:

  "filtering device which didn't fully initialize" id=GPU-eb132a13-b9f4-40e3-d85d-60f211dfd21e ... library=CUDA
  "filtering device which didn't fully initialize" id=GPU-550263c8-37e2-2a25-c0b6-10cc7511ed20 ... library=CUDA

  The reason is the CUDA library bundled with Ollama 0.17.4 was compiled for these architectures only:

  CUDA.0.ARCHS=750,800,860,870,880,890,900,1000,1030,1100,1200,1210

  The minimum supported compute capability is 7.5 (Turing / RTX 20xx series). Your GPUs are older than that:

  ┌──────────┬────────────────────┬──────────────┐
  │   GPU    │ Compute Capability │ Architecture │
  ├──────────┼────────────────────┼──────────────┤
  │ GTX 1070 │ 6.1                │ Pascal       │
  ├──────────┼────────────────────┼──────────────┤
  │ GTX 970  │ 5.2                │ Maxwell      │
  └──────────┴────────────────────┴──────────────┘

  Neither is in the supported list, so CUDA initialization fails for both, and Ollama falls back to CPU-only inference.

  Your options:

  1. Downgrade Ollama to an older version that still included Pascal/Maxwell support (pre-0.6.x era had broader arch coverage, but check release notes for specifics).
  2. Build Ollama from source with CUDA_ARCHITECTURES="52;61;75;80;86" to include your GPU architectures.
  3. Upgrade GPUs to at least an RTX 2060 or newer (compute 7.5+).

Das war ehrlich gesagt ein ziemlicher Dämpfer, denn ich wollte die GPUs so lange wie möglich nutzen, bevor ich auf eine neue umsteige.

Ich wollte Ollama nicht tatsächlich aus dem Quellcode neu bauen, denn es sollte eigentlich out of the box funktionieren, und ich war sehr verwirrt, warum es das nicht tat, obwohl die Windows-Installation diese Architekturen unterstützt hat.

Diese Karten wurden auf der Ollama-Website außerdem als unterstützt aufgeführt!

Um die lange Google-Odyssee abzukürzen:

Es stellt sich heraus, dass ollama-cuda nur mit den oben genannten Anforderungen kommt… und der Tipp lautete, ollama-vulkan zu installieren.

Nachdem ich das gemacht hatte, lief alles butterweich!

[Linux] Eine getrennte `apt dist-upgrade`-Sitzung wiederherstellen

Wed, 23 Oct 2024 00:00:00 GMT

Heute habe ich meine Proxmox-Installation aus der Ferne über die integrierte Konsole aktualisiert, dabei aber vergessen, was ich gerade tat, und den Tab mittendrin geschlossen.

Das führte dazu, dass ich mich nicht mehr verbinden konnte, da die Pakete bereits im Hintergrund aktualisiert wurden und das Upgrade eine Frage zum Ersetzen einer Datei gestellt hatte und nun auf meine Eingabe wartete.

Ich konnte mich also per SSH einloggen, aber nichts tun, da es immer noch auf eine Eingabe in einer Konsole wartete, mit der ich mich nicht verbinden konnte, weil sich die Oberfläche nicht öffnen ließ.

Nach kurzem Umschauen bin ich auf einen Serverfault-Thread gestoßen, in dem erwähnt wurde, reptyr zu benutzen, um die Terminalsitzung per SSH zu übernehmen.

Ich halte hier fest, was genau ich gemacht habe, um die Sitzung zurückzubekommen und das Upgrade abzuschließen:

Aus diesem Kommentar:

git clone https://github.com/nelhage/reptyr
cd reptyr
make install

Damit wurde reptyr auf dem Rechner installiert.

Dann habe ich mit ps ax | grep pts nach allen offenen Sitzungen gesucht, um den gesuchten Prozess zu finden.

Danach habe ich den obersten Elternprozess im Prozessbaum gefunden, dem ein pts zugewiesen ist, und mich über seine PID daran angehängt:

reptyr -T 1390511

Dann konnte ich das Upgrade abschließen! 🎉

[Linux] Syncthing – Dateisystem schreibgeschützt, wenn es als Service läuft

Wed, 06 Apr 2022 00:00:00 GMT

Ich benutze Syncthing schon eine Weile, um meine Arbeitskopie mit einem lokalen Dev-Server zu synchronisieren, genauer gesagt seit ein paar Monaten.

Anfangs habe ich es genutzt, indem ich mich eingeloggt und es manuell über die CLI gestartet habe. Das lief gut, also habe ich mir keine weiteren Gedanken gemacht, als ich es auf den Betrieb als Service umgestellt habe. Es startete, es synchronisierte ein paar Daten, alles war in Ordnung.

Bis es das natürlich nicht mehr war! 🙂

Wie sich herausstellte, hatte ich eine ganze Reihe von Fehlern in den Logs übersehen, die besagten, dass das Dateisystem auf dem Dev-Server schreibgeschützt ist, und deshalb synchronisierte Syncthing überhaupt nichts.

Ich dachte, es wäre ein Bug und es würde bei den Ordnern nur Out of Sync anzeigen, aber eigentlich würde es synchronisieren. Tja, falsch gedacht.

Nach ein paar Stunden Debugging und ein paar Google-Suchen, bei denen ich in den Foren absolut keine Hinweise fand, landete ich bei einem Syncthing-Artikel im ArchWiki, der genau meinen Fall beschrieb:

read-only file system error on /etc although run as root

Das war exakt mein Anwendungsfall, nur dass der problematische Ordner nicht /etc war, sondern /usr/local/src.

Nach dem Lesen stellte sich heraus: Wenn man Syncthing (oder irgendetwas anderes) über systemd laufen lässt und für den Service ProtectSystem auf full gesetzt ist, werden standardmäßig einige Verzeichnisse schreibgeschützt. /usr ist eines dieser Verzeichnisse.

Um das zu beheben, muss man in der Service-Konfiguration eine neue Zeile hinzufügen und den Service neu starten (und daemon-reload ausführen):

ReadWritePaths=/usr/local/src

Danach sollte Syncthing einwandfrei funktionieren.

[Linux] Mehrere Befehle parallel auf mehreren Servern ausführen

Mon, 19 Apr 2021 00:00:00 GMT

Ich habe zu Hause einen Cluster aus Raspberry Pis, auf dem Docker Swarm läuft. Damit alles im Gleichschritt bleibt, verwenden sie dieselbe Konfiguration – Benutzer, Docker-Versionen usw.

Manchmal erfordern Updates, dass auf allen Knoten des Clusters dasselbe ausgeführt wird – zum Beispiel das Anlegen eines neuen Docker-macvlan-Netzwerks.

Dafür muss man entweder dieselben Befehle auf allen Knoten manuell ausführen, indem man sich per ssh auf jeden einzelnen einloggt, die Befehle laufen lässt und dann zum nächsten weitergeht.

Da ich versuche, langfristig meinen Aufwand zu reduzieren und alles so ordentlich wie möglich zu halten, habe ich angefangen, nach Möglichkeiten zu suchen, Befehle auf allen Knoten gleichzeitig auszuführen.

Iteration 1: Eigenes Python-Skript

Die erste Iteration bestand darin, ein eigenes Python-Skript zu schreiben. Einerseits wollte ich dabei Python etwas besser lernen, andererseits fand ich keinen guten Weg, Befehle auf eine eher native Art auszuführen.

Wie zu erwarten war (ich habe schließlich noch wenig Erfahrung mit der Sprache 🙂 ), wurde es ziemlich schnell ein aufgeblähtes Durcheinander und war sehr anfällig für Fehler.

Ich musste einen anderen Weg finden, ohne mir ständig neu erarbeiten zu müssen, was ich vor drei Wochen gemacht hatte und was beim letzten Mal kaputtgegangen ist.

Iteration 2: `pssh`

Beim Herumgooglen bin ich auf [pssh](https://linux.die.net/man/1/pssh) gestoßen, das Dinge parallel über SSH ausführen kann.

Alles in allem war es ziemlich einfach, das Ganze zum Laufen zu bekommen.

Das Problem war, dass ich einige Dinge per sudo ausführen musste. Passwörter herumzureichen war nicht gerade ideal, also musste ich wieder suchen, wie ich das sudo-Passwort senden kann, wenn der entfernte Server danach fragt.

Es stellt sich heraus, dass es ziemlich einfach ist, wenn man über den richtigen StackOverflow-Kommentar stolpert.

Die Kurzfassung (TL;DR):

stty -echo; printf "Password: "; read PASS; stty echo; echo "${PASS}" | \
pssh -h <HOSTFILE> -o /tmp/output -t 0 -I "`cat ./commands.sh`"

Das -I "`cat ./commands.sh`" muss genau so geschrieben werden (in Anführungszeichen und Backticks eingefasst), sonst werden die Befehle nicht richtig ausgeführt. Das Passwort wird als separater Befehl gesendet und nicht als Eingabe für sudo aufgenommen.

Der andere Haken ist, dass man wegen dieser Konstruktion sudo mit dem Parameter -S ausführen muss, damit die Passworteingabe korrekt entgegengenommen wird.

Das Passwort einer numerischen ZIP-Datei nur mit Kommandozeilen-Werkzeugen erraten

Mon, 14 Sep 2020 00:00:00 GMT

Heute habe ich meine monatliche Rechnung von meinem Internetanbieter erhalten und etwas kam mir seltsam vor.

Die Rechnung, die in der E-Mail enthalten war, befand sich in einer ZIP-Datei mit Passwort.

Ganz zu schweigen davon, wie merkwürdig es in der heutigen Zeit ist, einen Anhang als ZIP-Datei zu erhalten (Spam, Malware, Phishing usw.), kam mir das gewählte Passwort ziemlich schwach vor.

Es ist der Geburtstag des Kontoinhabers im Format YYMMDD.

Ich habe im Fitnessstudio eine sehr grobe Berechnung im Kopf angestellt und bin auf sehr wenige mögliche Kombinationen gekommen. Nachdem ich mit einem Online-Tool berechnet habe, wie viele Tage seit dem 1900-01-01 vergangen sind (da nicht alle Kombinationen ein gültiges Datum ergeben würden), stellte sich heraus, dass es nur 44.075 Kombinationen sind (bis 2020-09-14).

Da ich weiß, dass optimierte Tools, die GPU-Leistung zum Knacken von Hashes nutzen, Millionen von Versuchen pro Sekunde durchführen können, wollte ich sehen, wie schnell das Passwort ohne solche Tools geraten werden kann, nur mit der Linux/macOS-Kommandozeile (da ich im Fitnessstudio nur Zugriff auf einen VPS hatte).

Ich habe folgenden Code entwickelt, der unter macOS funktioniert:

echo {1..44000} | xargs -P 16 -n 1 -I{} date -v "-{}d" +"%y%m%d" | xargs -P 16 -I{} sh -c 'unzip -qqoP "{}" 0417160508.zip && echo "{}" && exit 255'

Der Befehl ist von seiner Funktionsweise her ziemlich einfach, auch wenn er kompliziert erscheint.

echo {1..44000} erzeugt die Zahlen von 1 bis 44.000 und gibt sie an den nächsten Schritt weiter.

xargs -P 16 -n 1 -I{} date -v "-{}d" +"%y%m%d" – nimmt die Eingabe aus dem ersten Schritt und erzeugt Daten im Format YYMMDD, indem die Funktionalität von date genutzt wird, ein Datum um einen bestimmten Betrag zu „ergänzen“. In diesem Fall würde es X Tage vom aktuellen Datum abziehen, wobei X die im ersten Schritt erzeugte Zahl ist. Auf diese Weise können wir Daten vom heutigen Tag zurück bis in die 1900er Jahre erzeugen.

Der dritte Schritt ist der interessantere, daher werde ich ihn in zwei Teile aufteilen:

xargs -P 16 -I{} sh -c '...'

Dies nimmt die in Schritt 2 erzeugten Daten und führt für jedes dieser Daten einen Befehl aus. -P 16 bedeutet hier, dass dies in 16 parallelen Prozessen ausgeführt wird, um das Durchsuchen der Daten zu beschleunigen. Derselbe Trick wird auch in Schritt 2 angewendet, um die Datumserzeugung zu beschleunigen.

Der zweite Teil ist der Ort, an dem die Rateversuche stattfinden:

unzip -qqoP "{}" 0417160508.zip && echo "{}" && exit 255

Dabei wird zunächst versucht, die ZIP-Datei mit dem in Schritt 2 erzeugten Passwort zu entpacken. Wenn es erfolgreich ist, wird das erratene Passwort ausgegeben (echo), und dann erzwingt exit 255, dass xargs die Ausführung stoppt. Wir wollen nicht weiter raten, wenn das Passwort bereits gefunden wurde.

Alles in allem war es eine ziemlich schlechte Entscheidung, dies als Passwort für die Datei zu wählen, denn das Ausführen des obigen Befehls dauert nur etwa 10 Sekunden, um das richtige Passwort für meine Rechnung zu erraten. Für jeden anderen auch nicht viel länger.

Umgang mit Spaghetti-Code in PHP: Anonyme Funktionen nutzen, um Teile von Template-Code zu extrahieren

Sat, 08 Aug 2020 00:00:00 GMT

Kürzlich habe ich einem Freund geholfen, Code zu verstehen und so zu ändern, dass er gut mit asynchronen Aufrufen ans Backend funktioniert. Ein Bonus wäre, ihn modularer und wiederverwendbarer schreiben zu können.

Der Code ist ein WordPress-Plugin, das mit einem sehr altmodischen Ansatz geschrieben wurde – Business- und Frontend-Logik an einer Stelle vermischt. Datenmanipulationen mitten im Template-Code und so weiter.

Im Grunde das, was man Anfang der 2000er auf PHP-Seiten gesehen hat, bevor all die großartigen OOP-Erweiterungen in die Sprache kamen und es eine Reihe ausgereifter Frameworks gab.

Der Fall, an dem ich heute geknabbert habe, sah so aus: Du hast eine Tabelle, die eine Menge Einträge anzeigt. Wir mussten der Tabelle mehrere Filter hinzufügen und sie per AJAX funktionieren lassen, damit sich die Oberfläche schnell aktualisiert, ohne die ganze WordPress-Admin-Seite neu zu laden.

Das Filtern der Daten war einfach – ein schnelles Inline-array_filter, um die Daten zu filtern, bevor sie an den Template-Code übergeben wurden (um den Code-Stil beizubehalten, stand das ebenfalls in der Template-Datei 😇).

Das Problem begann, als wir daran gingen, die Tabelle über AJAX renderbar zu machen.

Sie steckt mitten in einem Haufen anderen Template- und Business-Codes. Wenn wir die Ausgabe per AJAX nur auf die Tabelle beschränken wollten, hatten wir nur ein paar Möglichkeiten.

Die erste wäre, das HTML vor und nach der Tabelle in RIESIGE if-Anweisungen zu packen, damit es nicht gerendert wird.

Eine andere wäre, das Template in eine separate Datei auszulagern und sie in der AJAX-Action einzubinden, die wir im Code des Plugins definieren würden.

Anonyme Funktionen to the rescue!

Als ich überlegte, wie sich das am einfachsten lösen lässt, versuchte ich, eine normale PHP-Funktion zu definieren, die den Tabellencode enthält, aber da gab es ein Problem.

Der Code läuft innerhalb einer Klassenmethode. Im Tabellen-Template gibt es Verweise auf $this. Wenn wir den Code nicht zu sehr ändern wollen, müssten wir $this als Funktionsargument übergeben. Tja, das funktioniert nicht so ganz, denn $this kann man nicht als Parameter übergeben 🤷‍♂️.

Ich war ein bisschen enttäuscht, dass wir einen Haufen im Template umschreiben müssten, und es gab ziemlich viele Verweise, die wir im Blick behalten wollten, damit alles weiter funktioniert.

Dann fiel mir ein, dass die Seite nicht auf PHP 5.2 läuft, sondern auf PHP 7 und anonyme Funktionen somit unterstützt würden.

Und die haben dieses praktische Feature, mit dem man festlegen kann, welche Variablen aus dem aufrufenden Scope an die Funktion weitergereicht werden, wenn sie aufgerufen wird. Zum Beispiel:

$table_function = function() use ( $pages, $current_page, $items ) {
    // ... Table render code
}

Dadurch kannst du direkt im Funktionskörper auf $pages oder $items zugreifen.

Das Großartige daran: Du kannst auch $this als Variable in den Funktions-Scope übergeben!

Jetzt konnten wir den Code zum Rendern der Tabelle komplett in eine separate Funktion auslagern, die wir beim AJAX-Aufruf isoliert aufrufen können!

Natürlich muss man bei den Variablen im Funktionskörper sehr vorsichtig sein, da sie definiert sein müssen. Man sollte also genau darauf achten, wo die AJAX-Funktion aufgerufen werden kann.

Für uns bedeutet das, dass wir in der Hauptklasse eine winzige Action hinzufügen, die die Datei weiterhin einbindet, wir aber mehr Kontrolle darüber haben, alle anderen Ausgaben zu unterbinden, die sonst stattfinden würden.

Arduino/ESP32: Den Task-Watchdog deaktivieren

Wed, 29 Apr 2020 00:00:00 GMT

Kürzlich habe ich ein bisschen mit der Multicore-Funktionalität des ESP32 und dem Pinning von Tasks auf bestimmte Kerne herumgespielt.

Ich habe AutoConnect verwendet, um eine WLAN-Verbindung ohne im Code gespeicherte Zugangsdaten zu unterstützen und OTA-Updates über die Web-Oberfläche anzubieten.

Das war für ein Projekt, das einige 4-Pin-PWM-CPU-Lüfter in meinem Serverschrank steuern sollte, um die Luft darin zu kühlen. Dafür wollte ich die Logik auf zwei Tasks aufteilen.

Ein Task für APIs, Sensorauslesung, Updates, WLAN usw. und ein Task für den Interrupt und die PWM-Steuerung der Lüfter.

Alles war gut, die Tasks wurden erstellt, aber beim Ausführen des Codes zeigte sich ein seltsames Verhalten, sobald ich den ESP32 in den Modus brachte, in dem man sich mit ihm verbinden muss, um ihm zu sagen, mit welchem WLAN er sich verbinden soll: Er startete alle paar Sekunden den Controller neu, und ich bekam die Verbindung nicht zum Laufen.

Das war eine nervige Zeit, denn ich musste den Controller von seinem Platz abmontieren und per USB anschließen, um eine neue Firmware zu flashen.

Nachdem ich das getan hatte, bemerkte ich, dass der Fehler vom Watchdog kam:

Task watchdog got triggered. The following tasks did not feed the watchdog in time:

IDLE (CPU 1)
Tasks currently running:
CPU 0: ManageTask
CPU 1: ControllerTask

Beim Recherchieren stellte sich heraus, dass das vom Task-Watchdog des ESP32 ausgelöst wird, der sicherstellt, dass alle Tasks ihre Rechenzeit auf der CPU bekommen.

Außerdem schien AutoConnect in einem Task-Kontext nicht besonders flexibel zu sein, verglichen mit der Ausführung außerhalb eines Tasks, direkt zusammen mit dem restlichen Code und den anderen Funktionen.

Nach etwas Herumstöbern und Ausprobieren scheint der einfachste Ausweg zu sein, den Watchdog einfach zu deaktivieren und zu hoffen, dass alles rechtzeitig ausgeführt wird 🙂 Der Task ist nicht geschäftskritisch, also ist es in Ordnung, wenn er etwas länger braucht, um fertig zu werden.

Um den Watchdog zu deaktivieren, musst du zwei Dinge tun:

Erstens: den Header esp_task_wdt.h einbinden. Füge dazu #include <esp_task_wdt.h> zu deinem Include-Bereich hinzu.

Zweitens: den Watchdog so einstellen, dass er den Controller nicht zurücksetzt und länger wartet. Dafür musst du esp_task_wdt_init(30, false); am Anfang deines Task-Codes einfügen.

void manage_core_task(void *pv_parameters) {
    esp_task_wdt_init(30, false);
    // .... rest of the code ...
}

Das setzt das Watchdog-Timeout auf 30 SEKUNDEN und deaktiviert den Controller-Reset, wenn er ausgelöst wird.

Wenn du möchtest, dass der Controller nach dem Auslösen des Watchdogs trotzdem zurückgesetzt wird, ändere den zweiten Parameter des Funktionsaufrufs von false auf true.

Einen YubiKey für das Signieren von Git-Commits einrichten

Wed, 08 Jan 2020 00:00:00 GMT

Ich benutze einen YubiKey als Zwei-Faktor-Authentifizierungs-Schlüssel und um meine Git-Commits zu signieren. Bis vor ein paar Tagen habe ich einen YubiKey 4 benutzt. Da mein aktueller Rechner keine USB-A-Anschlüsse hat, habe ich ständig USB-A-auf-USB-C-Adapter in meinem Rucksack herumjongliert, und den Key zu benutzen war im letzten Jahr ein ziemlicher Krampf. Deshalb habe ich beschlossen, dass es Zeit ist, auf meinen „neuen“ YubiKey 5C umzusteigen, damit ich nicht mehr mit diesen Adaptern hantieren muss.

Eigentlich habe ich den Key schon eine Weile, denn ich hatte ihn zusammen mit einem Ersatz-YubiKey-4 bestellt, wegen des Infineon-TPM-Problems, das sie damals festgestellt haben. Aber erst jetzt habe ich entschieden, dass es Zeit für den Wechsel auf den neuen Key ist.

Der andere Grund, es jetzt zu tun: Meine alten GPG-Keys sind abgelaufen und ich musste sie neu ausstellen, also kann ich den Key gleich zum Signieren meiner Git-Commits benutzen.

GPG-Wahnsinn

Wenn du schon einmal mit GPG-Keys zu tun hattest (oder gerade hast), weißt du, dass es ziemlich schwer sein kann, alles richtig und sicher zum Laufen zu bringen, wenn man es noch nie gemacht hat. Master-Keys offline halten, öffentliche Schlüssel hin- und herschieben, Keys nach dem Ablauf neu ausstellen, sie eventuell mit früheren Keys signieren, um sie zu verifizieren, Keys widerrufen … Selbst in der Theorie ist es nicht leicht, die Best Practices zu befolgen. In der Praxis wird es extrem kompliziert.

Die meisten Tutorials im Netz sagen, du sollst die CLI zum Erzeugen deiner Keys benutzen, dich durch Menüs mit einem ungewöhnlichen Bedienkonzept hangeln, und generell ist es eine Qual, das alles zum Laufen zu bringen. Die meisten Tutorials empfehlen einen Offline-Rechner wie einen Raspberry Pi und/oder Master-Key und Subkeys offline zu erzeugen und den Master-Key nicht auf deinem Rechner zu lassen.

🤯

Damit schlage ich mich jetzt seit fast 4 Jahren jeden Januar herum. Ich fürchte den Moment, in dem ich folgenden Fehler bekomme, der mir sagt, dass meine Signing-Keys abgelaufen sind.

error: gpg failed to sign the data
fatal: failed to write commit object

Dieses Jahr habe ich beschlossen, dass es Zeit ist, diesen Prozess deutlich einfacher zu machen und die eingebaute Schlüsselerzeugung zu nutzen, um den ganzen Ärger mit der GPG-Key-Generierung und Co. zu vermeiden.

Schlüsselerzeugung direkt auf dem YubiKey

Auch hier müssen wir die CLI-Oberfläche benutzen, aber sie ist etwas übersichtlicher, weil es weniger Schritte gibt.

Zuerst müssen wir unsere Karte bzw. unser Gerät einrichten.

Einrichtung von Karte/Gerät

Führe gpg --card-status im Terminal aus und du solltest in etwa Folgendes sehen:

Reader ………..: Yubico Yubikey 4 OTP U2F CCID
Application ID …: <Serial number>
Version ……….: 2.1
Manufacturer …..: Yubico
Serial number ….: <Device serial number>
Name of cardholder: unspecified
Language prefs …: en
Sex …………..: unspecified
URL of public key : \[not set\]
Login data …….: <e-mail or nothing>
Signature PIN ….: not forced
Key attributes …: rsa4096 rsa4096 rsa4096
Max. PIN lengths .: 127 127 127
PIN retry counter : 3 0 3
Signature counter : 9

Wenn du etwas Ähnliches siehst und keine Fehler auftauchen, kannst du weitermachen.

Führe gpg --card-edit aus.

Du landest in einer CLI-Oberfläche, die zu Beginn dieselben Informationen anzeigt und unten eine Eingabeaufforderung gpg/card> hat.

Tippe admin und drücke Return/Enter.

Mit help kannst du jetzt herausfinden, wie du die Besitzerinformationen und die PINs der Karte änderst.

Eines MUSST du tun: die Standard-PINs der Karte ändern. Es gibt zwei davon. Die erste ist die PIN, mit der du auf die Keys auf der Karte zugreifst. Die zweite ist die „Admin“-PIN oder PUK (Personal Unblocking Code).

Dazu tippst du passwd und siehst ein Menü:

gpg/card> passwd  
gpg: OpenPGP card no. <Serial number> detected

1 - change PIN  
2 - unblock PIN  
3 - change Admin PIN  
4 - set the Reset Code  
Q - quit

Tippe 1 und folge den Anweisungen, um deine PIN zu ändern. Die Standard-PIN ist 123456.

Wähle danach 3, um die Admin-PIN zu ändern. Der Standardwert ist 12345678.

Wenn beide PINs geändert sind, gehe zurück ins Hauptmenü, um die Key-Informationen fertig zu aktualisieren.

Die verfügbaren Befehle sind:

name – um den Namen des Karteninhabers zu ändern
login – um die E-Mail-Adresse oder den Login des Karteninhabers zu ändern

Danach können wir mit der eigentlichen Schlüsselerzeugung weitermachen.

Schlüsselerzeugung

Jetzt ist es Zeit, die Keys tatsächlich zu erzeugen.

Tippe dazu generate.

Du wirst gefragt: Make off-card backup of encryption key? (Y/n). Wie in der Dokumentation von YubiKey erwähnt, ist das aber nur ein Schein-Backup und erstellt kein vollständiges Backup der geheimen Schlüssel, daher spielt es keine Rolle, ob du mit Yes oder No antwortest. Ich antworte mit No(n).

Falls bereits Keys auf der Karte gespeichert sind, wirst du gefragt, ob du sie ersetzen willst:

gpg: Note: keys are already stored on the card!

Replace existing keys? (y/N)

Stelle sicher, dass du nichts Wichtiges ersetzt, wovon du kein Backup hast, und fahre mit Y fort. Wenn etwas Wichtiges drauf ist, brich den ganzen Vorgang besser mit Ctrl+C ab.

Du wirst nach der Karten-PIN gefragt, die du vorhin gesetzt hast.

Danach musst du auswählen, wie lange die Keys gültig sein sollen:

Please specify how long the key should be valid.
        0 = key does not expire
      <n> = key expires in n days
     <n>w = key expires in n weeks
     <n>m = key expires in n months
     <n>y = key expires in n years
 Key is valid for? (0)

Wenn die Keys nur 1 Jahr gültig sein sollen, tippe 1y.

Du wirst gebeten, das Ablaufdatum zu bestätigen. Prüfe, ob alles stimmt, und bestätige.

Danach wirst du aufgefordert, Informationen zum Key-Besitzer einzugeben:

Is this correct? (y/N) y
GnuPG needs to construct a user ID to identify your key.
Real name: <Your name>
Email address: <Your e-mail>
Comment: <Comment is optional>
 You selected this USER-ID:
     "<Your name> <comment> <your e-mail>
 Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit?

Type `O` to confirm if everything seems correct.

Dann wirst du nach deiner Admin-PIN bzw. PUK gefragt. Die wird gebraucht, weil auf die Karte geschrieben wird.

Wenn alles stimmt, beginnt der YubiKey zu blinken und tut das eine ganze Weile (bei mir etwa fünf Minuten).

Wenn er fertig ist, siehst du die folgende Meldung:

gpg: key <Short ID> marked as ultimately trusted
gpg: revocation certificate stored as '/Users/bisko/.gnupg/openpgp-revocs.d/<LONG ID>.rev' public and secret key created and signed.

Notiere dir die <Short ID>, wir brauchen sie später noch.

An diesem Punkt kannst du die GPG-Eingabeaufforderung mit quit oder Ctrl+C verlassen.

Jetzt ist es Zeit, den öffentlichen Schlüssel zu sichern, damit wir den Key auch auf einem anderen Rechner verwenden können.

Führe dazu den folgenden Befehl aus:

gpg --armor --export <Short ID> > <Short ID>.asc

Das exportiert den öffentlichen Schlüssel in eine Datei namens <Short ID>.asc. Die brauchst du später, wenn du den YubiKey auf einem anderen Rechner nutzen willst oder wenn du deine GPG-Konfiguration verlierst.

Um den öffentlichen Schlüssel in deinem Schlüsselbund wiederherzustellen, musst du Folgendes tun:

gpg --import < <Short ID>.asc
gpg: key <Short ID>: public key "Your Name <your@email>" imported
gpg: Total number processed: 1
gpg: imported: 1

Ein sehr wichtiger Hinweis. Wenn es eine frische GPG-Installation oder ein anderer Rechner ist, erkennt GPG die Keys auf der Karte nicht von selbst. Du musst gpg --card-status ausführen, damit GPG die Karte ausliest und die Keys darauf erkennt.

Git für das Signieren einrichten

Damit Git deine Commits signiert, musst du Folgendes zu deiner ~/.gitconfig hinzufügen.

Im Abschnitt [user] musst du die folgende Zeile hinzufügen (oder aktualisieren):

signingkey = 0x<Short ID>

Wenn du alle deine Commits signieren willst, füge am Ende der Datei Folgendes hinzu:

[gpg]
  program = /usr/local/bin/gpg
[commit]
  gpgsign = true

Damit signiert Git alle deine Commits.

Um GitHub einzurichten, musst du deinen öffentlichen Schlüssel zu deinem Profil hinzufügen. Gehe dazu auf GitHub -> Settings -> SSH and GPG keys -> New GPG key.

Dann siehst du ein Textfeld, in das du den gesamten Inhalt der oben erzeugten Datei <Short ID>.asc einfügen musst.

Wenn du den Inhalt der Datei kopieren willst (unter macOS), kannst du das hier tun:

cat <Short ID>.asc | pbcopy

Das kopiert den Inhalt der ganzen Datei in die Zwischenablage.

Füge ihn in das Textfeld auf GitHub ein und klicke auf den Button Add GPG key.

Danach kannst du einen Commit machen und zu GitHub pushen, und du solltest das hübsche Verified-Label sehen.

Debugging

Manchmal klappt nicht gleich alles. Um mehr Informationen zu sammeln, kannst du Folgendes versuchen:

Signieren mit GPG

Versuche zuerst, mit dem Key etwas zu signieren:

gpg -s <file>

Wenn das fehlschlägt, versuche herauszufinden, warum. Ich bin kein Experte und kann da nicht weiterhelfen.

Sieh dir die Ausgabe von Git anGIT_TRACE=1 git commit -am “test”

Das zeigt dir genau, was Git tut, während es versucht, den Commit durchzuführen und zu signieren. Es gibt dir einen Hinweis darauf, warum das Signieren fehlschlagen könnte.

Daran kannst du auch sehen, dass Git den folgenden Befehl ausführt:

/usr/local/bin/gpg --status-fd=2 -bsau <Key ID>

Du kannst versuchen, ihn manuell auszuführen, um vielleicht eine aussagekräftigere Fehlermeldung zu bekommen.

e1000e eth0: Detected Hardware Unit Hang

Wed, 18 Dec 2019 00:00:00 GMT

Vor Kurzem hat mein Heimserver und VM-Host angefangen, zufällig die Netzwerkverbindung zu verlieren. Von außen sieht es so aus, als würde er noch laufen, aber ich kam auf keinem Weg mehr aus der Ferne an ihn heran. Der Ethernet-Adapter war laut Switch eingeschaltet, also musste das Problem irgendwo in der Software liegen.

Es wäre nicht das erste Mal, dass ein Treiber für eine hängende Netzwerkverbindung verantwortlich ist. In der Vergangenheit haben mich schon fehlerhafte WLAN-Treiber unter Linux und Windows geärgert.

Nachdem ich ein bisschen in den Systemlogs gegraben hatte, bin ich auf Folgendes gestoßen:

vmhost kernel: e1000e 0000:00:1f.6 eth0: Detected Hardware Unit Hang:
vmhost kernel: TDH <0>
vmhost kernel: TDT <1>
vmhost kernel: next_to_use <1>
vmhost kernel: next_to_clean <0>
vmhost kernel: buffer_info[next_to_clean]:
vmhost kernel: time_stamp <10fbc2f81>
vmhost kernel: next_to_watch <0>
vmhost kernel: jiffies <10fbc3871>
vmhost kernel: next_to_watch.status <0>
vmhost kernel: MAC Status <40080083>
vmhost kernel: PHY Status <796d>
vmhost kernel: PHY 1000BASE-T Status <7800>
vmhost kernel: PHY Extended Status <3000>
vmhost kernel: PCI Status <10>
vmhost kernel: e1000e 0000:00:1f.6 eth0: Reset adapter unexpectedly
vmhost kernel: vmbr0: port 1(eth0) entered disabled state

Danach setzt er den Netzwerkadapter zurück und macht nach einer Weile wieder dasselbe, bis die Maschine komplett offline geht.

Bei der Suche nach Antworten im Netz bin ich auf diesen ServerFault-Thread gestoßen.

Ursache

Nach dem Lesen verschiedener Quellen und Bug-Reports scheint der beste Weg, das Problem zu reproduzieren, eine Situation mit hoher Bandbreite auf dem Gerät zu sein, also etwa das Streamen großer Datenmengen, die die Schnittstelle auslasten.

Bei mir passierte es meistens, wenn ich Medien vom lokalen Plex-Server auf ein Gerät streame. Wegen der Art, wie das Netzwerk aufgebaut ist, muss die Windows-VM, auf der die Plex-Instanz läuft, die Mediendatei von einer NFS-Freigabe auf einem separaten Gerät holen, in der VM transkodieren und sie dann an das Wiedergabegerät schicken.

Das summiert sich zu einer Menge Netzwerkverkehr, meist ~40–100 Mbit/s, je nach Wiedergabegerät und Qualität der Quelldatei.

Dasselbe Problem trat auch beim Streamen von Spielen per Steam Link auf unseren Apple TV auf. Die Verbindung ist kabelgebunden, aber es ist nicht ungewöhnlich, dass das Netzwerk abbricht. Ich vermute, dass es mit demselben Problem zusammenhängt, werde aber ein Auge darauf haben, ob es nach dem Fix in Zukunft noch passiert.

Möglicher Fix

Ein möglicher Fix scheint zu sein, GSO (Generic Segmentation Offload), TSO (TCP Segmentation Offload) und GRO (Generic Receive Offload) auf der Netzwerkschnittstelle zu deaktivieren*:

ethtool -K eth0 gso off gro off tso off

Ich habe das bei mir angewendet und warte nun ab, ob es das Problem auf lange Sicht wirklich löst.

Fußnoten

* Diese Optionen betreffen das Auslagern der Paketsegmentierung an den Netzwerk-Controller, um die CPU-Last auf der Maschine zu verringern. Mehr Details gibt es in diesem Wikipedia-Artikel.

Snippets: Eine lokale/private Docker-Image-Registry für den Swarm betreiben

Fri, 11 Oct 2019 00:00:00 GMT

Heute wollte ich aus einem Node.js-Projekt ein Docker-Image erzeugen und es auf meinem lokalen Test-Swarm deployen.

Leider wird ein lokal gebautes Docker-Image nur auf dem Node gespeichert und ist auch nur dort verfügbar, auf dem es erstellt wurde. Die anderen Swarm-Nodes kommen nicht heran.

Die Lösung: das Image in eine Docker-Registry pushen, aus der es dann alle Nodes im Swarm pullen können.

Die Registry erstellen

Um einen Registry-Service im Swarm zu starten, führe Folgendes aus:

docker service create —name registry —publish 5000:5000 registry:latest

Das erstellt den Registry-Service und lässt ihn im Swarm laufen, sodass er für alle Nodes im Swarm erreichbar ist.

Ein Image in die Registry pushen

Um ein Image in die Registry zu pushen, musst du zwei Dinge tun – das Image taggen und dann pushen.

Hier ein Beispiel, wie man das Image in einem Rutsch baut und taggt:

docker build . -t localhost.localdomain:5000/:latest

Und so pusht man es in die Registry:

docker push localhost.localdomain:5000/:latestDas Image in einem Service/Container/etc. verwenden

Um das Image in einem Service oder Container zu verwenden, gibst du den vollständigen Pfad von oben an, also localhost.localdomain:5000/<image-name>:latest.

Die Swarm-Nodes haben dann Zugriff auf das Image und können es pullen und ausführen.

Wichtiger Hinweis zur Registry-Adresse

In den meisten Tutorials im Netz wird die Registry-URL als localhost:5000 angegeben. Leider funktioniert das nicht, und meistens läuft die Verbindung in einen Timeout. Wenn wir das zu localhost.localdomain ändern, klappt es!

Keine Ahnung, warum das passiert, wo doch sowohl localhost als auch localhost.localdomain zu 127.0.0.1 aufgelöst werden.

Snippets: Die Apple-Tastatur-Taste „Paragraphzeichen“ auf Backquote umbelegen ( § zu ` )

Wed, 31 Jul 2019 00:00:00 GMT

Ich benutze schon eine Weile Apple-Tastaturen, aber wenn man in Europa lebt, ist es nicht leicht, die US-Layout-Varianten zu bekommen, die ich gewohnt bin.

Unter macOS gibt es einen „einfachen“ Weg, die Tastatur mit nur einem Terminal-Befehl umzubelegen:

watch -n1 -x hidutil property -m ’{“ProductID”:592, “VendorID”:1452}’ —set ’{“UserKeyMapping”:[{“HIDKeyboardModifierMappingSrc”:0x700000035,“HIDKeyboardModifierMappingDst”:0x700000064}]}’

Dieses Stück Code ändert die Belegung der Paragraphzeichen-Taste ( § ), sodass sie stattdessen die Backquote-/Tilde-Taste ( `/ ~ ) ausgibt.

Der Teil watch -n1 -x führt das jede Sekunde aus, weil macOS die Einstellung manchmal verliert, meist wenn der Computer in den Ruhezustand geht oder die Tastatur ab- und wieder angesteckt wird.

Beachte bitte, dass das Hilfsprogramm watch bei manchen macOS-Versionen nicht installiert ist und über etwas wie Homebrew oder MacPorts nachinstalliert werden muss.

Der obige Code funktioniert mit der externen Apple-Tastatur mit USB und europäischem Layout mit bulgarischen Buchstaben. Bei anderen Tastaturtypen müssen die Hex-Werte der Tasten eventuell leicht angepasst werden.

Eine Variante des Befehls funktioniert gut für denselben Tastaturtyp am MacBook Pro selbst. Dazu musst du nur die Positionen der Werte 0x700000035 und 0x700000064 vertauschen.

Ich habe schon überlegt, ein Tool zu schreiben, das das automatisch für mich erledigt, aber im Moment denke ich, dass es sich mehr lohnt, in eine neue Tastatur mit dem richtigen Layout zu investieren 🙂

Apple-TV-Fernbedienung zurücksetzen/neu starten

Sun, 17 Feb 2019 00:00:00 GMT

Gestern Abend, während eines Gästebesuchs, habe ich es geschafft, unsere Apple-TV-Fernbedienung unter Wasser zu tauchen. Schlafmangel und wackelige Gläser führen eben zu Unfällen.

Die Fernbedienung funktionierte gestern Abend noch einwandfrei, aber heute hat sie den Dienst quittiert. Sie reagiert auf keinerlei Eingaben. Ich habe versucht, sie gegen meine Hand zu schlagen und das Wasser herauszuschütteln. Es hat überhaupt nichts gebracht.

Wir dachten, sie sei hinüber, und suchten schon in den Schränken nach der Reispackung.

Ich ging online, größtenteils aus Spaß, um zu schauen, ob ich versuchen kann, sie „neu zu starten“.

Eine hilfreiche Anleitung riet mir, die Tasten Lauter und Menü 2–3 Sekunden lang gedrückt zu halten, um die Fernbedienung zurückzusetzen und in den Kopplungsmodus zu versetzen.

Ich war echt überrascht, als es tatsächlich funktioniert hat!

Wenn also etwas faul zu sein scheint, versucht zuerst, die Fernbedienung zurückzusetzen. Wenn das nicht klappt, könnt ihr es immer noch mit Reis und einem Eingriff an der Hardware probieren.

TL;DR;

Menü + Lauter 2–3 Sekunden lang gedrückt halten
Ein paar Sekunden warten
Versuchen, mit dem Apple TV zu interagieren

bisko.be - Dev

Ollama mit älteren GPUs unter CachyOS betreiben

TL;DR;

Storytime

[Linux] Eine getrennte `apt dist-upgrade`-Sitzung wiederherstellen

[Linux] Syncthing – Dateisystem schreibgeschützt, wenn es als Service läuft

[Linux] Mehrere Befehle parallel auf mehreren Servern ausführen

Iteration 1: Eigenes Python-Skript

Iteration 2: pssh

Die Kurzfassung (TL;DR):

Das Passwort einer numerischen ZIP-Datei nur mit Kommandozeilen-Werkzeugen erraten

Umgang mit Spaghetti-Code in PHP: Anonyme Funktionen nutzen, um Teile von Template-Code zu extrahieren

Arduino/ESP32: Den Task-Watchdog deaktivieren

Einen YubiKey für das Signieren von Git-Commits einrichten

GPG-Wahnsinn

Schlüsselerzeugung direkt auf dem YubiKey

Einrichtung von Karte/Gerät

Schlüsselerzeugung

Git für das Signieren einrichten

Debugging

Signieren mit GPG

e1000e eth0: Detected Hardware Unit Hang

Snippets: Eine lokale/private Docker-Image-Registry für den Swarm betreiben

Snippets: Die Apple-Tastatur-Taste „Paragraphzeichen“ auf Backquote umbelegen ( § zu ` )

Apple-TV-Fernbedienung zurücksetzen/neu starten

Iteration 2: `pssh`