Dokumentenverwaltung mit ecodms

Daheim habe ich ja schon seit fast 10 Jahren ein papierloses Büro: alle reinkommende Post wird gescannt und digital weiterverarbeitet. Bisher habe ich es mir einfach gemacht und die gescannten Dokumente in einen grossen Ordner geworfen und mich beim Suchen auf Tools wie grep verlassen. Nun ist mir von Bekannten ecodsm als komfortable Alternative für den Hausgebrauch empfohlen worden. Für den Privatanwender kostenlos bringt es neben der obligaten Verschlagwortung auch eine Volltextsuche mit.

Installation und Inbetriebnahme gestalten sich einfach, es gibt ein gutes Handbuch. Das System arbeitet zweistufig: alle neuen Dokumente landen erstmal in einer Inbox, koennen dort verschlagwortet und dann archiviert werden. Ich habe ungefähr 3500 Dokumente, die will ich nicht alle einzeln einlesen. Dafür gibt es Templates: man definiert, welche Eigenschaften wie enthaltenen Text ein Dokument hat, wie es dann verschlagwortet werden soll und schon kann so ein Dokument automatisch archiviert werden. Für den initialen Load habe ich mir also so eine Art wildcard Template angelegt: egal welcher Text, es soll archiviert werden. Ein paar Tests funktionieren, also werfe ich dem ecodsm mal meine gesamten Datenbestand vor die Füsse.

Dass dauert dann doch eine ganze Weile. ecodsm macht selber eine ocr, dass kann schonmal eine gute halbe Stunde pro Dokument dauern. Wie weit er mit dem Import ist, erfährt der Anwender nicht. Irgendwann ist er dann wohl durch und ich bin erstaunt: gut 600 Dokumente sind in der Inbox hängen geblieben. Warum die nicht per Template automatisch archiviert worden sind, sagt ecodsm nicht. Noch spannender wird es, wenn man sich die archivierten Dokumente anschaut: eine Funktion zum zählen habe ich nicht gefunden, aber ecodsm vergibt fortlaufende Nummern und die höchste, die ich finden kann, liegt bei knapp 2500. Satte 1000 Dokumente sind einfach verschwunden. Fehlermeldungen sind keine zu finden. Da ecodms auch keine Duplikate erkennt, verzichte ich auf Wiederholung des Imports.

Die ocr von ecodms basiert auf tesseract. Das hatte ich zum letzten Mal Mitte letzten Jahres getestet, und verworfen. Die Qualität der Ergebnisse war alles andere als überzeugend. Wie macht sich Tesseract mit ecodms? Nicht viel besser, ein paar Volltextsuchen liefern magere Ergebnisse. Das ist vor allem schmerzhaft, da die importierten pdfs schon beim Scannen einer ocr unterzogen worden waren, mit deutlich besseren Ergebnissen.

Also in der Disziplin “Importieren von Altdaten” hat mich ecodms bis jetzt nicht überzeugt. Mal schauen, wie es sich dann im Alltag schlägt. Eine Chance will ihm noch geben.

Shuttle

Das wandboard hat leider nicht lange durchgehalten: schon gegen Ende des Sommers machte es durch ein leises Summen auf sich aufmerksam (ein Geraeusch, das man von einem luefterlosen Geraet einfach nicht hoeren moechte), dazu kamen in immer kuerzeren Abstaenden spontane Reboots. Nachdem die durchschnittliche Uptime auf unter 2 Stunden gefallen war, habe ich mich also nach Ersatz umgeschaut. Nach den Erfahrungen mit ARM-Geraeten (Hardware nur teilweise unterstuetzt, abenteuerliche cross-compile-Arien mit zweifelhaften Resultaten usw.) bin ich wieder heimgekehrt ins Reich der x86 und habe mich fuer einen Shuttle entschieden: luefterlos, fuer 24/7 freigegeben. Mit einer SSD und 4GB RAM braucht er bei mir im Mittel ca. 6 Watt, wobei der Verbrauch bei Vollast bis etwa 11 Watt hochgeht. Der uebliche Benchmark:

mathias@shuttle:~$ time echo "scale=5000; a(1)*4" | bc -l > /dev/null
real 0m42.464s

Also gut 3mal so schnell wie das wandboard, bei ca. doppelten Stromverbrauch – fairer deal.

