Archiv der Kategorie: Software

Alles was mit Software zu tun hat

Arch Linux: Schlüsselfehler bei Update

Nur „mal kurz“ updaten – „pacman -Syu“, paar mal Enter und schon ist das notwenige Übel von der Todo-Liste verschwunden. Nunja, üblicherweise. Auf einem System trat heute nach dem Download folgender Fehler auf:

Fehler: key "B02854ED753E0F1F" could not be looked up remotely
Fehler: Erforderlicher Schlüssel fehlt im Schlüsselbund
Fehler: Konnte den Vorgang nicht durchführen (Unerwarteter Fehler)
Fehler sind aufgetreten, keine Pakete wurden aktualisiert.

Ursache ist ja schon recht gut beschrieben: Ein Paket ist offenbar mit einem Key signiert, den das System noch nicht kennt. Üblicherweise versucht pacman dann diesen von den Arch-Servern(?) nachzuladen. In meinem Fall erfolglos – der Rechner hat keinen direkten Internetzugang und kommt nur per HTTP-Proxy nach draußen.

Um den Fehler zu beheben sollte man vor dem Systemupdate das Paket archlinux-keyring neu installieren. Dieses bringt alle aktuellen Schlüssel mit und aktualisiert die lokale Datenbank, danach sollten auch die restlichen Aktualisierungen problemlos laufen.

WordPress, HTTPs optional und die SEO-Leute

OK, Zertifikate erneuert, dann auch noch „schnell mal“ HTTPs im Blog einschalten. Oder auch nicht…

Ich habe bereits seit langem den Adminbereich meines Blogs über HTTPS eingebunden, hierzu ist lediglich ein einfaches

define('FORCE_SSL_ADMIN', true);

in der wp-config.php notwendig. Den Blog selbst hatte ich seinerzeit auf HTTP gelassen, denn nicht jeder hat die von mir verwendete Zertifizierungsstelle CACert installiert was zu unschönen Warnungen führen würde. Optional wäre toll, aber damals zeigte sich schnell, dass die SEO-Funktionen von WordPress aus dieser einfachen Sache mal wieder eine lange Geschichte machen. Anstatt Anfragen einfach zu verarbeiten wird zur Optimierung der Suchmaschinenplatzierung alles unbekannte auf die konfigurierte Hauptadresse umgeleitet – incl. dem für WordPress unbekannten https://….

Im Netz findet man häufig kleine Codefragmente, welche in der wp-config.php die interenen Adressen bei HTTPS-Zugriffen umbiegen sollen. In meinem Fall biss sich diese Methode leider mit dem verwendeten Cache-Plugins. Fündig geworden bin ich im Plugin „WP-SSL„. Über wenige Filter werden die Adressen direkt über die API ersetzt. Da so auch die Cacher entsprechende Ausgaben erhalten ist auch der parallele Einsatz kein Problem. Das Plugin ist für mich eher Vorlage als Fertiglösung gewesen – einige Zeilen für alternative URLs und Plugins musste ich ergänzen, aber generell ist die Methode praktisch und schnell zu verstehen.

Rekonfiguration erfolgreich – somit ist diese Seite jetzt auch offiziell (auf Wunsch) per HTTPS erreichbar – selbstverständlich auch mit PFS und paranoiden Schlüssellängen, auch wenn es wohl für einen einfachen Blog nicht wirklich etwas zur Sache tut ;).

Anm: Offenbar gibt es doch noch den ein oder anderen Client (IE auf WinXP, Android 2.3), welche noch kein SNI unterstützen – für die heißt es: „Sorry, aber ohne Update geht’s nur ohne“…

Gentoo: You’re missing a /dev/fd symlink to /proc/self/fd.

Hui, ich dachte der wäre schon mal da gewesen, aber hey… Während eines Updates verabschiedete sich Portage mit folgender Meldung:

Gentoo: You're missing a /dev/fd symlink to /proc/self/fd.

Auslöser ist, dass das udev-initscript, zumindest auf meinem hardened-System, nicht bei Systemstart ausgeführt wird. Ein kurzes

rc-update add udev sysinit
/etc/init.d/udev start

[Source]

sollte das Problem beheben.

Windows 8.1: Meteo-Apps zeigen nur Splashscreen

