/blog/wvk

Nachdem ich vor nunmehr einigen Monaten irgendwie das RAID meines Arbeitsrechners leicht angeschossen habe, habe ich heute wieder einmal einen Reparaturversuch gestartet. Diesmal kam auf Grund von Plänen, nächste Woche zwei 1TB-Platten einzubauen, die Idee hinzu, den ganzen Plattenzoo mit LVM zusammenzufassen. Herausgekommen ist nach dieser Anleitung: http://www.howtoforge.com/linux_lvm sowie etwas eigenem Hirnschmalz folgendes Setup, welches alle wesentlichen Anforderungen erfüllt:

• Datensicherheit (safety) durch Spiegelung auf je 2 identischen Platten
• Flexiblität in der Erweiterung des Speichers durch logische statt physikalische Volumes
• Datensicherheit (security) durch Verschlüsselung der logischen Volumes

Schon erstaunlich, wie man um der Flexiblität Willen erst einmal seine Platten in Partitionen zerteilt, um diese sogleich zu RAID-devides zusammenfasst, um diese dann wiederum zu logischen Volume Groups zusammenzufassen, die wiederum in einzelne Logical Volumes unterteilt werden -- dafür aber von der Einheit "Festplattenkapazität" unabhängig sind. Was im Mainframe-Bereich schon seit Jahr und Tag üblich ist, findet also endlich im eigenen Arbeitszimmer Einzug ;)

Wenn als nächste Woche die neuen Platten kommen, dann werden diese einfach dem einen oder anderen Logical Volume angehängt und es brauchen keine Daten umkopiert werden. Und ja, das ganze scheint bislang mit verschlüsseltem FS hervorragend zu funktionieren. Dafür, dass es unter Linux noch keinen vernünftigen ZFS-Support gibt, halte ich dieses Setup für optimal.

Nachtrag: Die beiden neuen Platten sind eingebaut. mit diesen Befehlen klappte sodann auch das Erweitern der LV's inklusive der verschlüsselten Dateisysteme einwandfrei:

~# cfdisk [erstelle je eine 1TB-Partition auf sdc und sdd]
~# mdadm --create -l1 -n2 /dev/sdc1 /dev/sdd1
~# pvcreate /dev/md3
~# vgextend data /dev/md3
~# lvextend -L+1T /dev/data/ftp
~# e2fsck -f /dev/mapper/data-ftp_crypt
~# resize2fs /dev/mapper/data-ftp_crypt

Ein nochmaliger Aufruf von e2fsck bezeugte, dass das Dateisystem weiterhin gesund und munter ist :)

Seit einiger Zeit suche ich nach einer Lösung, um meine ganzen Quittungen, Rechnungen und amtlichen Dokumente elektronisch zu archivieren. Ich weiß, dass es dafür unter MacOS das eine oder andere hervorragende System gibt, aber unter Linux sieht es da ziemlich mau aus.

Das Archivieren von Dokumenten sieht nach meiner Vorstellung so aus:

• einscannen des Dokuments mit einem normalen Flachbettscanner @ 300dpi
• automatisches Konvertieren des Bildes mittels ImageMagics convert-Kommando: normalisieren des Kontrastes, entfernen von Staub und Rauschen, speichern als monochrom-Bild
• automatisches Erkennen der Zeichen (OCR) und Speicherung als Plaintext, zusammen mit dem bild für spätere Volltextsuche
• Das ganze liegt irgendwo über ein Webinterface erreichbar in einer MySQL-Datenbank.

Der erste Schritt ist der zeitaufwändigste, da das Scannen leider nicht gerade schnell von Statten geht. Der Rest soll automatisch und ohne mein Zutun geschehen, wenn ich ein Bild über besagtes Webinterface hochlade. Insbesondere die Texterkenung ist dabei aber leider ein kleines Sorgenkind, wie die folgenden Beispiele zeigen.

Getestete OCR-Programme

Die Programme testete ich mit (unter anderem) volgendem Bild (Ausschnitt):

Nach der Konvertierung mit convert kscan_0026.png -crop 2450x3450+20+20 -unsharp 8 -normalize -monochrome ocr.tif sah selbiges so aus:

Und nun zu den Programmen:

gOCR: einfach zu bedienen, relativ flott, kommt mit so ziemlich allen Bitmapformaten zurecht.

$ gocr ocr.png

<auszug>
  Erlauterungen
  Untertttzun9sle1stungen der E7tern s1nd nict einkommensteuerpflchtig.


  S1e  aen  Ihre E1nkommensteuererlrung auf nǐchtamtl1chem Vorruck oder auf elektron1schem ege
  agegeen.  Aus  Ko5tengründen  werden  wir  zukünft1g aur de Versendung von amtl1chen Vordrucken
  verz1chten.