Der Umzug von dns/dhcp war etwas schwieriger, mittlerweile legt Ubuntu einem da so einige Steine in den Weg (muss ja mit NetworkManager, resolvconfd, dnsmasq usw. alles schoen automatisch gehen – wehe dem, der da manuell eingreifen will.)

Nach der Huerde waren owncloud, dovecat, getmail, tiny-rss, munin, sslh und apache dann recht pflegeleicht.

Die Datenhalde sollte eigentlich auf ein NAS (im Moment ein Synology DS214) – das spielt aber nicht so richtig mit: urspruenglich sollte es per iscsi angebunden werden, damit dort ein luks-Volume drauf kann, welches per samba exportiert wird. Bei iscsi geht das NAS aber nie in den suspend – was ein Spielverderber. Also ein normales Volume draufgelegt, mit einer Container-Datei gefuellt, die als loopback gemountet und dort das luks drauf: durch die Brust ins Auge. Nicht schoen, funktioniert aber.

Ein klein wenig Aerger bereitete dann noch ein Ubuntu-Update, nach dessen Einspielenn der Rechner alle naselang einfach runterfuhr. Den logs war nur zu entnehmen, dass der systemd per dbus die Anweisung genau dazu bekommen hat. Auch hier wieder: wehe dem, der da Fehler suchen muss. Irgendwann war dann der lightdm enttarnt: nach dem update crashed der haeufiger, und upstart interpretiert das Ende des lightdm als Signal, den Rechner runterzufahren. Offenbar ist es in der Linux-Welt mittlerweile recht ungewoehnlich, dass sich mehrere Leute auf einem Rechner anmelden oder ein Rechner neben dem gui noch andere Dienste anbietet.

Das Backup macht jetzt auch der shuttle: ein kleines Script schaut sich die blkid angeschlossener Platten an, wenn es eine als Backup-Platte erkennt, mountet er die und start das Backup (per rsnapshot). Einfach USB-Platte anschliessen, Script per screen starten und laufen lassen.

Bequemlichkeiten

Remote steuern konnte ich mein ganzes Geraffel schon immer. Im Zweifel per ssh übers wandboard, der ghost wird per wake on lan gestartet, andere Geräte über die Schalt-Steckdose per sispmctl. Aus irgendwelchen Gründen, gefiel das aber nicht jedem (genauer: jeder). Also habe ich mich mal aufgerafft, das Ganze zu verschönern:

device-2014-05-29-191224Ein bisschen jQuery-Mobile, ein wenig Javascript, html, fast gar kein css und etwas cgi für dieses Ajax-Zeug ergeben das Bild (vom Nexus7). Ein Click auf die plug-Buttons toggelt deren Zustand, das Datum der nächsten Aufnahme kommt ja vom vdr selber, für den Stromverbrauch habe ich mir eine FritzDect gegönnt. Die hängt noch vor der USV – das ist also der Stromverbrauch von FritzBox, USV, Nas im Ruhezustand, ghost schlafend, einem Switch, der Schalt-Steckdose selber und dem wandboard. Die Anzeige aktualisiert sich alle 30sec.

Ganz komfortabel die Actions auf der 2. Seite:

device-2014-05-29-191240

Diese Links werden in Abhängigkeit der States erzeugt, läuft der vdr steht dort also: “stop vdr”. Dahinter liegen Skripte die ganau dies tun, wobei sie sich auch die Umgebung anschauen. Z.b. prüft startVdr.sh ob switch und nas auch laufen und schaltet sie bei Bedarf ebenfalls ein. (Eventuell baue ich später nochmal etwas, um diese Geräte auszuschalten, wenn sie nicht benutzt werden – dann wird das mal wichtig.)

Seite 3 sind die Links die man so braucht:

device-2014-05-29-191257

Hier fehlt noch einiges (owncloud z.B.).

Und schliesslich auf Seite 4 dann wieder ein paar Infos für mich:

device-2014-05-29-191316

Genau die syslogs. Die Geräte loggen übrigens alle remote auf das wandboard – das macht das Einsammeln der Infos bei Problemen deutlich einfacher.

Ich muss gestehen, so macht das auch irgendwie Spass. Auch wenn es den spröden Charme eine Text-Konsole natürlich nicht annähernd ersetzen kann.