Das neue Update 1 für Windows 8.1 treibt einen doch dazu die Kachelkiste nochmal näher anzuschauen – üblicherweise sitzt sie nur als Monitoring-Anzeige in der Ecke und wird nur für Softwaretests aktiv genutzt. Schnell mal in den Store und… Ach nein – ich vergaß. Alle hier verwendeten Rechner wurden seinerzeit mit Windows 8 installiert und über den Store auf 8.1 aktualisiert – mit einigen Nebenwirkungen: Nirgendwo konnten nach dem Update Meteo-Apps aufgerufen werden. Nach dem Start wird lediglich der Splash-Screen angezeigt, danach landete man wieder auf der Übersicht. Das früher gut funktionierende Motto „Installieren wir das Update nochmal drüber“ fällt leider flach, da MS diese nicht mehr Separat anbietet sondern – aus Gründen der Usability – nur im Store bereit stellt. Klasse, denn a) Er lässt sich nicht mehr öffnen und b) Da das Update ja schon da ist ließe es sich vermutlich nicht mehr auswählen.

Die Lösung war nach einigem Hin und Her nicht wirklich auszumachen, zumeist dürfte es aber an Registry- oder Datei-Fehlern oder zu langer Ladezeit liegen. Gegen letzteres hilft es üblicherweise zu prüfen, ob die aktuellsten SATA/AHCI und Grafikkartentreiber installiert sind. Auch Virenscanner sind häufig nur notdürftig auf Windows 8.1 portiert worden und führen häufig zu einem solchen Verhalten. Gegen Systemfehler stellt Microsoft ein Tool namens „AppsDiagnostic.diagcab“ zu Verfügung, welches Registry & Dateien prüft und automatisch korrigiert.

Wie immer sollte man natürlich vor allen Änderungen ein Backup machen. In meinem Fall konnte ich alle betroffenen Rechner wieder mit Kacheln bestücken und die Update-Orgie in Gang setzen.

wget 1.14 & Perl 5.18.x: Expected text after =item, not a number

Beim Kompilieren eines OpenWRT machte eben wget-ssl dicke Backen: „Expected text after =item, not a number“ im Dokumentationsordner ließ die letzte Meldung verlauten. Grund sind striktere Syntaxchecks in Perl ab Version 5.18. Im Wget-Upstream ist das Problem bereits erledigt (0102e0e7e503c4fcd70a14eba4ffe357c84de3bb), für 1.14 gibts einen passenden Patch von Javier Vasquez, bei OpenWRT schwirrt auch etwas passendes von Jonathan McCrohan herum, hat es aber noch nicht in den Trunk geschafft.

Wer dem ganzen Problem ausweichen möchte: Seit Januar ist wget 1.15 verfügbar, hierzu einfach in feeds/packages/net/wget/Makefile folgende Änderungen vornehmen:


11c11
< PKG_VERSION:=1.14 --- > PKG_VERSION:=1.15
16c16
< PKG_MD5SUM:=316f6f59292c9098ad81fd54f658c579 --- > PKG_MD5SUM:=7a279d5ac5594919124d5526e7143e28

Linux: Single-Thread-Programme auf Multicore-Rechnern parallelisieren

*Auf Uhr tipp* Dauert mal wieder lange, das berechnen – kein Wunder, denn die Software, welche ich hier einsetze, kann nur einen einzigen CPU-Kern nutzen. Wäre doch schön, wenn man so Aufgaben beschleunigen kann, oder?

In meinem Fall heißt die „Bremse“ Tesseract, ein open source OCR-System um eingescannte Dokumente in Text zu verwandeln. Bisher fütterte ich jede Seite nacheinander an das Programm um im Anschluss eine zusammengesetzte PDF zu generieren. Eine einfache Beschleunigungslösung wäre es mehrere Seiten parallel zu starten, aber dazu ist einiges an Logik notwendig – ich möchte nur bis zu einer maximalen Anzahl an parallelen Prozessen haben (CPU-Kerne) und benötige die Info wann alle Prozesse fertig sind. Viel Scripting für ein bisschen Geschwindigkeit – und unnötig, denn es gibt ein Passendes Tool: GNU parallel von O. Tange aus „;login: The USENIX Magazine, February 2011:42-47„.

Das Tool ist unter Arch nicht vorinstalliert, findet sich aber im Community-Repo. Der Aufruf ist ähnlich zu xargs – in meinem Fall sieht der Befehl so aus:

parallel -j 8 \
tesseract {} {.}.hocr -l deu hocr \
::: ${files}

In der ersten Zeile wird bestimmt, dass maximal 8 Prozesse zugleich gestartet werden. Danach kommt der Aufruf der Software. {} wird durch den Dateinamen ersetzt, {.} durch den Dateinamen ohne Endung. In der dritten Zeile wird nach dem Trennzeichen (:::) die Dateiliste mitgegeben – in meinem Fall in einer Variable, es kann aber auch direkt per Globbing gearbeitet werden („::: /tmp/out*“).

Der Grundprozess parallel blockt dabei so lange, bis alle Unterprozesse beendet sind – perfekt für meine Anforderung. Durch diese kleine Änderung ist bei mehrseitigen Dokumenten die Verarbeitung um ein vielfaches schneller.

Das Tool ist dabei natürlich nicht auf OCR beschränkt, auch bei anderen Programmen, welche man auf mehrere oder aufteilbare Quellen loslässt, kann es verwendet werden. Ein gutes Beispiel wäre das Umwandeln von Bildern in einer Batch:

parallel -j 8 \
convert {} {.}.png \
::: ./*.bmp

OpenVPN: Kein automatischer Restart nach Verbindungsabbruch

Kurze Verbindungsunterbrechung und weg war er, mein VPN-Tunnel. Soweit nichts besonderes, aber eigentlich sollte OpenVPN die Verbindung automatisch neu aufbauen. In der Praxis funktionierte das Ganze bei mir leider nicht, der Tunnel verschwand einfach, der zugehörige Prozess war nicht mehr auffindbar. Im Log zeigte sich folgendes:

[…server…] Inactivity timeout (--ping-restart), restarting
TCP/UDP: Closing socket
/etc/openvpn/down.sh tap0 1500 1576 …ip… 255.255.255.0 restart
WARNING: Failed running command (--up/--down): could not execute external program
Exiting due to fatal error
/bin/route del -net …gateway… netmask 255.255.255.255
ERROR: Linux route delete command failed: could not execute external program
/bin/route del -net 0.0.0.0 netmask 128.0.0.0
ERROR: Linux route delete command failed: could not execute external program
/bin/route del -net 128.0.0.0 netmask 128.0.0.0
ERROR: Linux route delete command failed: could not execute external program
/etc/openvpn/down.sh tap0 1500 1576 …ip… 255.255.255.0 init
WARNING: Failed running command (--up/--down): could not execute external program
Exiting due to fatal error

Nach kurzem Nachdenken klare Sache: OpenVPN gibt bei Angabe von user/group in der Config nach der initialen Verbindung seine Root-Rechte auf und läuft im spezifizierten Userkontext weiter – und der darf nicht an den Routingtabellen oder Netzwerkgeräten herumfummeln. Die Lösung: Der OpenVPN-User muss rechte zum setzen von Routen behalten oder OpenVPN unter einem höher privilegiertem User laufen.

Scanner-Button unter Arch Linux

Gesehen habe ich sie schon oft, die Hardware-„Scan“-Tasten diverser Scanner – einen wirklichen Sinn haben sie für mich nie ergeben, sind doch üblicherweise Scanner und Tastatur nicht sonderlich weit voneinander entfernt. Nun habe ich für ein autonomes Scansystem einen Raspi ohne Monitor mit Scanner und Scripten verknüpft – wäre praktisch, wenn ich mir jetzt noch die Scan-Taste nutzbar machen könnte, oder?

Das Zauberwort schien erst „scanbuttond“ zu lauten, welches für Arch im AUR verfügbar ist – andere Distributionen scheinen ebenfalls großteils Pakete bereit zu stellen. Nach der Installation kann man mit dem Befehl

scanbuttond -f

prüfen, ob der Scanner unterstützt wird: Das Programm startet kommentarlos im Vordergrund, sollte beim Drücken des Scan-Knopfes jedoch eine passende Meldung erzeugen. Sollte – in meinem Falle leider nicht. Auslöser ist vermutlich die neuere libusb, welche scanbuttond das Gerät nicht finden lässt.

Nach kurzer Recherche fand ich im Arch-Forum den Verweis auf scanbd – ebenfalls im AUR – welches noch aktiv entwickelt zu werden scheint. Die Einrichtung selbst ist in der Arch-Wiki beschrieben. In der Hoffnung dass mein Gerät sofort funktioniert wird der Daemon mit folgendem Befehl gestartet:

scanbd -d 7 -f

Die Ausgaben sind etwas chaotisch, jedoch ist definitiv mein Scannermodell zu erkennen und auch beim Drücken der Scan-Taste ist etwas passendes zu sehen:

scanbd: trigger action for scan for device fujitsu:fi-4120Cdj:13715 with script test.script
[…]
scanbd: append string fujitsu:fi-4120Cdj:13715 to signal scan_begin
scanbd: now sending signal scan_begin
[…]

Entsprechend der Anleitung werden die Dateien kopiert (cp /etc/sane.d/* /etc/scanbd/sane.d/), in /etc/sane.d/dll.conf alles bis auf „net“ gelöscht und in /etc/sane.d/net.conf der Server „localhost“ aktiviert. In /etc/scanbd/sane.d/dll.conf wiederum wird „net“ gelöscht.

Der Scan-Button ist bereits mit /etc/scanbd/test.script vorbelegt, der Einfachheit halber habe ich nur den Inhalt der Datei durch meine Befehle ersetzt. Es wäre auch möglich die zahlreichen Zusatztasten meines Scanners zu nutzen um so bereits einen Speicherort o.Ä. zu definieren oder z.B. den Scan bereits beim einlegen des Papiers zu starten, aber ich belasse es erst mal beim Standard. Unter Arch sollte man nach der Konfiguration noch das Debuglevel in /etc/scanbd/scanbd.conf senken, ansonsten wird das Systemlog durch die sekündlichen Prüfroutinen gut gefüllt.

Dank der kleinen Bastellösung kann ich nun „ohne PC“ scannen – Papier rein, Knopf drücken und der Raspi übernimmt automatisch das einscannen, OCR und archivieren mit (zumindest meistens) brauchbaren Metadaten – der Feinschliff kann dann später am PC erfolgen.

PHP mail(): Sonderzeichen im Betreff richtig Codieren

Na das ist mir noch nie aufgefallen: Offenbar ist die mail()-Funktion von PHP nicht in der Lage deutsche Sonderzeichen im Betreff korrekt zu verarbeiten. Die erste Meldung besagte, dass der Betreff bei einigen Providern verstümmelt ankommen würde. Der IT-Fluch schlug natürlich wieder zu: Sowohl mein Thunderbird als auch K9-Mail und Roundcude zeigten keinen Fehler. Dankenswerterweise brachte dann Amavis die Erleuchtung:

X-Amavis-Alert: BAD HEADER SECTION, Non-encoded 8-bit data (char C3 hex):
Subject: Testm\303\203\302\244il

Argument, so passt das nicht… In den Mailheadern ist das genünschte „ä“ einfach nur als UTF-8-„ä“ vorhanden – E-Mails sind aber üblicherweise nur 7 Bit… Um den Betreff korrekt zu versenden muss man den String vorab mit mb_mime_mimeheader in die richtige Form bringen:

mail('empfang@emfang.em', mb_encode_mimeheader('Testmäil', 'UTF-8', 'Q'), 'Text');

Gentoo-Upgrade: XML::Parser perl module is required for intltool

Uff… Updates schleifen lassen ist bei Rolling-Release-Distros ja immer ein Problem. Heute im Angebot: Das Gentoo-Upgrade eines Systems, welches etwa 4 Monate stand, verabschiedet sich bei nahezu allen Paketen mit folgender Meldung während „configure“:

XML::Parser perl module is required for intltool

Eine Neuinstallation von Perl und dem genannten XML-Modul brachte keine Besserung, auch unter @preserved… oder revdep-rebuild zeigte sich nichts passendes. Die Lösung ist einfacher als befürchtet: Der Befehl

perl-cleaner --reallyall

sucht alle betroffenen Pakete, welche noch Verweise auf ein altes Perl enthalten, und baut sie über portage neu. Bei mir kam es noch zu einer Kollision durch veraltete glib und qt-Pakete, da der emerge-Befehl aber bereits fertig zum kopieren bereitstand war die nötige Ergänzung kein wirkliches Problem – knapp 190 Pakete später funktioniert’s dann auch wieder mit dem Update.