</auszug>

Das sieht nicht ganz übel aus, aber die Fehlerrate ist für einen so einfachen Text (im Sinne von Zeichen- und Schriftenvielfalt) eigentlich inakzeptabel. Zusammen mit einem Wörterbuch könnte man hier sicherlich noch mehr herausholen, aber leider unterstützt gOCR das nicht. Das Programm erkennt jedoch Seitenlayoute ohne Fließtext relativ gut, wie sich an einigen Formularen zeigte.

OCRAD: bietet etwas umfangreichere Kommandozeilenargumente. Bei nicht-englischen Texte empfiehlt es sich, den Ausgabe-Zeichensatz auf utf8 zu setzen. Außerdem verfügt OCRAD über die Möglichkeit, "Layouterkennung" in drei Stufen einzustellen. Dabei werden die erkannten Fließtextblöcke nacheinander ausgegeben und nicht, wie in gOCR, unter Beibehaltung des ursprünglichen Layouts.

$ ocrad --format=utf8 --layout=2 ocr.pbm

<auszug>
  Er | autarung_n
  Unterstützung5lelstungen der Eltern s1nd nlcht elnkommen5teuerpfllchtlg.

  Sle haben Inre Elnkommen5teuererklárung avf nichtamtllcnem vordruck oder auf elektronlschem wege
  abgegeben . Au5 Ko5tengründen werden wlr zukünrt1g auf d1e ver5endung von amtl1chen Vordrucken
  verz1c_ten.
</auszug>

Nunja -- nicht bedeutend besser. Ein paar zusätzliche Wörter werden korrekt erkannt, aber die Fehlerrate ist nicht bedeutend geringer. Manche Ausgaben erinneren wirklich an 1337-5p34k ;).

Tesseract-OCR: Diese Software wurde Ende der 1980er von HP entwickelt und ist mittlerweile Open Source. Die Software soll zu den Top-OCR-Programmen gehört haben. Sie verfügt über sprachspezifische Bibliotheken, die auch selbst erstellt werden können. Die Verarbeitung dauert etwas länger als mit den o.g. Programmen und funktioniert auch nur mit TIFF-Dateien, aber das Resultat spricht für sich:

$ tesseract ocr.tif out -l deu

<auszug>
  Erläuterungen
  Unterstützungsleistungen der Eltern sind nicht einkommensteuerpflichtig.
  Sie haben Ihre Einkommensteuererklärung auf nichtamtlichem Vordruck oder auf elektronischem Wege
  abgegeben. Aus Kostengründen werden wir zukünftig auf die Versendung von amtlichen Vordrucken
  verzichten.
</auszug>

WOW sag ich nur! Der kontrollbereich ist komplett fehlerfrei; auch der Rest des Textes weist nur hier und da Unstimmigkeiten auf. Es sieht also so aus, als würde diese Software meine Wünsche erfüllen ;-)

Leider sieht es noch nicht danach aus, als würde Tesseract Layouterkennung unterstützen, was allerdings für den gewünschten Zewck, nämlich Volltextsuche in der Datenbank, völlig unerheblich ist.

Heute installierte ich die neueste Version von MyTether (http://mytether.net/) auf dem Palm Pre und siehe da, diesmal funktioniert die Anwendung wie sie soll. Nun sitze ich im RE4 von Düsseldorf nach Witten und habe endlich vernünftigen Internetzugang auf dem Notebook über das Pre -- Wahlweise via USB oder WiFi, bevorzugt natürlich ersteres.

Die Installation ist beliebig einfach:

quantino:~# novaterm
quarkino:/# wget -qO- http://mytether.net/install.php | /bin/sh

Um Tethering über USB zu verwenden, muss USBnet aktiviert sein. MyTether kann dies über einen Schiebeschalter, aber wenn man schonmal auf der Konsole ist, kann man das auch gleich dort erledigen:

quarkino / # usbnet enable
Usbnet will be enabled after reboot. Type "reboot" now.
quarkino / # reboot

Und lossurfen!

...oder Apache nicht auf localhost horchen möchte... ...oder Ejabberd sich nicht nach localhost connecten mag... ...oder Dienst XYZ nicht auf localhost ... will...

dann schau mal nach ob das loopback-device überhaupt "up" ist!

und wenn nicht: ifup lo

und dann mal nachsehen ob in /etc/network/interfaces vielleicht aus Versehen die Zeile mit auto lo auskommentiert ist.

Notitz an mich selbst: Netzwerkdienste setzen eine korrekte Netzwerkkonfiguration voraus. Wer diese Einstellungen zuerst überprüft, erspart sich womöglich einen Arbeitstag mit sinnloser Frustration.