Alle Beiträge von Malte

Bei linuxserver/docker-wireguard automatisch WireGuard-Clients im laufenden Betrieb hinzufügen

Für die Realisierung eines WireGuard-VPN in Sterntopologie nutze ich linuxserver/docker-wireguard. Das Docker Container-Image ist eines von vielen ganz hervorragenden Container-Images von linuxserver.io, welches mit einem gefestigten Featureset und regelmäßigen Updates kommt.

Leider sieht es im Standard nur vor, dass WireGuard-Peers per Umgebungsvariable „PEERS“ mit Komma getrennt eingestellt werden. Peers, die nicht mehr oder noch nicht in der Liste sind, werden auch nicht als solche in der vom Server verwendeten wg01.conf eingetragen und sind damit nicht in der Lage, eine Verbindung aufzubauen. Wie ich das unkompliziert gelöst habe, ohne das Container-Image anzupassen, möchte ich hier zeigen:

Bei linuxserver/docker-wireguard automatisch WireGuard-Clients im laufenden Betrieb hinzufügen weiterlesen

Bessere tesseract-Trainingsdaten „tessdata_best“ in paperless-ngx (Docker) nutzen

paperless-ngx nutzt zur Texterkennung tesseract-ocr über OCRmyPDF. Für tesseract-ocr gibt es dabei zwei unterschiedliche Arten von Texterkennungs-Trainingsdaten (tessdata_fast, tessdata_best). Wobei die standardmäßig im paperless-ngx Docker-Image installierten immer die bereitgestellten „tessdata_fast“-Trainingsdaten sind. Diese sind zügig, aber haben auch eine höhere Fehlerrate in der Erkennung.

Um für paperless-ngx „tessdata_best“ zu nutzen, empfiehlt sich eine ganz simple Lösung: Wir laden die Trainingsdaten herunter, legen sie in ein Verzeichnis unserer Wahl und mounten sie in den paperless-ngx Container an der jeweilig korrekten Stelle:

Bessere tesseract-Trainingsdaten „tessdata_best“ in paperless-ngx (Docker) nutzen weiterlesen

In paperless-ngx signierte PDF-Dokumente trotz Signatur mit OCR importieren

Um in paperless-ngx Dokumente zu importieren und OCR (Texterkennung) über jene laufen zu lassen, bedarf es einer kleinen Anpassung in den paperless-ngx-Einstellungen. Ohne die Änderung verweigert paperless-ngx und die genutzten Drittanwendungen das Einlesen des Textes mit der Meldung:

Unter „Konfiguration“ -> Reiter „OCR-Einstellungen“ > „OCR-Argumente“ muss die folgende Option in JSON-Format eingefügt werden:

In paperless-ngx signierte PDF-Dokumente trotz Signatur mit OCR importieren weiterlesen

Einmalige Email-Benachrichtigung bei Freigabe in paperless-ngx einrichten

Stand heute unterstützt paperless-ngx leider keine Email-Benachrichtigungen wenn eine Freigabe an einen anderen Benutzer erfolgt. Mit ein paar Tricks lässt sich diese Funktionalität jedoch, zumindest in einer grundlegend, nachrüsten.

Ich möchte hier kurz erläutern wie ich Email-Benachrichtigungen bei Freigabe in paperless-ngx ohne externe Tools realisiert habe:

Einmalige Email-Benachrichtigung bei Freigabe in paperless-ngx einrichten weiterlesen

Webhook-Queue in paperless-ngx löschen

Spielt man ein bisschen mit den Workflows „Arbeitsabläufen“ in paperless-ngx, kann es passieren, dass man versehentlich viele Webhook-Calls generiert, indem man z. B. für seine gesamte Dokumentensammlung Webhooks durch den Auslöser „Geplant“ auslöst, die dann allesamt in der nachgelagerten Redis-Datenbank feststecken und unter Umständen nur noch sehr langsam oder gar nicht mehr abgearbeitet werden, weil die externe API, welcher der Webhook-Call galt, nicht mehr mitmacht.

Eine pragmatische Lösung dazu ist, die gesamte Warteschlange an wartenden Webhook-Calls zu entfernen. Im Docker-basierten paperless-ngx ginge das wie folgt:

Webhook-Queue in paperless-ngx löschen weiterlesen

Pacemaker und IPaddr2 mit unterschiedlichen Network-Interface Namen je nach Cluster-Node

Migriert man eine virtualisierte Infrastruktur beispielsweise zwischen VMware und Proxmox, so lernt man schnell, dass bei anders virtualisierten Netzwerk-Interfaces sich auch die Namen derer ändern. Aus ens192 wird zum Beispiel ens18 aufgrund der anderen internen Adressierung und weiteren Faktoren.

Möchte man einzelne Nodes eines Pacemaker- und Corosync-basierten Clusters nun Node-by-Node in die andere Infrastruktur überführen, lernt man schnell, dass der „nic=“ Parameter des ofc_heartbeat_ipaddr2-Skripts selbstverständlich im Rahmen der crm.conf, der „CIB“ (Cluster Information Base), sofort nach Änderung bzw. Aktivierung bei manueller Anpassung mit den anderen Nodes synchronisiert wird.

Das führt genau dann zu Problemen, wenn ein Node bereits auf Proxmox läuft, aber die CIB noch auf ein nicht mehr existierendes Network-Interface verweist. Um ein Cluster ohne Downtime und ohne Probleme im Betrieb zu switchen, empfiehlt es sich, den „nic=“ Parameter abhängig vom Namen des jeweiligen Nodes zu setzen. Eine elegante Lösung in der Konfiguration erschien mir so:

primitive vip1 IPaddr2 \
        params ip=10.10.10.5 cidr_netmask=32 \
        op monitor interval=3s \
        meta target-role=Started \
        params 3: rule #uname eq node1 nic=ens192 \
        params 2: rule #uname eq node2 nic=ens192 \
        params 1: nic=ens18

Die Nodes sind hierbei „node1“, „node2“ und „node3“. Die Priorität bestimmt „params 1“ bis „params 3“ wobei immer dort aufgehört wird, wo eine Regelübereinstimmung passiert. Im Beispiel würden node1 und node2 also als nic=ens192 bekommen, alle anderen Nodes, also auch node3, jedoch nic=ens18.

Übrigens wieder eine tolle Option, welche ChatGPT und auch eine Google-Suche nicht sofort zu Tage fördern, welche man jedoch sauber über die man-Page findet (siehe „Syntax: Rule expressions“).